Human Factors Integration and Model Based Systems …...Human Factors Integration (HFI) is the MOD...

This document and the information contained herein is proprietary information of MBDA and shall not be disclosed or reproduced without the prior authorisation of MBDA. MBDA 2011.

Human Factors and Model Based Systems Engineering

Chris VanceHead of Human FactorsMBDA


Ref.: -

Overview

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


Ref.: -

• Quote:

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

behaviour”From “The Object Advantage”

by Ivar Jacobson(Systems Engineering guru and one

of the Founding Fathers of UML)

?????

Why worry about the End User?


Ref.: -


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


Ref.: -

• 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



Ref.: -

• 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



Ref.: -

• Case Study: Cognitive / Organisational

• Minx

• Replacement for mine laying equipment

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

‘Sappers



Ref.: -

• 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



Ref.: -

• 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



Ref.: -

• Case Study: System Safety

• Airbus A320 – Alsace

• Herald of Free Enterprise

• Boeing 737 – Kegworth

• USS Vincennes

• Chernobyl



Ref.: -

• 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.: -


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

TechnologyPeople

Environment

Human Factors Integration


Ref.: -

• 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:



Ref.: -

Human FactorsIntegration


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.: -

This may look like the System Engineering Process.

HFI IS part of the System Engineering Process!!

Decisions onDefinition

Decisions onRequirements

UNDERSTANDVIEWPOINTS

ESTABLISH THESYSTEM

REQUIREMENTS

DESIGN & DEFINESYSTEM

DEVELOPSYSTEM

ASSESSSYSTEM

ViewpointObjectives

SystemRequirements

SystemDefinition

SystemImplementation

Decisions onImplementation

• HFI Process



Ref.: -

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.: -


• 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.: -

Develop HFIP

Develop HFI Strategy

Develop HFI Requirements

Manage HFI aspects of

Acceptance

Identify HFI Issues

HFI Assurance

Manage HFI Issues



Context


Develop System

Define Physical

Architecture

Define Functional

Architecture


System Validation

System Verification

Element Integration

Management Activities


Ref.: -

Establish HFI Requirements and

Acceptance Criteria

Establish the Context of UseDescribe User

population

Describe the Task

Design Jobs, Roles and Tasks

Design Equipment, HMI and Workspace

Design Working Environment

Develop Training


Assess Operability


Context


Develop System

Define Physical

Architecture

Define Functional

Architecture


System Validation

System Verification

Element Integration

Technical Activities


Ref.: -


Mission Analysis

Functional Analysis

Allocation of 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


Context


Develop System

Define Physical

Architecture

Define Functional

Architecture


System Validation

System Verification

Element Integration

Supporting Techniques


Ref.: -

Modelling the User/s

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


Ref.: -

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.: -

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 of 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.: -

Human Functions & TasksUC 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.: -

swimlane_1:Principle Warfare Officer

Notes:

Observe Kill Assessment Report

["Kill"]

Report to AWO

Request Not to Reengage

[Other Assigned MIF] Consider Action

[No Other Assigned MIF]

["No Kill"]

Report to AWO

[Accept Unsuccessful KA]

Reject Unsuccessful KA

[Reject Unsuccessful KA]

[Other MIF assigned]

Consider Action



Report to AWO

Report to AWO

[Request Not to Re-engage] [Manually Conduct Re-engagement]

[System Auto-Re-engages]

[Request Not to Re-engage]

[Observe System Requires Manual Re-engagement]

[Observe System Auto-Continuation Re-engagement]

Send TEM (Command Open Line)

[Accept Successful KA]


Determine Kill Assessment

["Kill Unknown"]

Reject Successful KA

[Reject Successful KA]

Input "Kill"

["Kill"]

Input "No Kill"

["No Kill"]


[Other Assigned MIF][No Other Assigned MIF]

[Manually Conduct Re-engagement]

Report to AWORequest Not to Re-engage

swimlane_0:Air Warfare Officer

Receive Report re: Successful KA

[Request Accepted]

[Request Declined]

[Request Accepted]

[Request Declined]

Receive Report re: Auto-Engagement

Receive Reoprt re: Rejection of Successful KA

Receive Report re: Auto-Continuation

Receive report re: Reject Unsuccessful KA

Receive Report re: Unsuccessful KA

Receive report re: Successful Kill

Receive Report re: System Auto Re-engagement


Notes:


["Kill"]

Report to AWO




["No Kill"]

Report to AWO





Consider Action



Report to AWO

Report to AWO










["Kill Unknown"]



Input "Kill"

["Kill"]

Input "No Kill"

["No Kill"]







[Request Accepted]

[Request Declined]

[Request Accepted]

[Request Declined]









Notes:


["Kill"]

Report to AWO




["No Kill"]

Report to AWO





Consider Action



Report to AWO

Report to AWO










["Kill Unknown"]



Input "Kill"

["Kill"]

Input "No Kill"

["No Kill"]







[Request Accepted]

[Request Declined]

[Request Accepted]

[Request Declined]








["Kill"]

[Other Assigned MIF]


["No Kill"]

[Accept Unsuccessful KA] [Reject Unsuccessful KA]

[Other MIF assigned][No Other Assigned MIF]






[Accept Successful KA] ["Kill Unknown"][Reject Successful KA]

["Kill"] ["No Kill"]



[Request Accepted]

[Request Declined]

[Request Accepted]

[Request Declined]

Swimlanes allow task Assignment to Human Role Link Tasks to System Use

Cases (SE Developed)

Human Functions and Tasks


Ref.: -

Monitor_Launch«HF_Task»

TrainingRequirements

SR_102«Requirement»


The system shall

OperationalEquipment

requirement_5«Requirement»


ID = 104

The system shall alert theuser of a failure to launch a missile.


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 launchfailures. Operators should be trained to take appropriateaction in the event of missile failure during launch.A means to simulate missile launch is required as part of embedded training

«satisfies»

«derive»

«satisfies»

«derive»

«satisfies»

«derive»

OperationalEquipment«HFRequirementStatement»

Operators must be able to determine whether the firing policy has been successfully fulfilled or 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.: -

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.: -

Modelling User Roles & Competencies


Ref.: -

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.



Ref.: -

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

Performs1..*

Requires

1



Ref.: -

• 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 organisation (e.g. rank structure) and manpower



Ref.: -

Modelling Organisations

Ad – Compile Tactical Picture Process

Job Assignment

Specify InformationRequirements

Send Tactical Picture

Request Clarification

<<Post>>Ground Commander

SpecificationNot understood

Gather relevantInformation

:Map

SpecificationIs understood

<<Post>>Tactical Picture Compiler

Package TacticalPicture

Review tactical Picture

Not OK

:Tactical Picture

OK

:Troop Location

:UAV Location

:UAV Imagery


Ref.: -


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 >>



<<Post>>Ground Troop

[7]


<<commands>>

11

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.: -


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


Compiler[3]

<<commands>>

<<Co-operates with>>1

1

3

3

<<Post>>Section

Commander [1]

<<Unit>>Ground Deployment [1]

1

1

<<commands>>




<<Post>>Ground Troop

[7]


<<commands>>

33

Task Based relationship

between TPC & SC

7

7

1

1


Ref.: -


Bdd – H-Fly Human Interaction Structure

<<Physical Location>>H-Fly GCS Shelter


<<Physical Location>>Forward


<<Physical Location>>HQ

<<Post>>:Ground

Commander


Compiler


Compiler

<<Post>>HQ

Commander

<<Post>>:Section

Commander

<<Post>>:Section

Commander


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>>





<<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.: -


Bdd – H-Fly Human Interaction Structure

<<Virtual Location>>H-Fly Information Environment

<<Post>>:Ground

Commander


Compiler


Compiler

<<Post>>HQ

Commander

<<Post>>:Section

Commander

<<Post>>:Section

Commander


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>>

<<Tasking & Status>>

<<Tasking & Status>>








<<Transfer SA information>>

<<Post>>:Ground

Commander

<<Post>>:Ground

Commander




Virtual Location Stereotype

Virtual Location

Decentralised social network structure


Ref.: -


• 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.: -

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.: -


• 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.: -


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.: -


Tactical PictureTactical Picture

Opacity

500m

ID – 561349Golf 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.: -


• 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.: -

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.: -

Questions?

XKCD.com

Human Factors Integration and Model Based Systems …...Human Factors Integration (HFI) is the MOD...

Documents

Transcript of Human Factors Integration and Model Based Systems …...Human Factors Integration (HFI) is the MOD...