1. In need of a model for complexity assessment of highly automated human machine systems Fredrik Barchéus, Pernilla Ulfvengren, Johan Rignér

2. Content Goal of research Purpose of paper Future ATM, context Theory; Human Factors, automation and complexity Models of complexity Conclusion and discussion

3. Goal of our research Apply and integrate knowledge of human factors into development and continuous improvement of critical systems in order to improve overall system performance.

4. Purpose of this paper Initial work, problem definition and ideas for further research Link multiple areas of research -Design and system development -Human Factors and User Centered System Design -Automation and complex systems -Models of complexity Identify potential criteria for human factors specific to operating in highly automated and complex systems. Explore future research needed to develop a model for complexity assessment in these systems

5. Future ATM system – Multiple goals Commercial pressure Demand for increased capacity Descrease costs Decrease environmental impact Increase efficiency Increase safety Deployment of new technologies Shift of paradigm: airspace based to trajectory based High level automation Integrated systems

6. Effects and consequences of future system on human operators and system performance New operational rules, new tasks, new roles Increased automation -”Ironies of automation” -Less operator understanding/predictability of operational processes Change of responsibilities among human roles: -air traffic controllers, pilots, ground handlers etc. Various levels of automation in new and old parts in operating system. Actors with different technologies in joint systems

7. Multiple goals, trade-offs in design Good design – managing trade-offs -To evaluate your design choices -There is no perfect solution -You need to know the trade-offs. The perfect car: DC3 aircraft – made aviation available to public Not best on any single parameter Best trade-offs between speed, comfort, price, size etc.

8. Design and system development process Design requirements: -Precise, limited design requirements specification -Both enabler and blocker of designing for operability with full functionality. Timing: identifying needs for improvement -Easier and cheaper to change early in design phase. -An alternative is to add restrictive user instructions In IT-systems design: -Insufficient or faulty initial requirements. -Customer may not define or even know what design requirements that will fulfill operational requirements

9. Human Factors and User-Centered System Design Needs driven, context and operational focus Front-end analysis with user in early focus Operator analysis difficult, too unspecified design requirements. Still not always applied from the start of system development. HF remains an add-on in design of human-machine systems.

10. Operational requirements User requirements Design requirements Tech. requirements ”As few as possible” User involvement and testing Beyond normal operations, complexity

11. Automation and complexity Automation -Enable cost-effective systems -Enable safer systems -Affect work environment, content, tasks and procedures Imperfect automation leads to complacency and mistrust from operators Full automation in part hindered by insufficient data The human remains in the system as a backup ”Not all that could be automated should be automated” Levels Of Automation, LOA

12. Levels of automation 10 the computer does everything. 5 the computer acquires information, suggest one solution and waits for the human to execute. 1 the human does everything

13. Levels of automation Information acquisition Information analysis Decision selection Action implementation 10. 5. 1 10. 5. 1 10. 5. 1 10. 5. 1

14. The Swiss cheese model of accident causation Active errors Latent conditions Managerial decisionsTraining Operator error

15. Swiss cheese model Tightly coupled automated systems Decision to automate

16. Complexity of technological systems Coupling Interactions Universities Nuclear plant Aircraft ATM Assembly-line production Most manufacturing Dams Loose Tight Linear Complex CDM Automation SWIM ASAS ?

17. Quantifying interactions ASAS Free Flight V=6V=3 Controller separationPilot separation V=12 Pilot separation (System)

18. Complexity assessment of changed responsibilities Task migration Emergent cognitive functions Default case Pilot  Controller Controller  Pilot

19. Layered model for System of Systems δγβαδγβα Resources δγβαδγβα Operations δγβαδγβα Economics δγβαδγβα Policy aircraft, crew, engineers… Development, ATM, airline… Regulations, SOP’s… Individual Team Organisation

20. Example: Multitude of equipment and procedures Aircraft descent from a pilot’s perspective -Airspeed mode -Vertical speed mode -FMS mode Manufacturer and airline economic profile differs Trajectory differs between different modes

21. Aircraft Example: Change of communication routes PilotCabin Catering Aircraft PilotCabin Catering BeforeAfter

22. Example: Change of responsibility and procedures ASAS applications -ASAS Self separation -ASAS Separation -ASAS Spacing Self separation Separation Spacing Default Controller Pilot

23. Validity of models and methods Simplifications Cover only sub-systems under certain conditions Use of domain knowledge Simulation models need valid basic assumptions Purpose of automation model(s)? -Training, procedure design -Limited wider modeling applicability

24. Future system - Again Multitude of equipment and procedures -More interactions – higher complexity Change of communication routes -Changed interactions – complexity? Change of responsibilites and procedures -Changed interactions – complexity? Highly automated -Tightly coupled – error propagation Significant system integration -More/less complexity?

25. Conclusion and discussion Complexity and automation highly intertwined in the context of SESAR and the future European ATM system -Paradigmatic change – viability of old methods and models -Old systems remain in new context – new interactions need new reassessments -Mixed system functionality and equipage – full system assessment -Lack of “full context” – careful use of domain expert knowledge Collaboration between ComplexWorld and HALA!

26. Thank you! Questions? barcheus@kth.se KTH Royal Institute of Technology Stockholm, Sweden