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

Content

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

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.

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

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

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

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 parameterBest trade-offs between speed, comfort, price, size etc.

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

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.

Operational requirements

User requirements

Design requirements

Tech. requirements

”As few as possible”

User involvement and testing

Beyond normal operations, complexity

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

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

Levels of automation

Information acquisition

Information analysis

Decision selection

Action implementation

10....

5...

1

10....

5...

1

10....

5...

1

10....

5...

1

The Swiss cheese model of accident causation

Active errorsLatent conditions

Managerial decisions Training Operator error

Swiss cheese model

Tightly coupled automated systems

Decision to automate

Complexity of technological systems

Coupling

Interactions

Universities

Nuclear plant

Aircraft

ATM

Assembly-line production

Most manufacturing

Dams

Loose

Tight

Linear Complex

CDMAutomation

SWIMASAS

?

Quantifying interactions

• ASAS Free Flight

2

1

nnmV

V=6 V=3Controller separation Pilot separation

V=12Pilot separation(System)

Complexity assessment of changed responsibilities

Task migration

Emergent cognitive functions

Default case

Pilot Controller

Controller Pilot

Layered model for System of Systems

δγβα

Resources

δγβα

Operations

δγβα

Economics

δγβα

Policy

aircraft, crew, engineers…

Development, ATM, airline…

Regulations, SOP’s…

Individual

Team

Organisation

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

Aircraft

Example: Change of communication routes

Pilot Cabin

Catering

Aircraft

Pilot Cabin

Catering

Before After

Example: Change of responsibility and procedures

• ASAS applications- ASAS Self separation- ASAS Separation- ASAS Spacing

Self separation

Separation

Spacing

Default

Controller

Pilot

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

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?

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!

Thank you!

Questions?

barcheus@kth.se

KTH Royal Institute of TechnologyStockholm, Sweden