The Functional Safety Concept

1 The objective of the functional safety concept is to derive the functional safety requirements, from the safety goals, and to allocate them to the preliminary architectural elements of the item, or to external measures. 

1 To comply with the safety goals, the functional safety concept contains safety measures, including the safety mechanisms, to be implemented in the item s architectural elements and specified in the functional safety requirements. 

For this section, ISO 26262 assumes that the vehicle architecture is already existent, since the safety requirements of the functional safety concept have to be implemented in the existing entire vehicle architecture. The functional safety concept used to have the basic intent to describe the necessary safety requirements. 

The processes described in this chapter should not act as a model for a functional safety concept but rather as support for considering the right aspects for the design. Therefore we consider the following four safety goals  

Furthermore, the values always depend on the operation environment, driving situation etc. A hot engine could behave completely different than a cold engine in 

---

ABSTRACT The draft document of the NATO allied ordnance publication (AOP) 52 gives guidance on software safety design and assessment of ammunition-related computing systems. The content of the draft is reviewed and compared with the lEC 61508 standard for functional safety of electrical/electronic/programmable electronic (E/E/PE) systems. We discuss the overall development model, the safety-lifecycle model and proposed techniques and measures. We also investigate whether the functional safety concept of lEC 61508 is incorporated in the document. 

The derivation of safety goals in the EEA tool PREEvision is presented in [16]. The functional safety concept phase will be performed by the role of the safety expert at the original equipment manufacturer (OEM). However, the role of the safety expert at the OEM may consult the EE architect during item definition, the preliminary architectural assumption or the allocation of FSRs to elements of this architectural assumption. 

OCL validation checks concerning consistency and correctness of the functional safety concept are set up. Thus, we provide a computer-aided technique to discover errors in the hazard analysis caused by finding inconsistencies or errors in one or more of the UML models. 

Our paper is organized as follows. The goal structuring notation is introduced in Sect. 2.1. In Sect. 2.2, we give a brief overview of ISO 26262. Our method is presented in Sect. 3. This section also describes our UML profile, which is used to express the functional safety concept. Based on this profile, we define the validation conditions. The tool support is outlined in Sect. 4. We introduce the illustrative example of an electronic steering column lock system as case study in Sect. 5. Section 6 presents related work, while Sect. 7 concludes the paper and gives directions for future work. 

It is important that the functional safety concept is complete. The following... 

ISO 26262 requires to perform a verification review of the functional safety concept. This must be performed by a different person who knows the technology of the system-to-be. This is supported by some of the OCL validation constraints in Tab. 4 and the generation of a structured document from the model. 

After defining all attributes of the functional safety concept, it is automatically checked that for each safe state at least one safety-related function is defined and that for each assumption at least one general safety requirement exists by executing Conditions 3C01SS and 3C02AS (see Tab. 4). 

An operating mode overview (see Tab. 4, 3G04OR) can be generated from the functional safety concept information. Additionally, a controllability rationale... 

Allocations of functions, partial functions and their requirements (so called functional requirements) on a logical element are the main activity for the development of the functional safety concept besides the verification of such requirements. Without such allocations verification is impossible. The logical elements El to E4 should implement function 1 and 2. The allocation could lead to the following result ... 

These questions build the foundation for the verification of the functional safety concept. In each individual level, in which requirements can be verified, a similar approach can be used for the requirement verification. The figure above shows that if functions or the elements, which those functions should realize, do not have common interfaces, the number of interfaces will explode exponentially. If also a situation related failure analysis had to be made on the basis of such heterogenic positive descriptions and perhaps correlations had to be described through several horizontal abstraction levels, completeness, transparently, comprehensibility, consistence and correctness would no longer be given. Such an amount of interfaces would not be analyzable and therefore no longer controllable. 

F. 4.22 ASE. alLocation in the functional safety concept red arrows indicate possible malfunctions)... 

The verification of the functional safety concept should be supported by a draft FMEA (see Fig. 4.23) or as illustrated by a positive fault tree. A hierarchically stmctured FMEA would be able to support the verification very well according to the VDA approach. 

Within the overall development lifecycle, the technical safety requirements are the technical requirements necessary to implement the functional safety concept, with the intention being to detail the item-level functional safety requirements into the system-level technical scfety requirements. 

The basic requirement says that the system design should be drived from the functional safety concept, whereby the architecture should still play a central role. In effect, this causes the various functions of the functional safety concept and then-requirements to be again allocated to common elements. This is often the case for microcontroller. 

Functional and technical requirements are not different by its nature, the allocation within the architecture characterize them as such. Figure 4.25 shows that if the logical and technical perspectives are separated, the common usage of element 3 (E3) becomes transparent. We can describe functional correlations from technical as well as logical elements and we can also functionally describe the internal correlations or a technical element. This is why it is important to determine a specific description level for the technical system architecture and specify flie implemented element and their interfaces. As a result the safety requirements are derived from the functional safety concept to the elements and the interfaces of the technical architecture, whereas the system interfaces do not necessarily have to be described by technical elements. 

The first objective is to provide evidence of compliance with the safety goals and that the functional safety concepts are appropriate for the functional safety of the item... 

Two objectives are defined for safety validation the first is the evidence that the safety goals are considered adequately in the context of the functional safety concept and the defined item. The second objective asks for the evidence that the safety goals themselves are correct and achieved on vehicle level. The hope of any safety validation is, to proof that the vehicle is safe as such, hut ISO 26262 could provide support on the evidence of functional safety for E/E-Systems. The safety-live-cycle in ISO 26262, part 2 shows, that external measures and also measures of other technology have to be considered during safety validation. In 9.2 General the relation to other activities are detailed. 

Thus it is also in the second interpretation, the request itself is really what is required, according to ISO 26262 in deriving the functional safety concept for technical safety concept through to the component requirements. Here ISO 26262 calls the activity also verification of requirements. 

ISO 26262 uses the term evaluate in connection with the functional safely audit and assessment and check for the confirmation reviews. The assessment character for the functional safety audits could come from checking whether the safety activities have been implemented as planned on the basis of the functional safety concept. 

Why the definition of the item, the functional safety concept, the component integration and their tests, the safety validation and the qualifications of hardware and software components do not undergo a confirmation review is unclear. However, some of these work results need to be verified. 

The Functional Safety Concept (FSC) starts with a functional system architecture (function block diagram) of the nominal function, which may look similar to SysML Internal Block Diagrams, or the block diagrams used in simulation and design tools, such as the popular simulation tools Simulink from MathWorks or ASCET from ETAS. On this basis, the FSC describes how the function blocks contribute to the Safety Goals (i.e. what they must assure on their part in order to assure the Safety Goal) or can violate Safety Goals by any foreseeable misbehavior. 

The functional safety concept that has been chosen to achieve the safety goal, named Distributed detection and mitigation of torque errors, is based on degradation whereby all faults that can lead to excessive acceleration are detected within an acceptable time interval. On detection of a fault, the vehicle acceleration is limited to a value below that specified in the safety goal. The concept is based on the assertion that only malfunctioning behaviour of the Item that can violate the safety goal (which is specified in terms of vehicle- QVQ behaviour acceleration) is the delivery of... 

---