functional safety in co-operative driving using systems ...1072594/fulltext01.pdf1 examensarbete mmk...

IN THE FIELD OF TECHNOLOGYDEGREE PROJECT DESIGN AND PRODUCT REALISATIONAND THE MAIN FIELD OF STUDYMECHANICAL ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2016

Functional Safety in Co-operative Driving using Systems-Theoretic Process Analysis

JOAKIM OSCARSSON

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF INDUSTRIAL ENGINEERING AND MANAGEMENT

Functional Safety in Cooperative Driving using Systems-Theoretic Process Analysis

Joakim Oscarsson

Master of Science Thesis MMK 2016:172 MDA 552 KTH Industrial Engineering and Management

Machine Design SE-100 44 STOCKHOLM

1

Examensarbete MMK 2017:172 MDA 552


Joakim Oscarsson

Godkänt

2016-11-07 Examinator

Martin Törngren Handledare

Naveen Mohan Uppdragsgivare

Kontaktperson

Sammanfattning Kooperativ körning är fenomenet av uppkopplade väg fordon som utbyter information för att uppnå säkrare och mer effektiva trafiksituationer. Det är en invecklad kontext som ger nya synvinklar på området funktionell säkerhet. Det kan automatiseras, och då autonoma fordon är beroende av pålitlig information för att kunna fatta beslut, så uppstår frågan med tillit till data mottagen genom kooperativa körningskanaler. Även bortsatt från området datasäkerhet, finns fortfarande en risk att brister i andra fordon kan orsaka att inkommande kommunikationssignaler ej blir trovärdiga. I det här examensarbetet visas att antaganden om nivån av tillförlitlighet till data från externa fordon kan ha en signifikant påverkan på den slutgiltiga arkitekturen. Det visas också att det varken att fullt lita på, eller att inte alls lita på data mottagen genom kooperativa körningskanaler, är optimalt när hänsyn tas till säkerhet, nyttjande av kommunikationsmöjligheter och kostnader.

På grund av komplexiteten i kooperativ körning utförs analyserna med den nya och tillsynes lovande metoden System-teoretisk process analys (STPA). För tillfället är det praxis inom fordonsindustrin att för funktionell säkerhet rätta sig till standarden ISO 26262, som inte ger någon naturlig väg att implementera STPA. Därför presenterar detta examensarbete en utvecklingsprocess som nyttjar fördelarna med STPA och rättar sig efter ISO 26262 standarden. STPA har störst potential under produktutveckling vid system design, men även andra användningsområden har identifierats. STPA är en modern, generell analysmetod som aldrig tidigare används i kontexten kooperativ körning. Därför inleder detta examensarbete med att validera dess tillämpbarhet i denna specifika kontext. Utvärderingen utförs genom en studie av ett verkligt fall, kopplat till KTHs deltagande i Grand Cooperative Driving Challenge - en tävling av i-GAME, menat att snabba på implementeringen av kooperativ körning i Europa. Metodens validitet i kontexten styrks av fler än en analytiker, utvecklingsteamet för kooperativ körning på KTH, en klients godkännande av resultat, samt av akademisk granskning.

3

Master of Science Thesis MMK 2016:x172 MDA 552


Joakim Oscarsson

Approved

2016-11-07 Examiner

Martin Törngren Supervisor

Naveen Mohan Commissioner

Contact person

Abstract Co-operative driving is the phenomenon of connected road vehicles exchanging information to achieve safer and more efficient traffic. It is a convoluted context, which gives the topic of functional safety new complex angles. It can be automated, and as autonomous vehicles are dependent on reliable information for decision making, the issue of trusting data received over co-operation communication channels is raised. Disregarding the topic of security, there is still the possibility of failures in external vehicles causing incoming transmissions to be untrustworthy. In this thesis, it is shown that premises regarding levels of external trust can have significant impacts on the final architecture. It is also shown that neither fully trusting, nor not trusting data received over co-operation communication channels is the best option, when considering safety, usage of communication potential and cost. Because of the complexity of co-operative driving, the analyses are performed using the new and promising method of Systems-Theoretic process analyses (STPA). The current best practice of automotive functional safety is to comply with the domain specific ISO 26262 standard, which does not provide a natural way of implementing STPA. Therefore, this thesis also presents a development process which utilises the benefits of STPA, while complying to the ISO 26262 standard. STPA has the greatest potential during the product development at system level, though other uses have also been identified. STPA is a generic analysis method, which has previously not been used in the context of co-operative driving. This thesis therefor begins by validating the applicability of STPA in this specific context. The evaluation is performed using a real world case study connected to KTH’s participation in the Grand Cooperative Driving Challenge - a competition by i-GAME to speed up the implementation of co-operative driving in Europe. The validity of the method when applied to this context is strengthened by multiple analysts, the KTH co-operative driving development team, client approval of results and academic reviews.

Acknowledgements

I would like to thank Max Stoltz-Sudnes, with whom I performed the preliminarycase study. M. Stolz-Sundnes is, at the time of writing, a M.Sc. student at the de-partment of mechatronics, at KTH Royal Institute of Technology. The preliminarycase study is a joint collaboration between this thesis and his.

I would like to thank Naveen Mohan for his efforts as thesis supervisor andViacheslav Izosimov, who together with N. Mohan assisted in the publication of thepreliminary case study.

I would also like to thank the development team at the Integrated TransportResearch Labs at KTH, Royal Institute of Technology. Most noteworthy, StefanosKokogias and Lars Svenson, who dedicated countless hours to the analyses as do-main experts.

Finally, I would like to thank my cousin Emil Djupfeldt, who inspired me tostudy mechatronics in the first place.

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Introduction to co-operative driving . . . . . . . . . . . . . . 11.1.2 Introduction to autonomous vehicles . . . . . . . . . . . . . . 21.1.3 Introduction to automotive functional safety . . . . . . . . . 41.1.4 Introduction to Systems-Theoretic Process Analysis . . . . . 4

1.2 Questions of interest . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.1 Problem motivation . . . . . . . . . . . . . . . . . . . . . . . 51.2.2 Research questions . . . . . . . . . . . . . . . . . . . . . . . . 51.2.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.1 Literature study . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.2 Pre-study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.3 Process design . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.4 Architectural case studies . . . . . . . . . . . . . . . . . . . . 8

2 Frame of Reference 92.1 Automotive functional safety . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 ISO-26262 Concept phase . . . . . . . . . . . . . . . . . . . . 102.1.2 ISO-26262 System level product development phase . . . . . 14

2.2 Systems-Theoretic Process Analysis . . . . . . . . . . . . . . . . . . 162.2.1 Accidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.2 Hazards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.3 Control structure . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.4 STPA-step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.5 STPA-step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Pre-study 233.1 Context and case study description . . . . . . . . . . . . . . . . . . . 23

3.1.1 Grand Cooperative Driving Challenge . . . . . . . . . . . . . 243.1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.1.3 Experimental setup . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Preliminary study . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.1 Accidents and hazards . . . . . . . . . . . . . . . . . . . . . . 323.2.2 Control structure . . . . . . . . . . . . . . . . . . . . . . . . . 323.2.3 STPA step 1 and 2 . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3 Discussion & conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 353.3.1 STAMP-STPA evaluation . . . . . . . . . . . . . . . . . . . . 353.3.2 Problem space exploration . . . . . . . . . . . . . . . . . . . . 37

4 Study 394.1 Automotive functional safety design process using STPA . . . . . . . 39

4.1.1 STAMP-STPA in safety guided design . . . . . . . . . . . . . 394.1.2 Safety guided design with STPA in accordance with ISO 26262 42

4.2 Architectural case studies . . . . . . . . . . . . . . . . . . . . . . . . 514.2.1 Hazard analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.2 Functional safety requirements . . . . . . . . . . . . . . . . . 524.2.3 Technical safety requirements . . . . . . . . . . . . . . . . . . 574.2.4 System design . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5 Discussion 655.1 Automotive functional safety design process using STPA . . . . . . . 655.2 Architectural impacts . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.2.1 Case 1: Data received from external vehicles can be trusted . 665.2.2 Case 2: Data received from external vehicles can not be trusted 685.2.3 Case 3: Data received from external vehicles can only be

trusted if it can be confirmed by at least one independentsource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.2.4 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6 Conclusions 736.1 Automotive functional safety design process using STPA . . . . . . . 736.2 Architectural impacts . . . . . . . . . . . . . . . . . . . . . . . . . . 746.3 A note regarding the C-ITS protocol . . . . . . . . . . . . . . . . . . 746.4 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Bibliography 77

List of Figures

1.1 Description of the levels of automation according to the SAE standardJ3016, and their relationships to the levels of automation defined byNHTSA and BASt. Illustrated by Bryant Walker Smith, originally pub-lished by the Stanford Law School[1]. . . . . . . . . . . . . . . . . . . . . 3

2.1 Automotive lifecycle according to the ISO 26262 standard . . . . . . . . 102.2 A coarse overview of the building blocks of the STAMP-STPA method . 172.3 Illustration of a standard control loop, as depicted by Nancy G. Leve-

son in Engineering a Safer World, Systems Thinking Applied to Safety,published by The MIT Press [2] . . . . . . . . . . . . . . . . . . . . . . . 20

2.4 Examples of control flaws leading to hazards, as depicted by Nancy G.Leveson in Engineering a Safer World, Systems Thinking Applied toSafety, published by The MIT Press [2] . . . . . . . . . . . . . . . . . . 22

3.1 GCDC merging procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 Prototype architecture provided by the GCDC developers . . . . . . . . 283.3 The preliminary architecture represented as a functional data flow dia-

gram. Green boxes represent item functionalities. Blue boxes representexternal functionalities. . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4 Expansion of the perception functionality . . . . . . . . . . . . . . . . . 313.5 Expansion of the control agent’s functionality . . . . . . . . . . . . . . . 313.6 Visualisation of the categories of collision . . . . . . . . . . . . . . . . . 33

4.1 Overview of the STPA in a safety guided design. . . . . . . . . . . . . . 404.2 Overview of safety guided design with STPA in accordance with the ISO

26262 standard. Part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3 Overview of safety guided design with STPA in accordance with the ISO

26262 standard. Part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.4 Safety constraint assignment according to the STPA method . . . . . . 484.5 Relationship between safety goals, functional safety requirements and

subsystem allocation according to the ISO 26262 standard. . . . . . . . 484.6 Process to undergo when adding optional STPA step 1 loops. . . . . . . 504.7 Planner to vehicle control loop for case 1 . . . . . . . . . . . . . . . . . 574.8 Planner to vehicle control loop for case 2 . . . . . . . . . . . . . . . . . 58

4.9 Planner to vehicle control structure loop for case 3 . . . . . . . . . . . . 584.10 Results from STPA step 2, for case 1. Analysing causes for: A lane

change is performed when the target lane is occupied. . . . . . . . . . . 604.11 Results from STPA step 2, for case 2 Analysing causes for: A lane change

is performed when the target lane is occupied. . . . . . . . . . . . . . . 604.12 Results from STPA step 2, for case 3 Analysing causes for: A lane change

is performed when the target lane is occupied. . . . . . . . . . . . . . . 614.13 Augmented architecture, case 1. . . . . . . . . . . . . . . . . . . . . . . . 624.14 Results of second iteration of STPA step 2, case 1, Analysing for causes

for: A lane change is performed when the target lane is occupied. . . . . 624.15 Results from an STPA regarding false data transmission in case 3. Analysing

causes for: TX data is false. . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.1 Concluding architecture for Case 1. . . . . . . . . . . . . . . . . . . . . . 675.2 Augmented architecture for case 2 . . . . . . . . . . . . . . . . . . . . . 685.3 Overview of the functional architecture of two vehicles communicating

over V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.4 Overview of the augmented architecture . . . . . . . . . . . . . . . . . . 71

List of Tables

2.1 ASIL assessment table . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Example of STPA step 1 table. . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 Accident and corresponding hazards . . . . . . . . . . . . . . . . . . . . 343.2 Accident and corresponding hazards . . . . . . . . . . . . . . . . . . . . 34

4.1 Levels of trust in external signals for the three case studies. . . . . . . . 524.2 Functional safety requirements for cases 1 and 3; trust and partial trust

in external information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.3 Functional safety requirements for case 2; no trust in external information 554.4 Refined Functional safety requirements for the perception functionality

for case 2; no trust in external information . . . . . . . . . . . . . . . . 564.5 Refined Functional safety requirements for parts of the agent controllers,

for all cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.6 Results from STPA step 1 for the reference path update control action,

for all three cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Chapter 1

Introduction

This chapter is intended to introduce the reader to the study, present and motivatethe topics of interest, as well as the methods used.

1.1 Background

This section provides the reader with the required knowledge to conceive the prob-lems covered by this study.

1.1.1 Introduction to co-operative driving

Co-operation between drivers is a necessity in any multi-vehicular traffic situation,and it requires communication. Traditional tools and techniques for communicatingintended actions include, among other things, indicators, stop lights, lane position-ing and speed adjustments. These allow drivers to estimate the future state oftheir environment and plan accordingly to avoid hazardous situations. However,the communication provided by these tools and techniques is limited by a numberof factors, such as the means of delivery. All the methods mentioned rely on visualprocessing on the receiving side, thus creating the requirement of line of sight, andthe difficulty of maintaining communication in the dark. Another limiting factor isthe amount of information that can be delivered. For example, indicators broad-cast the intention of deviating from the current lane. They do not tell when this isgoing to happen. A third limiting factor is the poor ability to acknowledge receivedintentions. Acknowledging can be done using the same techniques as when broad-casting intensions, i.e. through lane positioning and speed adjustment, but theseare transient operations and take time.

In modern terms, co-operative driving does not refer to the traditional meth-ods of co-operation, but is rather synonymous to the terms connected driving andnetworked driving. It is the concept of road vehicles and road infrastructure, ex-changing digital information, such as intentions and vehicle states, to overcome thelimitations of traditional driver to driver communication.

1

CHAPTER 1. INTRODUCTION

With wireless digital data transfers as the means of communication, line of sightis a less limiting factor. Ambient visible light spectrum conditions are no longer arelevant factor. Computational systems, embedded in the vehicles, can speed upthe process of estimating future environmental states. Further, the communicationbandwidth can be increased, so that the amount of information to be communicatedcan be increased without increasing the ambiguity of the messages.

The benefits of co-operative driving are believed to include more fluid and ef-ficient traffic situations, leading to less congestions and eco-friendlier driving. In-creased communication abilities will also lead to a better understanding, more pre-cise traffic predictions, and overall safer traffic experience.

Current development towards co-operative driving in Europe include the de-velopment of a standard for co-operation between intelligent transport systems, C-ITS[3] . Based on this in-development-standard, the European commission supportsan international project to speed up the implementation of co-operative driving. Aspart of this project, a competition between universities in co-operative driving is or-ganised every fourth year: The Grand Co-operative Driving Challenge (GCDC)[4].

1.1.2 Introduction to autonomous vehicles

While co-operative driving in it self does not imply autonomous vehicles, this studyconsiders automating co-operative driving.

The level of automation is increasing in modern road vehicles. Today, func-tionalities such as Adaptive Cruise Control (ACC) and other Advanced Driver As-sistance Systems (ADAS) are becoming more frequent, and the idea of future fullyautonomous vehicles, seems increasingly realistic. There are several metrics to mea-sure the level of automation in vehicles. The U.S Department of Transportation’sNational Highway Traffic Safety Administration (NHTSA) and the Federal HighwayResearch Institute (BASt) of the German government, have both released policiesdefining five different levels of vehicle automation[5] [6] . In terms of standardisa-tion, SAE International’s On-Road Automated Vehicle Standards Committee havereleased the standard SAE standard J3016: Taxonomy and Definitions for TermsRelated to On-Road Motor Vehicle Automated Driving Systems, in which six levelsof automation are defined. All references to levels of automation in this thesis, willrefer to the SAE standard J3016.

The six levels of automation defined by the standard are:

• Level 0: No AutomationAt this level, the human driver handles every part of the driving and the monitoringof the driving environment

• Level 1: Driver AssistanceAt this level, a driver assistance system handles either lateral or longitudinal controlof the vehicle, while the human driver monitors the driving environment and is readyto intervene when necessary.

2

1.1. BACKGROUND

Summary of Levels of Driving Automation for On-Road Vehicles This table summarizes SAE International’s levels of driving automation for on-road vehicles. Information Report J3016 provides full definitions for these levels and for the italicized terms used therein. The levels are descriptive rather than normative and technical rather than legal. Elements indicate minimum rather than maximum capabilities for each level.

“System" refers to the driver assistance system, combination of driver assistance systems, or automated driving system, as appropriate.

The table also shows how SAE’s levels definitively correspond to those developed by the Germany Federal Highway Research Institute (BASt) and approximately correspond to those described by the US National Highway Traffic Safety Administration (NHTSA) in its “Preliminary Statement of Policy Concerning Automated Vehicles” of May 30, 2013.

Leve

l

Name Narrative definition

Execution of steering and acceleration/ deceleration

Monitoring of driving

environment

Fallback performance of dynamic driving task

System capability (driving modes) BA

St

leve

l

NH

TSA

le

vel

Human driver monitors the driving environment

0 No Automation the full-time performance by the human driver of all aspects of the dynamic driving task,

even when enhanced by warning or intervention systems Human driver Human driver Human driver n/a Driv

er

only

0

1 Driver Assistance

the driving mode-specific execution by a driver assistance system of either steering or acceleration/deceleration using information about the driving environment and with the expectation that the human driver perform all remaining aspects of the

dynamic driving task

Human driver and system Human driver Human driver

Some driving modes As

sist

ed

1

2 Partial Automation

the driving mode-specific execution by one or more driver assistance systems of both steering and acceleration/deceleration using information about the driving environment

and with the expectation that the human driver perform all remaining aspects of the dynamic driving task

System Human driver Human driverSome driving modes Pa

rtial

ly

auto

mat

ed

2

Automated driving system (“system”) monitors the driving environment

3 ConditionalAutomation

the driving mode-specific performance by an automated driving system of all aspects of the dynamic driving task with the expectation that the human driver will respond

appropriately to a request to intervene System System Human driver

Some driving modes H

ighl

y au

tom

ated

3

4 High Automation

the driving mode-specific performance by an automated driving system of all aspects of the dynamic driving task, even if a human driver does not respond appropriately to a

request to intervene System System System

Some driving modes

Fully

au

tom

ated

3/4

5 Full Automation the full-time performance by an automated driving system of all aspects of the dynamic driving task under all roadway and environmental conditions that can be managed by a

human driver System System System All driving modes

-

cyberlaw.stanford.edu/lodaFigure 1.1. Description of the levels of automation according to the SAE standardJ3016, and their relationships to the levels of automation defined by NHTSA andBASt. Illustrated by Bryant Walker Smith, originally published by the Stanford LawSchool[1].

• Level 2: Partial AutomationAt this level, both lateral and longitudinal control is automated, but the human drivermonitors the driving environment and is ready to intervene when necessary.

• Level 3: Conditional AutomationAt this level, lateral and longitudinal control, as well as primary driving environmentmonitoring is automated, and the driver is ready to take over upon request.

• Level 4: High AutomationAt this level, the vehicle is capable of automation under certain roadway and envi-ronmental conditions, without driver intervenience .

• Level 5: Full AutomationAt this level, the vehicle handles all aspects of the driving and monitoring, under allroadway and environmental conditions.

[7]

The levels and their relationship to the NHTSA and BASt definitions are illus-trated in Figure 1.1

3


1.1.3 Introduction to automotive functional safety

Functional safety is a critical aspect of automotive development. While automo-tive vehicles used to be purely mechanical, they now increasingly rely on Electricaland/or Electronic (E/E) systems[8]. Thus, more safety critical functionalities arebeing implemented in embedded E/E systems and software. Examples of such func-tionalities are the previously mentioned ACC, anti-lock breaking systems, collisionwarning systems and air bag systems. The embedded systems handling these func-tionalities are also considered safety critical, and safety measures must be takenwhen dealing with them.

To make sure a product is fit for its purpose, standards are used. They providerequirements, specifications, guidelines and characteristics to ensure safety, relia-bility and quality[9]. ISO (the International Organisation for Standardization) isone organisation issuing standards, who in 2011 released the standard, ISO 26262:Road vehicles - Functional safety, [10]. This standard provides guidance in termsof requirements and processes to appropriately deal with functional safety in auto-motive (E/E) systems. Complying with this standard is the current best practicein the automotive industry.

The ISO 26262 standard specifies a lifecycle for functional safety of automotiveE/E systems. The lifecycle contains the following three phases:

• The concept phase

• The product development phase

• The after release for production phase

Each phase then has its sub activities[11]. For this study, the concept phase androughly the first half of the product development phase are of particular importance,since catching flaws and mitigating hazards early in the design process reduces thedevelopment costs.

Even though the ISO 26262 standard is a relatively young standard, the methodsit recommends are old. Some so old, that they were originally developed for purelymechanical systems. Critique against these methods include their inability to copewith the level of complexity of modern products[2].

1.1.4 Introduction to Systems-Theoretic Process Analysis

Systems-Theoretic Process Analysis (STPA) is a modern safety analysis methoddeveloped by N. Leveson. In her book, Engineering a Safer World, Systems ThinkingApplied to Safety, 2011[2], she points out the need for a new analysis method. Shebases this on the raising complexity of E/E systems, software dependencies andinadequacy of the current best practise methods, such as Failure Mode and EffectsAnalysis (FMEA), Fault Tree Analysis (FTA) and Event Tree Analysis (ETA)[23].She argues that those methods are based on the assumption that a system is safeif it’s components don’t fail. In other words, if the components are reliable, the

4

1.2. QUESTIONS OF INTEREST

system will be safe. While this might have been true in the past, when the itemsof analysis were mechanical items, with easily understood connections, she says, itis no longer the case with todays complex products, where unforeseen behavioursmay emerge due to the interactions between components and subsystems[2].

As a response to this need, Leveson then presents a new causality model,Systems-Theoretic Accident Model and Processes (STAMP), which accounts fornew causal factors associated with the increasing complexity, software dependen-cies, human-decision making, social and organisational design, and new technology.STPA is based on STAMP and focuses on maintaining controllability of the sys-tem, to prevent hazards, rather then maintaining reliability. It is a general analysismethod, studied in the context of several industries, such as aeronautics, astronau-tics, automotive, medical equipment and chemical plants.

1.2 Questions of interestThis section is intended to motivate the study.

1.2.1 Problem motivationSTAMP and STPA are hypothesised to be well suited for safety analysis of automo-tive E/E systems, in the complex context of co-operative driving, due their successin other fields[12] [13] [14]. STPA is a generic safety analysis method which has notbeen scientifically tested in the particular context of co-operative driving. It hashowever been applied in other automotive domains, with success[15]. Furthermore,since the automotive industry’s best practice is to follow the ISO 26262 standard,it must also be determined how well, and where, STPA and the systems thinkingapproach fits within the ISO 26262 standard.

Automating co-operative driving raises the issue of external reliability. For co-operative driving vehicles of a SAE automation levels higher than 2, the responsi-bility of safety is moved from the driver, to the system. Without the driver in theloop, the importance of the ability to trust the information from other co-operativevehicles is increased from a functional safety point of view. Excluding the topicof security: how can trusting external information be motivated, knowing that thesource of that information might be faulty and the data misleading?

1.2.2 Research questionsTwo research questions are formulated in this thesis. The first one, related to theadaptation between STAMP-STPA and the ISO 26262 standard, is focused on themethod usage and appliance in the todays best practice standard of ISO 26262.The research question is formulated as:

• What part or parts of the ISO 26262’s lifecycle’s concept phase and product develop-ment at system level, can be assisted by STAMP modelling and the STPA method,to achieve a structured process?

5


The second research question relates to the specific context of co-operative driv-ing. Its focus is the potential difference in architectural design freedom, and thepossibilities that come with trusting external information. The research questionformulation is:

• What can the architectural impacts be, of varying the level of trust put in incomingtransmissions, while maintaining an adequate level of functional safety, under theassumption that signals external to the host vehicle can be faulty?

Host vehicle refers to the platform on which the co-operative driving logic is imple-mented.

Since co-operative driving is a complex concept, the second research questionis hypothesised to best be analysed using STAMP and STPA. Since co-operativedriving can be seen as a subdomain to the automotive domain, the STAMP andSTPA appliance to the automotive industry best practices must be considered.Therefore, the first research question must be answered before studies on the secondone can begin.

1.2.3 ScopeThe study aims to present a development process which makes use of STAMP andSTPA in accordance with the ISO 26262 standard, for safety guided design. Bothof the research questions are analysed in the context of co-operative driving and thefollowing delimitations apply:

• A post-transition state to co-operative driving is assumed throughout thestudy. I.e. all vehicles are assumed to be capable of co-operation in accordancewith the C-ITS standard[3].

• Standards concerning safety, other than the ISO 26262 are considered out ofscope.

• The ISO 26262 lifecycle is only considered up until the system design subactivity of the product development phase.

• The ISO 26262 step Verification of functional safety concept, as well as admin-istrative tasks, such as project planing, are considered out of scope as theseare in separate documents in the standard.

• Functional safety is considered solely during dynamic driving.

• Functional safety is only considered at system level, excluding hardware andsoftware specifics.

• The topic of security is considered out of scope.

For the second research question, the scope is limited to thee levels of trust: fulltrust, no trust, and trust upon independent confirmation.

6

1.3. METHOD

1.3 Method

This section presents the method to be used in this study.

1.3.1 Literature study

A literature study is conducted, focusing on STAMP, STPA and the ISO 26262 stan-dard. It is conducted digitally, using the abstract and citation database Scopus[16].Topics of particular covert are appliance of STPA in co-operative driving scenar-ios, STPA in the automotive domain, STPA in relation to industrial standards andcurrent perceived issues with STPA or the ISO 26262 standard.

Scopus is published by Elsevier and claims to be the largest abstract and citationdatabase of peer-reviewed literature online, with over 60.000.000 items. The largestpublishers indexed in Scopus make up approximately 40% of the indexed files andcan be found listed on the Scopus webpage[16].

Scopus is therefore considered to have a wide enough coverage to be the onlyused index database for this literature study. Full versions of the search results areaccessed at the respective publishers’ databases. KTH’s subscriptions services tothe different publishers is thus a further limiting factor.

Apart from the indexed searches, information is also retrieved from recommenda-tions from domain experts. Three mentionable sources of information, not accessedthrough indexed search engines, are the book Engineering a Safer World, by N.Leveson [2], the SAE J3016 standard, and the ISO 26262 standard.

1.3.2 Pre-study

As STPA has not been studied in the context of co-operative driving, its eligibilityin the context can not be confirmed by any existing related work. Therefore, theeligibility in the specific context is first evaluated in a pre-study. Such evaluationserves the purpose of motivating whether or not STPA is a valid method for usein this study. To ensure validity and realism in the evaluation, a case study isperformed. The case used is the development of a co-operative driving module itemat the KTH Integrated Transport Research Lab (ITRL). As part of the development,the STAMP causality model, and STPA is utilised for functional safety analysis.

The focus of the literature study is STAMP and STPA in automotive relatedcontexts, STAMP and STPA in the context of co-operative driving, and applicationsof the ISO 26262 standard.

1.3.3 Process design

Designing the process for STPA usage in accordance with ISO 26262 is conductedthrough abductive reasoning. The goal is to describe a way to develop E/E systemsin an automotive and co-operative driving context, using STAMP and STPA. Theprocess shall comply with the ISO 26262 standard, while utilising the advantages of

7


STAMP and STPA when possible. The process design is based on the informationgathered through the literature-, and pre-studies.

Designing any process is hypothesised to involve an intrinsic element of cre-ativity, making deductive reasoning unfeasible due to the possible lack of strictderivation from the premises. Instead, decisions regarding the process are based onexpert knowledge from domain experts, the pre-study development team and theGCDC organisers validation, as well as experience and knowledge gained from theliterature-, and pre-studies. Inductive reasoning is also unfeasible, since statisticalsignificance can not be derived from a single case study. Hence abductive reasoningis practised during this part of the study. Therefore, this study does not aim toderive the best generic process there can be, but the best process considering thedata at hand, and that which can be gathered during the time of this master thesis.Further development of this process is encouraged as more data become available.

1.3.4 Architectural case studiesThree case studies are performed to investigate the architectural impacts of varyingthe level of trust put in incoming transmissions. The three cases share foundationwith the preliminary case study, but differs in the preliminary assumptions regardinglevels of external trust. To verify the STAMP-STPA in accordance with ISO 26262process, it is used throughout all three cases. However, functional safety issues whichare invariant to the cases’ different preliminary assumptions are not expanded upon,as the purpose of these cases is not to derive a full safety report. These analysescontinue to a point where the preliminary assumptions create an evident differencein the design space between the three cases. The options and potential solutionsare then discussed.

The different preliminary assumptions for the three cases regard the amount oftrust which can be placed in data retrieved through co-operative driving communi-cation means. The three cases are:

1. Data received from external vehicles can be trusted.

2. Data received from external vehicles can not be trusted.

3. Data received from external vehicles can only be trusted if it can be confirmed by atleast one other independent source.

8

Chapter 2

Frame of Reference

This section contains information regarding the methods and tools used in thisstudy. It is the result of the literature study, and is meant to provide the readerwith the information that he / she requires to interpret the remainder of the thesis.

No previous research regarding STAMP-STPA in the context of co-operativedriving was found. However, STAMP and STPA have been used in other automotiverelated fields.

2.1 Automotive functional safety

Functional safety standards for automotive E/E systems existed before the releaseof ISO 26262 in 2011, as several different standards covering different aspects. TheISO 26262 is built on other such automotive standards and related work, such asASPICE, MISRA-SA, MIRSA and AUTOSAR, which in turn, based part of theircontent from more generic standards, such as ISO/IEC-15504 and IEC-61508[17].

The standard consists of ten parts, describing safety management, the productlifecycle, suggested analysis processes and safety guidelines. The product lifecyclecan be divided into three phases: The concept phase, the product developmentphase, and the after the release for production - phase. The Concept phase consistsof four sub activities: The item definition, the initiation of the safety lifecycle, thehazard analysis and risk assessment and the functional safety concept. The productdevelopment phase consists of three activities: operation planning, production plan-ning and system level product development. The system level product developmentthen contains hardware level product development, software level product devel-opment, safety validation, functional safety assessment and release for production.The after the release for production - phase consists of two activities: Productionand Operation, service and decommissioning. This phase is not covered in thisstudy, as it is considered out of scope. An overview of the lifecycle can be seen inFigure 2.1

9

CHAPTER 2. FRAME OF REFERENCE

Item definition

Initiation of the safety lifecycle

Hazard analysis and risk assessment

Functional safety concept

Concept

Product developmentat system level

H.Wlevel

H.Wlevel

Safety validation

Functional safety assessment

Release for production

Production

Operation, serviceand decommissioning

Product developm

entA

fter the release for production

Figure 2.1. Automotive lifecycle according to the ISO 26262 standard

2.1.1 ISO-26262 Concept phaseISO 26262: Item definition

The item definition is a description of the system to be developed. It describesand defines the item, as well as its external dependencies and interactions. It alsoprovides enough understanding of the item, for the other phases. The followingpoints shall be specified:

• The functional concept

• The purpose and functionality

• Operational and environmental constraints

• Legal requirements

10

2.1. AUTOMOTIVE FUNCTIONAL SAFETY

• Standards to be followed

• Assumed expected behaviour

• Other items with similar behaviour

• Potential known consequences of behaviour shortfalls

• The elements of the item

• Interactions with other items or elements

• Functionalities required from and by externals

• The allocation and distribution of functions among involved systems and elements

• Functionality impacting operating scenarios

[11]

Initiation of the safety lifecycle

During the initiation of the safety lifecycle, all upcoming safety lifecycle activitiesare defined. The item definition can describe one of two things, either it is a newdevelopment, or it it a modification of an existing item. In the later case, an impactanalysis is carried out, and the existing safety plan is refined[11].

Hazard analysis and risk assessment

The hazard analysis and risk assessment identify and categorise all hazards (H)and create safety goals (SG) to prevent or mitigate those. The item’s Operationalsituations and modes are reviewed, and those which may lead to a hazardous eventare described. All hazards and their consequences are then determined systemat-ically for all relevant operational situations. They are defined in terms of vehicle-wide conditions or behaviour, for the item. The standard suggests methods suchas brainstorming, checklists, quality history, Failure Modes and Effects Analysis(FMEA) and field studies, for this task. As R. Barbosa and J. Karlsson point out,the method of choice must allow for prediction of behaviour, by extrapolation fromprevious measurements and data[18].

When all hazards are believed to be identified, they are classified with an Au-tomotive Safety Integrity Level (ASIL). These integrity levels range from A to D,based on severity, exposure and controllability. A is the highest integrity level, andD is the lowest.

Severity is the potential harm that a hazard can cause. It is classified on ascale from S0 to S3.

• S0 corresponds to no injuries to any person. This is if the consequences are limitedto material damage.

• S1 corresponds to light and moderate injuries.

11


• S2 corresponds to severe and life-threatening injuries where survival is probable.

• S3 corresponds to fatal and life-threatening injuries where survival is uncertain.

Exposure is the probability of the operational situations based on a represen-tative sample of operational situations for the target market. It is classified on ascale from E0 to E4.

• E0 corresponds to an incredible probability of exposure

• E1 corresponds to a very low probability of exposure

• E2 corresponds to a low probability of exposure

• E3 corresponds to a medium probability of exposure

• E4 corresponds to a high probability of exposure

Controllability is based on how likely it is for the driver or others in risk tocontrol the hazardous event so that harm is avoided, should the hazard occur. Forthis classification, the driver is assumed to be complying with legal regulations, hasproper training, and is in an appropriate condition to drive. Other drives actionscan also contribute to the controllability. Controllability is classified on a scale fromC0 to C3.

• C0 corresponds to the hazard being controllable in general

• C1 corresponds to the hazard being simply controllable

• C2 corresponds to the hazard being normally controllable

• C3 corresponds to the hazard being difficult to control or uncontrollable.

When severity, exposure and controllability have been determined, the ASILshall be determined according to Table 2.1. Any hazard with a severity of S0, anexposure of E0 or a controllability of C0 is not assigned any ASIL. The additionalclass of quality management (QM) denotes a hazard not related to any ISO 26262compliant requirements.

A safety goal (SG) is determined for each hazard that is assigned an ASIL. Ifseveral SG’s are similar, they can be combined. Each SG is assigned the ASIL ofthe highest ASIL rated relating hazard. If some system safe state can fulfil a safetygoal, this shall be specified.

If, during the development, a requirement with an assigned ASIL is refinedinto two independent requirements that are redundant to each other, their safetyintegrity levels can be a decomposition of the original requirement. A decomposedASIL typically has its parents ASIL as a suffix, in parenthesis, to keep track of theinitial level. An ASIL D requirement can be decomposed into one the following.

• One ASIL C(D) and one ASIL A(D)

12


Table 2.1. ASIL assessment table

Severity class Probability class Controllability class

C1 C2 C3

S1

E1 QM QM QME2 QM QM QME3 QM QM AE4 QM A B

S2

E1 QM QM QME2 QM QM AE3 QM A BE4 A B C

S3

E1 QM QM AE2 QM A BE3 A B CE4 B C D

• Two ASIL B(D) requirements

• One ASIL D(D) and one ASIL QM(D)

an ASIL C requirement can be decomposed into one of the following:

• One ASIL B(C) and one ASIL A(C)

• One ASIL C(C) and one ASIL QM(C)

an ASIL B requirement can be decomposed into one of the following:

• Two ASIL A(B) requirements

• One ASIL B(B) and one ASIL QM(B )

This allows specific parts of choice, to be developed with less strict requirements.The hazards, operational situations, compliance with the item definition, and

the consistency of the safety integrity levels shall be verified when all SG’s aredefined and classified[11].

Functional safety concept

The functional safety concept is a strategy to comply with the safety goals. Itderives functional requirements from the safety goals and assigns them to the ar-chitectural elements of the item. For each safety goal, at least one functional safety

13


requirements (FSR) is derived. Operating modes, fault tolerant time intervals, safestates, emergency operation intervals and functional redundancies are consideredwhen deriving these. The standard suggests using a safety analysis technique forthis, such as, FMEA, Fault Tree Analysis (FTA) or HAZards and OPerability (HA-ZOP) analysis. This part has been criticised as vague, and other methods have beendeveloped to deal with the creation of functional safety requirements. For example:G. Krithivasan et al. present a method based on process models that work muchlike a variant of Systems Theoretic Process Analysis, developed by J. Thomas’s[2].However, even though this is a structured approach, they say that the experienceof the system engineers and their level of knowledge is crucial for success[19] .

The functional safety requirements are assigned to the preliminary architecturalelements, which inherit the ASIL of the highest allocated functional safety require-ment. If, however, the responsibility of assuring a functional safety requirementis split up and allocated onto more than one independent architectural element,and those elements perform the same task, then the ASIL can be decomposed. Allexternal functionalities and measures that the item or the functional safety conceptrely on, get derived safety integrity levels and functional safety requirements, andtheir interfaces are specified. Their implementation is not within the scope of theISO 26262 standard, but there are methods developed, to assist in the process. Forexample, L. Azevdo et al. presents a tool to automatically decompose and assignsafety requirements[20]. The functional safety concept shall also include validationcriteria based on the functional safety requirements. It is verified in terms of con-sistency and compliance with safety goals and its ability to avoid and mitigate thehazards[11].

Critique to the functional safety concept description include that it’s final struc-ture is not defined. This can lead to inconsistencies, which make it harder to verifythe content[21]. K. Beckers et al. present a solution to this: a model based approachto functional safety requirements derivation together with a UML profile to expressall the required parts of the safety concept[22] . P. Antonio and M. Trapp presentanother format of structuring the safety concept. They point out that the safetyconcept and the system architecture usually are created by different people, andtherefore get disassociated. In their proposed structure is a method of formalisingthe format of the requirements, to attempt to close this disassociation[21].

2.1.2 ISO-26262 System level product development phaseThe system level product development phase consists of

• Initiation of product development at system level

• Specification of the technical safety requirements

• System design

• Hardware and Software product development

• Item integration and testing

14


• Safety validation

• Functional safety assessment

• Release for production

Initiation of product development at system level

The first step of the system level product development, is to plan out the processand activities to be done. This includes refining the project plan, tailoring thelifecycle, making validation plans, refining the safety assessments and planning foritem integration and testing.

Specification of the technical safety requirements

The safety goals, functional safety concept, and preliminary architectural assump-tions are used to derive technical safety requirements (TSR). The technical safetyrequirements are refinements of the functional safety requirements, with technicalaspects taken into account[21] . The safety integrity levels of the functional re-quirements are inherited by the technical safety requirements. Decomposition ispossible, if the requirements for such are fulfilled. The standard specifies a numberof requirements on the final technical safety concept, but not how to derive them.

System design

The actual design of the system shall be based on the technical safety requirements,the preliminary architecture as well as the specification of the item. The technicalrequirements are allocated to the different architectural elements, and as the safetyintegrity levels are inherited down the process, they shall be taken into accountwhen designing the system. If an element implements multiple technical safetyrequirements, the higher ASIL is inherited.

As part of the system design process, measures for avoiding systematic fail-ures are taken. Such measures include safety analyses, which can be performeddeductively or inductively. Deductive methods suggested by the standard are FTA,reliability block diagrams and Ishikawa diagrams[23]. Inductive methods suggestedare FMEA, Event Tree Analysis (ETA) and Markov modelling[23]. Other measureshave been presented for the process as well. H. Zhang et al. present a model basedapproach which combines FMEA and FTA for a more thorough analysis, wherethe FTA provides structure for the FMEA[8]. Both the inductive and the deduc-tive methods have however received critique for relying on the detail of the failuremodes of the components[24]. G. Krithivasan et al. suggest using the process modelbased method, previously mentioned in the concept phase description, for either in-ductive or deductive safety requirements[19]. Both internal and external causes ofsystematic failures shall if possible be eliminated. Otherwise, their effects shall bemitigated. Well-trusted automotive systems design principles shall be applied, such

15


as re-using of technical safety concepts, designs, mechanisms and standardised in-terfaces. This is especially important for ASIL D elements. As the design is refined,measures for control of random failures are taken, all technical safety requirementsare allocated to hardware and software, and all hardware-software interfaces arespecified. The requirements for these measures vary with the safety integrity levelsof the elements and functionalities.

A. Ismail and W. Jung state that most steps of the development are not de-scribed in detail by the ISO 26262 standard. This creates an area where manystudies and research can be further explored[25]. Some exist, such as H. Zang etal.’s approach, which deals with the lack of explicit instructions in the standard. byintroducing an expansion of the V-model, where the suggested methods from thestandard are combined.

This concludes the description of the parts of the ISO 26262 standard, consideredin scope with this study.

2.2 Systems-Theoretic Process Analysis

Traditional hazard analysis methods are based on assumptions that are not all validanymore. This includes for example the assumption that safety can be ensured byensuring that the individual components don’t fail. Such assumption implicitly as-sumes that the system is working as intended as long as nothing fails. In otherwords, that no design errors exist in the system. While design flaws might havebeen easy to spot and avoid in the past, that is no longer the case in modern, com-plex products. A modern car can contain more than a hundred embedded ElectricControl Units (ECU) that interact with each other as well as with the mechanical,thermo dynamical and chemical processes, required to fulfil today’s demands. Therisk for design flaws increases with the number of components and the complexityof their interactions. Accidents can occur even though no individual componentfails, as N. Leveson explains with various real world examples[2]. A reliable systemis not necessarily a safe system. Therefore, according to Leveson, safety shall notbe viewed as a reliability problem, but as a control problem. For example: Eventhough all components in some system are reliable and function just as intendedindividually, their combined effect might not have been predicted accurately due tohigh complexity. Systematic design flaws might exist in the system, causing it to behazardous even though no failures occur. On the other hand, even if a componentfails in a system, the system will not be hazardous if it is still controllable and canbe brought to a safe state. It should be noted, that Leveson also states several otherreasons for why something different from the traditional hazard analysis methodsis needed.

STPA is based on a system-centric causality model called Systems-Theoretic Ac-cident Model and Processes (STAMP). In systems theory, a system can be describedin different hierarchy levels where each level is more complex than the ones below.Each level is characterised by emergent properties that appear only on high enough

16

2.2. SYSTEMS-THEORETIC PROCESS ANALYSIS

Accidents

Hazards

Control structure

STPA step 1

STPA step 2

Figure 2.2. A coarse overview of the building blocks of the STAMP-STPA method

levels[2]. In STAMP, safety is considered an emergent property in modern products.It is therefore important to see the system as a whole, and its context, to sufficientlyconsider safety. Even when looking at individual subsystem and subcomponents,their behaviour cannot be fully understood without the overall picture.

The overall process of STPA is typically divided into two steps and the preced-ing process of creating a STAMP model. The creation of a STAMP model involvesdefining accidents, identifying hazards and deciding on a preliminary control struc-ture. Figure 2.2 illustrates an overview of the process.

For the remainder of this section, the different parts of the STAMP-STPA pro-cess will be described in more detail.

2.2.1 Accidents

The STAMP causality model uses a top-down approach, to meet the systems-theorymethods. The first step in constructing a STAMP model, is to state unacceptablelosses at system level. These are called accidents and are defined as

”an unplanned and undesired loss event”.Note, that this does not only include bodily injuries and death, but can, if

desirable, include any unacceptable loss, such as property damage, environmentalpollution or financial loss. What is considered an accident, depends on the stake-holders. It is at this level, that the scope of the analysis is set. In some cases,the analysts might decide on the accidents. In other cases, the stakeholders mightalready have a set of accidents that need to be considered. For example, there canbe governmental rules and legislations that the product needs to obey.

Once the accidents are defined, the idea is to enforce safety, by constraining the

17


behaviour and interactions between the components, putting them in the controlspace. In other words, impose system level safety requirements / constraints tokeep the system in a safe state, and thereby avoid the accidents. These system levelrequirements / constraints shall later be refined and assigned to subsystems.

2.2.2 Hazards

To specify the system level requirements / constraints, the system hazards must beknown. A hazard in STAMP-STPA is defined as

”A system state or set of conditions that together with a worst-case set of envi-ronmental conditions, will lead to an accident (loss)”.

Since safety is ensured through control, this definition of a hazard emphasisesthe importance of controllability and environmental dangers. The hazards mustbe defined in a way such that they can be controlled either through design by thedesigner, or operation by the operator. If a hazard is not controllable, nothing canbe done to prevent it. In such case, the system boundaries need to be looked over,or the hazard needs to be reformulated to fit within the controllable space. Forexample, with the STAMP mind-set, a child running out in front of a car is notconsidered a hazard for a car manufacturer. It can lead to an accident, but thisis not controllable. Instead, the car manufacturer can define the hazard as havinga too large velocity, to be able to stop in time and thus putting the hazard in thehands of the designer and operator, giving them the responsibility to prevent theaccident. On the other hand, for a city planner, a child running out in front ofa car, can be within the design space, when planning roads, schools etc. So thecontrollability depends on the system boundary and the formulation of the hazards.

The part ”...with a worst-case set of environmental conditions...” ensures thatthe hazard is relevant. If there are no set of environmental conditions that leadto the accident, then there is no need to consider the hazard. For example, a cardrifting off lane can be a hazard leading to the accident A collision with anothercar. The worst case condition here, is that there is another car in the next lane.However, in the hypothetical case where some higher level infrastructural systemmakes sure that two cars can never be driving in parallel. Then, at the car level,the worst-case scenario does not exist, and the hazard is redundant, since it cannever lead to the accident: A collision with another car.

Hazards can be either events such as loss of traction for a car, or conditions assuch not fulfilling minimum separation distance between cars though it is importantto separate the hazards from the causes. If a hazard is defined as for examplefaulty distance measures to the vehicle in front, then that excludes all other causesfor potential violation of minimum separation between vehicles. One can perhapscompensate for this by finding all other causes and stating them as hazards in thesame way. However, by doing so, one can easily miss some causes, and a mayorpoint of the top-down approach is lost.

Once the accidents and hazards are defined, the hazards can be converted intosafety constraints and/or requirements. These will be high level constraints / re-

18


quirements, which are to be further refined by the STPA process.

2.2.3 Control structureWith the knowledge of the hazards, and the safety requirements / constraints, thenext step is to create a control structure. A control structure is a hierarchical way ofrepresenting the functions in an architecture in terms of controllers and controlledprocesses. Controllers and control loops make up the fundamentals of a controlstructure. The typical control loop consists of a controller, actuators, sensors and aprocess model. The process model is the controller’s representation of the controlledprocess’s state. It has three tasks[19]:

• To make sense of the current state of the process.

• To determine the desired state of the process.

• To activate the control actions, to take the process from its current state toits desired state.

The controller uses the information in this model to perform control actions to theactuator, to actuate the controlled process. It is then updated via the sensors, whichcloses the control loop. This process is illustrated in Figure 2.3

When designing the control structure, one can start by defining the differentinvolved actors and subprocesses. Next, identify who is capable of controlling who,through what means, and with what sensors. External interactions shall also beincluded, such as secondary controllers or disturbances. The different parts of thecontrol structure can be expanded and deepened to a suitable level. Later, duringthe STPA process, the control structure can change if architectural changes are con-sidered necessary. When the control structure, that is, the system level architecture,is considered adequate, the different safety constraints and/or requirements are tobe assigned to the different parts of the architecture.

For any controller to correctly control any process, it must have a model ofthe process’s state. Three things must be known to the controller: the currentvariables state, the way the controller can effect the state, and the relation betweenthe variables and actions. This holds true independent on whether the controller issoftware based on an embedded system, or a human operator. The model can bevery complex or very simple, depending on the process that is to be controlled.

2.2.4 STPA-step 1When a proper STAMP model has been created, the process of the STPA can begin.It is divided into two parts, referred to as STPA step 1, and STPA step 2. Thepurpose of STPA step 1, is to assess the controls of a system, to detect subsystemswith inadequate control that can lead to hazardous states. Inadequate control of aprocess can be categorised into five different categories of potential unsafe controlactions. These five categories are:

19


Figure 2.3. Illustration of a standard control loop, as depicted by Nancy G. Levesonin Engineering a Safer World, Systems Thinking Applied to Safety, published by TheMIT Press [2]

• A control action needed to ensure safety is not provided or executed

• A control action is provided that leads to a hazardous state

• A control action is provided too early, too late, or in the wrong order

• A control action needed to ensure safety is applied for too long, or stopped tosoon

• A control action is provided erroneously or inadequately

The first four categories of potential unsafe control actions, listed above, arecovered by STPA part 1. The last category is covered in STPA part 2.

Each combination of control action, defined in the control structure, and definedhazard, shall be checked against each of the first four categories of potential unsafecontrol actions. Situations where the control action, applied according the categoryof potential unsafe control actions, can lead to the hazard, shall be identified. Everysituation where this can happen, is considered an unsafe control action. The unsafecontrol actions are typically documented in a table, such as the example in Table2.2.

20


Controlaction

Notproviding

causeshazard

Providingcauseshazard

Providingtoo

soon/toolate/out ofsequence

causeshazard

Providingfor too

long/stoppedtoo sooncauseshazard

Controlaction 1

Unsafecontrol action

1


2


3


4...

Table 2.2. Example of STPA step 1 table.

Every category is not applicable to every control action. The fourth category;” Providing for too long/stopped too soon causes hazard” is for example, in mostcases, only applicable on continuous control actions. Should the communication ofa discrete off signal not be open for long enough, for the receiving end to receive thetransmission, then it would (for this thesis) be considered as not being provided atall, with potential causes being signal corruption, scheduler error etc. If an on-signalapplied over and over causes a hazardous situation, then it can be seen as if thefirst signal switches the system into an on-state, and the following signals causes ahazard due to being provided in the wrong state. If a system has several states, andthe states effect which control actions are unsafe, then it is necessary to investigateall states for all categories of potential unsafe control actions. John Thomas [26]presented a more rigorous and systematic approach to this, where all variables inthe process model are put in a table. Using this approach, each category of potentialunsafe control actions is mapped against all possible combinations of state variablesin the table, and all possible combinations of continuous variables’ boundary valuesand extreme values.

Once all unsafe control actions have been identified, they are to be translatedinto safety constraints and/or requirements. These constraints and/or requirementswill be refinements of the ones derived from the hazards. However, so far, noconclusions have been made regarding the enforcement of any of the constraints/ requirements. E.g. No analysis have been made regarding in which ways theconstraints / requirements can be violated and what the cause may be.

2.2.5 STPA-step 2

STPA step 2 is a causal analysis. For each unsafe control action, all the involvedparts of the control loop are analysed to see if and how they can cause, or helpcause, the unsafe control action to happen. The recommendation is to do thispart in a team with domain experts, since it is the part which relies the heaviest

21


Figure 2.4. Examples of control flaws leading to hazards, as depicted by Nancy G.Leveson in Engineering a Safer World, Systems Thinking Applied to Safety, publishedby The MIT Press [2]

on system knowledge, thought and prior experience[26]. There are causes thatfrequently occur, and guidelines for what to consider. However, one must not onlylook at these, since every case is unique and doing so can lead to undetected causes.

22

Chapter 3

Pre-study

This chapter covers the preliminary case study and it’s consequences on the remain-der of the thesis.

3.1 Context and case study descriptionSince the literature study did not reveal any previous cases of STAMP-STPA relatedto co-operative driving, it’s applicability in the context must be evaluated. Thepurpose of the pre-study is

1. To evaluate the STAMP causality model and the STPA method in the context ofco-operative driving.

2. To explore the problem space of the case and to find the orientation for the upcomingcase studies.

The item of the analysis is the co-operative driving module developed at ITRL.It is modelled as a control structure according to the STAMP causality model, andanalysed using STPA. Due to

• the STAMP-STPA method is a top-down approach, in which the number of sub-analyses to be conducted for each step and iteration can grow without any theoreticalboundary,

• time limitations,

• and the purpose of the pre-study

the pre-study case analyses only undergo one STPA iteration. It is conducted in abreadth-first-search manner, i.e. the problem space’s breadth will be explored beforeits depth. The safety analyses are documented in a safety report, and delivered tothe GCDC staff for participation approval.

The GCDC setup provides realistic testing scenarios for vehicles up to an SAEautomation level of two. KTH participates in the 2016’s GCDC with two vehicles:

23

CHAPTER 3. PRE-STUDY

one Scania truck and one prototype vehicle. The co-operative driving module isimplemented on both platforms.

The Scania truck is participating as an SAE automation level 1 vehicle, withautomated longitudinal control. Instructions regarding lateral control are sent to thedriver for compliance, proving the point that autonomous vehicles are not requiredfor co-operative driving.

The prototype vehicle, here after named the research concept vehicle (RCV) isa drive by wire vehicle with four actively controlled camber wheel hub motors and acentral ECU. It participates as an SAE automation level 2 vehicle, with automatedlongitudinal and lateral control.

3.1.1 Grand Cooperative Driving Challenge

In may 2016, The Grand Cooperative Driving Challenge (GCDC) is held for thesecond time. Ten different universities are competing, and the starting field containscars, trucks and prototype vehicles. Each competing vehicle is to participate in threescenarios:

1. Co-operation on highway

2. Co-operative intersection

3. Emergency vehicle

Scenario description

The scenario in scope of this study, is the co-operation on highway scenario. Itis meant to demonstrate advanced manoeuvres on the highway[27]. By utilisingco-operative driving, the vehicles are to resolve the situation while taking safety,traffic flow and energy efficiency. Two platoons, i.e. front steered convoys, are to bedriving side by side in separate lanes. A roadside unit (RSU), defined as a RoadsideIntelligent Transport System Station (R-ITS-S) form the ETSI’s EN302665 standard- Intelligent Transport Systems (ITS); Communications Architecture [28], is to givethe signal of an upcoming roadwork, telling the two platoons that one lane is closedup ahead. The left platoon, named platoon A, will thus have to merge into theright platoon, named platoon B. Two areas are defined: Competition zone 1 and 2.The merge is to take place in competition zone 1, which ends where the roadworksite begins. In the second competition zone, each vehicle will be judged based onhow accurate they hold the set distance to the frontal vehicle. Each platoon islead by a first vehicle (FV). This vehicle is throughout this study referred to as thelead vehicle. For the competition, this vehicle is a reference vehicle, driven by theorganisers to allow a fair evaluation of the participants’ performance throughoutdifferent heats.

The RSU communicates the position of the construction site, the maximum al-lowed speed, and the start time for the competition in advance. At the indicated

24

3.1. CONTEXT AND CASE STUDY DESCRIPTION

Merging vehicle

Platooning vehicle 1


Merging vehicle



Merging vehicle



Figure 3.1. GCDC merging procedure

start time, the participants negotiate for their position in the planned merged pla-toon. Vehicles in platoon B make room for the vehicles in platoon A, based on thisnegotiation. The vehicles in platoon A will merge sequentially, and shall have doneso before the end of competition zone 1[27].

The procedure for merging is as follows and is illustrated in Figure 3.1.

1. Merging vehicle adjusts its speed to match the platoon to merge with.

2. Merging vehicle sends a merge request.

3. Merging vehicle starts to make a gap to platoon vehicle 1.

4. As the merge request is made, platoon vehicle 2 starts to make a gap.

5. Platoon vehicle 2 makes safe distance checks. When the distance to vehicle 1is large enough, platoon vehicle 2 sends out the safe to merge signal.

6. Merging vehicle double checks the distance to vehicle 1.

7. Merging vehicle sends a merge request to its driver. When the driver confirms,the merge is performed.

25


3.1.2 Scope

Only the co-operation on highway scenario is included in the scope of this study. Thefollowing points further delimit the overall scope of this study, for this pre-study:

• The traffic on the road is assumed to be sparse

• All vehicles between the lead vehicle and the last vehicle of the platoon areassumed to take part in the platooning.

• The maximum speed limit is assumed to be 45 km/h, due to speed limitationsof the case platform.

• A driver is present in all vehicles, and has the final responsibility for safety.

• It is always the vehicle following’s responsibility to avoid collision

These scope extensions are in line with the GCDC setup and regulations.

3.1.3 Experimental setup

This experimental setup is used for the pre-study and, with minor exceptions, forthe three following cases.

Prototype architecture

The data for the case studies originates from a baseline in the co-operative moduledevelopment, taken on Mars 23, 2016. The GCDC developers present a proto-type architecture for the control structure, consisting of three layers with assignedexpected behaviour:

• Negotiation and supervisory control layer:

1. Activate, configure and deactivate the control agents2. Make traffic decisions based on the available information3. Manage communication

• Control layer:

1. Provide steering signals to the host platform2. Provide acceleration signals to the host platform

• Perception layer:

1. Estimate the state of the host vehicle2. Estimate the state of the surroundings

26


A visualisation is shown in Figure 3.2.There are four functionalities in the prototype architecture. The negotiation

and supervisory layer, as well as the control layer, each have one functionality,corresponding to the responsibility of the layer. The perception layer has its re-sponsibility divided in two: a host vehicle tracking functionality, and an objecttracking functionality. External dependencies are

• The host vehicle which needs acceleration and steering reference signals andreturns sensor data.

• External vehicles and infrastructure which communicate over vehicle to vehicle(V2V) and vehicle to infrastructure (V2I) communication.

For convenience, V2V and V2I will for the remainder of the report be referred totogether, as V2X.

Item definition

The need for the item can be formulated as:

• Need: A module capable of controlling the vehicle in a safe manner, accordingto the ISO 26262 standard, using the host vehicle’s sensors and co-operativecommunication with external vehicles and infrastructure.

The purpose of the item is to efficiently and safely execute the manoeuvresrequired for the situation. It is to analyse the surrounding traffic situation andsend directions to achieve to external dependent items. It is responsible for allnegotiation and autonomous decision making. It can be formulated as the goals:

• To receive, interpret, and base decisions on incoming co-operative drivingtransmissions

• To safely control a vehicle longitudinally and laterally.

• To ensure participation in co-operative driving scenarios by broadcasting thehost vehicle’s state and intentions in accordance with the GCDC specifica-tions.

The preliminary architecture is developed from the GCDC prototype architec-ture and is illustrated in Figure 3.3 Note: What is presented here is the baselinedversion of the preliminary architecture. Part of the pre-study consisted of derivingthis architectural setup and representation.

There are five defined external actors of the item:

• Other vehicles and infrastructure: RSUs and the other vehicles are communicatingfor negotiation and broadcasting their statuses and intentions. They are expectingthe same from the item

27


Supervisory control

Control agents

Hosttracking

Objecttracking

Host vehicle

controllersettings

Acceleration reference,steering angle

referenceHostdata

Object data

V2X

Sensordata

V2X

Human-machine-interface

Settings Info

Figure 3.2. Prototype architecture provided by the GCDC developers

• The host vehicle: This is the platform. It is responsible for physical manoeuvring,and collecting low level sensor data, such as velocity, steering angles etc.

• Driver: The driver shall interact with the vehicle when confirming merges and config-uring the scenarios. He / she shall also receive information necessary to evaluate thesafety of the situation. As a safety precaution, the driver can override the cooperativemodule at any time, as the steering wheel, break pedal and gas pedal are bypassingthe whole module, and connects directly to the low level drivers. This is to be donein an emergency. For the Scania truck platform, the driver is also responsible for thelateral control at all times.

• Co-driver: This actor is introduced for testing purposes. He / she has the control tomonitor and manipulate all variables in the system. This actor will be excluded fromthe analysis and diagrams, since it exists for testing purposes only, and is not meantto have this level of control in a real implementation.

28


Control agents World model

Supervisory controller

Driver interface

Driver

Perception

Gateway

RadarLow level controllers & sensors

Camera GPS

Router

Other vehicles and infrastructure

Emergencyoverride

Driver input Driver feedback

Driver input World data

World dataWorldupdate

Controlconfigurations

Cameradata

Lateral and longitudinal

control signals

Lateral and longitudinal

control signals

Sensordata

Sensordata

V2X

V2X

V2X

V2X

V2X

V2X

GPSdata

Radardata

Host and environment status

Worlddata

Figure 3.3. The preliminary architecture represented as a functional data flowdiagram. Green boxes represent item functionalities. Blue boxes represent externalfunctionalities.

• Radar: The radar is a separate sensor, external to the item.

The defined item functionalities are:

• A driver’s interface, to relay control and situational information to the drive, and toenable the driver to configure the system and confirm merges.

• A supervisory controller functionality, responsible for the high level autonomous anddecision making, including communication with other vehicles.

• A control agents functionality container holds the control agents which are responsiblefor providing correct reference signals to the low level controllers.

• A world model functionality which stores current state information.

• A router, to manage incoming data traffic, take care of loss of packages and routetransmissions to the correct functionality.

29


• A perception functionality, also referred to as an estimator, which task is to estimatethe state of the host vehicle, and the surrounding vehicles, based on the informationform the sensor feedback from the host vehicle, the GPS and the incoming commu-nication.

• A gateway between the item and the Ego-vehicle. The gateway is a logical barrier insoftware, isolating the item from the platform.

• A Camera to identify the road lanes

• A GPS for positioning

• A co-drivers interface, which grants the co-driver real-time access to all underlyingvariables in the item. This is just a testing functionality and is therefore not includedin the scope of the analysis. Hence it will not be explained or illustrated further.

The item is delimited by its interfaces to the external actors; the gateway, sep-arating the item from the platform. The router, separating the item from otherco-operative entities, and the human-machine interfaces, separating the item fromthe driver and co-driver.

The supervisory controller is the ”intelligence” in the system. It monitors thetraffic environment and activates and configures the correct control agents depend-ing on the situation. It bases its decisions on the configurations from the driverand the world estimates from the world model. The world model is an on-boarddatabase of the current environment and host vehicle state estimations. It pushesthis information to the supervisory controller for high level decision making, to thecontrol agents as control feedback, and the necessary information to the driver. Therouter is responsible for sorting the incoming packages and sending information re-garding intensions and requests to the world model, and vehicle state informationto the perception functionality. The perception functionality can be further dividedinto the host estimator, and the data fusion functionality. This is illustrated inFigure 3.4

The host estimator estimates the current host vehicle state, based on GPS dataand sensor data from the platform, such as encoder values. The data fusion func-tionality reads the current traffic environment information from the world model,compares it to incoming transmissions, radar measurements and the current hostvehicle estimation. It fuses the information received from other vehicles to themeasured radar data, and updates the traffic environment information in the worldmodel.

The control agent’s functionality can be expanded into a lateral control agent,with a path planner, and a longitudinal control. The longitudinal control consistsof a cruise control (CC) agent and a combined co-operative adaptive cruise control(CACC) agent and an obstacle avoidance (OA) agent. This can be visualised inFigure 3.5.

The planner is responsible for making a reference path that keeps the currentlane or changes lane in case of a merge. The lateral controller is responsible fortranslating this path into reference steering angles for the wheels. In case of the

30


Perception

Host estimator Data fusionHostState

World model

Router

GPS Gateway

Host vehicle state Environment state

Radar dataEncoder dataGPS data

V2X

V2X

V2X

Figure 3.4. Expansion of the perception functionality

Control agents

Longitudinal control

CACC & OA agents

CC agent

Planner

LC agentPredictions

Camera Gateway

Supervisory controller

Referencepath

Lateral control signal Longitudinal control signal

Agent configurations

World data

Figure 3.5. Expansion of the control agent’s functionality

Scania Truck platform, the data is never sent to the host vehicle, but instead,instructions are sent to the driver regarding what manoeuvres to perform. Boththese functionalities rely on camera data for lane positioning. The CACC/OAagent is responsible for longitudinal control, whenever another vehicle is in front.If there are no vehicles in front, the longitudinal control switches to the CC agent.The gateway is the interface between the host vehicle and the co-operative module.

31


3.2 Preliminary studyThis section describes the implementation of the STPA eligibility evaluation casestudy. During the preliminary case study, the process does not rigorously followthe ISO 26262 standard. Focus is instead on the STAMP-STPA method in theco-operative driving context. Integration with the ISO 26262 standard is done at alater stage.

For the item definition, see section 3.1.3 of the experimental setup.

3.2.1 Accidents and hazardsAccidents and hazards are determined at a workshop with safety experts from theinstitution and domain experts working on the implementation of the co-operativedriving module. A brainstorming session is held to formulate accidents in accor-dance with the STAMP definition of an accident. Another brainstorming session isheld to to formulate related hazards, in accordance with their definition by STAMP.Three accidents are included in the analysis.

• A1 — Collision with vehicle includes collisions with any other vehicle, within thescope, at the speeds specified by the scope. The different possible collisions arecategorised into three different categories, determined by the angle of impact, asshown in Figure 3.6

• A2 — Collision with environment includes collisions with any environmental object,within scope, at speeds specified by the scope. Accident A2 follows the same cate-gories of collision as accident A1, as defined in Figure 3.6

• A3 — Driver G-force dangerously high includes all sudden forces acting on the driverand co-driver, not caused by a collision.

The corresponding hazards are shown in Table 3.1All hazards are translated into safety requirements / constraints. These are

shown in Table 3.2

3.2.2 Control structureThe control structure is illustrated in Figure 3.3 of the experimental setup. NineSTPA control loops are identified in the item.

• Driver to supervisor

• Supervisor to CACC/OA agent

• Supervisor to CC agent

• Supervisor to lateral control agent

• Supervisor to planner

• Planner to lateral control agent

32

3.2. PRELIMINARY STUDY

Left

Right

FrontBack

45°

45°45°

45°

Figure 3.6. Visualisation of the categories of collision

• Lateral control agent to low level controllers

• CACC/OA agent to low level controllers

• CC agent to low level controllers

The driver controls the supervisor by switching it on / off, initiate specific sce-narios, and confirming that a merge is safe to execute. The supervisor controls theCACC/OA agent by switching it on/off and setting the reference vehicle to follow.It controls the CC agent by switching it on/off and setting the reference speed. Italso switches the planner and lateral controller on/off and gives the perform mergecommand to the planner. The planner controls the lateral controller by updatingthe reference path. The lateral controller controls the low level drivers through up-dates of the reference steering angles for the front and rear wheels. (For the RCVplatform) The CACC/OA agent controls the longitudinal movement by increasingor decreasing the torque, or by sending break signals to the low level controllers.The CC agent controls the longitudinal movement by increasing or decreasing thetorque.

These interactions are defined as the controls actions.

33

CHAPTER 3. P

functional safety in co-operative driving using systems ...1072594/fulltext01.pdf1 examensarbete mmk...

Documents