Functional Safety (FuSa) is the part of systems engineering which focuses on reducing risk to the user from the malfunction of electrical or electronic systems. At DISTek, we focus specifically on the scope of Functional Safety associated with embedded software development and continuous integration (CI). This means that we identify then reduce or mitigate hazards through achieving acceptable risk with associated malfunctions. Basically, what this means is that we ensure the system under development follows the desired processes and avoids malfunctions and dangerous situations. Engineering a system to achieve Functional Safety requires the specification of all safety goals, and the performance level of the automatic safety response. The process includes the following high-level steps:
- Identifying the safety hazards: This step requires an analysis of all the hazards and the associated risk with each.
- Assessment of risk-reduction required by each safety function: During this step, one must quantify the risk of hazard through a performance level assessment.
- Identify Safety Goals, Concept, and Functional Safety Requirements: Test functional safety requirements to verify safety goals achieve acceptable risk, even in failure-mode(s). Have qualified engineers following the appropriate quality management system QMS and FuSa ISO standards laying out the design & lifecycle processes.
- Verify that the performance level of each safety function is met: This is completed through a failure mode, effects, and diagnostic analysis (FMEDA).
The tool to kick off the implementation of this standard in step one is a HARA, or Hazard Analysis and Risk Assessment. This tool is a process in the Functional Safety standard that enables engineers to identify potential hazards and the risk of harm that is associated with each. When a potential hazard is discovered, the process instructs us to classify by severity of impact, exposure, and controllability of the malfunction. It is important to note that a hazard could pose harm to either the environment or the user of the system, where both must be considered during the HARA. This classification utilizes a table as seen above to make sense of the Severity, Exposure, and Controllability parameters of each hazard. Following in the order listed, find which box in the table is associated with the combination of S, E, & C that you have determined. This box signifies the performance level that the specific hazard must meet to provide for the overall safety when using the system. Think of a performance level as a gauge for the level of safeguards/risk reduction required to provide relative safety, where the ‘a’ performance level is the least stringent and ‘e’ is the most. At this point you have laid the basis for defining your safety goals.
Safety goals are solutions to the hazards identified and assessed in the HARA. This requires you to derive goals to cover every potential hazard. Safety goals drive the design principles you use to define the safety concepts. Use these safety concepts to translate the safety goals into safety requirements. Safety concepts are used to define the spectrum of requirements needed to achieve a safety goal. Generate your functional safety requirements outlined by the safety concept to test if you have achieved your safety goals. The following diagram displays the relationship between the safety goal, concept, and requirements.
At this point, the functional safety requirements must be verified and validated through testing. Not only this, but you must verify that the system achieves performance levels previously set in the HARA when tested. This ensures that your safety goals reduce the risk of hazards to an acceptable risk, putting a close to this design loop.
This investigation serves as a brief overview of a generalized Functional Safety process. Depending on which industry you are working in, there will likely be an associated ISO or IEEE standard to outline specifics only relevant to your field. Despite that, it is universal that a QMS, or Quality Management System, process is required in tandem with the implementation of a Functional Safety standard. DISTek has experience working with more than one Functional Safety standard, including ISO 26262 and ISO 25119, while interfacing with our client’s currently used QMS system. If you are struggling with achieving Functional Safety with your embedded software, DISTek could be the right fit for you. Reach out today to discuss your needs – sales@distek.com.
