EN 
DE 1. Introduction
The development of electronic and mechatronic devices in which software is embedded places high demands on planning and precision. This is true especially if a malfunction of the device can lead to injury or death of people. In such a case, the device is called "safety-related" or "safety-critical". Examples of such systems are steering and braking systems, which must meet the highest safety standards, but also electric window lifters, which are typically equipped with an anti-pinch protection mechanism for safety reasons.
The success of such a product development project depends largely on a clear structuring of the works to be done in the course of the project. At the beginning of the project, the product architecture levels should be defined together with all works and work products (= documents) for each individual product architecture level. Equally crucial are effective supporting processes.
You will learn more about this in the following sections. Section 2 deals with the development works and their documentation. Section 3 is dedicated to the supporting processes, while Section 4 summarizes the key findings.
2. Development works and their documentation
Successful product development starts with looking at the product to be developed and subdividing the product into product architecture levels. These product architecture levels comprise at least:
- the system level,
- the hardware level and
- the software level.
It is important to note that the software level is always below the hardware level because software never exists “abstractly”, but is always implemented on specific hardware components such as microcontrollers or signal processors. For each hardware component with integrated software, a detailed hardware-software interface specification needs to be drawn up to ensure a smooth interaction between the hardware and software development teams.
The Role of the Design Specification
The design specification of every product architecture level forms the basis for all further specifications at that level. It should include:
- Configuration and parameters of the parent system one level up,
- System states and system state transitions of the parent system,
- Names and functions of the elements the respective product architecture level,
- Relevant laws, standards and regulations,
- External interfaces and chains of effects between the elements of the respective product architecture level.
Safety analyses
Comprehensive safety analyses must be carried out from the top product architecture level down to the product architecture level under consideration:
- Hazard Analysis and Risk Assessment (only on the top level),
- Fault Tree Analysis (FTA),
- Failure Mode and Effects Analysis (FMEA) or an FMEA variant such as an FMEDA, and
- Dependent Failure Analysis (DFA).
These safety analyses should be performed as soon as the system architecture is available from the top product architecture level down to the respective product architecture level. This allows to identify risks at an early stage and to adapt or supplement requirements for the system and its elements.
The V-model of system development
The V-model shows how the various development and testing steps are linked. The development steps "Design", "Analysis" and "Requirements" repeat on every product architecture level.
The V-model is vertically subdivided into the product architecture levels named:
the product or system level: the top product architecture level,
the subsystem level: can consist of several subsystem levels or may not exist at all,
the hardware level: can consist of several hardware levels, and
the software level: can consist of several software levels.
3. Supporting processes and their documentation
Efficient and standard-compliant product development is not possible without supporting processes. The supporting processes ensure both quality assurance and compliance with the industry-specific functional safety standard. The main supporting processes are:
- project, quality and functional safety management,
- competence, configuration and change management,
- document management, in particular requirements management, as well as
- test management including integration and test strategies.
The autoConform® Software Suite helps companies ensure the long-term quality and safety of their products. Furthermore, the autoConform® Software Suite significantly reduces the manual effort it takes to create, update and maintain the associated documentation.
4. Summary
The development of safety-critical products requires a systematic approach which is structured according to the architectural levels of the product to be developed. By carrying out safety analyses as early as possible and by implementing effective supporting processes, a product development project can not only be accelerated, but can also be more reliable and predictable.
With a project setup and structure appropriate for the product to be developed, with clear processes and with the help of tools such as the autoConform® Software Suite, product development becomes more focussed, efficient and compliant with standards - an investment in quality and competitiveness.
