Modern development according to the design-centered approach
In the development of mechatronic systems, attempts have long been made to align the development processes of mechanics and the system with those of hardware and software development. The development processes of the mechanics and the system are still strongly determined by the iso9001 and TS16949 standards, which are determined by the software by ISO 15504 (SPICE).
Modern development methods, such as model-based development, are used to ensure a high degree of innovation. For this, it is essential that system development arrives at an early stage to an evaluable design decision. Design decisions can be evaluated by the FMEA methodology by risking the functions to be performed. For the software design, the introduction of evaluated design decisions would be of great benefit. The FUNCTIONAL Safety Standard ISO 26262 also aims in this direction by reproduced the areas of system, hardware and software development by means of a V model and assessing functions in terms of their risk.
There is currently no company in the automotive sector that does not make great efforts to build bridges between the methods. In particular, software interfaces between ALM Tools and PLM Tools must be programmed. Tools that can integrate data from models e.B. from Matlab into ALM tools are also in high demand. Although there are tools that offer editing FMEA in ALM tools, FMEA and requirements management are still being processed in parallel because of a lack of an inclusive approach. The resulting duplication demotivates the developers, which affects the project result, which in turn puts a strain on the budget (Fig. 1).
Figure 1
SIBAC Int. shows a solution for how the processes and methods for a system consisting of mechanics, hardware and software developed on a model basis can be meaningfully integrated through the design-centered approach (DCA) approach. The paradigm shift required for this is the number of levels to be considered in demand management and FMEA (Fig. 2).
Figure 2
The DCA describes the approach to system development at different levels of abstraction. Each level of abstraction consists of a functional specification and a comprehensibly derived design decision, the architectural design. The architectural design determines useful function blocks from the function specification and relates the function blocks (see function blocks in Matlab-Simulink see Fig. 1). The relationships of the function blocks are the interfaces of the system. The interface tests that can be derived from this are the integration tests known from the V model. The follow-up level can be traced in detail in order to trace the function blocks determined.
In practice, this has the advantage that any functional description of a function block as a specification or specification is coherent and can either be processed internally or assigned externally (see Fig. 2). The deducible tests are the known system or, depending on the level of subsystem tests.
The possible misconduct of the system is derived from the extension of the function specification due to malfunctions. This allows the root cause of the error to be identified at each level, analogous to the FMEA methodology, and evaluated in the probability of detection and detection. This gives the developer the risk value of a design decision and provides the project team with clear decision-making. Duplicate work is no longer necessary, the level of development is always comprehensible and the team is motivated (see Fig. 3).
The DCA seamlessly integrates the FMEA into the process for complex product developments. The 5 levels recommended by VDA Band 4 have led to target conflicts in the description of complex systems, since the system complexity cannot be mapped without compromise. The chosen approach resolves this conflict of objectives by using the architectural design as a central starting point, thus fully fulfilling the above-mentioned standards.
Figure 3 shows how the evaluation can be done at the system level. The design is adapted to the system requirements in several loops. An A-rating analogous to the FMEA is not yet possible at the vehicle level. However, if you add the system tests as they are known from the requirements management, a B*E evaluation of the system design becomes possible. If the functions are described at the following system level, the A rating and thus the calculation of the RPZ known from the FMEA can also be performed. Similarly, the ASIL ratings in the specification are directly linked to the design ratings.
There is no need to transfer data from one assessment and documentation system to another. The clarity of the description of the specification as well as the clarity in the derivation of functional and integration tests increases significantly.
Figure 3