Title: ADS - Missing Requirement for ADS-demand-contract response PDR Reference: 99070003 Originator Reference: - SARPs Document Reference: ADS SARPs, Status: ADOPTED Impact: C (Clarification) PDR Revision Date: 30/01/02 (RESOLVED -> ADOPTED) 26/08/00 (FORWARDED -> RESOLVED) 22/11/99 (ACCEPTED -> FORWARDED) 26/07/99 (SUBMITTED -> ACCEPTED) PDR Submission Date: 24/06/99 Submitting State/Organization: RTCA SC-189 / EUROCAE 53 Submitting Author Name: Lelievre, T Submitting Author E-mail Address: Submitting Author Supplemental: Contact Information: SARPs Date: Document 9705 Edition 2 SARPs Language: English Summary of Defect: There is no recommendation on what the ADS-air-user shall do when it receives an ADS-demand-contract indication but is not able to send the response within 0.5 seconds. Actually, the ADS SARPs are not aligned with the ADSP ORs. Whatever the contract type is, the aircraft should be allowed to send to the ground a positive acknowledgement to indicate that it accepts the contract but it is not able to send immediately the ADS report. This is applicable to the ADS-demand contract as well. The ADS SARPs do not allow the aircraft to send a positive ack upon receipt of an ADS-demand-contract indication. Assigned SME: Sub-Volume II SME Proposed SARPs amendment: SME Recommendation to CCB: FORWARDED The ADS SARPs do not allow the aircraft to send a positive ack upon receipt of an ADS-demand-contract indication, for the following reasons provided by the ADS editor: ******************************************************************************** Originally - in the early versions of the draft ADS SARPs - the ADS demand contract had the following three valid sequences that the aircraft could make in response: 1. ACK, ADS-report 2. NCN, ADS-report 3. NACK During the development of the SARPs, the ADS manual was also updated and changed on a regular basis. Because of this, in the early stages it was often difficult to track the changes in the Manual into the draft SARPs. In the earlier versions of the Manual there were statements that were clearly technical in nature, and had no operational content. It was sometimes difficult for the working group to determine what was the real operational intent behind the technical statements. (These technical statements were mostly removed in later versions of the Manual.) One solution to the problems of tracking the Manual was to ensure that there were members of the ADSP who attended the working group on a regular basis. Where confusion arose about the meaning of the Manual within the working group, the ADSP members were consulted for clarification. This became the normal way of working within the group. At one meeting of the working group (I don't remember which) there was a discussion about the meaning of the Manual with regard to the ADS demand contract. It was not clear and the discussion went on for some time. The working group agreed on the current structure of the ADS demand report based on a very clear statement from one of the ADSP members present. The statement is how I have always understood the requirement, and how I have presented the ADS demand contract at all meetings since then. I also summarised it in the ADS guidance material (now the CAMAL) - using almost exactly the same words that were stated in that meeting: "Note that, unlike event and periodic contracts, demand contracts do no permit the aircraft to return a positive ack, followed by an ADS report some time later. The reason for this is as follows: it is anticipated that normal operation will use event and/or periodic contracts. The use for demand contract is, therefore, expected to be for cases when the controller needs an immediate response to a query outside the normal surveillance operation. The requirement is that the information is required as soon as possible. The aircraft can use the positive ack as a form of delay, and this is therefore prohibited in a demand contract". From that point on, the working group never had a discussion on the basic structure of the ADS demand contract. However, it was repeatedly reported directly or indirectly at many meetings since then. It is my opinion that, at the time, "normal operation" was widely considered to be a periodic contract or an event contract either or both of which would be used to ensure that the aircraft was flying according to the flight plan. I also recall discussions from that time that implied that the purpose of the demand contract was for use when the aircraft appeared not to be flying by the flight plan and the controller wanted to know what was happening immediately. This may have been the view that was presented when the above decision was made - I cannot recall. Clearly, the common view of what "normal operation" is has either changed or was misrepresented to me and the working group all those years ago. Since then there appears to have been a breakdown in communication. The structure of the demand contract has been presented on many occasions by myself, and possibly others at many public occasions. Likewise the Manual has become much more stable and available to the working group. There have been opportunities on all sides to spot this issue for some time. It has apparently only surfaced now. So that is where we have come from. I do not want to either place or avoid blame - only to comment on my memory of the background. Now, what to do about it... If the ADS demand contract is re-engineered to include the ACK - this would be a significant change to the SARPs. It would require a change to the ASN.1, changes to the protocol machine definition, changes to the abstract service interface and changes to the user requirements. I stress that the changes are so significant that some level of re-validation would certainly be necessary. Although I am out of touch with the operational aspects of the demand contract, I would question whether inclusion of the ACK is operationally or practically an absolute requirement. We may achieve the same result with a much simpler solution. For example, if the value of the recommended reply time was increased or removed for the ADS contract, - would the result not be close enough to the operational requirement? Are there any other solutions? ******************************************************************************** Since the changes to the SARPs are too significant to be included in version 1 ADS (interoperability would not be guaranteed with earlier implementations), the current proposal is 1/ to progress the PDR to FORWARDED for inclusion of the pos ACK as acceptable demand contract response in version 2 of ADS. 3/ clarify in the CAMAL the current use of the ADS-demand-contract response by the aircraft, as follows: If the ADS-air-user can satisfy the demand contract in its entirety, then it sends an ADS-report as soon as possible. If the ADS-air-user cannot supply some of the optional information required in the demand contract, then it sends immediately (0.5 seconds is recommended) a noncompliance notification immediately, followed by an ADS report which supplies the information that it has available. This only applies if some of the optional information is unavailable. If the ADS-air-user cannot supply some of the mandatory information for an ADS-report, or cannot supply the required information within a reasonable space of time (for instance, the ARINC 702 standard recommends 35 seconds to retrieve the extended projected profile), then it will reply with a negative acknowledgement. CCB Decision: atnp_ccb_chair: 19/07/99 (SUBMITTED) CCB-10 (Gran Canary): ACCEPTED atnp_ccb_chair: 22/11/99 (FORWARDED) CCB-12 (Berlin): RESOLVED (26/08/00) CCB-12 decided to pass the FORWARDED PDRs to the status RESOLVED when the issue raised in the PDR for edition 1 or 2 is addressed and resolved in edition 3.