Functional safety compliance is often a time-consuming and expensive process. That, in turn, underscores the role of documentation in efficiently implementing the functional safety guidelines.
So, designers need full documentation to support the development of functional safety-enabled embedded systems. It includes safety manuals that document all the information for integrating functional safety-enabled MCUs into the embedded system. These manuals detail all applicable safety requirements, procedures, and conditions of use.
Figure 1: In functional safety, documentation constitutes the third fundamental building block, along with hardware and software components. (Image:: Infineon Technologies)
Functional safety requirements are specified in the ISO 26262 standard for automotive safety, IEC 61508 for industrial applications, IEC 62304 for medical software, and IEC 60730 for automatic electric controls. There are functional safety experts such as TÜV SÜD that certify the compliance of components, tools, IPs, and end systems to these standards.
Here is a brief description of some of the common terms that engineers come across while dealing with functional safety requirements.
Failure Mode Effects Analysis (FMEA)
It’s a qualitative analysis tool that contains a detailed list of microcontroller failure modes and related mitigation measures. FMEA is a step-by-step approach that identifies all possible means of failure in a design (failure modes) and the consequences of those failures (effects). It is the key to correctly defining how to mitigate faults and lays the foundation for the quantitative analysis applied later in the process.
Failure Mode Effects and Diagnostics Analysis (FMEDA)
It’s a quantitative analysis technique that the design team must apply after completing the FMEA. FMEDA helps determine the effectiveness of the MCU safety integrity architecture by providing a static snapshot of failure rates computed at both the microcontroller and basic functional detail levels.
The FMEDA report computes failure rates for each MCU block, including the effect of permanent and transient faults, allowing safety managers to review all the information regarding adherence to functional safety standards.
Assumptions of Use (AoU)
The documented AoU informs designers about how a component like a microcontroller is expected to be used in embedded system design. It reflects the expected safety concept, safety requirements, and safety mechanisms to be used by the system designer.
While third-party functional safety certification of a component like MCU encompasses the AoU analysis, system designers are still obliged to analyze the component in the context of their own use.
Safety Element out of Context (SEooC)
The hardware or software components developed without a context of a particular application in which they are going to be used fall under the preview of SEooC. Otherwise, a wrong assumption about hardware or software component may impact the entire functional safety compliance.
In the hardware realm, microcontrollers, a pervasive building block in the embedded systems, are a common SEooC item. Likewise, in the software domain, RTOS equipped with a scheduler and designed to meet the real-time requirements of an embedded system is a classic example of SEooC.
Leave a Reply