ADS-C Open Issues / Pending Tasks

1. ADS-C Open Issues / PendingTasks • To figure out the OR related to the FMS Integration (consistently with need statements in ATS Function Section) • To assess WG85 Feedback: • …. • EPP event details are inconsistent. • Are the event types supposed to be separate request types, or is the EPP event type an enumerated variable? • => style/editorial issue - leaf fields have to be identified as such • EPP event types are too numerous • Operational need for each event type needs to be validated, at least for the events that are difficult to implement in the avionics. (we may need to tell them which event types are difficult.) • => number of EPP events might be reduced in the light of validation feedback • Speed schedules (nominal, min/max) need definition of interpretation, since there are different possible interpretations of the details. • => Action MJ: to check the description of speed schedule is included in the 4DTRAD material for inclusion in final SPR • [Level] variable is just a number with no description of what altitude reference is used or should be used (baro, standard pressure, geometric, etc.). • => Not an issue specific to SC214 – Applicable to FANS also – No CSG action • Crossover altitude • Question about whether or not it is needed, since we now have speed schedule so the ground system could compute it. • If we do need it, needs to be at least 2 values, one for climb, one for descent, possibly step climbs or descents. • Also, should it be a vertical point type so we have the lat/lon and other EPP data for the point? (this would be difficult to provide for some avionics systems.) • Issue forwarded to 4DTRAD group (CSG Webex date TBD) – Define 2 values or delete the crossover level parameter • Transition level needs to be 2 values, one for climb, one for descent. • => Issue forwarded to 4DTRAD group (CSG Webex date TBD) – ok to define 2 values ? • Assumptions about content of EPP report • Speed changes – some implementations may include only next speed change, not all in trajectory. • We have more input to gather based on prototype implementations • Data in the reports that ground systems do not need • Data needed by the ground systems that are not in the reports.