validating requirements for the automotive industry using

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


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


Intelligent Customised

Maintenance Schedules


Cruise Control Activ ation


Cruise Control

Deactiv ation


Cruise Control Suspend


Cruise Control Speed

Change Request


Cruise Control Activ e

Indication


Cruise control


Activ e parking assist


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


Customer


Supplier - Engineer


Supplier - Manager


Supplier


Customer - Driv er


External

«actor»

Stakeholder Role


External - Safety Authority


External - Industry Standard


External - Gov ernment

Legislation


Supplier - Safety Officer


Customer - Pedestrian


Supplier - Marketing


Customer - Passenger


External - Public Opinion«actor,stakeholder role»

Supplier - Sales


Customer - Vulnerable Road

User


Customer - Other Vehicles


Supplier - Assembly

Operator


Customer - Thief


Customer - Competition


External - Police


External - Emergency

Serv ices


Customer - Obstacle


Customer - Power Supply


Customer - Dismantler


Customer - Satellite


Customer - Garage


Customer - Fossil Fuel


Supplier - Quality Inspector


Customer - Incumbent

infrastructure occupants

Modelling Needs in Context


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»


v ehicle to hav e an

entertainment system

«feature»


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»


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»


v ehicle to contain

v aluable components

Thief steals fuel

from the v ehicle

«stakeholder role»

Vehicle


Customer - Sponsor


Thief - Opportunist Thief


External - Police


Supplier - Marketing


Supplier - Sales

«include»

«constrain»

«constrain»

«include»

«include»«constrain»

«include»

«include»

«include»

«constrain»

«include»

Modelling Scenarios


: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


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


Extending to Safety


«fault»

XYZ Clutch Mechanism Fault


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)


The ACRE Viewpoints


«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


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


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


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


7. Questions


Want to know more?


Follow us on LinkedIn – Scarecrow Consultants • www.linkedin.com/company/scarecrow-consultants • Play SysML-anary every Friday

validating requirements for the automotive industry using

Documents