Safety Analysis of a Cooperative Adaptive Cruise Control System

(1)

Safety Analysis of a Cooperative

Adaptive Cruise Control System

Guido Loupias

August 11, 2016, 28 pages

Supervisor: Dr. Yanja Dajsuren, PDEng

Host organisation: Centrum voor Wiskunde & Informatica

Universiteit van Amsterdam

Faculteit der Natuurwetenschappen, Wiskunde en Informatica Master Software Engineering

(2)

This thesis researches safety analysis for a cooperative driving system. The main objective is to assess how cooperative elements in an ISO 26262 item definition affect safety goals. The functional safety of a cooperative adaptive cruise control system is modeled and analyzed using a combination of fault tree analysis and fault classification methods. The results show that inclusion of cooperative elements affects the safety goals of cooperative adaptive cruise control because ASIL determination is influenced by vehicle-to-vehicle communication faults.

(4)

Chapter 1

Introduction

In many urban areas, there is an increasing number of vehicles on the road leading to problems of increased traffic congestion and fuel emissions [1]. That is why a priority set by the European Union is resource efficient transport, which includes minimization of traffic congestion and minimization of fuel emissions [2]. One of the potential solutions to the problems of traffic congestion and fuel emissions is cooperative driving. In cooperative driving, traffic participants utilize wireless technology to exchange information and use this information to optimize the collective behavior of the involved traffic participants [3].

One of the well known examples of cooperative driving is platooning. As shown in figure 1.1, a platoon can be defined as a number of vehicles that automatically follow a manually controlled lead vehicle [4]. Platooning has been empirically researched as part of the European SARTRE (Safe Road Trains for the Environment ) project. It was found that fuel consumption tends to decrease for all vehicles in the platoon as the following distance decreases and could decrease down to 84% [5]. Van Arem et al. [6] showed that cooperative adaptive cruise control (CACC) might increase traffic throughput (average vehicle speed) up to 10 km/h during traffic merges, but it depends significantly on the percentage of vehicles equipped with CACC capability.

Suppose that all the vehicles on the highways can be organized into cooperative platoons, the results in the previous paragraph imply that fuel emissions and traffic congestion might be significantly reduced. Therefore, further investigating the potential of cooperative driving would be a worthwhile endeavor.

Because cooperative driving relies on digital information processing of which the goal is to deter-mine the behavior of vehicles, a central ingredient of cooperative driving is the shift from mechanical-hydraulic control systems to hybrid or fully electronic control systems, called by-wire systems [7]. By-wire systems work by first interpreting commands with software running on electronic control units, the software then controls the vehicle via electronic actuators. Examples of a steering-by-wire

(5)

and a braking-by-wire system are given in Bertoluzzo et al. [7]. The combination of wireless com-munication and by-wire systems enables the automated vehicle following that is present in vehicle platoons [4].

Not only do by-wire systems enable cooperative driving, but they are also perceived to have other benefits with regard to energy efficiency of vehicles and driver safety [7]. This shift in the automotive industry has resulted in ISO 26262 [8], a product development safety standard specifically designed for the automotive industry released in 2011. The scope of this standard is the development of safe electrical and/or electronic (E/E) systems [9], of which software is an essential part. The standard has a dedicated part for software development [10].

It is remarked that ISO 26262 considers cooperative driving out of scope [11], and several studies propose extensions to the development process [12]–[14]. This research aims to shed some more light on this discussion by performing a safety analysis on a cooperative adaptive cruise control system followed by determination of safety goals to find out more about the impact of cooperative driving technology on development of safe automotive systems.

1.1 Research objective

Nilsson et al. [12] stated that ISO 26262 suffers from a vehicle-centric perspective because it only applies safety analysis to in-vehicle elements and lacks a cooperative perspective necessary for the safety of cooperative driving. A cooperative perspective enables the application of safety analysis to cooperative elements, such as vehicle-to-vehicle (V2V) communication. However, there is no research that assesses the impact of explicitly modeling cooperative elements on a more detailed safety analysis. Therefore, our objective is to investigate the following main research question:

Research question. What is the impact of modeling V2V communication as a safety item from ISO 26262 on the resulting safety goals?

1.2 Outline

Chapter2further details the context of the research and background. Chapter3reviews related work. Chapter 4 explains the research method, which we apply in a case study in Chapter 5. Chapter 6

(6)

Chapter 2

Background

2.1 ISO 26262

The ISO 26262 standard was introduced in 2011 to provide product development guidelines for ensur-ing functional safety of automotive electrical/electronic (E/E) systems. Functional safety is defined as the absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems [8]. The standard dictates the V-model development model depicted in figure2.1where production occurs on the way down the V and quality assurance occurs on the way up.

Figure 2.1: ISO 26262 V-model [8], [15]

The standard consists of ten parts, each part covers a certain phase or aspect of the development process. For this research, the concept phase is the most relevant. The concept phase deals with the construction of safety goals from an item definition, which is more or less a high-level architectural model [16]. A safety goal is defined as a top-level safety requirement as a result of hazard analysis and risk assessment (HA&RA) [8]. An overview of the concept phase is depicted in figure2.2.

(7)

Figure 2.2: ISO 26262 concept phase

determination is based on three aspects: severity, probability, and controllability. Each of these aspects is divided into classes: S0–S3 for severity, E0–E4 for probability, and C0–C3 for controllability, where the degrees of severity and probability increase as the S-number and E-number increase respectively, and the degree of controllability decreases as the C-number increases. For example, S0 means “no injuries”, and C3 means “difficult or impossible to control” [16]. The ASIL (A–D) is then determined by a simple table-lookup [16]. Not every combination of the three aspects is assigned an ASIL, for example any combination with S0, E0, or C0. Also, some other low-risk combinations such as {S1, E1, C1} are assigned ASIL-QM, which requires no further analysis [16].

For each hazard where the ASIL falls in the range A–D, one or more safety goals are to be de-termined. The purpose of the safety goals is to mitigate the hazard as much as possible (prevent unreasonable risk). What exactly the safety goals should be, is not dictated by the standard, al-though some examples are given, such as imposing a maximum level of acceleration during certain situations [16].

2.2 Cooperative adaptive cruise control

Cooperative adaptive cruise control (CACC) is a variant of adaptive cruise control (ACC) that uses cooperative technology for further optimization. When a vehicle is in adaptive cruise control mode, it follows the preceding vehicle based on the setting of the desired time gap between two vehicles [17]. So, the physical distance between vehicles varies as the velocity of the vehicles varies while the time gap between vehicles remains constant. This is known as ACC based on a constant time headway policy [17]. The advantage of CACC compared to ACC is that the time gap could potentially be reduced safely thanks to cooperative technology, resulting in reduced fuel consumption and better usage of road capacity [5], [6].

When a vehicle is in cooperative adaptive cruise control mode, what is communicated from a vehicle to the successor vehicle is the acceleration setpoint of the vehicle, which is the desired acceleration or

(8)

Figure 2.3: Wireless communication in cooperative adaptive cruise control [18]

deceleration that the engine or brakes ought to achieve at the moment. See figure2.3for an illustration of this communication. Communicating this information enables the successor vehicle to follow the vehicle more closely than is possible with a traditional ACC system because it allows the successor vehicle to predict the location of the vehicle more accurately. Therefore, correct functioning of CACC is dependent on successful communication of this acceleration setpoint parameter in real-time.

Ploeg et al. [18] proposed a fault tolerance solution for V2V communication faults for CACC which is a graceful degradation scheme that estimates the current acceleration of the preceding vehicle using on-board sensors. However, there is no current research that analyzes the impact of V2V communication on ISO 26262 safety goals.

(9)

Chapter 3

Related work

This chapter reviews previous work carried out in the domain of safety analysis. Previous work is divided into three categories:

Standards application Research that focuses on the application of existing safety standards such as IEC 61508 and ISO 26262.

Safety analysis Research that focuses on existing or new safety analysis methods.

System development Research that focuses on system development methodologies that take safety analysis into account.

3.1 Standards application

Ward [11] investigated the challenges of system safety in hybrid and electric vehicles in addition to emerging vehicle technologies. The paper showed differences between the IEC 61508 and ISO 26262 standards, most notably their difference in approach to functional safety. “In IEC 61508, safety integrity levels (SILs) are related to assuring the reliability of safety functions. In ISO 26262, ASILs are related to assuring that the safety goals are not violated.” [11] It argued that functional safety in the IEC 61508 standard is a subset of system safety in hybrid and electric vehicles because the functional correctness of the safety measures that are implemented as electronic systems serves overall system safety. Also, it argued that a unified approach to HA&RA is better because HA&RA principles are universally applicable. A unified approach takes into account overall system safety as opposed to only functional safety. MISRA Safety Analysis Guidelines [19] is regarded as an example. Furthermore, it is stated that for some systems in modern vehicles, such as high voltage interlock systems, the IEC 61508 approach to functional safety might be better suited, and that ISO 26262 does not regard autonomous and cooperative vehicles.

Panesar-Walawege et al. [20] described a method for capturing the relationship between generic standards, such as IEC 61508, and sector-specific standards, such as ISO 26262, by using UML pro-files to describe generic standards and applying their stereotypes to UML models of sector-specific standards. OCL is used to verify the logical consistency of the relationship. This serves as a method-ology for specializing a generic standard for a particular domain.

Robinson-Mallett [14] proposed a coordinated development process which incorporates ISO 15408 and ISO 26262 in order to facilitate the aspects of both security and safety during the development process. There exist dependencies between the two, as the trustworthiness evaluation of a proposed security measure may influence the level of safety of a particular function, and the violation of a safety goal may be due to security threats. They recommended a standard development process model such as ASPICE [21] for developing vulnerability counter-measures, and they recommended a simplified approach on the estimation and categorization of residual risks (safety hazards revealed after evaluation of trustworthiness). It is stated that a transformation scheme for evaluation assurance level (EAL) and automotive safety integrity level (ASIL) could increase efficiency of the coordinated safety and security engineering activities as well.

(10)

Burton et al. [13] discussed the hazard of intentional malicious manipulation, either via direct physical contact or over a network. They described how ISO 26262 can be extended to include security issues and stated that these are becoming increasingly important as vehicular systems move towards interconnectivity.

Saberi et al. [22] described an ISO 26262 compliant method for improving the functional safety of an existing automotive software system, which could possibly have been developed without ISO 26262 compliance. The method covers the process from item definition to testing and verification.

3.2 Safety analysis

Nilsson et al. [12] argued that software development for cooperative automotive systems would benefit from a cooperative perspective, on the grounds that ISO 26262 does not accommodate for architecture artifacts that are shared across vehicles, and that this could result in the omission of relevant safety goals. They asserted that ISO 26262 suffers from a vehicle-centric perspective. ISO 26262 is applied to the abstract concept of an item, which is defined as a system or array of systems to implement a function at the vehicle level [8]. They argued that modeling vehicle-to-vehicle (V2V) communication as an item could improve the situation because it allows one to find new safety goals [12].

Liu and Joseph [23] described how fault tolerance and schedulability for real-time systems, as well as functional and time correctness, can be specified and verified within a single formal framework using transition systems as a program model and the Temporal Logic of Actions as the specification notation. They argued that the advantages of using a single formal framework are having a unified view of the functional and non-functional properties of programs and having a uniform method of verification. Also, if the formal framework is used as the specification tool, the schedulability of the specification could be verified by an oracle which uses scheduling theory for rapid analysis.

Mariani et al. [24] described a systematic approach to perform failure mode and effects analysis (FMEA) on the system-on-a-chip (SoC) level. They used a tool which extracts sensible zones and observation points from a resistor-transistor level (RTL) description. “A sensible zone is one of the elementary failure points of the SoC in which one or more faults converge to lead to a failure” [24]. “The effects of failure modes in a sensible zone are measured at observation points” [24]. The data extracted by the tool is used to compute the diagnostic coverage (DC) and the safe failure fraction (SFF) of the SoC. For failure modes that are detected on-line (by internal diagnostic tests), proper DC is one required artifact to argue that a diagnostic test is credible [25]. Different SILs require different SFFs. They also proposed a validation methodology based on several tools that perform fault injection and simulation.

Fujiwara et al. [26] described a method to classify a software system into a SIL based not on the development process used to build the software, but on a software reliability growth model (SRGM) for the software. A SRGM is used to predict the number of faults that are present in a software system over time. Based on an SRGM of choice, they showed how to derive a model for the mean time between failure (MTBF) of the software system, and they described a model for representing the rate of dangerous failures. By combining these models they obtained a model for the probability of dangerous failure per hour (PFH), which is a concept used in the IEC 61508 standard. Simply put, the standard places different upper bounds on the PFH for different SILs i.e. SIL-4 requires a PFH < 10−8 while SIL-3 requires a PFH < 10−7 [26].

Hillenbrand et al. [27] described a tool and metric based approach to evaluate and compare the relative functional safety of two initial architecture models. They proposed to use safety annotations in the architecture model which are used to trace safety goals to components. This leads to the identification of safety-critical components which can then be assessed according to a known safety assessment method such as FMEA. A metric for evaluation of the architecture model is proposed. This metric is based on the idea that a hazard is introduced either by an omission or commission failure. Omission failures occur due to failure to perform functions when required, commission failures occur due to functions being performed when not required. Omission and commission failures are two failure modes. Each component of the system has a certain probability that it will end up in a certain failure mode. The arrangement and grouping of the components into subsystems in the architecture determine how and when these probabilities are to be combined in order to obtain the probability

(11)

that a certain subsystem ends up in a certain failure mode. This information is used, before and after changing the architecture, to evaluate and compare the reliability of the system.

Schulze et al. [28] described a tool that aims to integrate functional safety analysis with variability. They integrated two tools, medini analyze and pure::variants, in the Eclipse IDE. Their tool consists mainly of a reference model that keeps track of which architecture artifacts in the medini tool are used in each variant of the pure::variants tool. While it is claimed that the approach is scalable, it seems that there is no automated support for identification of common artifacts across variants. Thus, there can be some doubt about the scalability when the number of variants exceeds the capacity of the safety analyst for keeping track of them all.

Briand et al. [29] described a mechanism to facilitate the safety inspection of SysML models. They devised an algorithm that creates slices of a design, based on traceability links between requirements and SysML models. They reported, based on a controlled experiment, that the use of design slices during inspections has significant advantages in terms of the correctness of the outcomes of the inspections, compliance decisions, and effort.

3.3 System development

Hunter [30] described a framework for achieving the independence of safety related functions by means of introducing a safety boundary around safety related components which are dependent on each other from a safety point-of-view and then determining safety separation levels (SSLs) across boundaries. SSLs are meant to constraint the probability of propagating dangerous failures across boundaries. Suggestions for SSLs for boundaries between subsystems with known safety integrity levels (SILs) were given, as well as an (incomplete) list of concrete means to achieve specific SSLs.

Baumgart et al. [31] indicated that, if modular safety certification can be achieved, then software product line engineering can be applied to increase efficiency during development.

Rupanov et al. [32] presented an iterative architecture design method in order to support early quantitative safety evaluation. Each iteration consists of the modification or creation of an archi-tectural blueprint, determining the safety requirements, followed by top-down safety analysis (FTA), followed by a selection of safety mechanisms, followed by a bottom-up analysis (FMEA), followed by a safety evaluation. The safety mechanisms and components to which the mechanisms apply, including their safety-related data such as diagnostic coverage, are modeled in a new metamodel and saved in a repository. This enables reuse and partially automated evaluation.

Rodriguez-Navas et al. [33] described the VeriSpec project. VeriSpec is an effort to improve several aspects of automotive software development by improving and creating new methods and tools. They stated that they will extend a tool called ViTAL with a requirements specification front-end that allows requirements to be automatically transformed into formal requirements by means of a pattern based approach, inspired by the avionics domain [33]. Also, they stated that they will extend the tool with a means of linking requirements to architectural elements to facilitate traceability.

Domis et al. [34] described a toolchain that facilitates software and system product line (SSPL) engineering for safety-critical systems by means of integrating component integrated component fault trees and feature models to enable the automatic deduction of failure modes of individual product variants.

Käßmeyer et al. [35] described a holistic systematic change impact analysis process for software product line automotive systems. Due to the safety-critical nature of automotive systems, when changes are requested, the safety goals that are related to the affected components need to be re-evaluated for fitness and possibly changed. This can be a complicated process because when a safety goal is affected, it can in turn affect multiple components, and the process has to take into account all product variants which are affected. The process proposed is one that takes into account the view of the software developer and the view of the safety expert.

Kreiner [36] described the architectural viewpoints model Trident. The purpose of Trident is to facilitate the architecting of dependable (i.e. reliable, safety-critical) systems. It defines three archi-tectural views: a functional view, an elements view, and a composition view. The functional view shows the functional requirements and quality attributes of the system on all levels of granularity. The elements view shows individual system and subsystem components. The composition view shows the

(12)

composition of elements. Using this viewpoints model, you define, allocate, and compose functions in one iteration, and in another iteration, you analyze the behavior of an element and evaluate the behavior of a composition of elements to determine the level of acceptable risk of a particular function.

3.4 Research gaps

There exist many opportunities for evaluation of proposed system development methodologies in the cooperative driving context, and opportunities for evaluation of suggested ways to apply standards.

Specifically, we have not been able to find research that investigates how modeling cooperative elements impacts subsequent safety analysis and determination of safety goals. This research aims to close this gap by proposing a taxonomy for V2V communication faults and using it in a safety analysis on a cooperative adaptive cruise control system.

(13)

Chapter 4

Research method

The development method of the concept phase of ISO 26262 is applied to an existing cooperative adaptive cruise control system, as shown in figure4.1. An item definition is created, and using hazard data from experts, safety analysis is performed and safety goals inferred. As highlighted in figure4.1, the data on probability of exposure is not available because of reasons of confidentiality and lack of data gathering. Therefore, we have developed a method of safety analysis to show the relative contribution of vehicle-to-vehicle communication faults instead of probability of exposure.

Figure 4.1: ISO 26262 concept phase

For analysis we use fault tree analysis (FTA) [37]. With fault tree analysis a holistic view is obtained that reflects which faults affect a particular hazard. Since we have obtained our hazard data from automotive domain experts, performing FTA on the architectural model for each hazard is a logical follow-up action. It is also possible to use failure mode and effects analysis (FMEA) [38]. That method of analysis is particularly suited to finding all the ways in which certain components can fail and their consequences. Performing an FMEA on V2V communication could also provide informative

(14)

Figure 4.2: Example fault tree [39]

results but is considered to be out of scope in this research. Section4.1describes the method in more detail.

When fault tree analysis is completed, the result is used to determine the ASIL of the hazard. The determination of the ASIL dictates whether or not it is necessary to formulate safety goals for V2V communication.

4.1 Fault tree analysis

Fault tree analysis is used to discover what the causes of a particular event is. It is based on the concept of a fault tree, an example of a fault tree is depicted in figure 4.2. In the context of safety analysis, FTA relies on a list of known hazards. For each hazard a fault tree is constructed. The root node of a fault tree is the hazard.

Expressed in the terminology of fault tree elements, the hazard is an intermediate event. FTA is an iterative process whereby for each such event, the question is asked: what are the possible events that could be immediate causes of this event? The word immediate is used to indicate that the causal events are direct causes of the event in question. Suppose event A has event B as a cause. B is an immediate cause of A if there is no event C such that C causes A and B causes C.

Each immediate cause that is found is in turn modeled as either a basic event or another immediate event and becomes a child node of the event in question. A basic event is not further investigated, but the iterative process repeats itself for all intermediate events. In order for quantitative analysis to be performed on the tree, there should be data about the probability of exposure of each basic event. Effectively, a basic event is a root cause.

Between a node and its children, one boolean operator is attached to the bottom of the node that indicates in what way the children cause the event to happen. The most frequently used operators are the OR-operator and the AND-operator. The OR-operator says that the occurrence of any of the immediate causes of an event will cause that event to happen, the AND-operator says that all immediate causes must occur in order for the event to happen. If a combination of OR-ed and AND-ed immediate causes is found, this ought to be modeled by introducing an abstract event as a root for the AND-ed immediate causes and OR-ing that event with the OR-ed immediate causes.

4.1.1 Evaluation of fault trees

Quantitative evaluation of a fault tree relies on boolean algebra. Probabilities of basic events are propagated up the tree according to rules for each of the boolean operators. This results in the probability of exposure to the root event (the hazard).

A different, frequently used, method to obtain this probability is to calculate it based on all the minimal cut sets of the tree. A cut set is a set of basic events such that when the combination of

(15)

those events occur, they cause the root event. In other words, the combination of the basic events in a cut set is sufficient to cause the root event. A minimal cut set is a cut set that is both necessary and sufficient. If you remove any basic event from a minimal cut set, the root event is no longer caused. All basic events in the minimal cut set are necessary in the combination to cause the root event.

Effectively, obtaining all minimal cut sets is the same thing as obtaining all the ways in which the system can fail to cause the hazard at the root of the fault tree. Given the probability of exposure to each basic event B in minimal cut set M , the probability of exposure to M is the product of the probabilities of its basic events, as in equation4.1.

P (M ) = Y

B∈M

P (B) (4.1)

Given the probability of exposure to each minimal cut set M of a fault tree with root event R, the probability of exposure of R is the sum of the probabilities of the minimal cut sets, as in equation4.2.

P (R) = X

M ∈M CSR

P (M ) (4.2)

Where M CSR is the collection of all minimal cut sets for the fault tree with root event R.

This concludes the scope of FTA that is relevant for this research, for a thorough explanation of FTA the reader is referred to Stamatelatos et al. [37].

4.1.2 Hazards and basic events

As mentioned before, FTA relies on a known list of hazards and basic event probabilities. Both of these are usually obtained from experts and analysis of past projects respectively. For our case study we have been able to obtain a list of hazards from experts, but we have no such luck for probability data and are unfortunately not in a position to evaluate our own past projects. Therefore, we alter FTA such that, instead of revealing the probability of the top-level event, it reveals the relative contribution of the basic events.

In Nakajo and Kume [40], a fault classification taxonomy is given that is used in Lutz [41] to re-search what the probabilities are of different kinds of faults in safety-critical embedded systems in the aerospace domain. During this research, we have developed a method to show what the relative con-tributions of different fault classes are to the top-level event, based on a fault classification taxonomy for the basic events. Basic events are classified either as vehicle-local faults or V2V communication faults. Then, using the minimal cut set approach, it becomes possible to calculate the relative contri-bution of each fault class to the top-level event. Effectively, it allows us to see what percentage of total potential failures can be caused by V2V communication faults. Note that this does not say anything about the probability of exposure to V2V communication faults, so even though the percentage could be small, the impact could still be high. However, if the percentage is zero, we know for sure that V2V communication faults do not pose a threat. In the next section, the method is explained in detail.

4.2 Classification-based approach

Instead of a probability, each basic event in the fault tree carries a fault classification. A fault classification is a key-value structure that describes, for each fault class, the number of times a fault of that fault class has occurred. Let F C (B) be the function that gives the fault classification for an event B. An example fault classification for an event B is given in equation4.3.

F C (B) = {x : 1, y : 2} (4.3)

This fault classification says that one fault of class x and two faults of class y contribute to the exposure to basic event B. In order to be able to work with fault classifications, first some basic operations need to be defined.

(16)

Index The individual fault classes of fault classifications can be accessed by using the index operator [], so F C (B) [x] = 1 in the example of equation 4.3. If the given class does not exist in the fault classification, the operation evaluates to 0.

Class enumeration The set of all fault classes can be obtained from a fault classification with the function K, so K F C (B) = {x, y} for equation4.3.

Addition Fault classifications can be added together, what this means is that the individual fault classes are added together. Let F and G be fault classifications, then the definition of this operation is given in equation4.4.

F + G = {x : F [x] + G [x] | x ∈ K (F ) ∪ K (G)} (4.4)

Normalization Finally, fault classifications can be normalized by using the normalization operator ||. Normalizing a fault classification means dividing the occurrence count of each class by the total number of occurrences, so |F C (B)| =x :1

3, y : 2

3 for equation4.3.

Note that we do not define how fault classifications can be propagated up the fault tree like probabil-ities because this is not necessary, since we will use the fault classifications only to get an impression of the contributions of the fault classes to the hazard, and in order to do that, we only need them after we find all minimal cut sets. Using this mathematical representation of a fault classification as a building block, we can continue to define the method of analysis using minimal cut sets.

Given that a minimal cut set is a set of basic events which all occur in order to cause the hazard, we can add all fault classifications of those basic events together to get the fault classification of the minimal cut set. Intuitively, since a minimal cut set is a representation of the way in which the system fails, this means we get a measure for the contribution of each fault class to this way of failure. Given the fault classifications of each basic event B in minimal cut set M , the fault classification of M is sum of the fault classifications of its basic events, as in equation4.5.

F C (M ) = X

B∈M

F C (B) (4.5)

Since the set of all minimal cut sets represents the set of all the ways in which the system can fail to cause the hazard, if we sum the fault classifications of the minimal cut sets and respectively normalize the result, then we obtain a fault classification that represents the relative contribution of each fault class to the hazard. Given the fault classifications of each minimal cut set M of a fault tree with root event R, the fault classification of R is the normalization of the sum of the fault classifications of the minimal cut sets, as in equation4.6.

F C (R) = X M ∈M CSR F C (M ) (4.6)

So, by obtaining F C (R) for a fault tree where there are basic events that can be classified under the fault class of V2V communication faults, we can at least say something about the relative contribution of V2V communication to the hazard.

Note that it is possible that identical minimal cut sets can result from different parts of the tree i.e. the same minimal cut set of basic events can be picked from different parts of the fault tree. An example is depicted in figure4.3, where the minimal cut set {C} can come from two parts. Intuitively, this could be interpreted as saying that the system is vulnerable for the same way of failure in multiple places. The question must be answered: should identical minimal cut sets be counted separately, or should they be filtered out? On one hand, the duplicate sets represent the exact same way of failure. The system either fails in that particular way and the hazard is caused, or it does not fail in that way and the hazard is not caused, there is no in-between. The duplicate sets add no information about the different ways in which the system can fail. On the other hand, when you look at how probabilities propagate up the tree, multiple instances of the same basic event each contribute to the

(17)

Figure 4.3: Fault tree with two identical minimal cut sets

probability of exposure to the hazard. So, the amount of times that a minimal cut set is duplicated also influences the probability of exposure to the hazard due to that minimal cut set. We argue that a fault classification ought to behave in the same way i.e. if a particular fault affects multiple parts of the system, that ought to be reflected in the final fault classification. Therefore, we choose to interpret duplicate basic events in different parts of the fault tree as if they were actually different events, albeit with the same characteristics. This leads to separate counting of “identical” minimal cut sets (strictly speaking, identical minimal cut sets do not exist anymore).

To the best of our knowledge, there is no similar method.

4.2.1 Classification of basic events

The challenge that is left is to find appropriate classifications for basic events. For this research, we are interested in two classes of faults: vehicle-local faults and V2V communication faults.

The relationship between faults and fault classes are obtained from the fault class taxonomies that are presented in Section 4.2.2 and Section 4.2.3. FTA is performed by looking at the architectural model and identifying the basic events and intermediate events. Each basic event is a fault that is mapped to its corresponding fault class. During modeling, a best-effort attempt is to be made to find a balance between realism and keeping the model sufficiently high-level enough such that the FTA can be performed manually.

4.2.2 Taxonomy of vehicle-local faults

A fault taxonomy for automotive systems has been developed as part of the EASIS project [42]. Unfortunately, the detailed list is no longer available, but the high-level classification is given and is presented in table4.1. The CPU fault class also includes software programming errors [42].

Vehicle-local fault Reference

CPU fault [42]

Sensor fault [42]

Actuator fault [42]

Power supply fault [42] Communication system fault [42]

(18)

4.2.3 Taxonomy of V2V communication faults

V2V communication faults cannot be attributed to any single vehicle. They are properties of the network protocol used for communication. As a network protocol we aim at IEEE 802.11p and WAVE, since these protocols are on their way to being standardized for vehicle networks [43]. We base the faults on some of the network properties investigated in [43], [44], and [45]. We observe that the potential faults of V2V communication all have to do with the network being unable to deliver the required Quality-of-Service (QoS) level. Requirements on the QoS level are application dependent. Safety-critical applications such as collision avoidance have higher QoS level requirements than non-safety-critical applications. An example list of requirements on applications can be found in Ib’nez et al. [44]. The taxonomy is listed in table4.2.

V2V communication fault Reference Unacceptable packet delivery ratio [43][45] [44]

Unacceptable latency [44]

Table 4.2: Taxonomy of V2V communication Fault Class

4.3 Relation to safety goals

Since standard fault tree analysis is used to determine the probability of exposure to an event, it is a tool that is used to classify the hazard in one of the probability classes. We can say with certainty that if the relative contribution is zero, it can be interpreted as probability class E0. A conservative approach would be to interpret anything larger than zero as probability class E1 or higher. The exact relationship between the relative contribution and the probability is undefined.

(19)

Chapter 5

Case study

We apply the method developed in Chapter 4 to the cooperative adaptive cruise control system described in Ploeg et al. [46]. The CACC system described there is based on the constant time headway policy.

Automotive control systems are frequently implemented in Simulink, a visual modeling language for control systems [47]. This model can be used to generate AUTOSAR-compliant C++ code, AUTOSAR is an architecture standard for automotive software systems [48]. Unfortunately, that code generation part relies on a proprietary MATLAB module which is not available to us, so we cannot perform FTA on any generated code. However, it is possible to perform FTA on high-level architectural models if information about the causes for failure of components is available [49]. Such a model, including deployment information, is presented by Ploeg et al. [46, fig. 5].

The V2V communication fault class taxonomy deals with packet loss and latency, so it is important that our architecture model is realistic with regard to its responses to these faults. Therefore, in our model we assume that the fault tolerance capability of the CACC subsystem is limited to fault detection. In case of a V2V communication fault, the CACC component outputs a diagnostic error message to which the system is free to respond as it deems appropriate, for example by switching to the graceful degradation scheme proposed by Ploeg et al. [18].

The architecture model illustrated in figure5.1 is mainly based on the information from Ploeg et al. [46, fig. 5], with the addition of the V2V communication element and the omission of the ACC subsystem which was connected to the MOVE gateway [the ACC subsystem was modeled because it was part of the vehicle instrumentation]. The CACC platform is able to function without the ACC subsystem because it works directly with the radar and PMC.

(20)

Figure 5.1: Architecture model based on Ploeg et al. [46] with V2V communication

5.1 Application of fault taxonomy

The relationship between components and the fault taxonomy is given in table 5.1. These are the potential faults that can be present for each component. Not every potential fault is necessarily relevant for every hazard, so not every potential fault has to appear in the fault tree.

Component Potential faults

V2V communication Unexpected PDR, Unexpected latency Sensors Sensor faults, Power supply faults

Brakes Actuator faults, Power supply faults

E-motor Actuator faults

Engine Actuator faults

PMC CPU faults, Power supply faults

Radar Sensor faults, Power supply faults MOVE gateway CPU faults, Power supply faults

WiFi Sensor faults, Power supply faults

CACC CPU faults, Power supply faults

GPS Sensor faults, Power supply faults PMC-Sensors link Communication system faults PMC-E-motor link Communication system faults PMC-Brakes link Communication system faults PMC-Engine link Communication system faults MOVE-PMC link Communication system faults MOVE-Radar link Communication system faults MOVE-CACC link Communication system faults WiFi-CACC link Communication system faults GPS-CACC link Communication system faults

(21)

5.2 Fault tree analysis

For ACC, the following list of relevant hazards is provided by the domain experts: 1. No or not correct deceleration

2. No or not correct acceleration

Incorrect acceleration and deceleration are obviously hazards when it comes to automatic vehicle following. Since the distances in the case of CACC are even smaller, this becomes even more important. Also, from an operational situation point of view, ACC and CACC are very similar systems, since the only real difference is the distance. Therefore, we believe that this list can also be used for CACC. The fault tree for incorrect acceleration is presented in figure5.2. The fault tree for incorrect deceleration is presented in figure5.3.

5.3 Calculation of fault classification

The calculation for the incorrect deceleration case, figure5.3, is the most straightforward. Since the only boolean operator is the OR-operator, all minimal cut sets are singleton sets of one basic event each. There are 22 such singleton sets of which only two are singleton sets of V2V communication faults, the others are sets of vehicle-local faults. So the fault classification for the incorrect deceleration hazard is given in equation5.1.

F C (Incorrect deceleration) = vehicle_local : 20 22, v2v_comm : 2 22 (5.1) = vehicle_local : 10 11, v2v_comm : 1 11

So, only ₁₁1 of faults come from V2V communication in the deceleration case.

Calculation for the incorrect acceleration case, figure 5.2, is slightly more complicated because of the single AND-operator under the Full Hybrid Powertrain Failure event. Note that, going by equa-tion4.6, F C (Incorrect acceleration) adheres to equation5.2.

F C (Incorrect acceleration) = X M ∈M CSIncorrect acceleration F C (M ) (5.2) From figure5.2, we can observe that all minimal cut sets for this case are given by equation5.3.

M CSIncorrect acceleration=         

M CSAcceleration setpoint incorrect

∪ n

{P M C P ower supply f ault} , {P M C CP U f ault}o ∪

M CSF ull Hybrid P owertrain f ailure

         (5.3)

From figures5.2and5.3, we can observe that the fault classifications that arise from

∪ n

{P M C P ower supply f ault} , {P M C CP U f ault}o

are exactly the same in both cases, it is a collection of nineteen singleton sets of basic events of which two are singleton sets of V2V communication faults (take the total of 22 singleton sets from the deceleration case and subtract the three singleton sets that represent the brake faults).

(22)

(23)

(24)

For M CSF ull Hybrid P owertrain f ailure, because of the AND-operator, it is calculated by combining

each minimal cut set from M CSEngine f ailure with each minimal cut set from M CSE−motor f ailure

as in equation5.4.

M CSF ull Hybrid P owertrain f ailure=

(

a ∪ b | a ∈ M CSEngine f ailure

, b ∈ M CSE−motor f ailure

)

(5.4)

This results in a collection of six minimal cut sets, where each set consists of two basic events, one from a minimal cut set in M CSEngine f ailureand one from a minimal cut set in M CSE−motor f ailure. Since

all basic events here are vehicle-local faults, and going by equations4.5and4.6, M CSF ull Hybrid P owertrain f ailure

contributes a total of twelve to the vehicle-local fault class (two for each minimal cut set).

Note that M CSF ull Hybrid P owertrain f ailure contains only two-element sets. The consequence of

this fact is that the collections

∪ n

{P M C P ower supply f ault} , {P M C CP U f ault}o and

M CSF ull Hybrid P owertrain f ailure

are disjoint, since the former contains only singleton sets and the latter contains only two-element sets. This implies that F C (Incorrect acceleration) is the sum of the fault classifications that we found for those two collections, going by equations5.2 and5.3. This leads to the fault classification in equation5.5. F C (Incorrect acceleration) = {vehicle_local : 17, v2v_comm : 2} + {vehicle_local : 12} (5.5) = |{vehicle_local : 29, v2v_comm : 2}| = vehicle_local : 29 31, v2v_comm : 2 31

So, only ₃₁2 of faults come from V2V communication in the acceleration case.

5.4 Discussion

This section discusses the safety analysis results of the cooperative adaptive cruise control system. The 802.11p protocol experiences increased latency as there is increased traffic [44]. Also, the packet delivery ratio is influenced by the number of vehicles and the vehicle speed [43], [44]. These conditions are impossible for a human driver to control; therefore, V2V communication faults are deemed difficult to control (C3).

As for severity, if incorrect acceleration or deceleration happens in a close distance platoon, a crash could have life-threatening consequences for everybody in and around the platoon (S3).

We have the relative contribution of V2V communication in terms of a fault classification. Since they are present, we estimate that the probability class is E1 or higher. For C3 and S3, the ASIL is ASIL-A if the probability class is E1, ASIL-B if E2, ASIL-C if E3, and ASIL-D if E4 [16]. Since it is necessary to formulate a safety goal for a hazard in case it is assigned any of these ASILs, the conclusion is that it is necessary to formulate safety goals for incorrect acceleration / deceleration.

Since redundancy is not a solution in this case, safety goals should aim for maintaining functional safety in the face of loss of V2V communication, example safety goals could be:

(25)

• During CACC, maintain a distance between vehicles that enables the driver to safely take over the wheel in case of communication loss, and alert the driver in case of communication loss. • Monitor communication availability and inform the driver of communication availability status.

Notify the driver in advance if communication loss is expected.

• Only allow CACC in case communication availability is high enough. Alert the driver and disengage CACC if communication loss happens or is expected.

5.5 Threats to validity

In the following paragraphs, we list a set of validity threats that may affect this study.

Unintended driver interruption It is also possible that the driver would accidentally interrupt the CACC by pressing the gas pedal or the brake pedal, which could also result in incorrect acceleration or deceleration. This would skew the fault classification more in the direction of vehicle-local faults. Mitigation measures As mentioned before, the automotive industry is known for secrecy with regard to data. But it can be assumed that there are mitigation measures for many basic vehicle-local faults that have been modeled. This would skew the fault classification more in the direction of V2V communication faults.

Missing hazards We have reused existing hazard data from experts. It is possible that cooperative adaptive cruise control has additional hazards that distinguish it from adaptive cruise control, such as intentional malicious manipulation suggested by Burton et al. [13].

Cooperative aspects V2V communication is not the only cooperative driving aspect. For example, as Nilsson et al. [12] show, the distributed system state also plays a part.

Multiple vehicle faults It should be highlighted that one V2V communication fault affects multi-ple vehicles. This is not clear when looking at a fault tree. Analysis methods that reflect a cooperative perspective more naturally could be more informative.

(26)

Chapter 6

Conclusion and future work

In this research, we investigated the impact of modeling V2V communication as an ISO 26262 item on the resulting safety goals.

We used a variant of fault tree analysis as a safety analysis method, and we found that a limitation of fault tree analysis in general is that it does not show that the occurrence of one V2V communication fault impacts multiple vehicles. Future work could focus on finding ways to make this clearer, as well as perform a safety analysis using FMEA.

By conservative estimation, we found that the ASIL assigned to the hazards of incorrect acceleration / deceleration for cooperative adaptive cruise control is at least ASIL-A due to V2V communication and that therefore safety goals need to be specified for V2V communication. In a more complex industrial application it should be evaluated what the exact ASIL is.

Furthermore, we found that V2V communication faults are generally difficult or impossible to control due to their nature. This by itself increases the probability that safety goals need to be specified for the system [16]. Also, it was found that safety goals should aim at assuming loss of function since it is at the moment not known how to solve this problem with redundant system components.

A taxonomy for V2V communication faults has been presented, but V2V communication is not the only aspect of cooperative driving [12]. Therefore, future work could focus on building an extensive taxonomy for cooperative driving faults. Another research gap that has not been addressed here is impact of security threats.

(27)

Acknowledgments

We would like to thank Dr. Jeroen Ploeg from TNO and Dr. Rudolf Huisman from DAF Trucks NV for providing information and expertise advice regarding automotive systems. Also, we would like to thank Dr. Yaping Luo from Altran for providing feedback on the safety analysis part. I want to thank Prof. Dr. Jurgen Vinju and all my colleagues from Centrum voor Wiskunde & Informatica for hosting me and creating a pleasant environment for my final project. Last but not least, I would like to thank my supervisor Dr. Yanja Dajsuren for her guidance and for giving me a fun thesis project.

(28)

Bibliography

[1] S. Jones, “Cooperative adaptive cruise control: human factors analysis”, Oct. 2013. [Online]. Available:https://trid.trb.org/view.aspx?id=1266088(visited on 08/09/2016).

[2] European Commission. (). Smart, green and integrated transport - horizon 2020 - european com-mission, Horizon 2020, [Online]. Available:https://ec.europa.eu/programmes/horizon2020/ en/h2020-section/smart-green-and-integrated-transport (visited on 08/03/2016). [3] J. Ploeg, “Analysis and design of controllers for cooperative and automated driving”, PhD thesis,

Technische Universiteit Eindhoven, 2014.

[4] C. Bergenhem, S. Shladover, E. Coelingh, C. Englund, and S. Tsugawa, “Overview of pla-tooning systems”, in Chalmers Publication Library (CPL), 2012. [Online]. Available: http : / / publications . lib . chalmers . se / publication / 174621 overview of platooning -systems(visited on 08/03/2016).

[5] A. Davila, “Report on fuel consumption”, Deliverables, SARTRE, 2013. [Online]. Available:

http://sartre-project.org/en/publications/Documents/SARTRE_4_003_PU.pdf (visited on 08/03/2016).

[6] B. Van Arem, C. Van Driel, and R. Visser, “The impact of cooperative adaptive cruise control on traffic-flow characteristics”, IEEE Transactions on Intelligent Transportation Systems, vol. 7, no. 4, pp. 429–436, Dec. 2006, issn: 1524-9050. doi:10.1109/TITS.2006.884615.

[7] M. Bertoluzzo, P. Bolognesi, O. Bruno, G. Buja, A. Landi, and A. Zuccollo, “Drive-by-wire systems for ground vehicles”, in 2004 IEEE International Symposium on Industrial Electronics, vol. 1, May 2004, 711–716 vol. 1. doi:10.1109/ISIE.2004.1571893.

[8] ISO, “Road vehicles — functional safety — part 1: vocabulary”, International Standards Organ-isation, Geneva, Switzerland, Standard ISO 26262-1:2011(E), 2011.

[9] ——, “Road vehicles — functional safety — part 2: management of functional safety”, Interna-tional Standards Organisation, Geneva, Switzerland, Standard ISO 26262-2:2011(E), 2011. [10] ——, “Road vehicles — functional safety — part 6: product development at the software level”,

International Standards Organisation, Geneva, Switzerland, Standard ISO 26262-6:2011(E), 2011.

[11] D. D. Ward, “System safety in hybrid and electric vehicles”, in Proceedings of the Australian System Safety Conference - Volume 133, ser. ASSC ’11, Darlinghurst, Australia, Australia: Australian Computer Society, Inc., 2011, pp. 79–84, isbn: 978-1-921770-13-5. [Online]. Available:

http://dl.acm.org/citation.cfm?id=2311896.2311904(visited on 04/15/2016).

[12] J. Nilsson, C. Bergenhem, J. Jacobson, R. Johansson, and J. Vinter, “Functional safety for cooperative systems”, Apr. 8, 2013. doi: 10.4271/2013- 01- 0197. [Online]. Available:http: //papers.sae.org/2013-01-0197/(visited on 01/25/2016).

[13] S. Burton, J. Likkei, P. Vembar, and M. Wolf, “Automotive functional safety = safety + security”, in Proceedings of the First International Conference on Security of Internet of Things, ser. SecurIT ’12, New York, NY, USA: ACM, 2012, pp. 150–159, isbn: 978-1-4503-1822-8. doi:

10.1145/2490428.2490449. [Online]. Available: http://doi.acm.org/10.1145/2490428. 2490449(visited on 04/15/2016).

(29)

[14] C. Robinson-Mallett, “Coordinating security and safety engineering processes in automotive elec-tronics development”, in Proceedings of the 9th Annual Cyber and Information Security Research Conference, ser. CISR ’14, New York, NY, USA: ACM, 2014, pp. 45–48, isbn: 978-1-4503-2812-8. doi:10.1145/2602087.2602091. [Online]. Available:http://doi.acm.org/10.1145/2602087. 2602091(visited on 04/15/2016).

[15] S. M. Kannan, Y. Dajsuren, Y. Luo, and I. Barosan, “Analysis of ISO 26262 compliant techniques for the automotive domain”, [Online]. Available: http : / / t3 - necsis . cs . uwaterloo . ca / mase15/MASE_2015_paper_12_Kannan- Analysis_of_ISO_26262_Compliant_Techniques_ for_the_Automotive_Domain.pdf (visited on 04/15/2016).

[16] ISO, “Road vehicles — functional safety — part 3: concept phase”, International Standards Organisation, Geneva, Switzerland, Standard ISO 26262-3:2011(E), 2011.

[17] P. A. Ioannou and C. C. Chien, “Autonomous intelligent cruise control”, IEEE Transactions on Vehicular Technology, vol. 42, no. 4, pp. 657–672, Nov. 1993, issn: 0018-9545. doi: 10.1109/ 25.260745.

[18] J. Ploeg, E. Semsar-Kazerooni, G. Lijster, N. v. d. Wouw, and H. Nijmeijer, “Graceful degrada-tion of CACC performance subject to unreliable wireless communicadegrada-tion”, in 16th Internadegrada-tional IEEE Conference on Intelligent Transportation Systems (ITSC 2013), Oct. 2013, pp. 1210–1216. doi: 10.1109/ITSC.2013.6728397.

[19] Motor Industry Software Reliability Association, “Guidelines for safety analysis of vehicle based programmable systems”, MIRA Ltd, 2007.

[20] R. K. Panesar-Walawege, M. Sabetzadeh, and L. Briand, “Using UML profiles for sector-specific tailoring of safety evidence information”, in Conceptual Modeling – ER 2011, ser. Lecture Notes in Computer Science 6998, M. Jeusfeld, L. Delcambre, and T.-W. Ling, Eds., DOI: 10.1007/978-3-642-24606-7_27, Springer Berlin Heidelberg, Oct. 31, 2011, pp. 362–378, isbn: 978-3-642-24605-0 978-3-642-24606-7. [Online]. Available:http://link.springer.com/chapter/ 10.1007/978-3-642-24606-7_27(visited on 04/18/2016).

[21] Automotive Special Interest Group. (). Automotive SPICE |ăhome, [Online]. Available: http: //automotivespice.com/(visited on 08/08/2016).

[22] A. K. Saberi, Y. Luo, F. P. Cichosz, M. v. d. Brand, and S. Jansen, “An approach for functional safety improvement of an existing automotive system”, in Systems Conference (SysCon), 2015 9th Annual IEEE International, Apr. 2015, pp. 277–282. doi:10.1109/SYSCON.2015.7116764. [23] Z. Liu and M. Joseph, “Specification and verification of fault-tolerance, timing, and scheduling”, ACM Trans. Program. Lang. Syst., vol. 21, no. 1, pp. 46–89, Jan. 1999, issn: 0164-0925. doi:

10.1145/314602.314605. [Online]. Available:http://doi.acm.org/10.1145/314602.314605

(visited on 04/15/2016).

[24] R. Mariani, G. Boschi, and F. Colucci, “Using an innovative SoC-level FMEA methodology to design in compliance with IEC61508”, in Proceedings of the Conference on Design, Automation and Test in Europe, ser. DATE ’07, San Jose, CA, USA: EDA Consortium, 2007, pp. 492–497, isbn: 978-3-9810801-2-4. [Online]. Available:http://dl.acm.org/citation.cfm?id=1266366. 1266472(visited on 04/15/2016).

[25] IEC, “IEC 61508-2: functional safety of electrical/electronic/programmable electronic related systems part 2: requirements for electrical/electronic/programmable electronic safety-related systems”, International Electrotechnical Commission, London, United Kingdom, Stan-dard IEC 61508-2/Ed.2 CDV, Nov. 14, 2008.

[26] T. Fujiwara, J. M. Estevez, Y. Satoh, and S. Yamada, “A calculation method for software safety integrity level”, in Proceedings of the 1st Workshop on Critical Automotive Applica-tions: Robustness & Safety, ser. CARS ’10, New York, NY, USA: ACM, 2010, pp. 31–34, isbn: 978-1-60558-915-2. doi: 10 . 1145 / 1772643 . 1772653. [Online]. Available: http : / / doi . acm . org/10.1145/1772643.1772653(visited on 04/15/2016).

(30)

[27] M. Hillenbrand, M. Heinz, K. D. Müller-Glaser, and N. Adler, “A metric-based safety workflow for electric/electronic architectures of vehicles”, in Proceedings of the Joint ACM SIGSOFT Con-ference – QoSA and ACM SIGSOFT Symposium – ISARCS on Quality of Software Architectures – QoSA and Architecting Critical Systems – ISARCS, ser. QoSA-ISARCS ’11, New York, NY, USA: ACM, 2011, pp. 105–114, isbn: 978-1-4503-0724-6. doi: 10 . 1145 / 2000259 . 2000278. [Online]. Available:http://doi.acm.org/10.1145/2000259.2000278(visited on 04/15/2016). [28] M. Schulze, J. Mauersberger, and D. Beuche, “Functional safety and variability: can it be brought together?”, in Proceedings of the 17th International Software Product Line Conference, ser. SPLC ’13, New York, NY, USA: ACM, 2013, pp. 236–243, isbn: 978-1-4503-1968-3. doi: 10.1145/ 2491627 . 2491654. [Online]. Available: http : / / doi . acm . org / 10 . 1145 / 2491627 . 2491654

(visited on 04/15/2016).

[29] L. Briand, D. Falessi, S. Nejati, M. Sabetzadeh, and T. Yue, “Traceability and SysML de-sign slices to support safety inspections: a controlled experiment”, ACM Trans. Softw. Eng. Methodol., vol. 23, no. 1, 9:1–9:43, Feb. 2014, issn: 1049-331X. doi:10.1145/2559978. [Online]. Available:http://doi.acm.org/10.1145/2559978(visited on 04/15/2016).

[30] B. Hunter, “Assuring separation of safety and non-safety related systems”, in Proceedings of the Eleventh Australian Workshop on Safety Critical Systems and Software - Volume 69, ser. SCS ’06, Darlinghurst, Australia, Australia: Australian Computer Society, Inc., 2006, pp. 45–51, isbn: 978-1-920682-50-7. [Online]. Available:http://dl.acm.org/citation.cfm?id=1274236. 1274243(visited on 04/15/2016).

[31] S. Baumgart, J. Fröberg, and S. Punnekkat, “Towards efficient functional safety certification of construction machinery using a component-based approach”, in Proceedings of the Third International Workshop on Product LinE Approaches in Software Engineering, ser. PLEASE ’12, Piscataway, NJ, USA: IEEE Press, 2012, pp. 1–4, isbn: 978-1-4673-1751-1. [Online]. Available:

http://dl.acm.org/citation.cfm?id=2666064.2666065(visited on 04/15/2016).

[32] V. Rupanov, C. Buckl, L. Fiege, M. Armbruster, A. Knoll, and G. Spiegelberg, “Early safety eval-uation of design decisions in e/e architecture according to ISO 26262”, in Proceedings of the 3rd International ACM SIGSOFT Symposium on Architecting Critical Systems, ser. ISARCS ’12, New York, NY, USA: ACM, 2012, pp. 1–10, isbn: 978-1-4503-1347-6. doi:10.1145/2304656. 2304658. [Online]. Available: http://doi.acm.org/10.1145/2304656.2304658 (visited on 04/15/2016).

[33] G. Rodriguez-Navas, C. Seceleanu, H. Hansson, M. Nyberg, O. Ljungkrantz, and H. Lönn, “Automated specification and verification of functional safety in heavy-vehicles: the VeriSpec approach”, in Proceedings of the 51st Annual Design Automation Conference, ser. DAC ’14, New York, NY, USA: ACM, 2014, 95:1–95:4, isbn: 978-1-4503-2730-5. doi:10.1145/2593069. 2602972. [Online]. Available: http://doi.acm.org/10.1145/2593069.2602972 (visited on 04/15/2016).

[34] D. Domis, R. Adler, and M. Becker, “Integrating variability and safety analysis models using commercial UML-based tools”, in Proceedings of the 19th International Conference on Soft-ware Product Line, ser. SPLC ’15, New York, NY, USA: ACM, 2015, pp. 225–234, isbn: 978-1-4503-3613-0. doi: 10 . 1145 / 2791060 . 2791088. [Online]. Available: http : / / doi . acm . org/10.1145/2791060.2791088(visited on 04/15/2016).

[35] M. Käßmeyer, M. Schulze, and M. Schurius, “A process to support a systematic change impact analysis of variability and safety in automotive functions”, in Proceedings of the 19th Interna-tional Conference on Software Product Line, ser. SPLC ’15, New York, NY, USA: ACM, 2015, pp. 235–244, isbn: 978-1-4503-3613-0. doi: 10 . 1145 / 2791060 . 2791079. [Online]. Available:

http://doi.acm.org/10.1145/2791060.2791079 (visited on 04/15/2016).

[36] C. Kreiner, “Trident architectural views: a pattern for dependable systems design”, in Proceedings of the 20th European Conference on Pattern Languages of Programs, ser. EuroPLoP ’15, New York, NY, USA: ACM, 2015, 18:1–18:9, isbn: 978-1-4503-3847-9. doi: 10 . 1145 / 2855321 . 2855340. [Online]. Available: http://doi.acm.org/10.1145/2855321.2855340 (visited on 04/15/2016).

(31)

[37] M. Stamatelatos, W. Vesely, J. Dugan, J. Fragola, J. Minarick III, and J. Railsback, Fault Tree Handbook with Aerospace Applications. NASA: NASA, Aug. 2002, 218 pp. [Online]. Available:

https://www.hq.nasa.gov/office/codeq/doctree/fthb.pdf(visited on 04/19/2016). [38] R. de Queiroz Souza and A. J. Álvares, “FMEA and FTA analysis for application of the

reliability-centered maintenance methodology: case study on hydraulic turbines”, in ABCM Symposium Series in Mechatronics, vol. 3, 2008, pp. 803–812.

[39] (). Use of fault tree models for reliability, safety, diagnostic, prognostics and testability anal-ysis, [Online]. Available: http://www.diagnosticmodels.com/FaultTrees.aspx (visited on 08/11/2016).

[40] T. Nakajo and H. Kume, “A case history analysis of software error cause-effect relationships”, IEEE Transactions on Software Engineering, vol. 17, no. 8, pp. 830–838, Aug. 1991, issn: 0098-5589. doi:10.1109/32.83917.

[41] R. R. Lutz, “Analyzing software requirements errors in safety-critical, embedded systems”, in , Proceedings of IEEE International Symposium on Requirements Engineering, 1993, Jan. 1993, pp. 126–133. doi:10.1109/ISRE.1993.324825.

[42] P. E. Lanigan, S. Kavulya, P. Narasimhan, T. E. Fuhrman, and M. A. Salman, “Diagnosis in automotive systems: a survey”, 2011.

[43] W. Alasmary and W. Zhuang, “Mobility impact in IEEE 802.11p infrastructureless vehicular networks”, Ad Hoc Networks, Recent Advances in Analysis and Deployment of IEEE 802.11e and IEEE 802.11p Protocol Families, vol. 10, no. 2, pp. 222–230, Mar. 2012, issn: 1570-8705. doi: 10.1016/j.adhoc.2010.06.006. [Online]. Available:http://www.sciencedirect.com/ science/article/pii/S1570870510000703(visited on 07/24/2016).

[44] A. G. Ib’nez, C. Flores, P. D. Reyes, A. Barba, and A. Reyes, “A performance study of the 802.11p standard for vehicular applications”, in 2011 7th International Conference on Intelligent Environments (IE), Jul. 2011, pp. 165–170. doi:10.1109/IE.2011.26.

[45] S. Eichler, “Performance evaluation of the IEEE 802.11p WAVE communication standard”, in 2007 IEEE 66th Vehicular Technology Conference, Sep. 2007, pp. 2199–2203. doi: 10.1109/ VETECF.2007.461.

[46] J. Ploeg, B. T. M. Scheepers, E. v. Nunen, N. v. d. Wouw, and H. Nijmeijer, “Design and experimental evaluation of cooperative adaptive cruise control”, in 2011 14th International IEEE Conference on Intelligent Transportation Systems (ITSC), Oct. 2011, pp. 260–265. doi: 10 . 1109/ITSC.2011.6082981.

[47] Y. Dajsuren, “On the design of an architecture framework and quality evaluation for automotive software systems”, PhD thesis, Technische Universiteit Eindhoven, 2015.

[48] AUTOSAR Development Partnership. (). AUTOSAR: home, [Online]. Available:http://www. autosar.org/(visited on 08/07/2016).

[49] M. B. Swarup and B. H. Prasad, “Software failure analysis of brake-by-wire automotive safety critical system using FMEA, FTA and MATLAB techniques”, SYSTEM, vol. 4, no. 6, 2015.

Safety Analysis of a Cooperative Adaptive Cruise Control System