PPRuNe Forums - View Single Post - Weiner's Laws
Thread: Weiner's Laws
View Single Post
Old 21st Jan 2019, 02:20
  #5 (permalink)  
Ian W
 
Join Date: Dec 2006
Location: Florida and wherever my laptop is
Posts: 1,350
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Not Long Now
Lots of difficult questions arise from his, and others work. Is it logical, for example, on a flight deck, to allocate the task of monitoring the aircraft systems' performance to a human, and then expect them to 'jump in' and resolve any issue that may occur, rather than have an automated system monitoring the human performance, and alerting when something is missed?
Being on the ground-based side of aviation, I am constantly reminded of this dichotomy when hearing of future plans for controllers to simply monitor flights, all of which are all following PRNAV routes knitted through the sky. The idea being, we would simply be a 'fall back', ready to jump in and resolve a situation which may have developed. Personally, I think my chances of being able to help if such a situation arose, having been diligently 'monitoring' the situation without intervention for perhaps a year or so, are close to zero.
Virtually all evidential testing seems to lean towards humans being rubbish at monitoring systems for perhaps initially minor unexpected changes, and automated systems being not much better at producing instant dynamic plans in reaction to unfamiliar scenarios, and yet that seems to be the path we have chosen to proceed along.
Fortunately, I will be retired before the controller task is reduced to such a state, and I'm sure systems will arrive that will do a grand job, for those 99.99% of the times when things are going swimmingly. I really don't fancy being the one to have to try to help when something does go wrong though.
The actual concept is not sit and watch, it is 'empowerment of the planner controller' (D-Side in NAS speak).

Instead of vectoring aircraft with the only idea of what is happening next in the controller's head. Aircraft trajectories are negotiated with the crew ahead of their entry into a sector then agreed and the automation then flies that trajectory. Effectively, automating what controllers call the 'sector transit plan'. The effect is that the tactical (radar/R-side) controller monitors the aircraft flight through the sector as it implements the trajectory agreed by the planner controller. This is actually the way controlling used to be with the planner controller using procedural control and the radar controller only being involved when procedural control had problems. Hence - empowering the planner controller - as trajectory based control is far more precise than procedural control and more efficient than radar vectoring.

There is a possibility that one aircraft may not follow the agreed trajectory, but that will be alerted to the controller by conformance monitoring software which will display the trajectory the aircraft should be following and often the vectors to put the aircraft back onto the trajectory. All this with backup from ACASx that will provide efficient avoidance based on aircraft capabilities should the controller/system not separate the aircraft.

The concerns on automation are understood but the systems are based on a different concept with long lookahead deconfliction - conflicts should be solved before the aircraft enters the sector. But controllers are still managing the aircraft it is just that they are doing so using trajectory management rather than control by vectoring changing speed, altitude and heading with open ended instructions.
Ian W is offline