Design and Safety Analysis of Emergency Brake System for Autonomous Formula Car

(1)

SECOND CYCLE, 30 CREDITS STOCKHOLM SWEDEN 2018,

Design and Safety Analysis of Emergency Brake System for Autonomous Formula Car

In Reference to Functional Safety ISO 26262

MARKUS BÖLANDER

(2)

Master of Science Thesis SD221X: Degree Project in Vehicle Engineering

Design and Safety Analysis of Emergency Brake System for Autonomous Formula Car

Markus Bölander

Approved Examiner Supervisor

2018-06-27 Mikael Nybacka Julian Koller

Commissioner Contact person

AVL Julian Koller

Abstract

The engineering competition Formula Student has introduced a Driverless Vehicle (DV) class, which requires the students to develop a car that can autonomously make its way around a cone track. To ensure the safety of such a vehicle, an Emergency Brake System (EBS) is required. The EBS shall ensure transition to safe state for detection of a single failure mode. This thesis work covers the design of the EBS for KTH Formula Student (KTH FS).

Due to the safety critical character of this system, the software part of the EBS, called EBS Supervisor, has been analyzed in accordance with the safety standard ISO 26262 to see if an improved safety could be achieved. The analysis has been perform according to Part 3: Concept phase of ISO 26262 with an item definition, Hazard Analysis and Risk Assessment (HARA), Functional Safety Concept (FSC) and Technical Safety Concept (TSC).

The result of the analysis showed that the EBS Supervisor requires extensive redundancies in order to follow ISO 26262. This includes an additional CPU as well as signal checks of inputs and outputs. Due to limited resources in terms of money and time within the KTH FS team, these redundancies will not be implemented. The process of working with the safety standard did however inspire an increased safety mindset.

Keywords: Emergency Brake System, Formula Student, Functional Safety, ISO 26262

(3)

Engineering

Design och Säkerhetsanalys av Nödbroms för Autonom Formula Bil

Markus Bölander

Godkänt Examinator Handledare

2018-06-27 Mikael Nybacka Julian Koller

Uppdragsgivare Kontaktperson

AVL Julian Koller

Sammanfattning

Ingenjörstävlingen Formula Student har introducerat en förarlös tävlingsklass (eng:

Driverless Vehicle) som innebär att studenterna ska utveckla en bil som autonomt kan ta sig runt en konbana. För att försäkra sig om säkerheten för ett sådant fordon krävs ett nödbromssystem (eng: Emergency Brake System (EBS)). EBS:en skall försäkra att en övergång till ett säkert tillstånd sker då ett singulärt fel upptäcks. Det här examensarbetet behandlar designen av EBS:en för KTH Formula Student.

På grund av den säkerhetskritiska karaktären hos detta system har mjukvarudelen av EBS:en, kallad EBS Supervisor, blivit analyserad utifrån säkerhetsstandarden ISO 26262 för att se om en förbättrad säkerhet kunde uppnås. Analysen har blivit genomförd enligt Del 3: Konceptfas av ISO 26262 med item definition, Hazard Analysis and Risk Assessment, Functional Safety Concept och Technical Safety Concept.

Resultatet av analysen visade att EBS Supervisor kräver omfattande redundanser för att uppfylla ISO 26262. Detta inkluderar en extra CPU såväl som kontroller av in- och utsignaler. På grund av begränsade resurser i form av pengar och tid inom KTH FS, valdes dessa redundanser att inte implementeras. Processen av att arbeta med säkerhetsstandarden har dock inspirerat ett ökat säkerhetstänk.

Nyckelord: Nödbromssystem, Formula Student, funktionell säkerhet, ISO 26262

(4)

Acknowledgments

As I am finishing up the last parts of this thesis, I cannot help but to reflect upon the five years of studies that are coming to an end. There has been a lot of hard work in combination with cherished moments. The last two years of Master’s studies in combination with Formula Student has been incredibly educational. Especially this last semester where I have learned a surprisingly large amount of interdisciplinary matters.

I would like to address my gratitude towards AVL and my supervisor Julian Koller for a fun and informative time at the company. It has been a great work environment and Julian has cleared any question or doubts regarding the area of functional safety.

A large gratitude for this year’s Formula Student team is given for all the long days and nights in the garage. The different cultural and technical backgrounds have inspired dozens of interesting discussions and solutions.

Lastly, I would like to mention my friends Max Ahlberg and Fabian Källström. The amount of laughter and humor we have had during the long hours of effort has been priceless. Thank you for inspiring to work even harder.

(5)

Acronyms

AAAM Association for the

Advancement of Automotive Medicine

AD Autonomous Driving

ADAS Advanced Driver Assistance Systems

AIR Accumulator Isolation Relay

AIS Abbreviated Injury Scale

AS Autonomous System

ASIL Automotive Safety Integrity Level

ASMS Autonomous System Master Switch

AV autonomous vehicles BHC Brake Heading Control CPU Central Processing Unit CV Combustion Vehicle

DC Direct Current

DTI Diagnostic Test Interval DV Driverless Vehicle E/E Electrical and/or

electronic

EBS Emergency Brake System

EV Electric Vehicle

FMEA Failure Modes and Effects Analysis

FRT Fault Reaction Time

FS Formula Student

FSC Functional Safety Concept

FSR Functional Safety Requirement FTA Fault Tree Analysis FTTI Fault Tolerant Time

Interval

GLVMS Grounded Low Voltage Master Switch

HARA Hazard Analysis and Risk Assessment

HAZOP Hazard and Operability Study

HIL Hardware in the loop IMU Inertial Measurement

Unit

ISO International Organization for Standardization

KTH FS KTH Formula Student LIDAR Light Detection and

Ranging

MIL Model in the loop

(9)

Control

PCB Printed Circuit Board PIL Processor in the loop PWM Pulse Width Modulation

QM Quality Management

ROS Robot Operating System RQ Research Question

SG Safety Goal

SLAM Simultaneous Localization and Mapping

SOTIF Safety of the Intended Functionality

TSC Technical Safety Concept

TSR Technical Safety Requirement

VCU Vehicle Control Unit

(10)

Chapter 1

Introduction

The following chapter aims to give an introduction to this Master’s thesis paper. A background regarding the addressed topics of functional safety and Formula Student is given and followed by a presentation of previous research in the same field. The used methodology and research questions stated for this work are also presented.

1.1 Background

The automobile has seen a large change and development since its conception in the late 1800s [1]. As it has enabled inhabitants to travel longer distances with resulting impacts on society and economy globally [2], consequences in terms of fatalities has also followed. With 1.3 million people dying of road injuries in 2015 [3], road injuries is the top 10 cause of death worldwide. This has made safety a highly prioritized issue for car manufacturers and it is one of the major changes that the automobile has seen throughout the years. Advanced deformation zones have improved passive safety for modern vehicles and active safety has been introduced to avoid accidents all together. Features like ABS, ESP, automated braking and lane keep assistance are examples of such systems that aim to assist the driver. These are referred to as Advanced Driver Assistance Systems (ADAS) and can be seen as stepping-stones in the transition towards Autonomous Driving (AD). By replacing the driver, a large amount of accidents could be avoided due to the nature of human behaviour [4]. With the "human factor" being involved in 90-95 % of all road accidents [5], replacing the driver with computers seems justified. However, these computers and algorithms are increasing in numbers and complexity, and hence ensuring its reliability becomes more difficult. That is why functional safety and the safety standard ISO 26262 becomes a crucial part of automotive development.

The trend of AD is seen in the industry as well as within academia. Large car manufacturers are developing their own Autonomous System (AS) and many consultant firms are a part of this development. One of these is the Austrian automobile consultant company AVL, with functional safety as one of their key competencies. An example of AD development within academia is the project KTH FS where a single seated race car with AD features is developed. With AVL being one of KTH FS’s main partners, a

(11)

collaboration in terms of investigating functional safety for the KTH FS race car laid the foundation for this thesis work.

1.2 Formula Student

Formula Student (FS) is Europe’s most established educational engineering competition [6], with the purpose of improving engineering student’s skills in design, manufacturing and financing. The challenge is to design and construct a single-seated formula style race car as illustrated in figure 1.1.

Figure 1.1. Rendering of a typical Formula Student race car.

The competition that has previously consisted of a combustion (CV) and an electric (EV) class is for 2018 introducing a driverless class (DV). The CV and EV classes are competing under similar conditions while the DV class is evaluated separately. The competition is divided into static and dynamic events according to table 1.1. During the design of the race car the students need to consider a 130 pages long rulebook [7]. It consists of rules in terms of how the contest shall be performed as well as requirements regarding the design of the vehicle. One of these requirements is the presence of an EBS for the DV. With its safety critical character, the EBS should be designed so that a single failure mode triggers the brakes and stops the car to a safe state. Since the safety aspects of the vehicle is a central part of the competition judges scrutiny, a rigorous design will be needed. This thesis will deal with the design of the EBS for KTH FS, followed by a safety analysis in reference to the safety standard ISO 26262 to justify the design.

(12)

1.3. Aim

Table 1.1. Maximum possible points for each event.

CV & EV DV

Static events:

Business Plan Presentation 75 points 75 points Cost and Manufacturing 100 points 100 points Engineering Design 150 points 325 points Dynamic events:

Skid Pad 75 points 75 points

Acceleration 75 points 75 points

Autocross 100 points -

Endurance 325 points -

Efficiency 100 points 100 points

Trackdrive - 250 points

Overall 1000 points 1000 points

1.3 Aim

There were two aims for this thesis; to design and develop the required EBS for the KTH FS car and to investigate its safety in regards to ISO 26262. This included a thorough study of the standard in order to acquire adequate understanding of how to use it. The analysis could then be performed while following the steps described in the safety standard.

1.4 Previous research

Since the release of ISO 26262 in 2011, plenty of articles and papers related to the topic have been published [8–13]. In [8] the concept phase of the ISO 26262 is discussed while in [9] a brake-by-wire system is analyzed in regards to the standard. In preparation of the second edition of ISO 26262 that will include heavy vehicles, research has been done in order to prepare OEMs for future requirements. However, since these papers concern implementation of a specific product the detail of information in [10, 11] is limited due to confidentiality.

Previous research of implementing functional safety for autonomous systems is also scarce. The ISO 26262 standard does not currently include self driving cars and how functional safety should be implemented on such systems is currently an uncharted area.

A suggestions with triple core redundancy is seen in [12] and some potential difficulties when applying ISO 26262 for autonomous vehicles (AV) are discussed in [13].

With the Formula Student Driverless competition being introduced in 2017 and with the EBS being a new requirement for 2018, there are currently no documentation of functional safety for such a system and context.

(13)

1.5 Methodology and research questions

When discussing research methodology, one must understand the difference between scientific and engineering methodology. While science aims to reach understanding, explanation and prediction of the universe, engineering aims to design an artifact that solves a practical problem [14]. This makes research in the separate areas different and one should not force-fit engineering research into scientific conceptions of general conclusions. In this thesis a methodology referred to as engineering design [15, 16] has been used, meaning that a systematic approach to create a sufficient solution to a specific problem has been done. The problem in this thesis is how one can or shall design and assure the safety of an EBS. Some Research Questions (RQs) that arise for this problem are presented below.

RQ1: How shall the EBS be design for KTH FS?

RQ2: What are the measures for functional safety?

RQ3: What potential faults, hazards and risks in the EBS are relevant for the Formula Student application?

RQ4: Is the EBS fulfilling the ISO 26262 standard?

RQ5: Can ISO 26262 be a useful standard for KTH FS to implement in their work process?

According to [17], one should consider if the research questions fulfill something abbreviate

"FINER", standing for feasible, interesting, novel, ethical and relevant. All of the defined RQs are perhaps not fulfilling each one of these criteria but will nevertheless be used in order to give structure to the thesis.

1.6 Scope

Due to the immensity of ISO 26262, it was decided to not include all parts of the standard.

Instead, focus in this thesis work was put on Part 3 - Concept phase [18] and the technical safety concept from Part 4 [19]. In addition to the functional safety analysis, the actual EBS with software and hardware was developed and tested together with the Formula Student team at KTH.

1.7 Organization of the thesis

The report is structured in the following manner. Chapter 2 will give an introduction to functional safety and describe the origin of ISO 26262 as well as the workflow of the standard. This is followed by a description of the EBS with its hardware and software in Chapter 3. With an understanding of the system, the safety analysis according to ISO 26262 is performed in Chapter 4, followed by the results of the findings to the defined research questions in Chapter 5. The report is then concluded with a chapter of

(14)

Chapter 2

Functional Safety

The following chapter gives an introduction to the area of functional safety. The wider term used in different industries is explained and followed by the use within the automotive industry in the form of ISO 26262.

2.1 Background to functional safety

Safety within the automotive industry has traditionally relied on robust design as well as hydraulic and pneumatic mechanisms [20]. Mechanically fixed steering column, two circuit hydraulic brake system, hand brake and engine braking have been used to ensure vehicle functionality. By having a robust brake system with higher brake torque than the maximum traction torque, transition to a safe state is presumably ensured. However, with increased electrification and automation like steer-by-wire/brake-by-wire and automated driving, software based safety mechanisms have become essential, see figure 2.1. The oil and gas industry, nuclear plants and machinery sector all rely on functional safety and the IEC 61508 standard by the International Electrotechnical Commission [21].

This standard has been used to create ISO 26262 which is an adaption to comply with Electrical and/or electronic (E/E) systems within road vehicles [22].

To quickly grasp the concept of functional safety, one can start with the definition from [22], which describes functional safety as:

"Absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems."

This includes the increased risks of systematic and random failures that could occur with increased technological complexity, software content and mechatronic implementations.

Examples of such include driver assistance, propulsion, vehicle dynamics control as well as active safety systems. The next section will give deeper insight into how ISO 26262 includes guidance to mitigation of these risks by providing appropriate requirements and processes.

(15)

Figure 2.1. E/E systems that are in need of safety analysis with ISO 26262 [23].

2.2 The ISO 26262 standard

ISO 26262 is developed by International Organization for Standardization (ISO) which is a worldwide federation developing and publishing International Standards through technical committees. For the first edition of ISO 26262 released in 2011, the following 10 parts are included:

– Part 1: Vocabulary

– Part 2: Management of functional safety – Part 3: Concept phase

– Part 4: Product development at the system level – Part 5: Product development at the hardware level – Part 6: Product development at the software level – Part 7: Production and operation

– Part 8: Supporting processes

– Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses

– Part 10: Guideline on ISO 26262

Each of these 10 parts contains subparts called clauses that refine the document with information and requirements. As seen in both Figure 2.2 of the safety lifecycle and Figure 2.3 of the ISO overview, references to ISO 26262 is done by referring to the part and clause with "n-m" convention. Here, "n" refers to to part and "m" to the clause.

On a high-level premise, ISO 26262 aims to do the following five main tasks [22]:

(16)

2.2. The ISO 26262 standard

2. provide an automotive-specific risk-based approach to determine integrity levels [Automotive Safety Integrity Levels (ASIL)]

3. use ASILs to specify applicable requirements of ISO 26262 so as to avoid unreasonable residual risk

4. provide requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety being achieved

5. provide requirements for relations with suppliers.

For this thesis, tasks 2 and 3 will be mainly considered. These are primarily handled in Part 3: Concept phase marked as bold in the list above. Below follows an introduction to the workflow of this part as well as the subsequent Technical Safety Concept (TSC).

Workflow for Part 3: Concept phase + TSC

This section describes the parts that are included in the concept phase of ISO 26262, seen in figure 2.2. The first step is to produce the item definition which describes the system under scrutiny. Another word for item could be "user object" since the item is not bound to a specific component, but rather a set of elements which enable certain functions. The item definition should contain all the relevant information for the subsequent phases, starting with the HARA. The objective of the HARA is to identify and categorize hazards that malfunctions in the item can trigger. From the identified hazardous scenarios, one formulate Safety Goals (SGs) that shall prevent or mitigate the hazardous scenarios in order to avoid unreasonable risk. The safety goals are assigned an Automotive Safety Integrity Level (ASIL), which is classified based on exposure, severity and controllability.

The next step is to derive the Functional Safety Requirements (FSRs) from the safety goals. These requirements constitute the FSC. This is the final step in Part 3: Concept phase, but a natural step is to also include the TSC, from Part 4: Product development at the system level. The TSC includes the Technical Safety Requirements (TSRs), which are refinements of the FSRs. For this thesis, no more work is done in accordance with ISO 262626. For industrial purposes one would continue to refine the TSRs to software and hardware requirements that would be followed by validation and safety assessment. In Chapter 4, the main parts of Part 3 - Concept phase as well as the TSC will be explained in detailed and applied on the EBS Supervisor. The EBS Supervisor will be explained in the next chapter together with the complete EBS.

(17)

Figure 2.2. Extract of the safety lifecycle according to ISO 26262-2:2011 5.2 [24].

(18)

2.2. The ISO 26262 standard

Figure 2.3. Overview of ISO 26262 [22].

(19)

Chapter 3

Emergency Brake System

This chapter gives an introduction to the preliminary design and architecture of the EBS that was made. This was used as the background for the item definition described in section 4.1. The following sections will describe the actual implemented hardware and generated Simulink software, while the item definition will describe the EBS from a functionality point of view with the EBS Supervisor being the item in focus.

3.1 Hardware

For the hardware design of the EBS, it was decided that an implementation that interfered as little as possible with the current brake design was to be used. The current brake system uses two hydraulic circuits, one for the front wheels and one for the rear wheels, which are activated by two separate master cylinders. The brake pedal is connected to both cylinders with adjustable screws in order to change the brake bias between front and rear wheels. In order to maintain this feature for driverless brake actuation, it was decided that the brake actuatuators would act on the brake pedal. The resulting design was a system using an electric rotating actuator and a pneumatic cylinder that pulls the brake pedal with a steel wire. The service brake and the pneumatic system are described below.

3.1.1 Pneumatic brake system

Due to rule DV3.1.3 in [7], a passive system with mechanically stored energy must be used for the EBS. This led to a pneumatic brake solution with a C0₂ cartridge as the mechanical energy source. In order to fulfill the functionality specified in [7] and [25], the EBS has been designed to maintain the states illustrated in figures 3.1-3.5.

The C0₂ cartridge will be inserted when the vehicle is turned off, and hence the electric

(20)

3.1. Hardware

Figure 3.1. Pressure flow after inserting C0₂ cartridge.

When the vehicle has been started and no errors have been detected, the EBS valve is supplied by the low-voltage battery and is closed. At this moment, the manual on/off valve can be opened to put the EBS in "armed"-mode, seen in Figure 3.2.

Figure 3.2. Pressure flow when EBS is armed.

As soon as either an error is detected, low-voltage supply cuts off or the EBS is triggered in the initial checkup, the EBS valve will open and release the pressure to engage the brakes. Figure 3.3 shows the pressure flow at this state.

(21)

Figure 3.3. Pressure flow when the EBS has been triggered.

The functionality of the EBS will be tested during the initial checkup by triggering the EBS and checking the hydraulic brake pressure. This is done by opening the EBS valve to trigger the brake, followed by closing the valve in order to release the pressure to atmosphere and transition back to EBS "armed"-mode¹. The pressure flow when releasing the brake after initial checkup is seen in Figure 3.4 below.

Figure 3.4. Pressure flow when releasing pressure after the initial checkup.

If the EBS is triggered after the initial checkup due to an error or power loss while driving on the circuit, there is no possibility to close the EBS valve by putting the signal to high again. Instead the pressure needs to be released manually by first closing the first manual on/off valve in order to cut the pressure supply. After this, the pressure still present in the system can be released by opening the second manual on/off valve. See Figure 3.5 below.

1The signal to the EBS valve will be put to low/high with the EBS Logic by changing the

"Brake_engage_NOT" signal to low/high respectively.

(22)

3.1. Hardware

Figure 3.5. Pressure flow when the EBS has been disabled in order to release the brakes manually.

The components used in the pneumatic EBS which are mentioned in figures 3.1-3.5 can be seen in Figure 3.6 and 3.7.

Figure 3.6. From left: C0₂ cartridge, pressure regulator, manual on/off valve.

Figure 3.7. From left: pressure sensor, normally opened 3/2 EBS valve, pneumatic cylinder.

(23)

3.1.2 Service brake actuator

An electric servo motor was chosen as the service brake actuator. The intention is that the actuator shall be used for longitudinal velocity control during driverless operation.

In case of a malfunctioning pneumatic EBS, the service brake will be used as redundant emergency brake.

The servo motor, seen in Figure 3.8, is of model type HS-1005SGT and supplied by Hitech Multiplex. The motor has the following specifications, described in Table 3.1.

Table 3.1. Specification of the HS-1005SGT servo motor.

Performance Specifications

Operating Voltage Range (DC) 11.1 - 14.8 V

Maximum Torque Range 84 - 110 kg/cm²

No Load Operating Current Draw 1300 mA

Stall Current Draw 6500 mA

Dead Band Width 2 µs

Physical Specifications

Dimensions 640 x 330 x 730 mm

Weight 363.0 g

Circuit Type Digital Amplifier with Mosfet Drive

Motor Type 5 Poles Cored Carbon Brushless

Figure 3.8. The electric actuator used as service brake and as redundancy for pneumatic EBS.

3.1.3 Non-programmable logic

In the Formula Student rules [7] it is stated in rule DV3.1.2 that "The vehicle must be equipped with an EBS, that is triggered when the shutdown circuit opens using non-

(24)

3.2. Software

as EBS Logic in the report, is described in the EBS Reference Guide [25]. It consists of discrete components like standard 74xx logic gates, transistors etc. No processors or programmable logic parts are included which ensures that the EBS can be triggered without CPU utilization. Figure 3.9 shows the Printed Circuit Board (PCB) where the discrete components are mounted on. A detailed schematic of the EBS Logic is given in the item definition in section 4.1 (see Figure 4.3).

Figure 3.9. Schematic of the EBS Logic.

3.2 Software

The software part of the EBS is referred to as the EBS Supervisor and the preliminary design was made in reference to the Formula Student rule book [7] as well as the EBS Reference Guide [25]. In [25] it is stated that the EBS Supervisor shall include an initial checkup sequence as well as a continuous monitoring. In addition to these features, a Brake Heading Control (BHC) logic has been added as a solution to prevent potential unintended yaw while braking. This was done in order to comply with rule DV3.3.3, stating that no intended yaw motion is allowed whilst deceleration during emergency braking. A collection of relevant Formula Student rules are seen in table A.1 in Appendix A.

The EBS software has been written in MathWorks Simulink environment and the architecture was developed and tested individually before integration to the complete vehicle model. The three main parts of the EBS Supervisor are seen in Figure 3.10 together with the interacting elements and signals. The following sections describe each part of the software in closer detail.

(25)

Figure 3.10. Detailed schematic of the signals to the EBS Supervisor.

3.2.1 Brake heading control

In order to prevent unintended yaw motion whilst decelerating from a triggered EBS, the steering actuator can be utilized to counteract the rotation. A feedback loop as seen in Figure 3.11 with a P-controller is a simple first solution to this problem. This feature will however only be implemented and further developed if discovered necessary. The first measures to avoid any unintended yaw motion will be to set up a balanced car and increase the brake bias for the front wheels. This will make the front wheels lock before the rear wheels and give a more stable brake heading. If the vehicle would nevertheless rotate during braking, a control loop with an active steering system will be necessary to implement ans is therefore included in the safety analysis.

The P-controller in Figure 3.11 is only activated when the EBS has triggered by using an

(26)

3.2. Software

Figure 3.11. As a first solution, a simple P-controller has been used for the BHC.

Figure 3.12. "Enabled Subsystem"-block in Simulink has been used to ensure that the BHC is only active when the EBS has triggered.

3.2.2 Initial checkup sequence

The initial checkup required by [25] was dealt with by using a state-machine in form of a "Chart" in Simulink. The necessary steps from [25] are seen in Table 3.2 and the corresponding state-machine can be seen in seen in Figure 3.13.

(27)

Table 3.2. Initial checkup sequence.

Step Action Description

1 Wait for Shutdown Circuit to close

Checks that all the relays are closed in the shutdown circuit in figure 4.5 2 Set "Brake_engage" to high Setting "not brake engage" to high, i.e.

do not engage brakes 3

Check that

"EBS_is_triggered" signal is active.

"Active" here means that EBS is triggered, which corresponds to low.

4 Activate watchdog signal Start toggling the watchdog signal 5

Check that

"EBS_is_triggered" signal is inactive

The EBS should now be inactivate since watchdog is activated 6 Set "EBS_set_active" to ’0’

to activate EBS

Setting "EBS not active" to ’0’, i.e.

activate the EBS 7 Check "EBS_is_active" is

active Check that signal value is high 8 Apply brakes through

"Brake_engage"

Setting "not brake engage" to low in order to engage the brakes (pneumatic

EBS) 9 Check brake pressure is built

up as expected

Reading the pressure in the hydraulic brake lines

10 Release brakes

Setting "Brake_engage" to high so that "not brake engage". Pneumatic pressure released with 3/2 valve.

11 Activate brakes through the

redundant system Send brake signal to the service brake 12 Check brake pressure is built

up as expected

Reading the pressure in the hydraulic brake lines

13 Check "Driving_state_active"

is inactive Check that signal value is low 14 Transit to ready state Transit to "AS Ready" according to

figure 4.6

(28)

3.2. Software

Figure 3.13. State-machine for the initial checkup of the EBS.

(29)

3.2.3 Continuous monitoring

The main objective of the EBS Supervisor is to perform continuous monitoring during operation to detect typical failures like cable or pneumatic line ruptures. The following are considered for the continuous monitoring:

• Pneumatic tank pressure

• Brake line pressure

• Plausibility of sensor signals

• Service brake transfer function

• Plausibility of non-programmable logic signals

• Check "Driving_state_active" is always active while driving

Pneumatic tank pressure check

Figure 3.14 shows the pneumatic tank pressure check. A plausibility check is made to see if the pressure values are within physically feasible limits, acting as a sensor check.

The sensor reading is also compared to a calibratable threshold to see if there is enough pneumatic pressure to perform an emergency braking.

Figure 3.14. Pneumatic EBS pressure check.

Brake line pressure check

Figure 3.15 illustrates the hydraulic brake line pressure check. This is done to see that the brake line pressure has increased above a calibratable threshold when the EBS has triggered. In case the EBS has triggered but there is not enough brake line pressure built up, the service brake will be triggered as a redundant EBS. The signal

"Failed_pneumatic_EBS" is sent to the "Service Brake EBS Engagement" logic described in Figure 3.16 to trigger the service brake. A "triggered subsystem"-block has been used to make sure that the "Failed_pneumatic_EBS"-signal is kept high once it has been detected that the pneumatic EBS has failed. Without this block, the service brake would start to toggle EBS braking as the brake line pressure starts rising when the service brake is applying brake force.

(30)

3.2. Software

Figure 3.15. Hydraulic brake line pressure check for triggered EBS.

Service brake EBS activation

Besides triggering the service brake when the pneumatic EBS has failed to build up enough brake line pressure, it shall also be activated for when the pneumatic pressure is to low, as well as when an error in the Nvida GPU has been detected. This will allow the GPU to do internal resets and a possibility to continue driving the vehicle after a shorter stop. The alternative of using the pneumatic EBS for a Nvida error would require a complete restart of the vehicle while if the service brake is used, the car can continue driving if the Nvidia error is resolved.

Figure 3.16. Service brake engagement.

Service brake transfer function check

Since the service brake is used as redundancy for the pneumatic EBS, it must be monitored and trigger the pneumatic EBS in case of detected malfunction. This will be done with a "transfer function" check that will compare the brake line pressure with a predefined lookup table that takes the Pulse Width Modulation (PWM) as input and gives a pressure

(31)

value as output. This table will have to be calibrated and tuned in order to achieve satisfactory performance. In case the deviation between the value from the lookup table and the sensor value of the brake line pressure is too large, a malfunction of the service brake will be assumed and trigger the pneumatic EBS. Figure 3.17 illustrates the described logic.

Figure 3.17. Lookup table used as transfer function check for the service brake.

Watchdog toggle

A Watchdog is mandatory to use to ensure that the EBS Supervisor is still alive. This signal is toggled by the software on the CPU and sent to the EBS Logic for "keep-alive".

In case the Watchdog is not detected by the EBS Logic, the EBS will trigger. If a service brake malfunction is detection by the transfer function check, the Watchdog toggling will be disabled in order to trigger the EBS.

Figure 3.18. Watchdog toggling generated with this logic.

(32)

3.3. Testing and functionality validation

3.3 Testing and functionality validation

The validation of the EBS was performed step-wise with each component of the software being developed and tested individually before assembling the complete system. The algorithms were designed in MathWorks Simulink which enabled easy Model in the loop (MIL) testing. With the software functionality validated, testing in terms of Processor in the loop (PIL) was done with an Arduino microcontroller in order to test if the model could compile to C-code. At the point of writing this report, no Hardware in the loop (HIL) testing has been performed. The testing and validation was never intended to be included in this thesis work and will instead be performed subsequently before the Formula Student competition.

(33)

Chapter 4

Concept Phase

The following chapter describes the safety analysis of the EBS Supervisor made by using the main parts from ISO 26262 Part 3 - Concept phase, including item definition, hazard analysis and risk assessment as well as functional safety concept. The technical safety concept is also included, which is a part of ISO 26262 Part 4 - Product development at the system level. A description of each part is given and then followed by an extract from

the resulting work product when applying ISO 26262 to the EBS Supervisor.

4.1 Item Definition

The purpose of the item definition is to describe the system or component that should be analyzed. This shall include the item’s functions as well as its dependencies and interactions with the environment and other items. The item definition results in a work product that is used to perform the subsequent phases including the HARA. This section describes the main parts of the resulting work product of the item definition, which includes:

• 4.1.1 Scope of item

• 4.1.2 Item overview on vehicle level

• 4.1.3 Interactions with other items

• 4.1.4 Functional description of related elements

• 4.1.5 Main operation modes and states of the item

• 4.1.6 Functional description of item

• 4.1.7 Environmental conditions

(34)

4.1. Item Definition

4.1.1 Scope of item

The EBS Supervisor will be used in the Formula Student car for monitoring and failure detection of the system. It is also responsible for the initial checkup as well as Brake Heading Control (BHC). The Supervisor consists of code which is integrated to the Central Processing Unit (CPU) of a dSpace MicroAutoBox. The architecture is designed in Simulink and then built to C-code before flashed to the CPU.

4.1.2 Item overview on vehicle level

The dSpace unit is located under the driver’s seat and is supplied by the low-voltage battery. The communication with connected elements are made over CAN, Ethernet and analog signals. Figure 4.1 illustrates an overview of the EBS with its related components.

Figure 4.1. System overview on vehicle level.

(35)

4.1.3 Interaction with other items

Since the EBS Supervisor monitors the entire EBS functionality, a considerable number of interactions with other items exist. In table 4.1 and 4.2, the input and output signals of the item are presented. A schematic of the signals and interacting items are presented in figure 4.2. Note that some of the signals in the tables are represented as Signal_name, where the overline means complement. This could be interpreted as "not", which is why the signals in figure 4.2 has the added "NOT" to the signal names. The reasoning for this convention is safety based. The system needs to continuously communicate for nominal conditions. As soon as a signal like "EBS_is_triggered_NOT" is interrupted, the system shall assume that the EBS has been triggered and take action.

Table 4.1. Table of input signals to item.

Input Signal From Description

ASMS Low voltage sup-

ply

Analog signal to activate the AS, including EBS Supervisor.

EBS_is_active EBS Logic Shows whether the EBS is in "armed"

state or not EBS_is_triggered EBS Logic

Directly shows the output of the EBS and determines if the system has been triggered or not.

Driving_state_active EBS Logic Displays whether driving state ASMS monitoring is active or not.

EBS_pressure EBS pressure tank sensor

Pressure reading from EBS pressure container

Brake_CH1

Hydraulic brake line pressure sensor

Pressure reading from hydraulic brake line

AS_nvidia_error Nvidia GPU Error message from the Nvidia GPU

IMU_yaw IMU Yaw reading from IMU

Wheelspeed Wheelspeed

encoder Used as vehicle velocity.

Steering_angle Potentiometer on

steering column Steering angle reading Shutdown_circuit Shutdown circuit The shutdown circuit signal

Torque_val dSpace Traction motor torque request

Service_brake_request dSpace Calculate service brake request from feedback controller

Service_brake_pos Service brake po-

tentiometer Service brake position reading

(36)

Table 4.2. Table of output signals from item.

Output Signal To Description

EBS_set_active EBS Logic Used to set the EBS into “armed”

state.

Watchdog EBS Logic

Mandatory to ensure the Supervisor is still alive. This signal must be connected to the CPU and periodically toggled by software to maintain a keep alive signal, otherwise the EBS gets triggered.

Shutdown_close EBS Logic

Gives the Supervisor the possibility to activate/deactivate the Tractive System (TS) without triggering the EBS. E.g. for enabling the TS before transiting to the autonomous system

“Ready” state.

Brake_engage EBS Logic

Enables the Supervisor to control the brake for initial check and to prevent the vehicle from rolling without triggering the EBS e.g. during “Ready”

state.

BHC_steering Steering actuator

Output of the Brake Heading Con- trol Loop to counteract vehicle yaw potion

EBS_checkup_done AS State-machine Signal to indicate finished EBS checkup

Service_brake_engaged Service brake Signal to engage the service brake during initial checkup

Service_brake_EBS Service brake Signal to trigger the service brake for emergency

(37)

Figure 4.2. Schematic overview of system and signals.

(38)

4.1.4 Functional description of related elements

Bellow follows a short description of the related elements that are connected to the EBS Supervisor.

EBS logic

A non-programmable logic is used to trigger the EBS when needed. It consists of discrete components like standard 74xx logic gates, transistors etc. No processors or programmable logic parts are included which ensures that the EBS can be triggered without CPU utilization. Figure 4.3 shows a schematic of the EBS logic.

Figure 4.3. EBS Logic overview [25].

Pneumatic part of EBS

The mechanical part of the EBS consists of a normally open 3/2 valve (referred to as EBS valve in this report), mechanical energy storage in terms of a CO₂ cartridge and a pneumatic cylinder that will actuate a brake force on the brake pedal. Figure 4.4 shows an overview of the design concept. The pressure from the CO₂ cartridge will be contained by the EBS valve until a failure is detected or low voltage supply is interrupted. The mechanical energy will then be released as the valve opens and actuate the pneumatic cylinder which will pull the brake pedal with the attached steel wire.

(39)

Figure 4.4. CAD grab of the prototype mount.

Service brake

The service brake consists of a servo motor that apply brake force to the brake pedal by pulling a steel wire as it rotates. It is used during nominal autonomous driving conditions in order to follow the desired trajectory path. The service brake is also used as redundancy for the EBS in case of malfunction of the pneumatic EBS. Continuous monitoring of the service brake actuator by the EBS Supervisor is therefor also required.

Processor unit (dSpace)

The main processing unit, also referred to as the CPU of the vehicle is a dSpace MicroAutoBox. It enables input/output, signal processing, control algorithms etc. The EBS Supervisor code is compiled with the main Simulink model to this unit.

Shutdown Circuit

The vehicle has a shutdown circuit that carries the current to close the Accumulator Isolation Relays (AIRs). This enables the high-voltage system, which supplies the traction motors. Figure 4.5 shows how the EBS is integrated in the shutdown circuit.

(40)

Figure 4.5. Schematic of the shutdown circuit in the top, and how the EBS is integrated to it.

ASMS

In order to activate the EBS Supervisor, the Autonomous System Master Switch (ASMS) must be closed. This physical switch activates the autonomous system where the EBS Supervisor is included.

IMU

The vehicle is equipped with an Xsens MTi Inertial Measurement Unit (IMU) that can measure the yaw motion of the car. This sensor reading is used for the Brake Heading Control system, included in the EBS Supervisor.

(41)

Steering Actuator

In order to enable steering actuation, a permanent magnet DC motor is connected to the steering column. The actuator is used for the BHC feedback loop in order to eliminate potential yaw motion during braking. A potentiometer attached to the steering column is used to feed back steering angle position.

Nvida Jetson TX2 GPU

Sensor inputs from LIDAR and camera is used for the computer vision algorithm to generate a map around the vehicle. From this, the vehicle can also localize itself with the SLAM algorithm and plan its path around the track with a MPC based trajectory planner. In case of any error within the ROS software on the Nvidia GPU, a message shall be sent to the dSpace CPU and the EBS Supervisor algorithm. This should trigger the service brake in order to reach a safe state.

4.1.5 Main operation modes and states of the item

The state-flow of the EBS is integrated in the AS state-flow which is described in figure 4.6. The relation between the two state-machines is described in table 4.3.

Table 4.3. Table of EBS modes.

Vehicle State EBS State Description

AS Off Unavailable Autonomous systems turned off Checkup EBS checkup procedure

AS Ready Armed Ready to drive, waiting for “GO” signal AS Driving Armed Vehicle driving selected mission

AS Finished Armed Vehicle finished with mission

Emergency Brake Triggered Shutdown circuit opened or GLVS supply interrupted

(42)

Figure 4.6. State-machine for the autonomous system [7].

4.1.6 Functional Description of Item

This section describes the main functionalities of the item. An overview of the functionality is given as well as the involved elements.

Initial brake engage

When the vehicle is started by turning on the GLVMS and ASMS, the vehicle shall engage the service brake. This is done in order to prevent unintended take-off due to involuntary torque request.

Involved external elements

Table 4.4. Involved actuators for initial brake engage.

Actuators Service brake

(43)

Initial checkup sequence

The initial checkup sequence is performed in order to detect failures that otherwise would trigger the EBS during operation. This includes failures related to misassembly and missing connections. The checkup sequence consists of the steps described in table 3.2 according to Formula Student EBS Reference Guide [25].

Table 4.5. Involved sensors and inputs for initial checkup sequence.

Sensor/Input

Autonomous System Master Switch (ASMS) Shutdown circuit

Hydraulic brake line pressure sensor

Table 4.6. Involved components for initial checkup sequence.

Components dSpace processor EBS logic

EBS valve

Table 4.7. Involved actuators for initial checkup sequence.

Actuators Service brake

Keep Alive

The EBS Logic is designed in such a way that a single failure results in an emergency braking. This is done with and-statements and a "keep-alive" structure that requires all signals set to high in order to keep the EBS valve closed. As soon as one of these signals are interrupted, the and-statement is not fulfilled which cuts off the signal to the valve.

This results in the EBS valve to open and release the mechanically stored brake energy.

This logic can be seen in the schematic of the EBS Logic in figure 4.3. The signal that keeps the EBS valve closed is To_power_amplifier and the inputs on the left side are the outputs from the EBS Supervisor as well as the analog signals from shutdown circuit and ASMS. The result is that the EBS Supervisor must supply the required signals in order to maintain the "keep-alive". The required signals that the EBS Supervisor must supply are EBS_set_active, Watchdog, Brake_engage, Set_f inish_state, Shutdown_close

(44)

Table 4.8. Involved components for keep-alive.

Shutdown circuit EBS valve

Monitoring

The Supervisor shall continuously supervise and monitor for potential failures. The monitoring shall include:

• Pneumatic tank pressure

• Brake line pressure

• Plausibility of sensor signals

• Service brake transfer function

• Plausibility of non-programmable logic signals

• Check "Driving_state_active" is always active while driving

Errors or forbidden values for these signals shall result in a triggered EBS.

Table 4.9. Involved sensors and inputs for monitoring.

Sensors/Input

Hydraulic brake line pressure sensor EBS pressure tank sensor

Table 4.10. Involved components for monitoring.

Shutdown circuit EBS valve

(45)

Trigger EBS

Most of the potential failures are handled by the EBS logic, which will trigger the brakes by cutting the signal to the EBS valve al release the pneumatic pressure. In case of failures of the pneumatic EBS, the EBS Supervisor shall engage the service brake actuator instead.

Any detected failure shall immediately trigger the service brake. Failures include:

1. Pneumatic tank pressure too low

2. Hydraulic brake line pressure not high enough when pneumatic EBS has triggered 3. Failure message from Nvidia GPU

The first failure imply that there is not enough stored energy to perform an emergency braking if needed. The second failure imply that an emergency brake was initiated by the pneumatic EBS, but for some reason the hydraulic brake line pressure has not increased as expected. This could be due to malfunctioning pneumatic cylinder or EBS valve. In both cases, the service brake should perform the emergency braking. The third failure imply that an internal malfunction in the Nvidia GPU has been detected, which shall also result in a triggered service brake.

There is also the possibility to trigger the pneumatic EBS through the EBS logic by intentionally stopping the watchdog toggling. A situations where this could be used includes malfunction detected in the redundant part of EBS (service brake) by a transfer function check.

Table 4.11. Involved sensors and inputs.

Sensors/Input

Hydraulic brake line pressure sensor EBS pressure tank sensor

Table 4.12. Involved components for EBS trigger.

EBS valve

Table 4.13. Involved actuators/output.

Actuators/output Service brake

(46)

Brake Heading Control

In accordance with rule DV3.3.3 in table A.1, the vehicle must remain in stable driving condition whilst decelerating. This means that no unintended yaw movement is acceptable under braking. This could be ensured by implementing a brake heading control that aims to eliminate any potential yaw motion during braking. The vehicle is equipped with an IMU that can read the yaw motion, which can be used for the feedback loop.

The steering actuator shall then aim to eliminate any yaw after EBS has been triggered.

Figure 4.7 shows a feedback control loop schematic. The reference signal is set to zero and the system output is the vehicle’s yaw motion. The output is sampled by the IMU sensor and together with the reference, the measured error is calculated. This is used for the controller to calculate the needed control signal in order to follow the reference.

Figure 4.7. Diagram of a feedback control loop.

4.1.7 Environmental Conditions

Surroundings

The vehicle will be used on restricted tracks with limited or no unexpected obstacles. No people will be allowed on the track during operation at competition. The surface will be asphalt and known obstacles are plastic cones. For testing however, test engineers within the team will be present in proximity to the track.

Climate and weather conditions

Table 4.14. Climate and weather conditions.

Property Condition

Temperature Approx. 5-25 ^◦C

Humidity Medium to high

Air pressure Atmospheric pressure

(47)

4.2 Hazard Analysis and Risk Assessment (HARA)

The purpose of the HARA is to identify and categorize the hazards that malfunctions in the item can trigger, and to formulate safety goals which shall prevent or mitigate the hazardous events. This clause uses the item definition as a prerequisite.

The HARA was performed while using an internal AVL spreadsheet template that helped streamlined the process. This included a workflow for identifying hazards with a Hazard and Operability Study (HAZOP), evaluating hazardous scenarios as well as classifying ASIL for the safety goals. In the following sections, some extracts from this process has been mirrored to give concrete examples. For the full analysis, please refer to appendices C-E.

This section will deal with the following:

• 4.2.1 Hazard and Operability Study (HAZOP)

• 4.2.2 Hazardous Scenarios

• 4.2.3 ASIL Classification

• 4.2.4 Safety Goals

4.2.1 Hazard and Operability Study (HAZOP)

When performing the HAZOP, the first step is to identify potential hazards that could occur due to malfunctions in the item. Each function described in section 4.1.6 is evaluated according to certain guide words like "NO", "UNINTENDED", "REVERSE", "MORE",

"LESS", "TOO EARLY" and "TOO LATE" [26]. In table 4.15, an extract from the HAZOP for the EBS Supervisor is shown. To give an example, considering the function of "Initial Service Brake Engage". Hazards where identified for "NO", "UNINTENDED",

"LESS" and "TOO LATE" functionality. The same process was repeated for all item functions and can be seen in appendix C. The resulting identified hazards from the HAZOP are summarized in table 4.16.

(48)

4.2. Hazard Analysis and Risk Assessment (HARA)

Table 4.15. Extract from the Hazard and Operability Study (HAZOP).

Abbrevia- tion of function

Functions according to item definition:

Guide

word Hazards Comments

Initial Service Brake Engage

Engage the service brake during initial checkup

NO Unintended

take-off

If torque request is 6= 0 and brakes not engaged,

unintended take-off could happen UNIN-

TENDED

Unintended standstill RE-

VERSE

Malfunction not applicable MORE Malfunction not

applicable

LESS Unintended

take-off

Not enough brake torque TOO

EARLY

Malfunction not applicable TOO

LATE

Unintended take-off

Did not apply the brakes in time

Table 4.16. Summary of identified hazards from HAZOP.

Hazard-ID Assumed Hazards Comment

H1 unintended take-off

H2 unintended standstill

H3 unintended braking

H4 loss of brake function No brake force when trying to brake

H5 loss of brake trigger function Not able to trigger the brakes H6 unintended long braking distance Included in H4 (less severe

version of H4)

H7 unintended rotation

H8 loss of steering

4.2.2 Hazardous Scenarios

With the hazards identified, one shall study these together with scenarios that the vehicle will be exposed to. The scenarios are classified with the following features:

• Main classification (driving, parking, charging, crash, repair etc.)

• Location/type of street (all roads, highway, main road, city area etc)

• Traffic/driving situation (normal, curved road, downhill, overtaking etc. )

• Speed range (low, normal, high speed)

(49)

• Environmental conditions (normal, wet roads, black ice etc.)

• Other particularities (with obstacle, other road users, oncoming traffic etc.) The scenarios for a Formula Student car is however different from a typical car. This meant that scenarios for this thesis had to be defined. The following three scenarios seen in table 4.17 were defined and decided to use for the safety analysis.

Table 4.17. Scenarios of operational situations.

Scenario Identifier

Main classifica-

tion

Loca- tion/

Type of streets

Traffic/

driving situa-

tions

Speed range

Environ- mental conditions

Other par- ticularity (free text)

ID-0-1 driving test track all

normal speed

normal

spectators/

test engineers/

track marshals

ID-0-2 driving test track all

normal speed

wet

spectators/

test engineers/

track marshals

ID-0-3 standstill test track all standstill

people in proximity to car

Start-up, with sur- rounding people

In order to identify hazardous scenarios, each scenario and hazard from table 4.16 are considered together as seen in figure 4.18. One must reflect upon and decide whether or not the hazard will cause any accident in that particular scenario. It is seen that hazards like "unintended standstill" and "unintended braking", that seem obviously dangerous, will not cause any accidents for these particular scenarios. This is because there are no other vehicles on the track that could collide with a car that is at standstill or suddenly performs a deceleration. It is on the other hand seen that an unintended take-off at the standstill start-up procedure could result in an accident with the possibility of a person being injured.

(50)

Table 4.18. Hazardous scenarios

ScenarioIdentifier H1:unin-tendedtake-off H2:unin-tendedstandstill H3:unin-tendedbraking H4:lossofbrakefunction Com-mentsforH4:lossofbrakefunction H5:lossofbraketriggerfunction H7:unin-tendedrotation H8:lossofsteering ID-0-1 not

relevantforthishazard noaccident

iscausedbythishazard noaccident

iscausedbythishazard collisionwithperson

(mediumdifferentialspeed) collisionwithperson

(mediumdifferentialspeed)

ID-0-2 not

relevantforthishazard noaccident

iscausedbythishazard noaccident

iscausedbythishazard AlreadycoveredbyID-0-1 AlreadycoveredbyID-0-1 AlreadycoveredbyID-0-1 AlreadycoveredbyID-0-1 ID-0-1 collisionwithperson(low

differentialspeed) noaccidentiscausedby

thishazard noaccidentiscausedby

thishazard collisionwithperson(low

differentialspeed) Sameconse-quenceasH1-ID-0-3,differentmalfunction notrelevantfor

thishazard notrelevantfor

thishazard noaccidentiscausedby

thishazard

(51)

4.2.3 ASIL Classification

The Automotive Safety Integrity Level (ASIL) is used to specify the item’s necessary requirements of ISO 26262 and safety measures to avoid unreasonable risk. There are four levels ranging from A-D, with A being the least strict level. The ASIL classification is a method of quantifying the severity of injuries, the probability of an operational situation and the ability to avoid specify harm through the reaction of the involved persons. These three categories are denoted severity, exposure and controllability. In the following sections an explanation of the classification is given. The information is based on "Annex B" in [18].

Severity

The ISO 26262 standard evaluates the severity based on the Abbreviated Injury Scale (AIS) which is issued by the Association for the Advancement of Automotive Medicine (AAAM). There are seven classes of AIS describing the different severity of the injuries

as below:

– AIS 0: no injuries;

– AIS 1: light injuries such as skin-deep wounds, muscle pains, whiplash, etc.;

– AIS 2: moderate injuries such as deep flesh wounds, concussion with up to 15 minutes of unconsciousness, uncomplicated long bone fractures, uncomplicated rib fractures, etc.;

– AIS 3: severe but not life-threatening injuries such as skull fractures without brain injury, spinal dislocations below the fourth cervical vertebra without damage to the spinal cord, more than one fractured rib without paradoxical breathing, etc.;

– AIS 4: severe injuries (life-threatening, survival probable) such as concussion with or without skull fractures with up to 12 hours of unconsciousness, paradoxical breathing;

– AIS 5: critical injuries (life-threatening, survival uncertain) such as spinal fractures below the fourth cervical vertebra with damage to the spinal cord, intestinal tears, cardiac tears, more than 12 hours of unconsciousness including intracranial bleeding;

– AIS 6: extremely critical or fatal injuries such as fractures of the cervical vertebrae above the third cervical vertebra with damage to the spinal cord, extremely critical open wounds of body cavities (thoracic and abdominal cavities), etc.

These classes are assessed together with accident statistics in order to determine the injuries expected to occur for different types of accidents. In table F.1 in appendix F, the examples of severity classification from ISO 26262 are seen. This table can be boiled down to table 4.19 to summarize the classes of severity. For the hazardous scenarios identified for the EBS Supervisor, severity level S2 and S3 were assigned.

(52)

Table 4.19. Classes of severity Class

S0 S1 S2 S3

Description No injuries

Light and moderate injuries

Severe and life-threatening injuries (survival

probable)

Life-threatening injuries (survival

uncertain), fatal injuries

Exposure

The probability of exposure is evaluated and given a level from E0 to E4. The lowest level E0 is given for highly unlikely or infeasible situations. Examples from ISO 26262 includes airplane landing on highway or natural disasters. Note that the exposure is evaluated for the situation that the vehicle is involved in. It is not the hazardous event or the accident that should be evaluated. For the classes E1-E4, the exposure is evaluated either depending on duration of situation or the frequency of occurrence. The most appropriate exposure rank shall be used for the analysis of situation. In Appendix F, Table F.2 and F.3 illustrate the different exposure rankings. In short, the probability is ranked as in table 4.20.

For the situations defined for this thesis (Table 4.17), the exposures were determined to E3 for ID-0-1 (driving, dry track) and E2 for ID-0-2 (driving, wet track). Since the Formula race car is never operated on normal roads, the classes according to ISO 26262 were merely used as a reference. For example, according to Table F.2 a wet road shall result in E3. However, since the likelihood of operation is lower for wet conditions for a race car compared to a normal car, the exposure was lowered to E2. Operation during dry road conditions is more likely and is therefore assigned E3.

For ID-0-3 (start-up at standstill) frequency of occurrence was used to give a level of E4. This is inline with Table F.2 stating that for E4, the frequency of situation "occurs during almost every drive on average".

Table 4.20. Classes of probability of exposure regarding operational situations Class

E0 E1 E2 E3 E4

Description Incredible Very low probability

Low probability

Medium probability

High probability

Controllability

The determination of the controllability class is based on the probability of the driver retaining or regaining control of the vehicle if a hazard were to occur. In Table F.4 examples of scenarios and respective controllability classes are given. In Table 4.21 a

Design and Safety Analysis of Emergency Brake System for Autonomous Formula Car