The foundation of the functional safety concept is the creation of functional safety goals. These goals are defined for a given system, or ‘item’ as it is referred to in the ISO-26262 standard. For each item, a hazard and risk analysis (HARA) is performed, which results in a list of possible hazards that need risk reduction and hazardous events linked to a number of situations. Retaining only the relevant combinations of hazard and situation, referred to as ‘scenarios’, for each of these, analysis then proceeds to severity/exposure/controllability determination. Severity evaluates the potential harm of the scenario (with levels 0 to 3). Exposure (with levels 0 to 4) evaluates the average exposure rate of the scenario. Controllability (with levels 0 to 3) evaluates the possibility for avoiding harm in that scenario. There is no free interpretation of the different levels, which have been associated with certain quantitative metrics. Design engineers should work their way from the highest value downwards until the next associated description no longer applies. A table links severity/exposure/controllability values to the ASIL rating. Once an ASIL for each scenario is determined, the next step is to define a safety goal for each of the scenarios, together with a safe state.
Table 1: ASIL Determination Based on Severity/Exposure/Controllability Levels.
For higher resolution click here.
(Image Courtesy of the International Organization for Standardization)
Following this, the set goals and states are translated into functional safety requirements. Then comes the critical step of defining a functional safety concept to realize the function or item and associated safety measures/mechanisms for the hazard risk reduction. When multiple elements realize a single function, the safety goals and requirements have to be allocated and assigned, then further cascaded down to the individual element. The ASIL remains associated to the individual requirement and not to the element. An element can therefore have multiple safety functions and requirements, each with their own ASIL. Through system level exploration the search for the most optimal architecture can yield different ASILs for the same function assigned to an architectural element, as what is considered ‘optimal’ in each case depends heavily on the designer’s constraints (limited choice of existing hardware components, limited PCB area, limited computational power, system cost restrictions, etc).
This can be illustrated by the following simplified example of an electrical power assisted steering (EPAS) system and an acceleration pedal system, both functions realized with a magnetic position sensor IC. Let us suppose that both systems have gone through a thorough HARA and resulted in an ASIL-D requirement linked to the functional safety goal ‘ensure the output signal is proportional to the driver’s intent. Assuming in each case the same transfer function, with maximum output signal equal to wide open throttle (WOT) for acceleration system or maximum torque for the steering system. Taking a fault detection time of 500 ms for the sensor IC, this could be enough to avoid an accident for the accelerator pedal case, but for the torque steering sensor this could result in dramatic safety problems at high speed making the IC not suitable for the given EPAS system design.