Human Factors Integration and Model Based Systems …...Human Factors Integration (HFI) is the MOD...
Transcript of 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
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.
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
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.
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
of the Founding Fathers of UML)
?????
Why worry about the End User?
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.
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
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.
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?
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.
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?
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.
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?
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.
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?
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.
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?
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.
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?
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.
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
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.
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
TechnologyPeople
Environment
Human Factors Integration
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.
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
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.
Ref.: Page 14 -
Human FactorsIntegration
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
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.
Ref.: Page 15 -
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
Human Factors and Systems Engineering
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.
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)
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.
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
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.
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
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.
Ref.: Page 19 -
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
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
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.
Ref.: Page 20 -
Human Factors within MBSE
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
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
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.
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
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.
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?
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.
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 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
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.
Ref.: Page 24 -
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
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.
Ref.: Page 25 -
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
[No Other Assigned MIF]
Request Not to Reengage
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]
Send TEM (Command Open Line)
Determine Kill Assessment
["Kill Unknown"]
Reject Successful KA
[Reject Successful KA]
Input "Kill"
["Kill"]
Input "No Kill"
["No Kill"]
Send TEM (Command Open Line)
[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
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
[No Other Assigned MIF]
Request Not to Reengage
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]
Send TEM (Command Open Line)
Determine Kill Assessment
["Kill Unknown"]
Reject Successful KA
[Reject Successful KA]
Input "Kill"
["Kill"]
Input "No Kill"
["No Kill"]
Send TEM (Command Open Line)
[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
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
[No Other Assigned MIF]
Request Not to Reengage
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]
Send TEM (Command Open Line)
Determine Kill Assessment
["Kill Unknown"]
Reject Successful KA
[Reject Successful KA]
Input "Kill"
["Kill"]
Input "No Kill"
["No Kill"]
Send TEM (Command Open Line)
[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
["Kill"]
[Other Assigned MIF]
[No Other Assigned MIF]
["No Kill"]
[Accept Unsuccessful KA] [Reject Unsuccessful KA]
[Other MIF assigned][No Other Assigned MIF]
[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]
[Accept Successful KA] ["Kill Unknown"][Reject Successful KA]
["Kill"] ["No Kill"]
[Other Assigned MIF][No Other Assigned MIF]
[Manually Conduct Re-engagement]
[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
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.
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 theuser 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 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
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.
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
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.
Ref.: Page 28 -
Modelling User Roles & Competencies
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.
Ref.: Page 29 -
Modelling User Roles & Competencies
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.
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
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.
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
Performs1..*
Requires
1
Modelling User Roles & Competencies
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.
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 organisation (e.g. rank structure) and manpower
Modelling User Roles & Competencies
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.
Ref.: Page 33 -
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
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.
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>>
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
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.
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>>
33
Task Based relationship
between TPC & SC
7
7
1
1
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
Ref.: Page 42 -
Modelling User Interfaces
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
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.
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.
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.
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
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.
Ref.: Page 45 -
Questions?
XKCD.com