Functional Safety And Requirements Engineering

Using an integrated model-based flow for more efficient safety-aware design.


Currently, dramatically increasing design costs are being reported for safety-critical applications. This is caused by additional necessary actions to implement and verify functional safety requirements. Such requirements are appearing with a clearly increasing tendency in the area of mobility (automotive, transport, aerospace) as well as in industrial automation and medical technology. In many projects from these areas, design costs are increasing by 50 to 100%.

A few methods have already been implemented in today’s development process that are required or recommended for development in accordance with ASIL (Automotive Safety Integrity Level). These include general procedures such as reducing the complexity of the interfaces and concrete methods such as FME(D)A (Failure Mode, Effect and Diagnostic Analysis). The goal of FMEDA, for example, is to analyze possible sources of faults in a timely manner with regard to how likely such a fault is, how great its effects are, and how well it can be detected. Such measures have been known for many years and are sometimes also used for quality assurance in projects that are not safety critical. However, they are limited to the consideration of individual levels in the development process.

In the future, the task will be to bundle individual procedures that are separate from each other into an integrated flow. This will make it possible to increase the efficiency of a safety-aware design flow considerably. Another relevant aspect here is integrating procedures that are already being used successfully in software engineering. The term “model-based design” is understood to mean a procedure in which abstract models are prepared for the target system very early in the development process and are carried along in parallel as a reference during the implementation process.

Closely integrating requirement engineering and systems engineering will result in a substantial gain in efficiency. In requirements engineering for instance, both functional requirements and safety requirements are kept track of throughout the development process. This is done via unique identifiers that are linked with the component in which this requirement is realized. During the partitioning of a system into subsystems, the linking is accordingly passed on to the relevant subsystems. As a result, it is clear at all times which components must be tested to verify that a requirement has been met. Furthermore, if a requirement is changed, only the corresponding tests need to be performed again.

In contrast, systems engineering tends to consider functional partitions rather than logical dependencies of the system. Functional models of the individual components make it possible to check and verify that a requirement has been correctly implemented. Such models on the electronic system level (ESL) are implemented in different languages. The use of Matlab/Simulink is extremely widespread, but SystemC and SystemVerilog are also becoming more widely distributed. The latter are particularly well suited to also functioning as a reference for downstream circuit designers.

As a result, in systems engineering the possibilities of requirements engineering are exceeded, but its approaches and tools can still be made use of. This means that partitions and interfaces are an important input for implementing models that, in addition to structural information, also include an abstract representation of the component function. Languages like UML and SysML are available as interfaces between the two worlds.

Executable system-level models are also a necessary prerequisite for performing fault injection via simulation. As a result, another requirement from the functional safety standards (IEC 61508 in general, ISO 26262 for automotive, DO-178C for aerospace, IEC 61511 for industrial automation) is met: System components must detect faults (e.g. interconnect opens or shorts) and also in these cases react in a defined and predictable way, which can be checked by means of fault injection. Such fault simulations can be performed in the concept phase with abstract system models, and also later in the implementation phase.

A model-based development flow from the concept phase to hardware and software implementation, ending with system verification, results in improved efficiency and quality in the process. Procedures and tools from requirements engineering should also be integrated here in order to establish a uniform and consistent design flow and to reduce design costs for safety-critical applications over the long term.

For more information, see:

Leave a Reply

(Note: This name will be displayed publicly)