Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
Validating Requirements for the Automotive Industry using Model-
based Systems Engineering Prof Jon Holt
Technical Director, INCOSE UK Professor of Systems Engineering,
Cranfield University
Copyright © 2015
Overview
1. Introduction
2. Requirements concepts
3. Realising the concepts
4. Extending to Safety
5. ACRE - A Framework-based approach to Requirements Engineering
6. Summary
7. Questions
Copyright © 2015 1
1. Introduction
• Validation is a key issue in all industries – Relies upon a good understanding of the original
requirements
• However, requirements are often simply captured as text-based descriptions – No consideration of context is made
• Not helped by multiple levels – Goals that reflect the requirements of the business – Features that reflect the capabilities of the system – Requirements for the actual system (and, hence,
subsystem, assembly, unit, etc.)
Copyright © 2015 2
Introduction
• The use of Model-based Systems Engineering (MBSE) techniques provides a robust, rigorous and demonstrable approach to understanding requirements
• This presentation looks at some of the MBSE techniques that are being successfully applied in automotive including the use of modelling ontologies, frameworks, processes and their associated tool sets.
Copyright © 2015 3
2. Requirements concepts
Copyright © 2015 4
«block»
Rule
«block»
Need
{abstract}
«block»
Source Element
«block»
Need Description
«block»
Feature
«block»
Goal
«block»
Requirement
1
is related to
0..*
1
is related to
0..*
1
describes
1
1
is needed to deliver
0..*
1..*
is elicited from
1..*
1..*
is needed to deliver 1 1..*
meets
1..*
1
is related to
0..*
1..*
constrains
1..*
1
is related to
0..*
Requirements concepts continued
Copyright © 2015 5
«block»
Rule
«block»
Context
«block»
Use Case
«block»
System Context
«block»
Need
{abstract}
«block»
Source Element
«block»
Need Description
«block»
Scenario
«block»
Feature
«block»
Goal
«block»
Requirement
«block»
Stakeholder
Context
«block»
Project Context
«block»
Organisational
Context
«block»
Process Context
«block»
Assumption1
is related to
0..*
1
is related to
0..*
1
describes
1
1
is needed to deliver
0..*
0..*
justifies
1..*
1..*
is elicited from
1..*
1..*
is needed to deliver 1
0..*
confirms
0..*
1..*
meets
1..*
1..*
validates
1..*
1..*
describes the context of
1..*
1
is related to
0..*
1..*
constrains
1..*{incomplete}
1
is related to
0..*
3. Realising the concepts
• The concepts are realised in a number of viewpoints
• Use a modelling language such as SysML to realise the viewpoints
• Examples follow
– These are VERY much simplified extracts of the real model which contains (to date) 1600 requirements, 70 features, 25 goals, 870 use cases and 980 scenarios
Copyright © 2015 6
Modelling Sources
Copyright © 2015 7
«source element»
Powertrain Hazard and Risk
Analysis
date = 29/06/15
location = Sharepoint
reference =
status = draft
type = excel spreadsheet
version = 4.5
«source element»
Vehicle Targets Book
date = 12-2014
location = SHAREPOINT : C207NE Vehicle targets book English Dec2014 Draft.xls
reference =
status = Draft
type = Spreadsheet
version = 1
«source element»
GB 18352.3—2005 Emissions Regulations
date = 01-07-2007
location = Embedded within Vehicle Targets Book
reference =
status = Draft
type = PDF
version = 1
«source element»
Feature List
date = 27-01-2015
location = SHAREPOINT
reference =
status = Draft
type = Spreadsheet
version = 1.0
«source element»
Transmission Parking
System
date = 28-01-2015
location = SHAREPOINT
reference =
status = Draft
type = Spreadsheet
version = 1
Modelling Rules
Copyright © 2015 8
«rule»
Rule R05
notes
Need Description text shall conform to the following format:-
CONDITION : SUBJECT : ACTION : OBJECT : CONSTRAINT
«rule»
Rule R04
notes
Each Need Description must only use
ONE of the terms from Rules 1..3
«rule»
Rule R01
notes
must indicates that a Need
Description is mandatory &
non-negotiable
e.g. legislation, standards etc
«rule»
Rule R02
notes
shall indicates that a Need Description
is essential & negotiable.
e.g. performance
«rule»
Rule R03
notes
should indicates that a Need
Description is optional &
recommended.
Modelling Needs
Copyright © 2015 9
«need description»
Aid the driv er
«need description»
Intelligent Customised
Maintenance Schedules
«need description»
Cruise Control Activ ation
«need description»
Cruise Control
Deactiv ation
«need description»
Cruise Control Suspend
«need description»
Cruise Control Speed
Change Request
«need description»
Cruise Control Activ e
Indication
«need description»
Cruise control
«need description»
Activ e parking assist
«need description»
Cruise Control Controls
the v ehicle Road Speed
«source element»
System design meeting
minutes_150429Goals
Features
Requirements
Legend
«satisfy»
«satisfy»
«trace»
«satisfy» «satisfy» «satisfy»«satisfy»
«satisfy»«trace» «satisfy»
«satisfy»
Modelling Contexts
Copyright © 2015 10
«actor,stakeholder role»
Customer - Sponsor
«actor,stakeholder role»
Customer
«actor,stakeholder role»
Supplier - Engineer
«actor,stakeholder role»
Supplier - Manager
«actor,stakeholder role»
Supplier
«actor,stakeholder role»
Customer - Driv er
«actor,stakeholder role»
External
«actor»
Stakeholder Role
«actor,stakeholder role»
External - Safety Authority
«actor,stakeholder role»
External - Industry Standard
«actor,stakeholder role»
External - Gov ernment
Legislation
«actor,stakeholder role»
Supplier - Safety Officer
«actor,stakeholder role»
Customer - Pedestrian
«actor,stakeholder role»
Supplier - Marketing
«actor,stakeholder role»
Customer - Passenger
«actor,stakeholder role»
External - Public Opinion«actor,stakeholder role»
Supplier - Sales
«actor,stakeholder role»
Customer - Vulnerable Road
User
«actor,stakeholder role»
Customer - Other Vehicles
«actor,stakeholder role»
Supplier - Assembly
Operator
«actor,stakeholder role»
Customer - Thief
«actor,stakeholder role»
Customer - Competition
«actor,stakeholder role»
External - Police
«actor,stakeholder role»
External - Emergency
Serv ices
«actor,stakeholder role»
Customer - Obstacle
«actor,stakeholder role»
Customer - Power Supply
«actor,stakeholder role»
Customer - Dismantler
«actor,stakeholder role»
Customer - Satellite
«actor,stakeholder role»
Customer - Garage
«actor,stakeholder role»
Customer - Fossil Fuel
«actor,stakeholder role»
Supplier - Quality Inspector
«actor,stakeholder role»
Customer - Incumbent
infrastructure occupants
Modelling Needs in Context
Copyright © 2015 11
Thief
«goal»
Thief steals a
prestigious v ehicle
«feature»
Thief wants the v ehicle to
be easy to steal when
occupied
«goal»
Thief attempts theft
«feature»
Thief wants the v ehicle
to be easy to steal when
un-occupied
«goal»
Thief wants the stolen
v ehicle to driv e nicely
«feature»
Thief wants the stolen
v ehicle to hav e an
entertainment system
«feature»
Thief wants the stolen
v ehicle to look nice
«goal»
Thief steals
v ehicle to get
home
«goal»
Thief steals v ehicle to
sell it
«goal»
Thief steals v ehicle to
joy ride«feature»
Thief wants the stolen
v ehicle to driv e fast
«feature»
Thief remains
undetected during theft
«feature»
Thief starts the v ehicle
easily
«feature»
Thief wants the
v ehicle to be easy to
steal from
«feature»
Thief sells tools for
car thiev es
«goal»
Thief steals v ehicle
to rev erse engineer
it
«goal»
Thief steals v ehicle
to sell components
«feature»
Thief wants the stolen
v ehicle to contain
v aluable components
Thief steals fuel
from the v ehicle
«stakeholder role»
Vehicle
«stakeholder role»
Customer - Sponsor
«stakeholder role»
Thief - Opportunist Thief
«stakeholder role»
External - Police
«stakeholder role»
Supplier - Marketing
«stakeholder role»
Supplier - Sales
«include»
«constrain»
«constrain»
«include»
«include»«constrain»
«include»
«include»
«include»
«constrain»
«include»
Modelling Scenarios
Copyright © 2015 12
:Thief - Professional Thief
(from Other
Stakeholders)
:Thief - Opportunist Thief
(from Other
Stakeholders)
:Customer - Other Vehicles
(from Stakeholder
l ifelines)
Use(Security Defeat Product)
Complains(Device Not Working)
Security(Defeated)
Security Codes(Fixed)
Sell Product(Security Defeat Device)
Use(Security Defeat Product)
Security Code(Accepted)
Send(Security Code)
4. Extending to Safety
Copyright © 2015 13
Need
{abstract}
System-lev el Safety
Goal
Subsystem Unit-lev el
Safety Goal
Functional Safety
Requirement
Goal
Element-lev el Safety
Goal
Requirement
1..*
satisfies
11..*
satisfies
1..*1..*
satisfies
1..*
Extending to Safety
• Concepts extended to include
– Functional Safety Requirements
– Safety Goals (system, subsystem and element) level
• Because these are extensions to the “standard” requirement and goal concepts discussed above, can apply same modelling to safety requirements and goals
Copyright © 2015 14
Extending to Safety
Copyright © 2015 15
«fault»
XYZ Clutch Mechanism Fault
«need description»
ACU XYZ Clutch Fault (FSR0030)
fault time interval =
id =
safety category = "ASIL B ISO 26262"
source id# = "FSR0030"
text = "ACU shall be able to detect XYZ clutch
faults and enter system safe state 2 within the
fault tolerant time interval of <TBC> ms if
detected"
type = "FSR"
«item»
XYZ Clutch
Mechanism
«source element»
Powertrain Hazard and
Risk Analysis
ref
ACU Insufficient Vehicle Acceleration
«element-level safety goal»
XYZ Clutch shall not expose
stakeholders to unreasonable risk due
to Insufficient Vehicle Acceleration
[ASIL B]
«safe state»
ACU Safe State 2
«subsystem unit-level safety goal»
Powertrain shall not expose
stakeholders to unreasonable risk due
to Insufficient Vehicle Acceleration
[ASIL B]
«system-level safety goal»
Vehicle shall not expose stakeholders
to unreasonable risk due to Insufficient
Vehicle Acceleration
«hazard»
Insufficient Vehicle
Acceleration
«element»
XYZ Clutch
«satisfy»
«mitigate»
«mitigate»
«occur»
«apply»
«trace»
«cause»
«validate»
«enter»
«satisfy»
«satisfy»
«trace»
5. ACRE - A Framework-based approach to Requirements Engineering
• To do requirements engineering correctly and consistently in a model-based way, we need a framework – Uses defined concepts and relationships between them
(an ontology)…
– …to define a define viewpoints organised into a framework
• The approach shown above is known as Approach to Context-based Requirements Engineering (ACRE)
Copyright © 2015 16
The ACRE Viewpoints
Copyright © 2015 17
«block»
Rule
«block»
Context
«block»
Use Case
«block»
System Context
«block»
Need
{abstract}
«block»
Source Element
«block»
Need Description
«block»
Scenario
«block»
Feature
«block»
Goal
«block»
Requirement
«block»
Stakeholder
Context
«block»
Project Context
«block»
Organisational
Context
«block»
Process Context
«block»
Assumption1
is related to
0..*
1
is related to
0..*
1
describes
1
1
is needed to deliver
0..*
0..*
justifies
1..*
1..*
is elicited from
1..*
1..*
is needed to deliver 1
0..*
confirms
0..*
1..*
meets
1..*
1..*
validates
1..*
1..*
describes the context of
1..*
1
is related to
0..*
1..*
constrains
1..*{incomplete}
1
is related to
0..*
Automation
• Successful use of modelling requires use of a modelling tool – Ensures consistency
• Allows automation of reviews – Used to improve validation of entire model
– Test ontology relationships
– Checks in seconds what would take hours to do manually
• Automation is a key driver for MBSE
Copyright © 2015 18
Example automation output
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Need Description Source Check Starting >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In package: C207 Project::C207 Vehicle::Stakeholder::Requirements::Goals and Features Documentation::Vehicle Features::Meet Emissions Targets ERROR: [Meet emissions targets] traces to OR is justified by NOTHING [ACRE02] In package: C207 Project::C207 Vehicle::Stakeholder::Requirements::Goals and Features Documentation::Vehicle Features::Automated Emergency Assist ERROR: [Automated emergency assistance request] traces to OR is justified by NOTHING [ACRE02]
DETAILS OMITTED *************************************** SUMMARY 2056 need descriptions found 105 need descriptions failed 5.1% failure rate Rule ACRE2 failed 105 time(s) *************************************** <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Need Description Source Check Complete <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Copyright © 2015 19
6. Summary • A framework-based approach to requirements engineering
helps to ensure – Consistency of approach – Coverage of all necessary concepts
• ACRE places emphasis on context – Forces requirements to be considered from different points of
view – Helps identify commonality and conflicts
• Tool use is essential – Modelling tool to implement ACRE approach and ensure
consistency – Automation in tool (such as scripting) to improve validation of
entire model, test ontology relationships – Checks in seconds what would take hours to do manually
Copyright © 2015 20
7. Questions
Copyright © 2015 21
Want to know more?
Copyright © 2015 22
Follow us on LinkedIn – Scarecrow Consultants • www.linkedin.com/company/scarecrow-consultants • Play SysML-anary every Friday