Originally Posted by
gusting_45
Relying entirely on automation whether in the Flightdeck or in the controllers facility only moves the source of the failure.
All responsibility would now be on the shoulders of the software designers, developers and testers. It is an uncontradictible truth that all software is riddled with errors whether of logic or syntax. Even systems that appear to be working will one day encounter a deadly embrace of errors.
I know, I used to work in IT. No matter how talented the developers etc, they are no less prone to error than the users.
Automation is brilliant, it is a huge reliever of workload in the flightdeck and I dare say in the radar room. That is how we should view it and use it.
I for one, will always feel happier to know that responsibility for the safe conduct of my flight and it’s control is under positive management of a human and that the responsibility has not been offloaded on to someone who has no skin in the operation.
I think you misunderstand what the change to 'trajectory based' control really is.
Currently, as an aircraft approaches a sector the sector controller forms a mental 'sector transit plan' for the aircraft where there could be problems potential conflicts and the way that the aircraft will be handled. Usually, with aircraft on published routes the plan is simple and the potential conflicts occur in the same places most times. If there is a conflict then the aircraft is given 'vectors' or altitude/speed instructions. These are 'open' instructions so while the controller has a cognitive plan the flight crew just know to maintain FL### at speed ### on heading ### the controller then guides all the aircraft along their cognitive plans. Many times the default can be continue as cleared. But there is no planning of the downstream impact and the FMC which is engineered with the idea of flight efficiency has no role. There is no long term thinking as what happens in the next sector is 'that sector's problem'. Fixed routes also mean miles in trail so your aircraft efficient at M0.84 is now inefficiently flying 20 miles in trail behind someone at M0.75.
Trajectory based (business trajectory) control makes use of the capability to share the aircraft ideal 'business trajectory'. So now as the aircraft approaches the sector the planner controller can assess (with conflict detection and resolution software) whether there will be conflicts in the sector. If there are then the trajectory of the aircraft has 'constraints' added to it that will modify the trajectory to keep it conflict free. These are uplinked to the aircraft and the FMC generates a new trajectory that will now automatically implement the sector transit plan with the advantage that any downstream constraints in different sectors will also be honored. So now the planner controller has safely separated the aircraft before it enters the sector. The aircraft follows the trajectory through the sector and the surveillance/tactical controller is there to ensure compliance. This approach allows aircraft to fly their own business trajectories that do not need to follow published routes so they can fly at efficient speeds and levels.
A summary of SESAR concept of operations. NextGen is similar.
Note that there is no single point of failure in that concept.