Human Factors and Model Based Systems Engineering Chris Vance Head - - PowerPoint PPT Presentation

Human Factors and Model Based Systems Engineering

Chris Vance Head of Human Factors MBDA

Ref.: Page 2 -

Overview

• Why worry about the End User?
• Case Studies
• Human Factors and Systems Engineering
• Human Factors and MBSE
• Modelling the User/s
• Conclusions

Ref.: Page 3 -

• Quote:

“The most volatile part of a system is its users’ behaviour”

From “The Object Advantage” by Ivar Jacobson

(Systems Engineering guru and one

• f the Founding Fathers of UML)

?????

Why worry about the End User?

Ref.: Page 4 -

Why worry about the End User?

• Humans are a major performance driver
• Humans have a major impact on system safety
• Humans are a major cost driver through life

Ref.: Page 5 -

• Case Study: Physical
• Single Role Mine Hunters
• Unit retrieval from the sea too

difficult due to pitch and role of the ship, particularly in high sea states

• Manual handling problem

underestimated during development

• To rectify, ship modifications

included a better crane, operator platform, additional recovery hook and pole

• Estimated cost of design changes

£1.9 million

Why worry about the End User?

Ref.: Page 6 -

• Case Study: Personnel
• M1 Battle Tank
• HFI was applied to the M1 series of

battle tanks. The earlier M60 tanks showed that performance correlated with user intellect.

• An Early Comparability Analysis

(ECA) showed clearly that, by redesigning for a range of crew abilities, high system performance could still be achieved and now any M1 crew out-performs the best M60 crew.

*AFQT - Armed Forces Qualification Test

Why worry about the End User?

Ref.: Page 7 -

• Case Study: Cognitive / Organisational
• Minx
• Replacement for mine laying

equipment

• Training Requirements
• Authority levels
• Would require all NCO’s and no

‘Sappers

Why worry about the End User?

Ref.: Page 8 -

• Case Study: Environment
• MLRS
• Environmental considerations
• Reload time 8 times longer for trained

service personnel in the field than when demonstrated by the contractor on hard standing

• Understanding of the system
• 35% more reliability achieved when

demonstrated by contractors, than when used by service personnel

Why worry about the End User?

Ref.: Page 9 -

• Case Study: Ergonomics / Health Hazards
• Stinger
• System Complexity
• 18 steps required for operating weapon
• Temporal aspects of the task
• Emits high levels of Hydrogen Chloride

when fired. Gunner must close eyes and hold his breath for 2 seconds after firing

• Weighs 35lbs compared with the 30lbs

recommendation

• Hit Probability
• Designed performance: 0.6
• Actual performance: 0.306

Why worry about the End User?

Ref.: Page 10 -

• Case Study: System Safety
• Airbus A320 – Alsace
• Herald of Free Enterprise
• Boeing 737 – Kegworth
• USS Vincennes
• Chernobyl

Why worry about the End User?

Ref.: Page 11 -

• In simple terms, HF aims to answers these questions:

. . . Can This Person . . . . . . . With This Training . . . . . . . Do These Tasks . . . . . . . . To These Standards . . . . . . . Under These Conditions?

• Goal of HF:
• “To ensure that we design systems which match the needs and abilities of

the users” Human Factors and Systems Engineering

Ref.: Page 12 -

Human Factors and Systems Engineering



Human Factors Integration (HFI) is the MOD process by which the People Component of Capability is considered during Capability Delivery



It is a systematic process for identifying, tracking and resolving human-related concerns ensuring a balanced development of both technologies and human aspects of Capability.



It aims to optimise the overall system performance by balancing human capabilities and characteristics with those of the hardware and software



Ensure the human component of the system is effectively included in the trade-off process

Processes Capability Technology People Environment 

Human Factors Integration

Ref.: Page 13 -

• HFI involves the identification and trade-off of people-related aspects

that could impact Capability development and delivery. This is facilitated by a framework of 7 Domains:

Human Factors and Systems Engineering

Ref.: Page 14 -

Human Factors Integration

Human Factors and Systems Engineering

Software Engineering Manufacturing Engineering Aeronautical Engineering Capability Analysis Electrical Engineering Mechanical Engineering Test Engineering Human Factors Engineering Safety Engineering Logistics Engineering Systems Engineering R&M Engineering Training

Ref.: Page 15 -

This may look like the System Engineering Process. HFI IS part of the System Engineering Process!!

Decisions on Definition Decisions on Requirements

UNDERSTAND VIEWPOINTS ESTABLISH THE SYSTEM REQUIREMENTS DESIGN & DEFINE SYSTEM DEVELOP SYSTEM ASSESS SYSTEM

Viewpoint Objectives System Requirements System Definition System Implementation Decisions on Implementation

• HFI Process

Human Factors and Systems Engineering

Ref.: Page 16 -

Human Factors within MBSE

• Model-based systems engineering (MBSE) is formalised application of

modelling to support :

• System requirements
• System design
• System analysis
• System verification and validation.
• MBSE should support these activities from the Concept phase and

continue throughout Development and later life cycle phases. (INCOSE definition)

Ref.: Page 17 -

Human Factors within MBSE

• Management Activities ensure that relevant questions are asked
• Technical Activities ensure that these questions are answered

Define Problem & Understand Context Agree System Requirements Develop System Define Physical Architecture Define Functional Architecture Assessment – Trade Studies & Supporting Processes System Validation System Verification Element Integration

Ref.: Page 18 -

Develop HFIP Develop HFI Strategy Develop HFI Requirements Manage HFI aspects of Acceptance Identify HFI Issues HFI Assurance Manage HFI Issues

Human Factors within MBSE

Define Problem & Understand Context Agree System Requirements Develop System Define Physical Architecture Define Functional Architecture Assessment – Trade Studies & Supporting Processes System Validation System Verification Element Integration

Management Activities

Ref.: Page 19 -

Establish HFI Requirements and Acceptance Criteria Establish the Context

• f Use

Describe User population Describe the Task Design Jobs, Roles and Tasks Design Equipment, HMI and Workspace Design Working Environment Develop Training

Human Factors within MBSE

Assess Operability

Define Problem & Understand Context Agree System Requirements Develop System Define Physical Architecture Define Functional Architecture Assessment – Trade Studies & Supporting Processes System Validation System Verification Element Integration

Technical Activities

Ref.: Page 20 -

Human Factors within MBSE

Mission Analysis Functional Analysis Allocation

• f Function

Task Analysis Target Audience Description Workload & Manpower Analysis User Interfaces/ Workspace Design Usability Assessment Human Reliability Assessment Job design Workload Assessment Operability Trials HAZOPS Training Needs Analysis

Define Problem & Understand Context Agree System Requirements Develop System Define Physical Architecture Define Functional Architecture Assessment – Trade Studies & Supporting Processes System Validation System Verification Element Integration

Supporting Techniques

Ref.: Page 21 -

Modelling the User/s

• Inside or outside the system?
• Human Functions and Tasks
• Requirements Derivation
• User Roles and Competencies
• Organisation
• User Interfaces

Ref.: Page 22 -

User inside or outside?

• The operator acts upon the equipment system and thus is defined as an actor
• In certain cases it may also be useful to describe the operator as processor or black-

box component in the system.

• This can then be modelled in a manner that is common with other Systems

Design teams

• Where is the system boundary?

Ref.: Page 23 -

Human Functions & Tasks

UC H-FlySystemContext

Maintain H-Fly System Conduct H-Fly Operation Deploy H-Fly System

H-Fly System

Conduct Ground Operation

Ground Deployment Integrated Logistics Support

Diagram Frame, with diagram kind

• f UC to show the diagram is a

Use Case and a diagram name of ‘H-FlySystemContext’ Actor Use Case System Boundary Subject Name Communication Relationship

Ground Control Segment HQ

Ref.: Page 24 -

Human Functions & Tasks

UC Conduct H-Fly Operation Plan H-Fly Mission Compile Situation Awareness Information Distribute Situation Awareness Information Direct Ground Deployment Ground Control Segment Ground Deployment View Situation Awareness information HQ Request Situation Awareness information Manage UAVs

• Important foundation for

subsequent modelling

• Defines system boundary
• Is the source for further

decomposition of tasks

Ref.: Page 25 -

Swimlanes allow task Assignment to Human Role Link Tasks to System Use Cases (SE Developed) Human Functions and Tasks

Ref.: Page 26 -

Monitor_Launch

«HF_Task»

TrainingRequirements SR_102

«Requirement»

SR_101

«Requirement»

The system shall OperationalEquipment requirement_5

«Requirement»

SR_104

«Requirement»

ID = 104 The system shall alert the user of a failure to launch a missile. SR_103

«Requirement»

ID = 103 The system shall provide an indication of the status of missile launch «satisfies» Training

«HFRequirementStatement»

Operators need to be trained such that they are able to identify the outcome of a missile launch and any launch

• failures. Operators should be trained to take appropriate

action in the event of missile failure during launch. A means to simulate missile launch is required as part

• f embedded training

«satisfies» «derive» «satisfies» «derive» «satisfies» «derive» OperationalEquipment

«HFRequirementStatement»

Operators must be able to determine whether the firing policy has been successfully fulfilled

• r a failure in launch has occured.

«derive» «satisfies» «satisfies» «satisfies» «satisfies»

Requirements Derivation

HF Requirements Traceability Diagram Task from activity diagram Justification Statement Derived System Reqs

Ref.: Page 27 -

Human Functions and Tasks / Requirements Derivation

• Modelling human functions & tasks within an overall systems model

enables us to:

• Identify human - system interactions, information flows and thus

requirements for User Interfaces

• Begin to understand the allocation of function between the operator and

the equipment system and the need for decision support functionality and automation

• Derive equipment, training & manpower requirements in a traceable

manner

• Begin further analysis
• Training Needs Analysis
• Predictive workload modelling / manpower assessment

Ref.: Page 28 -

Modelling User Roles & Competencies

Ref.: Page 29 -

Modelling User Roles & Competencies

Ref.: Page 30 - Bdd Ground Commander - Role to Task Mapping «Role» Resource allocation Performs «Role» Manage CGS «Role» Plan Missions «Role» Direct Ground Deployment 1 «Task» Assess request «Task» Assign Job «Task» Monitor Workload Ground Commander

Note that the other Roles performed by the ground Commander have not been analysed yet. As the analysis continues these would be updated.

Modelling User Roles & Competencies

Ref.: Page 31 - Bdd Resource allocation competency

• Processes & Procedures
• Military Doctrine
• Operational Objectives

«Competency» Knowledge

• Rank : string = Officer
• Fitness Level : string = Basic

«Competency» Attribute

• Multi tasking
• Leadership
• Analysis
• Communication

«Competency» Skill «Role» Allocate resources Ground Commander Performs 1..* Requires 1

Modelling User Roles & Competencies

Ref.: Page 32 -

• Modelling User Roles and Competencies within an overall systems

model enables us to:

• Allocate human functions and tasks to roles and posts
• Design jobs
• Capture existing user capabilities to influence system design decisions
• Establish conflicts between user capabilities and proposed roles
• Further understand personnel requirements and identify:
• Training gaps
• Requirements for decision support or automation
• Begin to understand the existing or required supporting human
• rganisation (e.g. rank structure) and manpower

Modelling User Roles & Competencies

Ref.: Page 33 -

Modelling Organisations

Ad – Compile Tactical Picture Process Job Assignment Specify Information Requirements Send Tactical Picture Request Clarification <<Post>> Ground Commander Specification Not understood Gather relevant Information :Map Specification Is understood <<Post>> Tactical Picture Compiler Package Tactical Picture Review tactical Picture Not OK :Tactical Picture OK :Troop Location :UAV Location :UAV Imagery

Ref.: Page 34 -

Modelling Organisations

Bdd – H-Fly Organisation and Command Relationships <<Unit>> Section [3] <<Post>> HQ Commander [1] <<Unit>> HQ [1] 1 <<commands>> <<Post>> Ground Commander [1] <<Unit>> Ground Control Segment [3] <<Co-operates with >> 3 1 3 <<Post>> Tactical Picture Compiler [3] <<commands>> <<Co-operates with>> 1 1 3 3 <<Post>> Section Commander [1] <<Unit>> Ground Deployment [1] 3 3 <<commands>> <<Co-operates with >> <<Co-operates with >> <<Co-operates with >> <<Post>> Ground Troop [7] <<Co-operates with >> <<commands>> 1 1 HFI001 – Commander workload may be too high, assessment needed.

Package Diagram Interaction Stereotype Indication of directionality Manning relationship, 1 Section Commander Commands 7 Ground Troops

7 7 1 1

Ref.: Page 35 -

Modelling Organisations

Bdd – H-Fly Organisation and Command Relationships <<Unit>> Section [3] <<Post>> HQ Commander [1] <<Unit>> HQ [1] 1 <<commands>> <<Post>> Ground Commander [1] <<Unit>> Ground Control Segment [3] <<Co-operates with >> 3 1 3 <<Post>> Tactical Picture Compiler [3] <<commands>> <<Co-operates with>> 1 1 3 3 <<Post>> Section Commander [1] <<Unit>> Ground Deployment [1] 1 1 <<commands>> <<Co-operates with >> <<Co-operates with >> <<Co-operates with >> <<Post>> Ground Troop [7] <<Co-operates with >> <<commands>> 3 3

Task Based relationship between TPC & SC

7 7 1 1

Ref.: Page 36 -

Modelling Organisations

Bdd – H-Fly Human Interaction Structure <<Physical Location>> H-Fly GCS Shelter <<Physical Location>> H-Fly GCS Shelter <<Physical Location>> Forward <<Physical Location>> H-Fly GCS Shelter <<Physical Location>> HQ <<Post>> :Ground Commander <<Post>> Tactical Picture Compiler <<Post>> Tactical Picture Compiler <<Post>> HQ Commander <<Post>> :Section Commander <<Post>> :Section Commander <<Post>> Tactical Picture Compiler <<Post>> :Section Commander <<Post>> :Section Commander <<Post>> :Section Commander <<Post>> :Section Commander <<Post>> :Section Commander <<Post>> :Section Commander <<Post>> :Section Commander <<Distribute SA Information>> <<Distribute SA Information>> <<Distribute SA Information>> <<Distribute SA Information>> <<Distribute SA Information>> <<Tasking and Status>> <<Tasking and Status>> <<Tasking and Status>> <<Tasking and Status>> <<Tasking and Status>> <<Tasking and Status>> <<Tasking and Status>> <<Tasking and Status>> <<Tasking and Status>> <<Distribute SA information>> <<Post>> :Ground Commander <<Post>> :Ground Commander

Instance Physical Location Stereotype Physical Location

Stove piped social network structure

Ref.: Page 37 -

Modelling Organisations

Bdd – H-Fly Human Interaction Structure <<Virtual Location>> H-Fly Information Environment <<Post>> :Ground Commander <<Post>> Tactical Picture Compiler <<Post>> Tactical Picture Compiler <<Post>> HQ Commander <<Post>> :Section Commander <<Post>> :Section Commander <<Post>> Tactical Picture Compiler <<Post>> :Section Commander <<Post>> :Section Commander <<Post>> :Section Commander <<Post>> :Section Commander <<Post>> :Section Commander <<Post>> :Section Commander <<Post>> :Section Commander <<Transfer SA Information>> <<Transfer SA Information>> <<Transfer SA Information>> <<Transfer SA Information>> <<Transfer SA Information>> <<Tasking & Status>> <<Tasking & Status>> <<Tasking and Status>> <<Tasking and Status>> <<Tasking and Status>> <<Tasking and Status>> <<Tasking and Status>> <<Tasking and Status>> <<Tasking and Status>> <<Transfer SA information>> <<Post>> :Ground Commander <<Post>> :Ground Commander <<Transfer SA Information>> <<Transfer SA Information>> <<Transfer SA Information>>

Virtual Location Stereotype Virtual Location

Decentralised social network structure

Ref.: Page 38 -

Modelling Organisations

• Modelling Organisational Structures within an overall systems model

enables us to:

• Bring together the Human Posts identified in other parts of the model &

investigate how they can function as an organisation

• Develop an understanding of physical separation of users across the

system, requirements for communication infrastructure and information flow

• Further understand pro’s and cons of different supporting organisations

and potential conflicts with existing ways of working / operational capabilities

• Further investigate this impact by e.g. process flow modelling or user trials
• Engage with stakeholders and validate assumptions

Ref.: Page 39 -

Modelling User Interfaces

• HMI to be used within the

model as a layer between the equipment system itself and the operator

• Without this level of

definition it is difficult to manage the manner and timings with which information is displayed to the operator, and how the user inputs are managed

Ref.: Page 40 -

Modelling User Interfaces

• To promote consistency across the model all HCI elements should be

characterised

• Equates to a form of style guide that governs how individual parts of

an HMI relate to each other

• Each block can be defined in terms of its physical characteristics, and

its place in a hierarchy of classes and sub-classes

• Together the set of HMI blocks should describe all possible types of

HMI component, such as buttons, displays, readouts, or inputs

Ref.: Page 41 -

Modelling User Interfaces

Bdd Situation Display 1 1

• Opacity : int = 0 to 100%
• Scale : int

«Graphic» Map 1..3 +On Mouse Over() +On Clickl()

• Height : int = 10
• Width : int = 4
• Co-ordinates : string = Lat/Long
• Status : bool = Engaged/Idle
• Engaged Colour : string = Red
• Idle Colour : string = Black
• Direction of travel : int
• Velocity : int
• ID : string
• Velocity vector
• Selected : bool = True or False
• Selected indicator : string = Cross hatched

«Icon» UAV Icon 1 +On activation()

• Background colour : string = Yellow
• Position
• Height : int = 10
• Width : int = 20

«Tooltip» UAV ID 1 +On Drag Drop() «Control» Navigator 1 +Updates Icon attributes()

• Movable : bool = True
• Maximisable : bool = True
• Minimisable : bool = True
• Re-sizeable : bool = True
• Title : string = UAV id / co-ordinates

«Window» Situation Display +On Drag Drop() «Control» Scaler +On Drag Drop() «Control» Opacity controler +On Mouse Over() +On Click()

• Height : int = 10
• Width : int = 4
• Co-ordinates : string = Lat/Long
• Colour : string = Black
• ID : string
• Callsign : string
• Selected indicator : string = Cross hatched

«Icon» Soldier Icon 0..* 0..* 1 +On Drag Drop() +On Maximise() +On Minimise() +On Close() «Control» Title Bar 1

Ref.: Page 42 -

Modelling User Interfaces

Tactical Picture Tactical Picture

Opacity 500m ID – 561349 Golf 4

UAV icon with velocity vector line showing speed and direction of travel Map graphic with scale Soldier icon Tooltip showing soldier id and callsign Control to alter the map’s opacity The map will be moved by dragging and dropping with the

• mouse. It will be

zoomed in/out using the spin button on the mouse

Ref.: Page 43 -

Modelling User Interfaces

• Modelling User Interfaces within an overall systems model enables us to:
• Specify a UI in a shared language for all stakeholders in a way which is clearly

linked to higher-level functionality and requirements

• This means that it is possible:
• For someone concerned with a whole-system viewpoint to see how their

requirements are met by separate elements of the system, and, further down, how those elements are controlled by the operator.

• For Software and HF Teams to trace the impact of their decisions back into the

higher-level model.

• Hence, the impact of decisions about implementation can be seen with a

considerable amount of clarity.

• The use of a common model between HF and Software also means that

they are better able to appreciate the difficulties and opportunities that each team may have.

Ref.: Page 44 -

Summary and Conclusions

• The human user will have a major impact on system performance,

safety and cost

• The role of the user should be considered as part of a robust systems

engineering approach

• The MOD process for this is called Human Factors Integration (HFI)
• HFI is necessarily a multidisciplinary approach
• This can be facilitated by modelling the role of the user (or users)

within the system

• The user can be represented within a system model enabling

identification of human tasks and human – equipment system interactions, interfaces and information flows

• This enables the identification requirements for the equipment system,

personnel, manpower and training

• Using a common modelling approach facilitates understanding of the

system by multiple stakeholders and thus can help ensure that human related concerns are effectively communicated and managed

Ref.: Page 45 -

Questions?

XKCD.com