PPRuNe Forums - View Single Post - ADS-B, ADS-C from the ATC point of view
View Single Post
Old 3rd Mar 2023, 11:57
  #3 (permalink)  
Roger That
 
Join Date: Mar 2000
Location: Scotland
Posts: 85
Likes: 0
Received 0 Likes on 0 Posts
Complex questions and I’m sure lots of folk on here will know much more technical detail, but here goes ….

1. Ads-B is ‘ATS Surveillance’ and each ATM surveillance system has ways to display aircraft ‘targets’ on the situation display. Frequently what’s displayed may comprise aggregated surveillance data from a number of sources and types (e.g. primary, SSR, Mode-S, ADS-B, and from many discreet sources) with the display symbols indicating quickly to the controller what types of data this being displayed to them. It’s often the case with surveillance ‘tracked’ systems that the actual source of the data is not immediately clear to the controller (though this can be interrogated by them within a few clicks), but it depends on complexity and type of operation being provided exactly what the controller is looking at (eg approach, Enroute etc.).
2. Downlinked Aircraft Parameters (DAPs) may be available for display by controllers but may not always be displayed (because of the rule set or controller preference). They are often used by the wider ATM system in the background, alerting controllers only when pre-programmed business rules are triggered (e.g. when your selected flight level differs from the cleared flight level within the ATM system). All of the ads-b message set is clearly defined within eurocae documentation and it also sets the values and tolerances that can be accepted for each parameter. The ATM safety case sets out what steps are taken to assure that only data with an acceptable providence is used, and also what the system does when this isn’t achieved. In my experience some very clever engineers rigorously analyse this data throughout the data lifecycle (ie before it’s commissioned and routinely whilst in operation) to assure the data is fit for purpose. This is part of the overall safety case and approvals approach. I don’t know what data is used or not, as my focus is often ‘what’s available, how can I use to improve safety, reduce controller workload, and improve the service quality provided to airlines’ - you’d need an engineer for that question.
3. Yes, these matter - a lot ! In some operational areas, the ads-c contract exchanges messages at log-on and also during routine reports to download the route as held in the FMS. It compares this route with what’s held in the ATM system and alerts the controller to a risk your aircraft may go ‘the wrong way’ and that is essential as the ATM system may have predicted possible conflicts based on the planned trajectory it’s holding. It can also cause controllers to question pilots about their routing and could cause some confusion in the air (eg ‘why am I being asked about my routing, surely they have my flight plan’ etc.). On coordinate inputs, ARINC424 sets out the short code use of coordinates and the standards that should be used. In some airspaces, often oceanic and continental offshore where intervention capability isn’t as timely as vhf, separation standards are predicated on flying to the right location, and contingency procedures and things like SLOP are predicated on a consistent use of ARINC424. With such standards being as small as 15nm, failure to correctly code your waypoint could put you many miles away and potentially head-on with someone else with a very large closing speed - that’s not a good look (!). Basically, this is airmanship (for woman and men - I can’t recall the right none-gendered term) 1-0-1, if you’ve standards to comply with, understand them, be competent to apply them, cross-check your work, and remember that others are relying on your doing that (and equally, you are relying on them too).

Like I say, others will know more than me, but that’s my 2c worth, offered with best intentions, and with the hope others can improve it with their knowledge and experience. RT
Roger That is offline