Functional Safety of Driver Assistance

Transcription

1 Functional Safety of Driver Assistance 6 Systems and ISO Ulf Wilhelm, Susanne Ebel, and Alexander Weitzel Contents 1 Objectives of Functional Safety Overview Objectives and Structure of ISO Differentiation Between Other Standards and Guidelines Differentiation from Handling of Other Failure Sources Safety Requirements for Driver Assistance Systems Specification of Safety Goals Specification of Safety Requirements Meeting the Safety Requirements Traceability of Requirement Levels Verification Validation Limits of ISO Gaps in Traceability Handling the Unknown in the Design Process Validation of Systems with Functional Insuffencies Summary and Outlook References U. Wilhelm (*) Robert Bosch GmbH, Ditzingen, Germany ulf.wilhelm@de.bosch.com S. Ebel Robert Bosch GmbH, Chassis Systems Control, Driver Assistance Systems, Leonberg, Germany susanne.ebel@de.bosch.com A. Weitzel Formerly Technische Universität Darmstadt, Darmstadt, Germany # Springer International Publishing Switzerland 2016 H. Winner et al. (eds.), Handbook of Driver Assistance Systems, DOI / _6 109

2 110 U. Wilhelm et al. Abstract This chapter gives a brief overview of the automotive standard ISO containing requirements for functional safety in order to avoid or control systematic failures and random HW failures. In this context the hazard analysis and risk assessment for a driver assistance function is shown, and further steps to prevent relevant hazards outgoing from the function are described. Since very important for the driver assistance functions, hazards resulting from functional insufficiencies, which are out of the scope of ISO 26262, are discussed in the last part of this chapter. 1 Objectives of Functional Safety 1.1 Overview To release a technical product for sale and use, proof that it is safe enough always has to be provided first. In this general safety consideration, the section of correct and safe product function is known as functional safety (Börcsök 2011). The reference for evaluating whether a product is safe or not is the tolerable risk limit. If the risk associated with the product is below the risk limit, then it can be considered as sufficiently safe. The risk, in turn, is defined in Engineering as the product of damage severity and probability of occurrence (ISO ). If persons involved in the process are able to employ defined actions to avoid damages when a fault occurs, then the controllability can be considered as an additional factor. The risk limit is defined by the current state of the art. In the event of damage, the manufacturer is obligated to prove that at the time the product was placed on the market, it complied with the state of scientific and technical knowledge regarding safety aspects (ProdHaftG 2002). The requirements resulting from this state of technology are often documented in standards. They comprise product characteristics, development methods, and documentation rules that has to be fulfilled by the product and the manufacturer. Requirements for functional safety of electrical, electronic, and programmable electronic systems in general are covered by the technical standard IEC/EN (2010). ISO (2011), which is the standard relevant for the automotive industry, has been derived from the IEC/EN standard. It contains definitions, guidelines, and methods for development and assessment of functional safety of electrical and electronic (E/E) components. 1.2 Objectives and Structure of ISO ISO defines requirements for the development process of safety-critical components and systems of road vehicles. Currently, this only includes passenger cars up to 3.5 t. However, adapted variants for commercial vehicles (Dardar et al. 2012; Teuchert 2012) and motorized two-wheelers (Bachmann and Zauchner 2013; Werkmeister and Englisch 2012) are under development.

3 6 Functional Safety of Driver Assistance Systems and ISO Fig. 1 Development process according to ISO with focus on system development The procedure described in ISO is oriented toward the general V-Model of product development (V-Model 2013). At the beginning of the product life cycle, in the design phase of the system, the hazards that could be caused by a function should be identified and the resulting risks should be quantified. Depending on this risk definition, the safety goals are defined and hereby the requirements for the development methods, quality assurance, and monitoring of the entire product life cycle. The simplified flow of the safety development process as per ISO with the relevant original chapter headings is shown in Fig. 1. The method defined by ISO thus ensures the integration of safety requirements right at the beginning of the development process. Thereby adequate methods are defined depending on product safety criteria. In particular, the quality requirements of the safety concept must be defined even before the product properties are specified in detail. 1.3 Differentiation Between Other Standards and Guidelines To enable a wide application, even to very different systems, ISO addresses issues of functional safety on an abstract level. Thus, it inevitably provides less concrete information on the methods and procedures required for application, for example, conversion of controllability estimations and tests for risk assessment. However, the quantification of individual factors influencing the risk directly determines the hazard assessment and, with it, the safety standards to be applied to the system or function. Due to this, the current state of the art regarding objective,

4 112 U. Wilhelm et al. generally accepted evaluation methods, and metrics for evaluating the frequency of the driving situation, controllability, and severity of damage should be taken into account during the risk evaluation. In the field of driver assistance systems relying on surround sensor systems, the Code of Practice (PReVENT 2009) (from the project PReVENT ) provides a reference. It summarizes the state of the art for evaluation methods and metrics and includes procedures for the evaluation of the human-machine interface. The Code of Practice contains extensive questionnaires to evaluate the interactions of assistance systems and drivers. Depending on the situation, these questions are classified in 18 categories (e.g., predictability, trust, traceability). With the documentation of the state of the art, even if it may be a few years old, the Code of Practice offers definitions and examples for the practical implementation of hazard assessment and risk evaluation. Due to its cross-functional objective, the ISO is different from the functionspecific standards for driver assistance systems. These standards, such as ISO for Adaptive Cruise Control (ACC), define functional areas, scopes, minimum requirements, and test methods related to the current driver assistance function. 1.4 Differentiation from Handling of Other Failure Sources While considering the functional safety of systems according to the specifications of ISO 26262, the distinct limits of fault types need to be defined (a detailed differentiation of the meaning of fault, error, and failure is included in the Glossary of ISO 26262). One limit is the restriction to electrical/electronic (E/E) and programmable systems, mechanical faults, for example, will not be considered as a cause of risks. Similarly, the standard considers only the functional faults (in the context of a deviation from an explicit specification) of a driver assistance system. This assumes that it is possible to differentiate clearly between a status that is compliant with the specifications, the correct function, and a status that is noncompliant with the specifications, a fault/failure or a malfunction. These faults can clearly be identified and can be reduced to a minimum, for example, with fault detection methods with a very high detection rate, switch-off measures, and degradation mechanisms. Interventions of driver assistance systems with surround sensor systems that are considered to be incorrect do not only occur due to faults of E/E components or software. Another type of failure occurs even though all components and software function comply with the specifications. Here, the system does not react in a way that is appropriate for the situation because the system specification does not cover all possible cases that can occur while operating a vehicle. The incorrect reaction of the system in the driving situation results, for example, from an incomplete perception of the situation or based on a prediction or model assumptions that are not feasible. According to the current state of knowledge, due to the large number of possible driving situations, systems relying on surround sensors can neither be specified distinctively nor can they be tested such that incorrect interventions occur only outside the specification (Weitzel et al. 2015). A more abstract

5 6 Functional Safety of Driver Assistance Systems and ISO formulation of the system specification only shifts this problem, as concrete system reactions have to be defined based on the latest available information about the surroundings of the vehicle at the time of technical implementation. Further discussions on this problem are given in Sect. 4 of this chapter. Even when the technical causes are different for both failure types, the effects that the driver perceives in the vehicle are probably similar (e.g., a vehicle deceleration without any perceivable reason). The procedure described in ISO for defining the safety requirements on the basis of an objective risk evaluation can be applied for both fault types. From the point of view of the driver and other people involved in the situation, it is irrelevant if the hazard results from functional faults or inadequacies of the system as long as the effects on the situation are the same or at least similar. In Ebel et al. (2010), this is denoted as a holistic approach, which allows a comparative evaluation of the effects of technical faults as well as of functional inadequacies. However, to what extent should the accepted risk limit and the evaluation metrics (of the resulting permissible fault rates that are to be applied according to ISO 26262) be compared? Which approach is feasible to solve this issue is still discussed among experts. Thus, in Ebel et al. (2010) an accepted risk limit is required at the system level for both fault types, while in (Ross 2014) the functional inadequacies are clearly associated with safety of use. 2 Safety Requirements for Driver Assistance Systems ISO requires that during the design phase, the risks associated with the E/E system be identified and the risk potential be evaluated. This is done on the basis of the hazard analysis and risk assessment (H&R), a method whose application is normatively prescribed in Part 3 of ISO (3 7 in Fig. 1). In the scope of H&R, potential hazards are analyzed at the vehicle level without considering the causes and the detected risks are classified. Here, vehicle level according to (Ross 2014) means the implementation of one or more systems to which ISO is applied and thus denotes the top most abstraction level in the overall vehicle system. To prevent the hazards defined in the scope of H&R, ISO requires the specification of safety goals (3 5 in Fig. 1). These provide the framework for development of the safety concept. The hierarchical structure of safety requirements is shown in Fig. 2. The safety goals are defined at the vehicle level taking into consideration the influencing factors and situations from the environment and subsequently derived as functional safety requirements in the vehicle system for the functions involved in the hazard (3 8 in Fig. 1). This derivation is still without solution and thus independent of the concrete implementation. The implementation of one or more functions is only done at the concrete system level, addressed by the technical safety requirements (4 6 in Fig. 1). As opposed to the functional safety requirements, technical safety requirements describe the implementation of the system, and, in the next derivation step, HW and SW safety requirements are given in detail accordingly for implementing the hardware and software (Parts of 5 and 6 in Fig. 1).

6 114 U. Wilhelm et al. Vehicle in the Environment (H&R) Specification of Safety Goals Vehicle System (Implementation) Specification of Functional Safety Requirements System (Implementation) Specification of Technical Safety Requirements Hardware (Implementation) Specification of Hardware Safety Requirements Software (Implementation) Specification of software Safety Requirements Fig. 2 Hierarchical structure of safety requirements This safety requirement flow is presented in more detail in the following, using of the Autonomous Emergency Braking (AEB) function as an example. The AEB should perform automatic emergency braking in case of an imminent collision with the vehicle in the front. Depending on the extent of intervention, the function is designed for minimizing damage or preventing damage (see Chap. 46, Fundamentals of Collision Protection Systems ). 2.1 Specification of Safety Goals Basic Principles ISO defines the method for analyzing and classifying hazards normatively. This is done on the basis of the following three risk parameters: Exposure: How often do the driving situations occur, in which a driver or other road users can pose a hazard? Controllability: How well can the driver or other road users control the hazard in this driving situation so that damage can be avoided? Severity: When damage occurs, what is its severity? Figure 3 shows the relationships between the three risk parameters in a risk diagram. This diagram helps to show how a risk evaluation is carried out. The product risk consists of the factors severity of damage (X-axis) and frequency (Y-axis). With reference to the risk parameters mentioned above, the severity of

7 6 Functional Safety of Driver Assistance Systems and ISO Probability Controllability of the malfunction (e.g. by the driver) Exposition of the driving situation Risk potential Tolerable Risk ASIL Residual risk Severity of a possible accident Fig. 3 Risk diagram Severity damage is evaluated with the parameter of the same name. The frequency results from the frequency of the driving situation and the controllability. The higher the frequency of the driving situation, the higher is the resulting risk potential. The risk can be reduced only by means of high controllability, which will be present when the road users involved in the critical situation have the possibility to prevent the damage. The result of the risk evaluation is the risk potential which is evaluated with an ASIL ( Automotive Safety Integrity Level ) in the classes QM, ASIL A, ASIL B, ASIL C, and ASIL D. Here, ASIL A corresponds to the lowest and ASIL D corresponds to the highest risk potential. Based on ASIL, the measures for preventing and controlling systematic and random faults are defined normatively so as to reduce the risk potential to such an extent that the remaining risk lies below the tolerable risk. In ASIL D, more methods and actions are to be applied to ensure safety than in ASIL A. However, if a hazard is classified only with QM (Quality Management), then the application of a certified quality management system is sufficient and the further application of ISO to the development process is not required. The ASIL classification is defined concretely with the help of evaluation of the individual risk parameters according to Table 1. Here, each risk parameter is classified into three to four classes. Each class corresponds to a different meaning. The annex of Part 3 of ISO contains informative tables with references and

8 116 U. Wilhelm et al. Table 1 ASIL determination matrix Severity Exposure Controllability C1 (simple) C2 (normal) C3 (severe) S1 (light/medium) E1 (very low) QM QM QM E2 (low) QM QM QM E3 (medium) QM QM A E4 (high) QM A B S2 (severe, likely to survive) E1 (very low) QM QM QM E2 (low) QM QM A E3 (medium) QM A B E4 (high) A B C S3 (risk to life, unlikely to survive) E1 (very low) QM QM A E2 (low) QM A B E3 (medium) A B C E4 (high) B C D examples using the risk parameters in which the severity of hazards of accidents, driving situations, and controllability of the driver have to be evaluated. Driving situations that occur in almost every drive (e.g., a drive through the countryside) are classified as E4 and driving situations that arise at least once in a month (e.g., driving with trailers in traffic jams) are classified as E3. Driving situations that occur even more rarely are then accordingly classified as E2 (e.g., driving on ice and snow) or as E1 for very rare situations (vehicle on chassis dynamometer). This example itself shows that an objective evaluation is not always possible as driving situations can be evaluated differently based on the considered environment. For example, driving on ice and snow in the northern regions of Europe will surely be deemed to occur than in the southern regions Safety Goals in the Example of AEB The AEB function activates the actuator brake. Based on the actuator function braking, the following malfunctions can be defined as potential hazards: (a) Unintentional automatic braking (b) Unintentional brake boosting during driver braking (c) No braking in spite of braking request (d) Too low braking in spite of braking request (e) Unintentional holding force during standstill In the first step, the risk potential of the hazards of the brake function is defined independently of the driver assistance function. This is done on the basis of H&R with the risk parameters Severity (S), Exposure (E), and Controllability (C) as per Table 2. There, the hazards (a) and (b) are classified as ASIL C. The evaluation is done without considering the safety measures (e.g., deactivation of brakes by the driver or limitation of brake intervention).

9 6 Functional Safety of Driver Assistance Systems and ISO Table 2 H&R with the example of actuator function braking No. Malfunction Situation Hazard S Reason S E Reason E C Reason C ASIL (a) Unintentional C autonomous braking (assumption: vehicle remains stable) (b) Unintentional brake boosting (assumption: vehicle remains stable) City driving/ countryside/freeway, heavy traffic with too short safety distance Rear-end collision by the vehicle behind 2 Accident statistics show light to heavy injuries 4 Heavy traffic in almost all driving situations 3 Controllability difficult for the drivers who are following because safety distance is too short

10 118 U. Wilhelm et al. Table 3 Safety goals with the example of actuator function braking No. Safety goal Safe state ASIL (a) Avoid unintended braking as it would lead to a Interrupt autonomous C hazard braking (b) Avoid unintended braking as it would lead to a hazard Interrupt brake boosting C The ASIL that is determined is used for further development of the product as a standard for risk reduction. Here, safety goals are specified for preventing the hazard rear-end collision. These being at the highest abstraction level (top-level safety requirements) are the starting point for developing the safety concept. Additionally, the safe state has to be specified for each safety goal. For the example from Table 2, the safety goal and the safe state are described in Table 3. Safety goals address all systems that can directly or indirectly access the actuator under consideration and thus have the potential to cause the hazards (a) to (e). The hierarchical structure of safety requirements from Fig. 2 requires the specification of the safety requirements from the vehicle level up to the HW and SW level in more detail. This safety requirement flow ensures the fulfillment of the given safety goals and thus the prevention of the identified hazards. 2.2 Specification of Safety Requirements Basic Principles Safety requirements are specified based on the safety goals at every level of the vehicle and system architecture (see Fig. 2). At the vehicle level, the safe behavior of the function, which can potentially damage the safety goal, is specified in the form of functional safety requirements. This is done in all the systems that are involved and is a part of the requirement specification sent to the individual system providers. The functional safety concept (3 8 in Fig. 1) describes the assumptions and solutions with the help of which functional safety requirements were derived from the safety goals. The requirement specification with the functional safety requirements are created by the party responsible for the vehicle system, this is generally the OEM. The system providers have the responsibility of specifying and implementing the safety concept in such a way that the functional safety requirements from the system are not affected. The technical safety concept contains the documentation of deriving the technical safety requirements from the functional safety requirements. This contains the concrete solution at the system level for preventing the violation of the functional safety requirements and, with it, implicitly for preventing violation of the superordinate safety goal.

11 6 Functional Safety of Driver Assistance Systems and ISO Safety Requirements in the Example of AEB An example of safety requirements for the AEB function at the vehicle and system level is given in Fig. 4. The components of the actuator function of braking are the Driver Assistance System (DAS) and the Electronic Stability Control (ESC) system. The safety goal Avoid unintended braking, which leads to a hazard must then be passed on to both the systems in such a way that it is not violated. This means for the DAS that an unjustified AEB request that could lead to a hazard has to be prevented. By limiting the AEB function in terms of duration and, in part, even in terms of strength, the risk potential that can be reduced as a shorter or weaker braking has a positive influence on the extent of the damage as well as on the controllability. The H&R described in ISO has its limits when it involves defining this risk reduction in a concrete manner. Usually, because of the rough classification of the risk parameters and the related subjective estimation, it is difficult to evaluate the brake interventions with different brake profiles based on their risk potential. In this case, objectified methods, such as simulations on the basis of equations of motions or use of endurance test data and accident statistics, can help further in defining the ASIL classification of different braking profiles more precisely. Assume the AEB intervention is limited such that the risk potential can be reduced to an ASIL A. In this case, this ASIL classification, along with the functional safety requirement Avoid unintended brake request within the AEB specification, is transmitted to the system FAS. However, to avoid that due to a fault, AEB braking is done outside the specified limits, these limits must also be Safety Goal Vehicle Avoid unintended braking as it would lead to a hazard ASIL C Vehicle System Functional Safety Requirement DAS Avoid unintended AEB request within the specified limits ASIL A Functional Safety Requirement ESC Avoid unintended AEB request beyond the specified limits ASIL C Technical Safety Reqiurement DAS Faults within the ECU shall be detected and the AEB request deactivated. ASIL A Technical Safety Requirement ESC The AEB braking shall be limited to the specified values ASIL C Technical Safety Reqiurement DAS Due to a faulty vehicle speed the AEB request shall be deactivated. ASIL A Technical Safety Requirement ESC Due to a fault in the brake the AEB request shall be suppressed. ASIL C Safety Concept System DAS Safety Concept System ESC Fig. 4 Hierarchical structure of safety requirements with the example of AEB

12 120 U. Wilhelm et al. secured. Usually, the AEB requirement is limited by the system ESC with an ASIL C derived from the original classification of the respective safety goal Decomposition Methods In addition to the inheritance of safety requirements, in which the ASIL is assigned to at least one derived safety requirement, ISO also offers the possibility of decomposition. Here, the ASIL of the derived safety requirements can be reduced. However, that is only possible if there is redundancy used. According to ISO , Chap. 5.4, a decomposition and with it the reduction of ASIL can only be done if the safety requirement before decomposition (initial safety requirement) can be implemented by means of at least two sufficiently independent elements or subsystems. Each derived safety requirement must thus be able to fulfill the initial safety requirement on its own. Here, elements or subsystems are considered as sufficiently independent when on the basis of the analysis of dependent faults (see ISO , Chap. 7), no common cause (CCF, see ISO , 1.14) or cascading failure (see ISO , 1.13) is determined, which would lead to violation of the initial safety requirement. Common cause describes the failure due to a common reason, while a cascading failure causes further failures (Ross 2014). In Fig. 4, the ASIL is inherited to all the systems involved. Here, the system ESC receives the ASIL of the initial safety goal. The reduction of ASIL in the DAS is not done by decomposition (there is no redundancy here) but by reevaluating the risk potential with limited braking function. Due to the fact that the safety mechanism for ensuring the specified limits is implemented in an independent electronic control unit, according to ISO 26262, it is absolutely permissible to reduce the ASIL to the actual risk potential in the DAS. However, if hypothetically no ASIL C requirement has to be implemented in the ESC system, then it is conceivable to distribute the ASIL C classification to both systems by observing the specified limits even in the DAS. In Part 9, Chap. 5, ISO offers different options for reducing the ASIL classification. However, here, the initial ASIL should always be given in brackets. Then, for example, ASIL C can be decomposed into an ASIL A (C) and ASIL B (C). For the safety requirements for the AEB function, the change would then result in Fig. 5. Safety Goal Vehicle Avoid unintended braking as it would lead to a hazard ASIL C Vehicle System Functional Safety Requirement DAS Avoid unintended AEB request within the specified limits Functional Safety Requirement DAS Avoid unintended AEB request beyond the specified limits Functional Safety Requirement ESC Avoid unintended AEB request beyond the specified limits ASIL A ASIL A (C) ASIL B (C) Fig. 5 Application of decomposition with the example of AEB

13 6 Functional Safety of Driver Assistance Systems and ISO Meeting the Safety Requirements After the risks resulting from a product are compiled systematically with the help of H&R (3 7 in Fig. 1) and safety requirements are derived from the safety goals, ISO26262 requires that the product development must ensure that these are actually implemented. According to the basic V-Model (2013), a complete requirement tree must first specify the product properties. This specification at all levels of detail serves as a basis for the right branch of the V-Model, the verification and validation of product properties. 3.1 Traceability of Requirement Levels If one assumes that the safety goals were validated, then, according to ISO 26262, a product is safe only if it can be proven that the solution fulfills the safety goals. Accordingly, it is not enough to describe precisely which algorithms are implemented or which hardware is used. The solution must be unambiguously linked with the abstractly specified properties, especially the safety goals, for validation purposes. Creating such complete documentation is very challenging in the case of complex systems. In a first attempt to specify a RADAR-based AEB system, the following requirements might be derived: (a) The internal resistance of the heating wire of the lens heater must be xx Ohm. (b) The RADAR sensor must detect reflection points using a fixed-beam-antenna. (c) AEB must not brake in situations that have no accident risk. (d) The driver must be able to override the AEB behavior at any time. (e) A Kalman filter must be used for object tracking. (f) The vehicle should not cause any accidents due to unauthorized brake interventions. (g) When activating the brake light switch (BLS), an automatic emergency brake control is interrupted and the deceleration requested by the driver is applied. (h) Etc. All requirements given in this example are valid product requirements. However, they are expressed at very different abstraction levels. Requirement (f) corresponds to a general safety goal. Requirements (c) and (d) are abstract descriptions of behavior that do not anticipate the concrete HW and SW solutions as yet. Requirements (b) and (e) describe HW components and SW algorithms without anticipating the implementation details. Requirement (a) in this example is the most concrete requirement, which refers directly to a HW implementation. After deriving the functional safety concept (3 8 in Fig. 1), requirement (d), for example, was introduced as a safety requirement. The core question that arises here is whether the compliance of the internal resistance according to requirement (a) is

14 122 U. Wilhelm et al. Fig. 6 The requirements can be structured in a requirement tree: This is the basis of traceability relevant for safety or is motivated only by quality aspects. A hierarchical requirement tree that orders the requirements yielding a trace from most abstract requirement to concrete solution definition is necessary to answer such questions (Fig. 6). With each level, the solution space is limited further. The tree can also be understood as a representation of nested solution spaces (Fig. 7). In this representation, the benefits of traceability are particularly noticeable: All methods of ISO are geared toward proving that the concrete requirement and its implementation are a subset of the more abstract specifications. In the subset image, a solution is not allowed if it leaves the solution space spanned by the abstract requirement. In practice, it often happens that the hierarchy levels are mixed up inadvertently. For example, the developer specifies a concrete algorithm at the level of the behavior description of the DAS. This leads to early, unnecessary limitations in the system design and also makes it more difficult to ensure the traceability, but is insignificant for compliance with ISO ISO concentrates on the complete consistency of the requirement tree with reference to the safety requirements only. To get a better system overview, it is useful to compile all the requirements belonging to one solution space into one system or subsystem description. For example, the requirements (c) and (d) are at the same description level and both describe the behavior of the feature AEB. A complete set of such requirements is also called a model: An output (system reaction) is always assigned to an input (driver activity, environment situation).

15 6 Functional Safety of Driver Assistance Systems and ISO Fig. 7 The requirement tree represented as nested solution spaces. The requirement The system is not allowed to cause any accidents defines a solution space that is limited by the concrete solution, The driver must be able to override the system at any time In ISO 26262, four broad hierarchy levels are defined with the corresponding models: 1. Abstract system level specified by means of safety goals (requirement (f)) 2. Solution-free product description consisting of functional safety requirements (requirements (c) and (d)) 3. Requirements at the implementation level that could be relevant to more modules and do not refer yet to the smallest architectural element: Technical safety requirements (requirements (b), (e), and (g)) 4. Implementation requirements relevant to the smallest structural element: HW/SW safety requirements (requirement (a) in this example only at the HW level) The requirement tree shown here as an example is obviously incomplete insofar as no system can be developed with the help of this simple specification. Moreover, excessive gaps prohibit an easy understanding of the trace: Is the property of the heating wire really not linked with requirement (f) (no unauthorized brake interventions)? This cannot be answered clearly due to a few text lines! This example demonstrates the challenge posed by a complete, unambiguous, traceable requirement tree for complex driver assistance systems. That is why,

16 124 U. Wilhelm et al. while creating the requirement tree, the structuring system architecture is an important element of mastering a safe system design. With the exception of the hierarchy levels required in ISO 26262, it is generally left to the system developer to decide how many derivation steps are to be provided on the way to the smallest structural element of his architecture. Small steps make it easier to trace the individual steps, but let the number of elements and the complexity of the link structure grow very fast. ISO demands the complete traceability only with reference to the safety goals derived in H&R. Since a well-documented requirement tree not only makes it possible to track compliance with safety goals but also helps the product quality in general, traceability is a standard requirement in the automotive industry, even without a safety goal to achieve. In the example shown here, the requirement tree derived from the safety goals is separate from the tree resulting from performance requirements for the AEB function. Often ISO implicitly assumes that a malfunction at system level is basically always caused by a fault, that is, a deviation from the implementation requirements. In this case, the differentiation between the safety architecture and functional architecture is very clear, as the safety requirements are basically limited to monitoring the specified implementation and reactions to this monitoring. The typical safety architecture protects the functional part of the system from implementation faults. This differentiation is no longer valid if the safety concept also considers the system limits that affect, for example, requirement (c) (AEB should not brake in situations that do not have risk of accidents). A faulty reaction could lead to a faulty safety-relevant behavior, in spite of correct implementation in HW and SW. In this case, all the requirements that result from a safety goal are relevant for safety; explicitly also those that specify the function of the subsystems. In the current version of ISO 26262, such system limits are explicitly excluded from the scope of the standard: ISO does not address the nominal performance of E/E Systems, even if dedicated functional performance standards exist for these systems. The challenges posed by it to the application of ISO for driver assistance systems are described in detail in Spanfelner et al. (2012). In this publication, a reference is made to the fact that in spite of full compliance with ISO 26262, the remaining risk of driver assistance systems can always lie above the tolerable risk (see Fig. 3). Reasons are functional inadequacies that lead to the critical question for safety-relevant driver assistance systems: How safe is safe enough? (Ebel et al. 2009). 3.2 Verification A prerequisite for a valid verification is the complete description of system specification at the defined abstraction levels given in the previous section. The verification aims to prove that the input/output relationship, which is specified in the models, is implemented by corresponding elements of the product. This is the domain of the requirement-based test.

17 6 Functional Safety of Driver Assistance Systems and ISO A correctly derived model, for example, the definition of requirements at the implementation level, is equivalent to the abstract system specification. Accordingly, it would actually be sufficient to verify only the model at the system level in the product. In practice, however, it is not possible to have a complete verification in case of more complex models. The more abstract the specification, the more input/output relations that have to be checked. Since the specification becomes really definite only at the implementation level, a certain degree of completeness can only be practically achieved here. ISO tries to alleviate this problem in two ways. Firstly, the verification is supported not only by simple test methods or reviews, but also, depending on the ASIL classification, further, stronger, formalized methods from the state of the art are recommended (e.g., verification of software code by applying the abstract interpretation ). Going deeper into the different methods would exceed the scope of this overview. Even the ISO itself only refers to established method descriptions here. Secondly, the verification is repeated at all abstraction levels. A simple SW module can be tested in a more complete manner than a complex, interactive system. Specific integration tests for each integration step identified in the design are also part of the verification at all abstraction levels. 3.3 Validation The verification basically proves that two equivalent models at the same abstraction levels of specification and implementation actually correspond to each other. The safety goal derived from the H&R, however, is consciously formulated in an abstract and general manner in such a way that even design faults, that is, models that are derived in a faulty manner, could lead to a violation of these top-level requirements (see Fig. 8). The phase 4 9 Safety Validation is specifically dedicated to the task of ensuring the validity of derivations from abstract requirements. Additionally, the completeness and correctness of the actual safety goals need to be validated. This includes the check of whether the driver can bring the system to a safe state. The required methods concentrate on system tests on the product level and especially focus on the robustness of the system to faults, that is, implementation elements that erroneously do not meet the specification. In practice, according to (Balzert 2008), 55 % of all faults appear in the requirement and design phase itself while defining the abstract requirements for detailed technical models. These faults are especially difficult to detect because all the subsequent design steps and the tests of implementation levels cannot reveal such faults. ISO relies on reviews by experts to detect such faults. The prerequisite here is that the experts have a 100 % understanding of the design step as per the state of the art. Correspondingly, ISO also emphasizes the value of simple designs as a basis for safe systems. A design step that transforms an abstract system model into a concrete technical model always forms the basis of a derivation model. Only with the help of such a

18 126 U. Wilhelm et al. Fig. 8 Representation of the terms validation and verification. The validation focuses on the correctness of the design step: vertical in the V-Model. The verification ensures the equivalence of implementation and implementation model: horizontal in V-Model Fig. 9 The design connects the abstract with the concrete model. A derivation model forms the basis of the figure derivation model is it possible to show that the concrete model lies in the solution space of the abstract model. This explanation forms the basis of validation of the concrete model (see Fig. 9). If, for example, for meeting the requirement (d) (override) the designer selects an electromechanical brake light switch, which is read into an electronic control unit via an A/D converter, then the physical models of the operating mechanism of the switch and of the A/D converter form the basis of this decision. These components are designed with the help of basic derivation models in such a way that they

19 6 Functional Safety of Driver Assistance Systems and ISO always fulfill their task, as long as the basic hardware components comply with their specifications. ISO implicitly assumes that the experts designing the system and those reviewing the system always have access to such a derivation model in the scope of state of the art. Even if this is not required explicitly in the form of documents, a complete requirement tree can be prepared only with the reference to such a derivation model. 4 Limits of ISO In the previous example, the safety goal The driver must be able to override the AEB control at any time could be achieved with a comparatively simple solution with the help of a brake light switch. The safety goal Never brake in a situation where there is no risk of an accident is harder to derive using a complete derivation model. In this case, the safety goal is identical with the system requirement defining the actual function of the system. A safety architecture that is separated from the core function is clearly more difficult, if not impossible. Accordingly the traceability must be ensured along the functional path, which could lead to intrinsic gaps in complex, interpreting, and predictive systems. 4.1 Gaps in Traceability One part of the system function is to predict the behavior of pedestrians in different situations: The system model maps all situations (input) in which the behaviors of the pedestrian and driver do not lead to an accident to the system reaction (output) Don t react. This leads to the question if there is a derivation model which makes it possible to derive an algorithm which shows the measured initial state of the situation in case of the predicted accident. This model must be able to predict the behavior of all possible pedestrians in all possible situations. This is generally not possible. The gap in this model lies in the fact that the intention of relevant players in the given situation is not known. The assumptions for the conventional validation methods, a complete derivation model as per state of the art, are therefore not available. 4.2 Handling the Unknown in the Design Process Are there comparable gaps in conventional systems? The core of the gap is the lack of knowledge of the state of a system element or an environmental load. The validation discussed in the previous chapter is based on a complete understanding of the derivation model assuming that the hardware requirements that form the basis of the design should be fulfilled. The hardware properties can be checked roughly after manufacturing and before releasing the product. It is more difficult to

20 128 U. Wilhelm et al. Fig. 10 Detection accuracy of a classifier can be set using parameters. When the fault classifications are reduced, i.e., false positive probability, then the detection accuracy is also reduced, i.e., true positive probability. On the other hand, increased detection accuracy always goes together with an increased fault classification probability. The gap between the reference lines corresponds to the selectivity and, with it, to the performance of the classifier. The maximum selectivity represents a compromise between the detection accuracy and fault classification probability model the properties over a longer period and when environmental loads are not precisely known. A fault of a specific component after a known load leads to a basically predictable, systematic fault. When the fault occurs, the reason and the breakdown process can be explained. However, for an exact prediction, the exact property of the component, possibly at an atomic level, as well as the exact load schema over the lifetime must be known. As this information according to state of the art cannot be known for all products that are delivered, the individual fault appears incidental. To design the components safely, statistical models are referred to during development. The lack of knowledge about individual properties of the component is thus averaged across a large quantity of components. Similarly to the statistical material modeling our example, the individual behavior of the pedestrian in a specific situation can be modeled statistically. This results in an algorithm which is often correct across a large number of similar situations ( true positive ) and, with a certain probability, wrongly estimates the situation ( false positive ). A wrong estimation that leads to an undesirable behavior that is inconsistent with the specification at the abstract level is referred to in the following as a faulty behavior. The probability of such a faulty behavior is called residual fault probability. This residual fault probability can usually be adjusted using model parameters in driver assistance systems (see Fig. 10). In contrast to the release of designs based on

21 6 Functional Safety of Driver Assistance Systems and ISO complete derivation models, where the design review confirms the absence of relevant faults, a false positive rate of the statistical model is known when the system is released. The system tests are used to confirm the probability of occurrence and with it the conformity with a targeted residual fault probability. The residual fault probabilities must be defined for designing such a system as part of the system specification. This is also standard for designing HW components. The conventional methods for modeling the fault frequency at the total system level are derived by means of rough estimations either quantitatively (Fault Tree Analysis, FTA) or qualitatively (Failure Mode and Effect Analysis, FMEA). The gap in traceability of the design that is described here is often called as functional insuffencies. 4.3 Validation of Systems with Functional Insuffencies For systems with functional insuffencies, the adherence to an upper limit (Ebel et al. 2009) must be proven for the residual risk inherent in the system. In the simplest case, a statistical Black-Box Test should be carried out at the system level. This measures the probability of faulty behavior without knowledge of implementation details using trials on a statistical representative sample. For driver assistance systems this means a lot of test hours under driving conditions that are representative for the function. Even in case of comparatively noncritical functions, depending on the derivation of the acceptable residual risk, residual fault rates of <10 5 /h have to be proven. Unfortunately, ISO does not give any concrete steps for deriving such residual fault rates. For critical functions, the Black-Box Test can quickly become more expensive than the entire development or, in the time frame of a product development, may not be realistically possible to execute in time. Another special challenge is to prove that the test kilometers that have been driven are representative enough for the situations that can be expected in the field. Which road profiles are to be used under which weather conditions, in which countries, with which drivers (Weitzel et al. 2015)? The statistical models of driver behavior are not always available. It is often necessary to take plausible expert opinions in these cases. Consequently, the statistical system tests are no replacement for a well-understood design derived as far as possible from robust models. During development there should be a focus on separating elements that can be designed using an adequate model, from elements in which gaps in the derivation model cannot be prevented. In the example of pedestrian protection, the imaging properties of a camera which has to detect the pedestrian should not be modeled statistically. Unique physical models calculate an angle to the object based on pixel mapping. The situation is different when the behavior of the individual pedestrian has to be predicted. Here it is necessary to statistically model the lack of knowledge about the intention of the pedestrian. The resulting algorithm will not estimate the intention correctly in every situation. Residual fault probabilities are the unavoidable consequence.

22 130 U. Wilhelm et al. 5 Summary and Outlook The first part of this chapter shows how ISO standardizes important procedures for achieving functional safety in the automotive industry. The focus here lies on the prevention of undesired or dangerous system behavior caused by hardware and software faults. With increasingly complex driver assistance systems, functional inadequacies, as the reason for unwanted system behavior, are becoming more prominent. In this case, the challenge lies in the limitations of the system design, making it necessary to handle unknowns using statistical models. One of the assumptions for the validation of such systems with functional insuffencies is the specification of release goals in the form of accepted residual probabilities for faulty behavior of the system. This requires a wide acceptance for the target values in society. Either tested designs or accepted goals have been established for the hardware. Such a standard still has to be developed in the case of designing new predictive systems for driver assistance systems. It is difficult to predict if this will be achieved by enhancing ISO or separate initiatives. According to current estimates, the application of ISO itself is still being interpreted differently in individual companies. This is because the standard allows for individual interpretations. This assessment is supported by looking at contributions to the conferences organized specially on the topic Functional Safety in Germany, North America, and Asia. For example, the risk potential of identical hazards is classified differently. It is also not yet clear how some requirements and methods are to be implemented or applied in a concrete manner (e.g., conducting a SW safety analysis). For the 2nd edition of ISO 26262, on which work has begun in 2015, it remains a challenge to limit this freedom of interpretation further. For the safety of the driver assistance systems, a new standard, be it in the scope of the 2nd edition of ISO or otherwise, should standardize the development goals, not the solutions. Driver assistance is still at the beginning of developments that are necessary for exploiting its full potential. An early rigidity in defined operationally tested solutions motivated by safety concerns could have the consequence that the benefits of the relevant system cannot be developed further. The original intention to provide more safety in this case might lead to the opposite effect: less protection and safety in traffic! References Bachmann V, Zauchner H (2013) Erste Erfahrungen mit dem Automotive-Standard ISO und Ausblick auf die Adaptierung f ur Motorräder (Initial experiences with the Automotive Standard ISO and view on adaptation for motorcycles), Vortrag (Presentation) TU Darmstadt, 23 May 2013 Balzert H (2008) Lehrbuch der Softwaretechnik Softwaremanagement (Textbook on software technology software management), 2nd edn. Spektrum Verlag, p 487