Weiner's Laws
Thread Starter
Join Date: Nov 2004
Location: Here, there, and everywhere
Posts: 1,122
Likes: 0
Received 12 Likes
on
7 Posts
Weiner's Laws
As far back as 1980, renowned aviation human factors guru Earl Wiener was asking the question – Has automation gone too far? Wiener in the early 1980s began researching what happens when humans and computers attempt to coexist on a flight deck. In a 1980 paper he co-wrote with NASA’s Renwick Curry, “Flight-deck automation: promises and problems”, Wiener wrote, “It is highly questionable whether total system safety is always enhanced by allocating functions to automatic devices rather than human operators, and there is some reason to believe that flight-deck automation may have already passed its optimum point.” Compilations of scholarly papers by Wiener and his colleagues resulted in two key human factors books, one of which – Human Factors in Aviation – is still in publication today, albeit as a new edition with new editors.
WIENER’S LAWS
(Note: Nos. 1-16 intentionally left blank)
17. Every device creates its own opportunity for human error.
18. Exotic devices create exotic problems.
19. Digital devices tune out small errors while creating opportunities for large errors.
20. Complacency? Don’t worry about it.
21. In aviation, there is no problem so great or so complex that it cannot be blamed on the pilot.
22. There is no simple solution out there waiting to be discovered, so don’t waste your time searching for it.
23. Invention is the mother of necessity.
24. If at first you don’t succeed… try a new system or a different approach.
25. Some problems have no solution. If you encounter one of these, you can always convene a committee to revise some checklist.
26. In God we trust. Everything else must be brought into your scan.
27. It takes an airplane to bring out the worst in a pilot.
28. Any pilot who can be replaced by a computer should be.
29. Whenever you solve a problem you usually create one. You can only hope that the one you created is less critical than the one you eliminated.
30. You can never be too rich or too thin (Duchess of Windsor) or too careful what you put into a digital flight guidance system (Wiener).
31. Today’s nifty, voluntary system is tomorrow’s F.A.R.
WIENER’S LAWS
(Note: Nos. 1-16 intentionally left blank)
17. Every device creates its own opportunity for human error.
18. Exotic devices create exotic problems.
19. Digital devices tune out small errors while creating opportunities for large errors.
20. Complacency? Don’t worry about it.
21. In aviation, there is no problem so great or so complex that it cannot be blamed on the pilot.
22. There is no simple solution out there waiting to be discovered, so don’t waste your time searching for it.
23. Invention is the mother of necessity.
24. If at first you don’t succeed… try a new system or a different approach.
25. Some problems have no solution. If you encounter one of these, you can always convene a committee to revise some checklist.
26. In God we trust. Everything else must be brought into your scan.
27. It takes an airplane to bring out the worst in a pilot.
28. Any pilot who can be replaced by a computer should be.
29. Whenever you solve a problem you usually create one. You can only hope that the one you created is less critical than the one you eliminated.
30. You can never be too rich or too thin (Duchess of Windsor) or too careful what you put into a digital flight guidance system (Wiener).
31. Today’s nifty, voluntary system is tomorrow’s F.A.R.
Join Date: Feb 2000
Location: solent-on-sea
Posts: 443
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
I am fascinated by the term "Manual Reversion". It seems to be the equivalent process to throwing one's hands in the air and admitting that the all-singing, all-dancing, wonder jet has taken you to a place where you have to do something just to stay alive.
Should we therefore be looking at an automatic,
manual reversion after a random period of flight, just to make sure that the drivers are on the ball?
IG
Should we therefore be looking at an automatic,
manual reversion after a random period of flight, just to make sure that the drivers are on the ball?IG
Join Date: Feb 2006
Location: USA
Posts: 487
Likes: 0
Received 0 Likes
on
0 Posts
This AvWeek article fondly remembers the Dr. - a unicycle enthusiast !
Join Date: Dec 2006
Location: Florida and wherever my laptop is
Posts: 1,350
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
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.
Join Date: Feb 2000
Location: solent-on-sea
Posts: 443
Likes: 0
Received 0 Likes
on
0 Posts
"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."
Thanks Ian. My point, although slightly muddled I admit, is that if you are to rely on an automated system, rely on it. What is the point of the 'controller' if the system monitors conformance, and provides remedy to non conformance? Surely it would be better, and a lot quicker if multiple 'instructions' are needed to remedy a situation, to simply remove the controller and send all messages by CPDLC/datalink whatever? It seems to me we are allowing reliance on automation, as long as a human has a veto at the crunch time, which seems to place a lot of faith in the ability of said human, and be contradictory to the initial premise that automation can do it, and probably better..,
Thanks Ian. My point, although slightly muddled I admit, is that if you are to rely on an automated system, rely on it. What is the point of the 'controller' if the system monitors conformance, and provides remedy to non conformance? Surely it would be better, and a lot quicker if multiple 'instructions' are needed to remedy a situation, to simply remove the controller and send all messages by CPDLC/datalink whatever? It seems to me we are allowing reliance on automation, as long as a human has a veto at the crunch time, which seems to place a lot of faith in the ability of said human, and be contradictory to the initial premise that automation can do it, and probably better..,
Join Date: Dec 2006
Location: Florida and wherever my laptop is
Posts: 1,350
Likes: 0
Received 0 Likes
on
0 Posts
"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."
Thanks Ian. My point, although slightly muddled I admit, is that if you are to rely on an automated system, rely on it. What is the point of the 'controller' if the system monitors conformance, and provides remedy to non conformance? Surely it would be better, and a lot quicker if multiple 'instructions' are needed to remedy a situation, to simply remove the controller and send all messages by CPDLC/datalink whatever? It seems to me we are allowing reliance on automation, as long as a human has a veto at the crunch time, which seems to place a lot of faith in the ability of said human, and be contradictory to the initial premise that automation can do it, and probably better..,
Thanks Ian. My point, although slightly muddled I admit, is that if you are to rely on an automated system, rely on it. What is the point of the 'controller' if the system monitors conformance, and provides remedy to non conformance? Surely it would be better, and a lot quicker if multiple 'instructions' are needed to remedy a situation, to simply remove the controller and send all messages by CPDLC/datalink whatever? It seems to me we are allowing reliance on automation, as long as a human has a veto at the crunch time, which seems to place a lot of faith in the ability of said human, and be contradictory to the initial premise that automation can do it, and probably better..,
Join Date: Jan 2008
Location: Cambridge
Posts: 240
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Join Date: Dec 2006
Location: Florida and wherever my laptop is
Posts: 1,350
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
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.
Pegase Driver
Join Date: May 1997
Location: Europe
Age: 74
Posts: 3,682
Likes: 0
Received 0 Likes
on
0 Posts
Ian W , I do not intend to start another debate with you , you are right in theory of course, but just for the sake of informing the others "normal" people dealing with day to day operations . 4D Trajectory based ATC is a very promising concept but unfortunately long way out. My guess is at least 20 years , if not at all because superseded by another technology .The 2 main blocking issues of the 4D trajectory based ATC, are the implementation of a global ( preferably unique ) data link which is both fast and able to absorb heavy data exchange . This does not exists yet . They are ideas how to solve it but will take a decade or so to be standardized ,. The next issue will be aircraft retrofit. Airlines are furiously against retrofit and as long as you will have multi mode operations and the sacro saint " first comes first serve " rule, there will be no real financial benefits and no incentive for the airlines to equip and implement. The same old story . Talk to the ATA in the US.
BTW ,you mention earlier of using ACAS as mitigation . I know the US is pushing for that but no chance for this in ICAO land, and in Europe. ACAS is a last minute safety device , not a separation tool . Plus ACAS X will fall into the same issues due lack of an adequate Data Link .
Gusting 45 :
Rest assured that it will be like this. in ATC at least . Full Automatic ATC has been demonstrated not to be improving capacity, in fact the opposite is true, and even more so in TMA/ APP /. It might change as new technology comes along,of course, but not in our lifetimes. I would say ..
BTW ,you mention earlier of using ACAS as mitigation . I know the US is pushing for that but no chance for this in ICAO land, and in Europe. ACAS is a last minute safety device , not a separation tool . Plus ACAS X will fall into the same issues due lack of an adequate Data Link .
Gusting 45 :
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
Flight-deck automation: promises and problems.
The continuing issue is that of balance.
The initial use of highly automated aircraft did not start well because of oversold capability, misplaced assumption by management and regulation, and thus poorly adapted training and use.
Over the years there has been good progress in readjusting the balance between operations and safety, but this is strained by the speed of technical improvement and changes in operational environment.
Current difficulties involve the need to regulate and operate a wide range of ‘automatic’ capabilities, yet the pace of regulation and training remain slow. This is complicated by fewer opportunities to gain experience, yet still being expected to manage the wide range of situations encountered by all aircraft types, standards of automation, and operating environment.
Overall what we have appears to be an acceptable given the current safety statistics.
However, avoiding complacency might be increasingly difficult even if a balance is maintained.
Consider a simple balance mechanism remaining in equilibrium whist each side becomes more heavily loaded - increasing demands of operations vs more safety defences. There is a point at which the mechanism itself can be overloaded on both sides, it can break - a big twang, which will not involve automation, operations, or training, instead an unforeseen effect of the operational and safety processes. Asking more of operations and training on one side and expecting greater capability at lower cost on the other, perhaps masked by the dazzle of current success and ease of assuming that the future will be the same or better.
There are fewer opportunities for safety learning, we are poor learners, and that which was learnt is quickly forgotten. Wiener’s rules should remind us of these aspects and all of the above.
Also, to be wary of an increasing opportunity for academic theories about human behaviour, automation, and training to diverge from the reality of operations, which could bias the choice of future safety options.
Does what we already have work in practice but not in theory ?
Are we, the industry thinking more like machines than humans ?
The initial use of highly automated aircraft did not start well because of oversold capability, misplaced assumption by management and regulation, and thus poorly adapted training and use.
Over the years there has been good progress in readjusting the balance between operations and safety, but this is strained by the speed of technical improvement and changes in operational environment.
Current difficulties involve the need to regulate and operate a wide range of ‘automatic’ capabilities, yet the pace of regulation and training remain slow. This is complicated by fewer opportunities to gain experience, yet still being expected to manage the wide range of situations encountered by all aircraft types, standards of automation, and operating environment.
Overall what we have appears to be an acceptable given the current safety statistics.
However, avoiding complacency might be increasingly difficult even if a balance is maintained.
Consider a simple balance mechanism remaining in equilibrium whist each side becomes more heavily loaded - increasing demands of operations vs more safety defences. There is a point at which the mechanism itself can be overloaded on both sides, it can break - a big twang, which will not involve automation, operations, or training, instead an unforeseen effect of the operational and safety processes. Asking more of operations and training on one side and expecting greater capability at lower cost on the other, perhaps masked by the dazzle of current success and ease of assuming that the future will be the same or better.
There are fewer opportunities for safety learning, we are poor learners, and that which was learnt is quickly forgotten. Wiener’s rules should remind us of these aspects and all of the above.
Also, to be wary of an increasing opportunity for academic theories about human behaviour, automation, and training to diverge from the reality of operations, which could bias the choice of future safety options.
Does what we already have work in practice but not in theory ?
Are we, the industry thinking more like machines than humans ?
