VDL2 Optional Parameters Review and Recommendations

vdl2 optional parameters n.w
1 / 14
Embed
Share

Review and recommendations for updating VDL2 optional parameters related to aircraft location, destination airport, and validation tests for avionics. Proposals for changes from optional to mandatory parameters in MASPS tables. Suggestions for test cases and clarifications on data validity criteria.

  • VDL2
  • Parameters
  • Aviation
  • MASPS
  • Test Cases

Uploaded on | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. VDL2 optional parameters Tom McGuffin 2022 Feb 2-4 1

  2. VDL2 Optional parameter I took an action item to clarify inclusion of optional parameters Aircraft Location and Destination Airport. VDL spread sheet items 47, 49 and 55. Also to add tests instead of relying on code inspection. I notice some other issues and expanded the scope a little Suggest changing tests of ground implementation to tests for avionics Should validation of data be more precise? Resolve definition of altitude value when aircraft is on ground Etc. MOPS review 2.4.5.5.2.5 Aircraft Initiated Private Parameters e.g. aircraft position. Current tests are inadequate and do not test the case when there is no valid data. I accepted an action item to draft test cases. I also accepted an action item to clarify data not valid which is expected to be a temporary condition and make it clear that aircraft position data et al is mandatory. Same for other parameters Spectralux Corporation 2

  3. MASPS Table 3-48b uplinks Aircraft Coverage and Nearest Airport ID parameters are shown as Optional in Table 3-48b for GIHO XID_CMD_ HO uplink AIHO XID_RSP_ HO uplink. Coverage and Nearest Airport ID parameters from Optional to Mandatory. Change note from 2 to 1. AND modify note 1 by deleting GSIF and use text similar to note 2: Where the Airport Coverage and Nearest Airport ID parameter are marked as mandatory, then either parameter shall be included in the XID frame, but not both. I suggest changing Aircraft Spectralux Corporation 3

  4. MASPS Table 3-48b downlinks Table 3-48b shows the Destination Airport and Aircraft Location parameters as optional in the GIHO XID_RSP_HO downlink. It seems to me that it would be beneficial to require both parameters in the GIHO XID_RSP_HO downlink? Therefore, I suggest making Destination Airport and Aircraft Location parameters mandatory for the GIHO XID_RSP_HO downlink and add note 3. Note 3 applies to Destination Airport and Aircraft Location parameters which are shown as mandatory in Tables 3-48a, b and c. The issue is that this is a CMU requirement and an aircraft installation requirement. MOPS can only test the CMU requirement. Current text: 3. Presence of this field is mandated only when valid data is available. In the absence of valid data, the parameter shall be omitted. Suggested revision to note 3: 3. Presence of this field is mandated only when valid data is available. A properly certified aircraft installation is should (shall?) provide valid data to the CMU. In the rare case when valid data is not available, such as equipment failure or broken wires, then the corresponding parameter shall be omitted. Spectralux Corporation 4

  5. Current MOPS section 2.4.5.5.2.5 2.4.5.5.2.5 Aircraft Initiated Private Parameters Procedure Test Case Name: Aircraft Initiated Information Private Parameters Purpose: Verify that the Aircraft Initiated Information Private parameters are encoded per ISO 8885 and DO-224D. This includes the following parameters Modulation Support Parameter Acceptable Alternate Ground Station Parameter Destination Airport Parameter Aircraft Location Parameter Reference: DO-224D, 3.2.2.5.2.5, 3.2.2.5.2.5.1 through 3.2.2.5.2.5.4 Tables 3-22 through 3-27 Comments: Encoding of Aircraft Initiated Information Parameters should be verified as part of the DO-178B software verification process (see Section 2.4.5.4) Spectralux Corporation 5

  6. Destination Airport parameter clarification Reference MASPS 3.2.2.5.2.5.3. Note that DO-224 seems to allow any IA5 character, not just valid values, for Destination Airport parameter. 1. Should the definition of valid Destination Airport data be stricter? E.g. KSEA is valid. 2. Should ksea be considered valid? 3. Should SEA be considered valid? 4. Should K,.A be considered valid? 5. Should there be a requirement to reset the parameter when valid data ceases or becomes invalid? Spectralux Corporation 6

  7. Proposed Destination Airport parameter test Proposed Destination Airport parameter test outline 1. Provide valid Destination Airport data to the CMU. Trigger XID CMD LE and XID CMD HO downlinks. Verify downlink XIDs contain the Destination Airport parameter and the data is correctly encoded. Repeat for several values? 2. Provide invalid Destination Airport data to the CMU.e..g. ksea , k a etc Trigger XID CMD LE and XID CMD HO downlinks. Verify downlink XIDs do NOT contain the Destination Airport parameter. Repeat for several values 3. Provide valid Destination Airport data to the CMU. Trigger XID CMD LE and XID CMD HO downlinks. Verify downlink XIDs contain the Destination Airport parameter and the data is correctly encoded. 4. Stop providing valid Destination Airport data to the CMU. Wait for data to clear. Trigger XID CMD LE and XID CMD HO downlinks. Verify that the XIDs do NOT contain the Destination Airport parameter. Spectralux Corporation 7

  8. Aircraft Location parameter Reference MASPS 3.2.2.5.2.5.4. Table 3-48a and 3-48b Note 3. Presence of this field is mandated only when valid data is available. In the absence of valid data, the parameter shallbe omitted. Aircraft location data consists of 3 subfields: latitude, longitude and altitude. The parameter should only be included when valid data is available for all three subfields. It s not clear whether Altitude should be barometric altitude or GPS altitude. It s not clear what value should be used for Altitude when the aircraft is on the ground? Should it be 0 or actual altitude on the airport? E.g. should an aircraft on the ground at DEN set altitude to 0 or 5,000 ft? FYI, Altitude resolution is 1000 ft. Spectralux Corporation 8

  9. Proposed Aircraft Location parameter test Proposed Aircraft Location parameter test outline 1. Provide valid Aircraft Location data to the CMU. Trigger XID CMD LE and XID CMD HO downlinks. Verify downlink XIDs contain the Aircraft Location parameter and the data is correctly encoded. Repeat for several values. 2. Change Aircraft Location data such that only longitude and altitude is provided. Latitude data should be missing or invalid, test both cases. Trigger XID CMD LE and XID CMD HO downlinks. Verify downlink XIDs do NOT contain the Aircraft Location parameter. 3. Change Aircraft Location data such that only latitude and altitude is provided. Longitude data should be missing or invalid, test both cases. Trigger XID CMD LE and XID CMD HO downlinks. Verify downlink XIDs do NOT contain the Aircraft Location parameter. 4. Change Aircraft Location data such that only longitude and latitude is provided. Altitude data should be missing or invalid, test both cases. Trigger XID CMD LE and XID CMD HO downlinks. Verify downlink XIDs do NOT contain the Aircraft Location parameter. Spectralux Corporation 9

  10. Other Aircraft Initiated Private Parameters Should Modulation Support and Acceptable Alternate Ground Station parameter tests be created? e.g. Proposed Modulation Support parameter test outline (MASPS 3.2.2.5.2.5.1). 1. Trigger XID_CMD_LE and XID_CMD_HO downlinks 2. Verify that the Modulation Support parameter in the downlink contains a valid value of either 0010 binary/hexadecimal 2 or 0110 binary/hexadecimal 6. Proposed Acceptable Alternate Ground Station parameter test outline (MASPS 3.2.2.5.2.5.2). 1. TBD Spectralux Corporation 10

  11. Other MOPS issue MOPS sections 2.4.5.5.2.6 and 2.4.5.5.2.7 seem to be testing whether the Ground station correctly encodes the parameters? Seems like the test should be whether the avionics decodes these parameters correctly and detects when the parameter is not encoded correctly? Spectralux Corporation 11

  12. MOPS 2.4.5.5.2.6 Test Case Name: Ground Initiated Modification Private Parameters Purpose: Verify that the Ground Initiated Modification parameters are encoded per ISO 8885 and DO-224D. This includes the following parameters Autotune Frequency Parameter Replacement Ground Station Timer T4 Parameter. MAC Persistence Parameter. Counter M1 Parameter. Timer TM2 Parameter. Timer TG5 Parameter. T3min Parameter. Ground Station Address Filter Parameter. Broadcast Connection Parameter. Reference: DO-224D, 3.2.2.5.2.6, 3.2.2.5.2.6.1 through 3.2.2.5.2.6.10, Tables 3-28 through 3-38 Comments: 1. Encoding of Ground Initiated Modification Parameter should be verified as part of the DO-178B software verification process (see Section 2.4.5.4) 2. Proper operation of several of these parameters (e.g. MAC Persistence, M1, TM2) is demonstrated by the tests in Section Error! Reference source not found. of this document. What about other parameters? 3. Avionics do not transmit these parameters, but must utilize them to control link operation. Spectralux Corporation 12

  13. Example Autotune Frequency Parameter test Outline of example test for Autotune Frequency Parameter 1. Establish VDL mode 2 connection 2. Uplink GRAIHO with Autotune Frequency Parameter value set to hexadecimal C64 and modulation subfield value set to 0010 binary. 3. Verify that avionics decoded frequency 131.725 and modulation VDL mode 2 and connected to new GS. 4. Repeat steps 1-3 with a few other values. 5. Uplink GRAIHO with valid frequency and invalid value of mode. E.g. mode value of 0001, 1000 or 1001 binary. 6. Verify that avionics rejected GRAIHO. 7. Uplink GRAIHO with valid mode value and invalid value of frequency. E.g. frequency subfield all zeros. 8. Verify that avionics rejected GRAIHO. Spectralux Corporation 13

  14. MOPS 2.4.5.5.2.7 Test Case Name: Ground Initiated Private Parameters Purpose: Verify that the Ground Initiated Private Parameters are encoded per ISO 8885 and DO-224D. This includes the following parameters 1. Frequency Support List Parameter 2. Airport Coverage Indication Parameter 3. Nearest Airport Parameter 4. ATN Router NETs Parameter 5. Ground Based System Mask Parameter 6. Timer TG3 Parameter 7. Timer TG4 Parameter 8. Ground Station Location Parameter Reference: DO-224D, 3.2.2.5.2.7, 3.2.2.5.2.7.1 through 3.2.2.5.2.7.8, Tables 3-39 through 3-48 Comments: 1. Encoding of Ground Initiated Private Parameters should be verified as part of the DO-178B software verification process (see Section 2.4.5.4) 2. Avionics do not transmit these parameters, but use them to control link operation. 3. Tests establishing ATN and AOA communications should verify the avionics properly handles the ATN Router Net parameter and how it is used for ATN and non-ATN communications initiation, as applicable to the equipment under test. What about other parameters? Spectralux Corporation 14

Related


More Related Content