6.2 Process to Develop a Functional Safety Concept
6.2.4 Safety in the Concept Phase of an Item
According to the ISO 26262 standard, the concept phase contains the Item Defini- tion, which describes the operation environment and the functional range of the developed item. Additionally, interfaces to other items in the overall system have to be defined. After the Item Definition, a Hazard Analysis and Risk Assessment is conducted to analyze the item. The result is a collection of operation risks for the developed item and a determination of ASIL for the elements of the item.
Functional System Description
In the concept phase, the external behavior of the item, possible operating modes, and the operation environment is analyzed and described. For a complete descrip- tion a textual part and a Functional System Architecture are common. In this chapter, the Skill Graph is added to the functional description.
Textual Description
The textual functional system description is the first work product in the Item Definition according to ISO 26262. It contains the functional range of the item, its operating modes and a description of the operation environment. This includes the system boundaries, either functional or resulting from the operation environment.
The operation environment contains a description of the road network, the traffic infrastructure and the traffic participants relevant for the desired functional range.
Besides these, regulations, rules, laws and standards that apply are at least referenced. Besides written rules, a value system as proposed by Gerdes and Thornton (2016) is necessary, which has to be considered in driving decisions.
The goal must be to describe the system and its environment as complete as possible.
For an automated vehicle for public traffic operation, a complete set of the possible situations or a meta-set of possible elements and their characteristics is beneficial. Dickmanns (2007) gives different lists for road types, traffic participant types, road conditions, and weather conditions. The possible combinations are so manifold, that it is unlikely to describe all of them. To avoid requiring all combi- nations, safety can be enabled with mastering of so called pathological scenarios.
These are scenarios that occur rarely, but can have severe consequences and thus have to be considered. A methodology to find such pathological scenarios for the item description could be to use accident data (Winkle2016) and realistic driving studies like EUROFOT (Benmimoun et al.2012). Utilizing this data only covers recorded accidents and dangerous situations encountered by human drivers. For a vehicle guidance system, additional dangerous situations are imaginable, which are not yet identified. An approach to a structured derivation of situations was presented by Schuldt et al. (2014) and in Chap.7in this book.
Another aspect is the definition of a safe state for each of the possible situations.
If normal operation is no longer possible, there have to be actions and possible transitions to keep the vehicle in a safe state.
Skill Graph
For the self-perception, Reschka et al. (2015)4describe a concept based on Skill and Ability Graphs. They show how to describe skills of the resulting system and the possibility to determine an ASIL for each of the skills instead of the whole system.
4Reschka et al. (2015) used the terms skill and ability interchanged than this chapter. Due to new research results, the terms had to be switched. Skills are defined in the concept phase and abilities are used during operation of the vehicle.
The Ability Graph has been introduced by Pellkofer (2003) and Siedersberger (2003) for automated vehicle guidance and was applied to a full drive-by-wire- vehicle and further improved by Bergmiller (2014). By Reschka et al. (2015) the skill and ability concepts were utilized to fit to our understanding of automated vehicles. From the resulting description of the automated vehicle system, the Skill Graph can be derived.
Pellkofer (2003) introduced the graph as an ability network (German:
Fa¨higkeitennetz) as a part of the ability concept (German: Fa¨higkeitenkonzept) developed by the working group “Verhalten” (English: Behavior) at the Universita¨t der Bundeswehr München (Siedersberger et al. 2000). The whole concept was introduced by Siedersberger (2003) and uses abilities from the categories percep- tion and scene description, behavior decision, driving and saccadic vision, and planning as introduced by Maurer (2000) to model the abilities of an automated vehicle during operation. Bergmiller (2014) further developed the concept to a self- concept, which enables a detailed self-representation of a full-by-wire actuation system. Bergmiller (2014) calls the abilities of Pellkofer and Siedersberger skillsand divides them into three groups: basic skills, action skills, and behavioral skills. These groups represent the three levels of performance introduced by Rasmussen (1983).
A starting point for abilities are the necessary driving maneuvers for the desired functionality and the relevant parameters to each of the identified driving maneu- vers. As Dickmanns (2007, p. 43) proposes, a driving maneuver is a specific control scheme in the system and each time, the control scheme changes, another maneuver is executed. Nagel and Enkelmann (1991) defined a necessary set of 17 driving maneuvers for vehicles in public traffic. T€olle (1996) defined a basic set of nine driving maneuvers derived from Nagel and Enkelmann (1991). For the definition of the Skill Graph, basic driving maneuvers according to T€olle (1996) can be used for the top layer in the Skill Graph. For each of the basic maneuvers, the necessary underlying skills can be derived from human tasks executed to fulfill the top skills.
These skills and their properties describe the system more detailed and in a structure, which can be transferred to a hardware and software architecture and can be utilized for online self-perception and self-representation of the vehicle.
Before introducing an exemplary Skill Graph for a Driver Assistance System, the difference between a functional component and a skill should be clarified. A functional component provides a functionality within a system. Many functional components work together to combine their functionalities to a complex system performing more complex tasks than a single functional component or a subset of functional components. To give a systematic overview of a complex system, the Functional System Architecture can be used as a basis, but it is not easily possible to identify safety relevant information like components with single points of failure or other metrics for a safety analysis, because the system architecture does not model the performance dependencies between functional components necessary for a safety analysis.
A Skill Graph provides this information as it contains performance metrics and in the graph. Redundancies can be identified, because each skill relies on at least two other skills and is itself necessary for more complex skills. Additionally, the
graph, which is built by deriving necessary skills for the item in development allows an identification of cyclic dependencies, e.g., if a skill is necessary for another skill and relies on this skill itself. Especially considering self-perception these cyclic dependencies are important to identify. A detailed analysis of the dependencies between skills is possible as well. These dependencies show which node in the tree can be removed without causing a complete outage of the system. It is possible to identify the most important nodes and the existence and the demand of redundant paths in the graph. Thus, an ASIL determination for skills is possible and even a skill-based ASIL decomposition seems feasible.
For every skill one or more aggregated performance metrics are necessary, which represent the current capability of a skill. These performance metrics use performance values from other skills and additional sensor values.
Figure6.5shows a Skill Graph for an Adaptive Cruise Control system, which includes Cruise Control and Electronic Stability Control functionality. The ACC can follow another vehicle in the estimated path of the ego vehicle based on the current speed of the leading vehicle and the yaw rate of the ego vehicle. Green blocks are meant to be the most abstract skills or the maneuver. Blue blocks describe skills with performance metrics, which are necessary to fulfill the top-level skill. Yellow blocks describe actuators and orange blocks sensors or inputs to the system.
The top node is the skill ACC driving. This skill enables the driving maneuver
“Follow” (German: “Folgen” according to T€olle (1996)) and additionally enables Cruise Control and Electronic Stability Control.
Fig. 6.5 ACC Skill Graph, which includes Cruise Control (CC) and Electronic Stability Control (ESC) functionality
A Cruise Control functionality (skill: “Control speed”) is active, if no leading vehicle is available.
An Electronic Stability Control functionality (skill: “Keep vehicle controllable”) is permanently available and acts if the vehicle is about to get out of control.
“Control distance” is the skill to adapt the ego vehicle’s speed to a leading vehicle, which has to be selected (skill: “Select target object”). Additionally, the skills “Accelerate” and “Decelerate” are necessary, and the driver is able to define a maximum speed and the time gap to a leading vehicle (skill: “Detect driver intention”). “Control speed” is the skill to drive a desired speed if no leading vehicle is available. Thus, the skill depends on the same skills as “Control dis- tance”. “Keep vehicle controllable” is the skill, which limits vehicle dynamics in a way that the driver is able to control the vehicle in every situation immediately.
This skill depends in the ACC system only on the longitudinal vehicle guidance (“Accelerate”, “Decelerate”). In Fig.6.5the skill “Select target object” is exem- plary composed by “Perceive and track dynamic objects” and “Detect driver intention”. The perception of objects is necessary to identify relevant objects, the driver intention is necessary to detect the desired path of the driver, because then it is possible to select the relevant target object. An early version of a similar approach has been published in 2012 (Reschka et al.2012a,b). As mentioned before, our current understanding of Skill and Ability Graphs is described in Reschka et al. (2015).
Functional System Architecture
Although not required explicitly in the standard, it is helpful in the concept phase, to design a Functional System Architecture. The ISO 26262 standard foresees a system architecture in the design phase. From the description in the standard, it is not clear which kind of architecture is used for the overall functional system modeling. For an automated vehicle such a system architecture based on the work by Maurer (2000), Wille (2012), Matthaei (2015), Matthaei and Maurer (2015), and others is described in Chap. 5 of this book. The Functional System Architecture lacks one important aspect for safety processes. There is no explicit representation of safety components as these are integrated into the functional modules (Matthaei 2014). This results in a more difficult identification of safety critical parts, because it is not visible which consequences failures have in the components of the Functional System Architecture. Therefore, it seems advantageous to use a Skill Graph as a modeling tool, which compensates this deficit. The Skill Graph can be understood as a link from the functional requirements in the Item Definition to the design phase of the system. Due to the fact, that a common understanding of the parties involved in the development process is necessary, a system architecture can help to build this. In the remaining of this chapter it is assumed that a Functional System Architecture is available in the concept phase and can be used for the following development phases.