Model-Based System Development and Automotive SPICE 4.0 72 prostep ivip Product Data Journal 2025-1 footnotes 1 The exchange of content between requirements tools is easily possible with the help of the OMG’s Requirements Interchange Format (ReqIF), whereas the exchange of content between different MBSE tools still causes problems today. 2 E.g., CPU, IOs, memory, peripheral units, … 3 Although SW interfaces can also be described in SysML, the possibilities are very limited due to the large number of attributes required per software signal or middleware-specific requirements (e.g. Autosar). References [1] Automotive SPICE – Process Reference Model / Process Assessment Model – Version 4.0, VDA QMC 2023 [2] Pohl, K., Broy, M., Daembkes, H., & Hönninger, H. (Eds.). (2012). Advanced Model-Based Engineering of Embedded Systems: Extensions of the SPES 2020 Methodology. Springer [3] ISO/IEC/IEEE 15288:2023, Systems and software engineering — System life cycle processes [4] ISO 26262-4:2018, Road vehicles — Functional safety — Part 4: Product development at the system level the HW architecture of the ECU? If the RFLP approach is applied to the ECU level, the physical view of the ECU architecture is synonymous with an abstract HW architecture. At this point, the systems engineering view and the HW concept of ASPICE do not fit together. An ASPICE HW architecture relates the HW elements to each other; however, systems engineering pro- vides for the linking of subsystems at the system level above. To be able to fulfill all HW architecture-relevant ASPICE Base Practices, more details are required than the P-view of a system architecture usually shows. According to ISO15288 [3], the documentation of the details is part of the “Detailed Design” step; the system level does not change. For ASPICE, artifacts of different system levels are therefore required in the process groups HWE.1 and HWE.2. You need to be aware of this when setting up the document structure for a system. The physical view of the ECU architecture is taken over from the HW development and refined in a HW block diagram, which corresponds to the ASPICE HW architecture. At this point we have a tool break at AVL, as the HW specialists use different tools than the system architects. In the first approach, traceability can be achieved by giving components and in-/outputs the same name. The MBSE methodology for generating an ECU architecture therefore supports HW development by providing traceable input for the HW detailed design. The established HW development process only needs to be changed minimally. At subsystem level, architectures for complex HW elements are also devel- oped, either by the in-house HW department or by external component manufacturers. These architectures can also be created using the RFLP approach. However, at AVL it is not used for pure HW circuits. AVL also does not design programmable components such as microcontrollers, but buys them in. In the case of a programmable component, however, the application and basic software must be developed by the customer of the component. The architecture of the software system is now interpreted as part of the functional and logical view of the component architecture. The software architecture is therefore described in the same MBSE tool as the ECU archi- tecture, also with the help of SysML and with focus on the functional and logical view. The logical architecture comprises the SW components as structural elements, which can be further broken down into SW units in the Figure 4 provides a brief overview of how AVL‘s RFLP approach is defined for ECU and software development. A metamodel defines which architectural elements are to be used in a specific view.
