

Abstract-This paper addresses the problem of how to identify all safety goals for an item in the automotive E/E domain. The paper gives a background on the problem of hazard analysis and risk assessment in general, and for the automotive domain in particular. A key factor for success is to identify all the relevant hazardous events, which task constitutes a paradox. Either the specification of the possible driving situations and the system hazards are done too general and abstract implying a too conservative analysis, or done too detailed and specific ending up with an almost infinite list of hazardous events to consider. This paper addresses this paradox by the formulation of a number of rules enabling to reduce the potentially infinite set of candidates of hazardous events to a limited number, still sufficient to cover all safety goals. Besides that it enables solving the paradox of becoming both detailed and limited, it also can be used as a tool for reviewing the completeness of a set of safety goals.

Index Terms-Hazard analysis, Automotive, ISO 26262.

I. INTRODUCTION

n all domains of functional safety, it is essential to perform a complete and correct Hazard analysis and risk assessment (HA&RA). The purpose of this activity is to identify and categorize all Hazards, i.e. all potential sources of accidents caused by erroneous behaviour of the function under consideration. In the automotive domain, the rules for HA&RA are given by part three of the ISO 26262 standard [START_REF]Road vehicles -Functional safety -Part 3, Concept phase[END_REF]. The goal of this HA&RA is to produce the so called Safety Goals. The rest of the standard prescribes how to guarantee that all these Safety Goals in the end are fulfilled, thus implying functionally safe road vehicles. However, in order for the complete vehicle to act functionally safe, first the set of items analysed must be complete, and secondly, for every item the set of Safety Goals must be complete. This paper addresses the latter problem.

In the process to identify the Safety Goals, the standard ISO 26262 prescribes to analyse all Hazardous Events that might have an impact on this set. This means that all possible failures of the Item of concern should be considered, and for all driving scenarios and all environmental conditions. The combined effect of the driving scenarios and the environmental conditions are called 'situation' in the ISO 26262 terminology. As there is no predefined standard set of situations, this would potentially generate an infinite number of Hazardous Events to analyse. The question is whether we can come up with a way to identify if there is a limited set of Hazardous Events that completely identifies the full set of Safety Goals. The reason why this would work is that a large number of Hazardous Events do not contribute to the identification of a unique Safety Goal. What we need is a way to identify a limited set of Hazardous Events, which still cover all Safety Goals for the item.

In ISO 26262 it is prescribed that the HA&RA shall be done, and that there shall be performed a verification activity showing the "completeness with regard to situations and Hazards". However, there is no information how to solve the problem of showing completeness. This paper addresses this problem. The remainder of the paper is structured as follows. The next section presents the HA&RA activity of ISO 26262, and why it is considered as a hard problem to identify a limited, but still efficient set of Safety Goals. In section III is introduced the concept of formulating rules to identify which Hazardous Event that are of interest when formulating the Safety Goals. Section IV is giving a structure how to categorize all possible pairs of Hazardous Events. The following section formulates the set of rules necessary, and section VI then shows the completeness and consistency of this set. The paper ends with a summary and conclusions.

II. BACKGROUND

It is well known in the area of functional safety, that the quality of the HA&RA is critical for the relevance of all other risk reducing activities prescribed by a standard. In Birch et al. [START_REF] Birch | Safety Cases and their role in ISO 26262 Functional safety Assessment[END_REF] is discussed how the complete safety case is dependent on a proper identification of the Safety Goals in the automotive domain, which in turn is dependent on the Hazardous Events. There are a number of techniques in this area which have in common that they address how to avoid missing any candidate Hazard. Often mentioned are Preliminary Hazard Analysis, HAZOP and FMEA. Other recommendations exist like a generic method by Jesty et al. [START_REF] Jesty | Hazard Analysis for programmable automotive Systems[END_REF] based on a state machine model of the transitions between a failure occurring in a system and a Hazardous Event.

In the following we are addressing specifically the HA&RA as specified for the automotive domain. Even though there are many similarities, there are also a number of fundamental differences between the industrial domains, as is pointed out in a comparative study by Blanquart et al. [START_REF] Blanquart | Criticality categories across safety standards in different domains[END_REF]. Section 7 of [START_REF]Road vehicles -Functional safety -Part 3, Concept phase[END_REF] prescribes in detail how an HA&RA shall be done according The end result of the HA&RA is a set of Safety Goals, each having an ASIL attribute that is limiting the occurrence of a certain Hazard. One Safety Goal may cover several different Hazardous Events, which implies that it gets the highest ASIL value among those. For each Hazardous Event, the ASIL attribute is calculated by determining a factor for each of: severity (S), exposure (E) and controllability (C). For each given Hazardous Event these factors may be determined by application experts, and may include driver controllability experiments, field data collection, etc. The problem of how to determine ASIL attribute of a given Hazardous Event is not addressed in this paper. Here is rather the focus how to find a list of Hazardous Events for which it is worth getting high confidence in the E, S and C factors.

As said above, in the automotive E/E domain, the HA&RA problem is explicitly decomposed into finding the Situations and the Hazards, and analysing all resulting effects. When performing this work, different organizations have different templates for identification of the Hazardous Events of concern. A frequent pattern is to separate the driving conditions from the environmental conditions. The former is focused on the state and the intended manoeuvres of the vehicle (driving at 70km/h, full braking, etc), and the latter describes the state outside the vehicle (dark, wet road, playing child on the road etc). There are initiatives to formalize the potentially infinite number of Situations. In Jang et al. [START_REF] Jang | A Study on situation analysis for ASIL Determination[END_REF] the authors present a template where they decompose the Situation into properties for vehicle, road and environment. For each of these they propose a number of properties to determine, each with some standard alternatives. Even in this rather simplistic template, the number of possible alternatives for each situation is about 50 millions. Then are still not the different possible Hazards considered. Multiplying the number of possible Hazards for a given Item, with 50 million would generate a prohibitively long list of possible Hazardous Events. This is not what the authors propose, but this shows that even if there is a standardized set of Situations and/or of Hazards, there will be a need for techniques to identify which Hazardous Events that are important for identification of the Safety Goals.

The German automotive organization VDA has created a standardized list of situations [START_REF] Verband Der Automobilindustrie E | Situationskatalog E-Parameter nach ISO 26262-3[END_REF]. The aim of this list is to harmonize the determination of the exposure factor between vehicle OEMs when performing the HA&RA.

Martin et al [START_REF] Martin | Investigation of the influence of non-E/E safety measures for the ASIL determination[END_REF] presents a study where the original list of Hazardous Events consists of 640 candidates. This list was reduced by checking the 'plausibility of the combinations' into 121 Hazardous Events. After this reduction, they started the classification and ASIL determination. This presented example is far from unique in the number of Hazardous Events to consider, and still it might be the case that this HA&RA is not detailed enough to allow a precise (not too conservative) formulation of Safety Goals. This is why this paper addresses the task of enabling of automatic reduction of a potentially infinite list of Hazardous Events.

As pointed out in [START_REF] Johansson | The Importance of Active Choices in Hazard Analysis and Risk Assessment[END_REF] it becomes even more important to find a carefully chosen set of Safety Goals when introducing vehicles capable of highly automatic driving (HAD) or even autonomous vehicles. The implications of many such Safety Goals are spread on a larger part of the E/E systems of the vehicle. This implies that ending the HA&RA activity with a few Safety Goals that could be regarded as too unelaborated, and thus potentially too conservative, may generate a significant increase in cost of the vehicle. This also motivates why it is important to identify rules assisting in formulating an efficient set of Safety Goals.

III. RULES FOR IDENTIFICATION OF DOMINANCE AND NON-DOMINANCE

There are a number of cases when adding a new Hazardous Event would not extend the list of already identified Safety Goals. Such Hazardous Events are of no interest, as the objective of the list of Hazardous Events, is to identify the list of Safety Goals. It would be beneficiary to have a set of rules that automatically can check whether a given candidate Hazardous Event would generate a new Safety Goal, or if it can be considered as redundant. We call such rules Dominance rules, as they identify if one Hazardous Event can be identified as dominated by other already identified Hazardous Events. Obviously we want to reduce a given list of Hazardous Events so that all the dominated ones are omitted from the final list.

In a similar way it would be efficient to have a set of rules that could clearly identify if a Hazardous Event will generate a unique Safety Goal that is not covered by any other Safety Goal. We call such rules Non-Dominance rules, as they identify Hazardous Events that cannot be identified as dominated by any other already formulated Hazardous Event.

In this paper we identify eight explicit rules that together cover all cases for determining dominance and nondominance, respectively. These rules can be used in at least two ways. The first use case is to review a list of candidate Hazardous Events, and remove all of these that can be shown as dominated by any of the others. For the remaining Hazardous Events, it is then possible to show that they pairwise show non-dominance. The second use case is to review a list of Hazardous Events with respect to its completeness. This means that rules for non-dominance are used to identify candidates missing in the list.

IV. CATEGORIZING HAZARDS AND SITUATIONS

Today, different organizations have a little bit of difference in their methodology how to list the Hazardous Events and how to perform the resulting analysis. For the following discussion, it is not necessary to include so many columns in the table that often are used.

In the following, we will use an example Item that we call Lane Keeping Assistance in Steering (LKA Steering). Once activated, this functionality takes the responsibility for the vehicle to stay in lane. Unless overridden by the driver, the LKA controls the steering of the vehicle. In the Table 1 is depicted a set of example Hazardous Events for the chosen example.

Even in this simplified example, it is not obvious if the part of the list of Hazardous Events (HE) in Table 1 is long enough to generate the identification of all Safety Goals, or if some of the HE are not contributing at all to the analysis. Let us first have a look on the effect of the different classification factors: Exposure (E), Controllability (C), and Severity (S). When setting up a detailed list of HE, it is of interest to identify the situations which constitute a border between two different values for at least one of the factors E, C or S. In our example this means that we shall identify the sizes of the steering angle failure, and the Situations, where (at least) one of the factors changes from one level to another. In the next section we look a little deeper in the question how these columns relate to each other.

A. Analysis of Exposure, Controllability and Severity

The Exposure factor is a direct function of the Situation, and independent of the Hazard. The definition of the E factor is that it categorizes how often a vehicle is in a given situation. If the situation is very general, the E factor will be higher than if we confine the situation. For example, comparing the HE2 and HE3 in Table 1, they only differ in how specific the situation is defined. For the more general situation of HE2 we argue that the factor should become E4, while the confinement made in HE3 implies a lowering of the E factor to E3. This lowering in turn implies a lowering of the resulting ASIL attribute. The HE2 is the more conservative case to consider. This means that it is a valid classification, but it might become too restrictive if there is no situation other than those in HE3 that will have the same effect on Controllability and Severity for the given Hazard.

The Controllability factor is a function of not only the situation, but also of the Hazard and the Severity. The interpretation of the C factor would be expressed as: "How easy is to avoid the specified Severity in this Situation given this Hazard". In our example (comparing HE4 and HE5) we say that there is a limit when the steering angle suddenly becomes 20% wrong, for the driver being able to avoid an S3 accident, when driving at high speed in heavy rain. For an error of more than 20% we consider it a C3, while staying in the interval between 5% and 20%, it will be lowered to a C2. As before, it is not the point of this example to be fully correct, but to illustrate the principles.

The Severity factor is also a function of all: the Situation, the Hazard and the Controllability. This means that the S and C factors respectively are mutually dependent on their interpretation for a given Hazardous Event. The interpretation of the S factor would be interpreted as "What might be the Severity given the specified C-factor in this situation given this Hazard". In our example list of Hazardous Events, there is a limit when we compare HE5 and HE6. The difference between these two cases is that the Severity is reduced when lowering the speed to medium.

When looking at all three of these factors, we conclude that Severity and Controllability are dependent and should be interpreted in any actual pair. It makes sense to interpret the Controllability factor as how easy it is to avoid a given Severity.

We conclude that when looking for the dimensioning Hazardous Events, it would be of interest to find those Situations and Hazards where any of the three factors E, C or S will change its value. The reason for this is that any such Table 1. Example extract of a Hazardous Event table case also will imply a change in the ASIL attribute value. We conclude that there is no meaning of having two Hazardous Event candidates that only differs a little bit in the definition of the situation, if this will not imply any change of any of the E, C, or S factors.

The question is whether all changes of Situations implying a change in any of the E, C, or S factors are relevant to consider, and what set of Hazards to take into account. This question is further elaborated in the following sections.

B. Categorizing Situations

When comparing two Situations, this means that both the driving scenarios and the environmental conditions are considered. When saying that two Situations are identical, this implies identity for everything specifying a Situation. One Situation can be seen as a special case of another. In our example, the Situation of HE1 (driving, under all conditions) can be seen as a general Situation of which the Situation of HE2 (driving at high speed) is a special case. Two Situations can also be seen as mutual exclusive. The Situations 'driving at high speed' (HE2) and 'driving at medium speed' (HE7), can never include any common scenario. Finally two Situations can be over-lapping. This implies that some special Situations only may occur according to one of the Situations, some only to the other, and some to both. These four possible relations are depicted in figure 1. .

Fig. 1. Categorizing relations between two Situations A and B

To clarify the subset relation we can formulate two implications:

A⊂B ⇨Any possible situation in A will also be a possible situation in B. A⊂B ⇨Guaranteeing the absence of any situation in B, will also guarantee the absence of that situation in A.

For our example we can list the following Situations Testing the conclusions as above, on some of these relations, we get: D⊂C ⇨ Any Situation that may be characterized as 'Driving at high speed in heavy rain' may also be characterized as 'Driving in heavy rain'.

D⊂C ⇨ Guaranteeing the absence of any Situation that may be characterized as 'Driving in heavy rain' will imply the absence of any Situation possible to characterize as 'Driving at high speed in heavy rain'.

B⊂A ⇨ Any Situation that may be characterized as 'Driving at high speed' may also be characterized as 'Driving'.

B⊂A ⇨ Guaranteeing the absence of any Situation that may be characterized as 'Driving' will imply the absence of any Situation possible to characterize as 'Driving at high speed'. This is in line with our intuitive understanding of these relations. The relations of these five example Situations can be depicted as either a Venn diagram or as partially ordered relations shown in the figure 2 below.

Fig. 2. Relations between example Situations

C. Categorizing Hazards

In a similar way as for the possible Situations, we can also categorize the possible relations between any two Hazards.

Naming the two Hazards X and Y, respectively, the possible relations are as depicted in figure 3.

Fig. 3. Categorizing relations between two Hazards X and Y

To clarify the subset relation we can formulate two conclusions: X⊂Y ⇨ Any possible Hazard in X will also be a possible Hazard in Y. X⊂Y ⇨ Guaranteeing the absence of any Hazard in Y, will also guarantee the absence of that Hazard in X.

For our example we can list the following Hazards: X: complete loss of steering functionality Y: steering angle delayed too late >0.5 s Z: steering angle more than 20% wrong V: steering angle more than 5% wrong U: steering angle between 5% and 20% wrong W: any loss of steering functionality Then we can derive the following pairwise relations: X⊂Y; X⊂Z; X⊂V; X⊂W; U∩Z=∅ (mutual exclusive); Y∩Z≠∅ (overlapping); U⊂V; Z⊂V; V⊂W; Y⊂W; U⊂W; Z⊂W Testing the conclusions as above, on some of these relations, we get: X⊂V ⇨ Any Hazard that is characterized as 'Complete loss of steering functionality' could also be characterized as 'Steering angle more than 5% wrong'.

X⊂V ⇨ Guaranteeing the absence of any Hazard that is characterized as 'Steering angle more than 5 % wrong' will also imply the absence of any Hazard possible to characterized as 'Complete loss of steering functionality'.

Z⊂W ⇨ Any Hazard that is characterized as 'Steering angle more than 20% wrong' could also be characterized as 'any loss of steering functionality.

Z⊂W ⇨ Guaranteeing the absence of any Hazard that is characterized as 'Any loss steering functionality' will also imply the absence of any Hazard possible to be characterized as 'Steering angle more than 20% wrong'.

If the difference between the two Hazards X and W, was not completely clear before, these clarifications have hopefully made the semantics of any of the Hazards in the list above clearer. The relations of these six example Hazards can be depicted as either a Venn diagram or as partially ordered relations shown in the figure 4 below.

Fig. 4. Relations between example Hazards

D. Categorizing the Effects on the E, C and S Factors

In the previous sections we have categorized the relation between two Hazardous Events by first looking at the Situation column and then at the Hazard column. The remaining columns necessary to categorize are the ones for Exposure, Severity, Controllability, and the concluded ASIL value. As pointed out earlier, the important thing when comparing two HE, is the resulting ASIL value. Any difference in the E, C or S factors will imply a difference in the resulting ASIL value. The E, C, S factors are still important to list in the HE tables because they give guidance to the classification of the Situations and the Hazards. When choosing how confined/general a certain Situation or a certain Hazard should be expressed, the ideal cases would be those that result in differences in any of the E,C or S factors. Once a Hazardous Event is formulated, for the purpose of determining dominance, it is sufficient to only consider the resulting ASIL value. The relation between ASIL values is easier to categorize than the relation between Situations or between Hazards. In fact there are three possible relations. Either the two HE have identical ASIL values, or the one is higher or the other is higher. The symbols =, > and < are used for this in the following sections of this paper.

V. RULES FOR REDUCING CANDIDATES OF HAZARDOUS EVENTS

In the following we use the notation as of the table 2 below when discussing the relation between Hazardous Events in a table. For the rules defined in the coming sections we compare the two general Hazardous Events HE1 and HE2. HE1 has the general Situation A, the Hazard X, and gets the concluded ASIL attribute value ASIL1, when analysing the resulting effects on Exposure, Controllability and Severity. For HE2 the Situation is denoted B, the Hazard Y, and the resulting ASIL value ASIL2.

A. Rules for Identification of Dominance

There are a number of cases when adding a new Hazardous Event would not contribute to the list of already identified Safety Goals. Such Hazardous Events are of no interest, when the objective of the list of Hazardous Events is to identify the list of Safety Goals. A first obvious example is when the candidate HE has exactly the same Situation and the same Hazard as an already listed HE, but a lower ASIL value. The same applies if it is only a difference in Situation or a difference in Hazard, and the other two columns are identical.

In all these cases we can directly conclude that the candidate HE will not add any Safety Goal compared to the ones already identified. Thus, we can formulate our first rule of dominance:

Rule DI: Dominance exists if two columns show relation 'identical' and the third one has the relation '⊂' or '<'.

Our next observation is that for a given Hazard, there will only become one resulting Safety Goal (this is how Safety Goals are identified). Thus if two Hazardous Events have the same Hazard, but different ASIL values, the one with the lowest ASIL value does not add anything to the analysis. This leads us to the second rule of dominance: In a next step, we can conclude three more observations possible to aggregate into one rule. 1) A more general Situation with a higher ASIL value will dominate as long as the Hazard relation is identity. 2) A more general Hazard with a higher ASIL will dominate as long as the Situation relation not implies a subset relation in the opposite direction. 3) When both Situation and Hazard are more general, this will cause dominance if the ASIL value is not lower. We aggregate these observations into our third rule of dominance:

Rule DIII: If two or more columns have the relation '⊂' or '<', there is dominance if they are all in the same direction, given that the column Hazard does not have the relation 'mutual exclusive' or 'overlapping'.

Finally, we have the case when the one Hazard is a special case of the other (a subset), and the more confined Hazard also has a lower ASIL value. In this case, the more general Hazard with the higher ASIL value will generate the dimensioning Safety Goal, and the other Hazardous Event will not add anything to the analysis. This will always hold, independent of how general the Situations are defined. This leads to the fourth and last rule of dominance:

Rule DIV: Dominance exists if Hazard has '⊂' relation in the same direction as the Integrity value has the '<' relation, regardless of the Situation relation.

For now we say that these are the only four rules of dominance needed to categorize all possible cases where one Hazardous Event can be seen as dominated by another. In a section VI, there is a proof that no other rules are needed, i.e. these four rules of dominance are complete. Before this, the rules for non-dominance are identified.

B. Rules for Identification of Non-Dominance

In the previous section we identified the rules identifying when one Hazardous Event makes another one unnecessary, i.e. when the other does not imply a unique Safety Goal. In order to determine the relation between any two Hazardous Events, it is as important to conclude when they both contribute to unique Safety Goals. Our first observation regarding such so called non-dominance, is when we are comparing two mutual exclusive Hazards or two overlapping Hazards. As long as both Hazardous Events are based on a Hazard which is (partly) unique, this will also imply that it will contribute to a unique Safety Goal. We can hence formulate our first rule of non-dominance:

Rule NI:

There is never dominance between two mutual exclusive Hazards or between two overlapping Hazards.

Next observation is that a more specific Hazard having a higher ASIL attribute than the general Hazard will add a new Safety Goal, but the first Safety Goal will still stay unique. For example, we can have one Safety Goal stating that we shall avoid steering angle failures above 20% by ASILD, and another one stating that we shall avoid steering angle failures above 5% by ASILC. The first one is more restrictive regarding the ASIL value, while the second is more restrictive regarding the threshold above which a deviation is considered as a failure. This means that no one of these two Safety Goals includes the other one, and they are hence both to be considered as unique. This leads us to the formulation of our second rule of non-dominance: We have now formulated 4+4 rules to determine whether any pair of Hazardous Events will generate one or two Safety Goals. In the former case we call that dominance, and in the latter case non-dominance. In the next section we investigate to what extent these eight rules are complete and consistent.

Rule
We want that all possible pairs of Hazardous Events are handled by at least one rule, and that there will never be any conflicting rules for any pair of Hazardous Events.

VI. COMPLETENESS AND CONSISTENCY OF THE RULES

In the previous chapter we categorize any pair of Hazardous Events as the combined effect of the relations for Situation, Hazard and ASIL value, respectively. For the Situation and the Hazard relations, there are five different possibilities each: Identical, Mutual exclusive, overlapping, and a subset relation in any of the two directions. For the ASIL value relation, there are three possibilities: Identical, and the one is higher or the other is higher. In total this implies 5*5*3=75 different possibilities to categorize the relation between any pair of Hazardous Events. Below in table 4, there is an extensive list of all these 75 possibilities, and for each is also noted what rules for dominance and for non-dominance that apply. The first row in this table is about when the two Hazardous Events are identical, and thus no comparison is motivated. For the remaining 74 rows there is some difference between the two compared Hazardous Events. We observe that for every row in this list, there is at least one rule that is found applicable. Furthermore we observe that there is no row where there is one rule for dominance and another for nondominance at the same time. The fact that all rows are covered by at least one rule, and that there is no row showing any contradicting rules, implies that our set of 4+4 rules is complete and consistent.

VII. DISCUSSION

Our eight rules for determining dominance or non-dominance can be used in at least two ways. The first use case is to review a list of candidate Hazardous Events, and remove all of these that can be shown as dominated by any of the others. For the remaining Hazardous Events, it is then possible to show that they pairwise show non-dominance. The second use case is to review a list of Hazardous Events with respect to its completeness. This means that rules for non-dominance are used to identify candidates missing in the list. Let us go back to our example with LKA steering list of Hazardous Events from Table 1. As shown in the Table 3 we can now conclude that neither of the candidates HE2, HE3, and HE6 will conclude to the identification of a unique Safety Goal. Furthermore, we can also make sure that the remaining Hazardous Events, all contribute to a unique Safety Goal. We can then continue our review by challenging this list by trying to add more Hazardous Events. However, we only add those candidates that are shown not to become dominated by one of the existing ones. We might come up with a new candidate that dominates one of the HE already in list, which implies that the new one will replace the dominated one.

In our example we can now consider all combinations of Situations and Hazards to find out whether any of these would generate a dimensioning Hazardous Event. Given that we have chosen these Situations and Hazards, respectively, and that they catch the cases when any of the E, C or S factors can change its value, we can argue for the completeness of the concluded list of Hazardous Events. Our rules give a hint which potential Hazardous Events to consider, which means that we can find arguments for a number of Hazardous Events at the time, why not to consider any of them (as they would be dominated by an existing Hazardous Event).

For example, given that we have HE1 in our list above, we can directly conclude that we do not need to look for any other Situation to combine with this Hazard, as they would all be dominated. The argument for this conclusion is that HE1 will not have a lower ASIL than any other HE, and also that no other Situation could be seen as a superset to the Situation of HE1. We can formulate it by saying that comparing HE1: <A,X,ASIL1> with any other HEk: <B,X,ASIL2> (the same Hazard), HEk will always be dominated by HE1. The argument for this is that ASIL2 is not greater than ASIL1 (ASIL1=ASILD), and B is always a subset of A (A is the most general situation). This means that either ASIL2=ASILD and then rule DI is applicable, or ASIL2 has a lower value and then rule DII is applicable. In a similar way as in the example above, a number of candidate Hazardous Events can in many situations be evaluated simultaneously.

  : A: Driving (under all conditions) B: Driving at high speed C: Driving in heavy rain D: Driving at high speed in heavy rain E: Driving at low speed on dry road Then we can derive the following pairwise relations: B⊂A; C⊂A; B∩C≠∅ (overlapping); D⊂B; D⊂C; D∩E=∅ (mutual exclusive)

Rule DII:

  Dominance exists if Hazard show relation 'identical' and the Integrity values are different (regardless of relation for Situation).

Table 2 .

 2 General notation in Hazardous Event table used in formulation of rules

	Hazardous	Situation	Hazard	Integrity
	Event ID			Value
	HE1	'A'	'X'	'ASIL1'
	HE2	'B'	'Y'	'ASIL2'
	HE3	'C'	'Z'	'ASIL3'
	…	…	…	…

  NII: If the Hazard and Integrity relations are in different directions, there is never dominance. Furthermore, we can observe that even if the Integrity value is identical for a pair of Hazardous Events, they will still both contribute to unique Safety Goals if either of Situation or Hazard cannot be seen as a subset of the other one. If either of the Situation or the Hazard relations, are mutual exclusive or overlapping, this implies that we cannot say that the Safety Goal derived from the one HE will include the Safety Goal derived by the other. This leads us to the formulation of the third rule of non-dominance:

	Rule NIII: There is never dominance if Integrity value relation
	is 'identical', and any of the other two relations are
	either 'mutual exclusive' or 'overlapping'.
	Finally, we conclude that even if the Integrity relation between
	two Hazardous Events is 'identical', this will still imply two
	unique Safety Goals if the relations for Situation and Hazard
	both have a subset relation, but in different directions. This
	leads us to the conclusion of the fourth rule of non-dominance:
	Rule NIV: There is no dominance if Integrity value relation is
	'identical', and the other two relations are in
	different directions.

Table 3 .

 3 Example extract of a Hazardous Event table, revisited

This work has been financed by The Swedish government agency for innovation systems (VINNOVA) in the FUSE project (ref 2013-02650).

Rolf Johansson is with SP Technical Research Institute of Sweden (

VIII. CONCLUSION

We have defined eight rules to be used for the identification of a minimal set of Hazardous Events necessary to identify all Safety Goals of an Item. The rules are used to compare any two candidates of Hazardous Events to conclude whether they are both generating a unique Safety Goal, or whether the one Hazardous Event can be seen as uninteresting (dominated by the other).

The rules are based on a categorization of the Situations, the Hazards and the ASIL attribute values, respectively. Regarding the ASIL attribute values, the integrity levels are either equal, or one of them is higher than the other. For both Situations and for Hazards, we use set theory to describe any pairwise relation. We show that our eight rules are complete and consistent. The completeness is shown as any possible combination of relations between Situations, Hazards, and ASIL attribute value, is covered by at least one rule. Consistency is shown as none of these possible combinations implies both dominance and non-dominance. This means that any combination is uniquely identified as either dominance or non-dominance.

This set of rules makes it possible to solve the paradox of being specific in the list of Situations and Hazards, and still end up with a limited number of dimensioning Hazardous Events. Today, many companies fear to be too detailed in the Hazard Analysis, as it might generate a potentially infinite number of Hazardous Events. Instead they run the risk of becoming unnecessarily conservative in the analysis, leading to a too expensive product. By applying a methodology where these eight rules are applied in the generation and the review of Hazardous Events, it is feasible to generate a list that is at the same time complete and precise.


Peter H Feiler

David P Gluch

John D Mcgregor
email: johnmc@clemson.edu

An Architecture-Led Safety Analysis Method

Keywords: safety analysis, architecture-led, error model

Safety-critical systems require specific development and evaluation activities in the software development life cycle to ensure that the product is safe. Some of these activities are aggregated into comprehensive safety engineering practices, which are standardized within an industry, such as Aerospace Recommended Practice (ARP) 4761 in the aircraft industry. These techniques focus on individual component failures and reliability. More recent techniques such as the Systems-Theoretic Process Analysis (STPA) go beyond reliability of individual components to consider the interactions among the components. In this paper we present the Architecture-Led Safety Analysis (ALSA) method that is part of the Architecture-Led Safety Engineering practice. ALSA combines the development and analysis of at least a partial architecture model using notations such as the Architecture Analysis and Design Language, its Error Model Annex, and existing ARP 4761 and ARP 4754A practices such as Functional Hazard Assessment, Preliminary System Safety Assessment, and System Safety Assessment as well as the emerging technique of STPA. This work contributes an illustration of using ALSA to analyze a Full-Authority Digital Engine Controller. The method is supported by the Open Source Architectural Tool Environment and has been piloted on an industrial-strength example.

Introduction

Safety-critical systems require specific development and evaluation activities in the software development life cycle to ensure that a system is safe. Some of these activities are aggregated into comprehensive safety engineering practices, which are standardized within an industry. Standards such as Aerospace Recommended Practice (ARP) 4761 in the aircraft industry define very specific techniques for assessing the safety of life-critical systems [START_REF]Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment[END_REF]. These techniques focus on individual component failures and their associated reliability. More recent techniques such as the Systems-Theoretic Process Analysis (STPA) go beyond methods based on the reliability of individual components to consider the interactions among the components [START_REF] Leveson | A Systems-Theoretic Approach to Safety in Software-Intensive Systems[END_REF].

The increasing complexity of current embedded systems is driving the need for increasing automation of all activities, including safety analysis. The goal of our research is to create a safety engineering practice that blends existing safety analysis techniques with an error ontology and a model-based architecture representation of the system and its operational context that will more effectively and efficiently discover hazards in the interactions among system components. The practice enables increased automation to support iterative development. Our technique differs from some existing practices as described in Chen and Biehl that use EAST-ADL [START_REF] Chen | Modelling Support for Design of Safety-Critical Automotive Embedded Systems[END_REF][START_REF] Biehl | Integrating Safety Analysis into the Model-Based Development Toolchain of Automotive Embedded Systems[END_REF][START_REF] Blom | EAST-ADL: An Architecture Description Language for Automotive Software-Intensive Systems[END_REF]. EAST ADL focuses on supporting system engineering mapping functional architectures onto hardware. It does not support modeling of the software architecture. In contrast, AADL allows modeling of system and software architectures. By supporting safety analysis across both, it addresses hazard contributions by software. There is plenty of recent evidence that software has become a major source of hazards; thus, it is crucial to extend safety analysis into the software system architecture.

In this paper we present the Architecture-Led Safety Analysis (ALSA) method and demonstrate its use. ALSA is part of an Architecture-Centric Virtual Integration Process (ACVIP) within a comprehensive, architecture-led systems engineering practice [START_REF] Yu | Towards an Architecture-Centric Approach Dedicated to Model-Based Virtual Integration for Embedded Software Systems[END_REF]. Figure 1 shows steps in the ACVIP, with the ALSA steps in boldface. We apply these process steps repeatedly down the hierarchy of subsystems. The diagram conveys that the ACVIP and ALSA steps are closely coupled and involve iteration and concurrency of activities. Our practice combines features of several existing safety engineering practices, model-based requirements analysis, and architecture design practices. It incorporates development and analysis of at least a partial architecture model using notations such as the Architecture Analysis and Design Language (AADL) [START_REF] Peter | Model-Based Engineering with AADL: An Introduction to the SAE Architecture Analysis and Design Language[END_REF]. The method incorporates existing ARP 4761 and ARP 4754A practices such as Functional Hazard Assessment (FHA), Preliminary System Safety Assessment, and System Safety Assessment. Our method also uses techniques similar to those in STPA, including a specially constructed set of guidewords. The unique contribution of our work is the use of an architecture representation of the system and its operational context and an error ontology to support hazard identification. An early version of this method was validated by its use in the System Architecture Virtual Integration technique [START_REF] Feiler | System Architecture Virtual Integration: An Industrial Case Study[END_REF].

We create the architecture representation, which supports our practice, using AADL and elaborate it over multiple iterations of analysis and design. Several annexes to the core AADL have been defined and we particularly use the error annex, referred to as EMV2 (error model version 2), in this safety analysis method. EMV2 supports expressing the error behavior of a component and its subcomponents using a state machine construct linked to the component's ports. Component connectors between ports and error flows through the connectors allow the designer to explicitly plan error propagations through the system. Work around, restart and other error recovery strategies can be modeled and analyzed. EMV2 defines the error ontology that is a center piece of the safety analysis method. The ontology provides guide words that are used to help locate safety hazards, which are added to the error model as properties that can be used to produce hazard analysis reports.

An architecture model created using the process in the rest of this paper supports safety analyses at user-selectable levels of detail. Certain analyses are conducted on an instantiation of the selected component including any subcomponents of the selected component. The algorithms are defined to accept the scope of the selected entity and to apply the analysis technique within that scope. The highly extensible OSATE predefines analyses such as FHA but as an open source tool based on Eclipse any analysis can be added to the tool set.

The practice is composed of four steps that we apply in a top-down manner to the system hierarchy. Feedback from lower levels drives the next iterations with new information. The individual steps interface with the encompassing ACVIP practice and inform other integration activities. The four steps are 1. Identify Operational Safety Risks: This step involves identifying operational system-level accidents, incidents, and contributory system-level hazards by considering the context in which the system is engineered and operates as well as its interfaces with the environment. This step requires significant stakeholder engagement, especially safety engineering, operational, and mission expertise.

Identify Operational Hazards and Hazard Contributors:

Step 1 helps to establish a minimal system architecture, associating identified accidents with various aspects of the system. The error ontology defined in the Error Model Annex of AADL provides guidance in identifying hazards and their contributors. 3. Identify Safety Requirements: The sources of error are used to define safety requirements that mitigate the identified hazards. While designated as a distinct step, safety requirements can be defined concurrently with hazard identification. 4. Develop Safety Architecture Design: A safety architecture is designed based on the safety requirements identified in the previous step. The safety architecture merges the safety aspects of the product into the overall product architecture.

The ALSA practice is supported by the Open Source Architectural Tool Environment (OSATE) [START_REF]Open Source AADL Tool Environment (OSATE)[END_REF]. It is conducted in coordination with the general systems requirements definition and initial architecture design activities in an iterative, incremental development approach. The architecture representation includes information about nominal and error flows in the system. These flows are analyzed end to end to identify hazards that may appear only when complex interactions among multiple components are considered together. As hazards are discovered, the architecture representation is annotated with information about the hazards, making this information available in future iterations of analysis as the system definition evolves.

The example in the next section illustrates elements of the ALSA approach but is not intended to represent a comprehensive safety assessment. In practice, experts utilize these techniques to develop the technical and safety aspects of the systems they analyze. In presenting the ALSA process, we assume that readers are familiar with the AADL, the AADL Error Model Annex (EMV2), and their application [START_REF]SAE AS5506B, Architecture Analysis & Design Language[END_REF][START_REF]Architecture Analysis and Design Language (AADL), Annex E: Error Model Annex[END_REF][START_REF] Delange | AADL Fault Modeling and Analysis Within an ARP4761 Safety Assessment[END_REF].

Example

This is an example application of the ALSA safety process to a representative Full-Authority Digital Engine Controller (FADEC) system. For our purposes, we address only the operating process aspects of the broader systemlevel theoretical framework presented in Figure 1. The example focuses on the fuel flow control aspects of the system as shown in Figure 2 and taken from [START_REF] Garg | Fundamentals of Aircraft Turbine Engine Control[END_REF]. The design presented here is illustrative, does not represent any specific or operational FADEC system, and is not intended for implementation. Nominally, a safety analysis is conducted for the complete aircraft, but in this problem (i.e., the system) we focus on the aircraft engine. A technical report is in preparation and will provide many details that are omitted here due to space limitations. We apply each of the four steps in the safety process and explain the interactions among the steps.

Identify Operational Safety Risks

This initial step interfaces with the encompassing ACVIP and defines the operational safety context for the system as part of the ACVIP context-definition activity. In this step, we identify safety risks (accidents, incidents, and toplevel operational hazards). As noted earlier, the specific procedures, techniques, and outputs depend on the preferences and norms of an organization. In some cases, certifications require specific practices. Various techniques can be used to identify system-level hazards in the ALSA process. Traditionally FHA has been the technique used to identify operational safety risks [START_REF]Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment[END_REF]. More recently, Leveson's STPA has also been used [START_REF] Leveson | A Systems-Theoretic Approach to Safety in Software-Intensive Systems[END_REF].

An FHA output table for the FADEC is shown in Table 1. For our purposes, we consider only the hazards and descriptions for the control thrust function while the aircraft is in motion and do not specify other entries in the table.

Table 2 shows the results using STPA. At this point, we identify the top-level safety requirements that prevent hazards or accidents (termed safety constraints [START_REF] Leveson | A Systems-Theoretic Approach to Safety in Software-Intensive Systems[END_REF]). The top-level safety requirements for the engine hazards are shown in Table 3. Defining safety requirements in concert with identifying hazards can be more effective, since experienced engineers with the requisite expertise are focused on the specific details of a hazard and immersed in the overall safety context. Often during the hazard-identification activities of ALSA, engineers implicitly assume or identify requirements, identify implicit architecture assumptions or alternatives, or make architecture decisions. For example, engineers may develop a requirement that a combat aircraft will include an ejection set for the pilot. At this point, they can begin to develop an operational model of the top-level system architecture and include an ejection system, along with potential alternative designs.

Table 3: Hazards and safety requirements.

Hazards Safety Requirements

H1: Engine provides no thrust SC1: Thrust must be provided at all times when commanded.

H2: Engine provides too little thrust H3: Engine provides too much thrust SC2: Thrust level must be provided at the commanded level.

H4: Engine is slow to provide commanded thrust SC3: Engine must provide commanded thrust within the required interval.

H5: Engine will not shut down when commanded [Relevant safety constraints arising from H5 include SC1, SC2, and SC4.] H6: Engine cannot be controlled -LOTC SC4: Engine must respond to all commands. SC4.1: Engine must start when commanded. SC4.2: Engine must shut down when commanded.

Identify Operational Hazards and Contributors

In this step, we detail hazards and identify hazard contributors by incrementally extending the hazard analysis into lower levels of the system operational and architectural hierarchy. Consequently, it is necessary that additional details or working assumptions about the architecture exist and possibly alternative architecture designs for consideration have been defined. These steps incorporate hazard analysis techniques-such as fault tree analysis, event tree analysis, and hazard and operability study from ARP 4761-as well as the STPA and are connected with the identification of safety requirements and the development of a safety architecture.

In the initial activities of this step, we establish the boundaries of the system and its subsystems and define the types of errors that can propagate among them. For the FADEC example, we choose to partition the relevant system into the cockpit (including the pilot), a separate autopilot, and the remainder of the physical aircraft. External elements in the environment may impact the system via sensors or other input (e.g., light entering the aircraft can produce heat within the aircraft). The system-level diagram shown in Figure 3 reflects an architecture in which pilot and autopilot commands to the aircraft's FADEC are separate and parallel.

Figure 3: Example aircraft decomposition.

A common way of viewing a system in its operational context is as a control system that involves interactions via Monitored and Controlled Variables. This approach, documented in the FAA Requirement Engineering Management Handbook [START_REF]Requirements Engineering Management Handbook[END_REF], has its roots with Parnas and Madey [START_REF] Parnas | Functional Documentation for Computer Systems Engineering[END_REF]. These variables can be used to represent states that characterize unsafe system conditions and interactions. The STPA utilizes a control loop representation for hazard identification [START_REF] Leveson | A Systems-Theoretic Approach to Safety in Software-Intensive Systems[END_REF].

Two principal considerations in identifying hazards are exceptional conditions within architecture elements (characterized using the ALSA error ontology) and mismatched assumptions (mismatched assumption-guarantee contracts between systems) about their interactions. Exceptional conditions and mismatched assumptions are hazardous (undesired) states of a system. Those that pose a threat to the well-being of people or offer the potential for catastrophic consequences to the environment are safety hazards.

As seen in Figure 3, the Pilot_Cockpit system provides control commands to the Autopilot and the Aircraft. We consider the port connections between the elements and choose the error types: no data is sent (service omission), bad data is sent, and data is sent late. We assume that the data is a single content record sent on some schedule. As we define the details of the communication between the components more specifically, we can define the amount of acceptable delay and adjust the model to accommodate these details. This information is summarized in Table 4, whose columns are labeled with the relevant error categories from the error ontology. The engine system within the aircraft system implementation is shown in Figure 4. For clarity, other internal aircraft components are not included. The FADEC within the engine system can be commanded by either pilot or autopilot input, and the FADEC does a signal selection based on the operational mode. The engine receives a command from the FADEC and provides engine turbine fan speed back to the FADEC.

Identify Safety Requirements

Operational safety hazards, errors sources, and other contributors to those hazards are used to establish safety requirements-statements about the desired operation and capabilities of a system that address safety hazards. As we have shown, safety requirements arise out of hazards and hazard contributors and can be identified throughout the ALSA process. Consider the example in Table 4; the identification of the hazard that an asymmetric transmission error can occur leads to a requirement to address asymmetric errors in the system.

Develop Safety Architecture Design

Developing a safety architecture is synergistic with the hazard analysis process and the general architecture design efforts. Especially for safety-critical systems, the safety requirements (safety constraints) identified in earlier steps in the process guide the engineering of the system. In safety-guided design, safety requirements drive the overall architecture development and define safety-specific architecture elements, such as redundant hardware, highly reliable communication, and low workload interface designs. Safety requirements significantly influence, and often dictate, architecture and detailed design trade-off decisions and overall system assurance activities.

In ALSA, standard error patterns such as the standard-error state machine shown in Figure 56 are collected in libraries that can be reused across architectures. The safety analysis is tied directly to the architecture by recording the identification of a hazard in the error model for the appropriate AADL component, as shown in Figure 67. Errors may be propagated from hardware into software components, or from one component to another, and may arise from the implementation and operation of the component itself, as shown in Figure 78. The error propagations can also lead the system/subsystem hierarchy, as shown in Figure 89. Making these error propagations explicit in the architecture description makes design decisions much more straightforward. This ties the safety architecture into the architecture design activity of the encompassing ACVIP. OSATE is extensible using the Extend language. By defining domain specific properties and encoding an algorithm to compute a measure from those properties a new analysis is added to the toolkit. Future work is intended to add to the analysis set and to enhance usability.

error

Conclusion

The ALSA process involves assessing interconnected elements within an architecture, considering the potential EMV2 errors that may apply to the interconnections, and representing each architecture element as an error state machine based on the impacts of these errors. The error model also includes considerations of the operational paradigm and system model of the component. ALSA also involves assessing the interaction paths between architecture components. Within ALSA, systems engineers consider system interaction scenarios in which each component representation is based on an assumed architecture model of the system and assumed operational paradigms (algorithms) that are premised on that model. Each component interaction can be affected by one of the EMV2 error types via its interaction with other components. These are errors output by or received by a component. ALSA is a safety engineering practice that blends existing safety analysis techniques with an error ontology and a model-based architecture representation of the system and its operational context. Using this blend, engineers can more effectively and efficiently discover hazards in the interactions among system components, increase automation to support iterative development, and help to ensure that a safety-critical system is safe.

Figure 1 :

 1 Figure 1: Process steps for ACVIP (lightface) and ALSA (boldface).

*Figure 2 :

 2 Figure 2: FADEC fuel flow control example [data adapted from 10].

Figure 4 :

 4 Figure 4: Major engine system components.

Figure 5 :Figure 6 :

 56 Figure 5: Three-state error model.

Figure 7 :

 7 Figure 7: Tying the FADEC to the higher level engine package.

Figure 8 :

 8 Figure 8: Dual redundant fuel flow.

Table 1 : Hazards identified using FHA.

 1

	Function	Failure Condition (Hazard Description)	Phase	Effect of Failure	Classifi-cation	Reference to Material Supporting	Verification
		Engine provides no thrust	Taxi
		Engine provides too little thrust	Takeoff
		Engine provides too much thrust	Landing
		Engine is slow to provide	Flight
	Control Thrust	commanded thrust (increase or decrease) Engine will not shut down when
		commanded
		Engine cannot be controlled -
		Loss of Engine Thrust Control
		(LOTC)

Table 2 : Results of applying STPA.

 2

	Accident	System-Level (Operational) Hazards
	A-1: Loss of life or serious injury	H0: Ineffective thrust to maintain controlled flight or safe taxi
	due to aircraft engine	H1: Engine provides no thrust
		H2: Engine provides too little thrust
	A-2: Catastrophic damage to	H3: Engine provides too much thrust
	aircraft or other property due to	H4: Engine is slow to provide thrust (increase or decrease)
	aircraft engine	H5: Engine will not shut down when commanded
		H6: Complete LOTC

Table 4 :

 4 Interface errors.

	Component Interface	Service Errors	Value Errors	Timing Errors	Replication Errors
	Pilot_Cockpit to	No command to	Bad value input	Late delivery
	Autopilot	autopilot (may not	into Autopilot	(since this is
		be a hazard -need		specified as a
		details on		message, potential
		assumptions of the		timing errors need
		autopilot system)		additional analysis)
	Pilot_Cockpit to Aircraft No command to	Bad value input	Late delivery
		aircraft	into Aircraft
	Autopilot to Aircraft	No command	Bad value	Late delivery
	Aircraft to Pilot_Cockpit No data	Bad value	Late delivery	Potential for
					asymmetric missing,
	Aircraft to Autopilot	No data	Bad value	Late delivery	value or timing error

propagation {No_Data,Bad_Data,Late_Data}; fan_speed: out propagation {No_Data,Bad_Data,Late_Data,AsymmetricSpeedFeedback}; end propagations;

	system FADEC extends Top_Level_Pkg::FADEC
	annex EMV2 {**
	use types FADEC_Error_library;
	error propagations
	autopilot_PLA_Cmd: in propagation {No_Data,Bad_Data,Late_Data};
	fan_speed: in propagation
	{No_Data,Bad_Data,Late_Data,AsymmetricSpeedFeedback};
	pilot_PLA_Cmd: in propagation {No_Data,Bad_Data,Late_Data};
	cmd_to_engine: out propagation {No_Data,Bad_Data,Late_Data};
	end propagations;
	**};
	end FADEC;
	device engine extends Top_Level_Pkg::engine
	annex EMV2 {**
	use types FADEC_Error_library;
	error propagations
	engine_cmd: in

**}; end engine;

Acknowledgments

Copyright 2015 Carnegie Mellon University This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN "AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. This material has been approved for public release and unlimited distribution. Carnegie Mellon ® is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. DM-0002899