3. The ASPICE-Processes (VDA Scope)
3.2 SYS.3 – System Architectural Design
What is the purpose?
Based on the system requirements the system architectural design is developed consisting of software, hardware, mechanics, hydraulics, sensors, etc.
What is the benefit?
A good system architecture defines the system components, the dynamic behavior, the functions, and the internal and external interfaces. It provides the basis for the system integration test.
What is the content?
- A system architecture is developed that is based on the system functional and non-functional requirements. (BP1)
- The system architecture defines all the elements within the system. It
may be decomposed, e.g., into a hierarchy of subsystems with different levels of detail. (BP1)
- The internal and external interfaces of the system elements are
defined and documented. (BP3)
- The dynamic behavior of the system elements is defined and
- Alternative designs for the system are considered based on evaluation criteria. Once a particular design is selected the rationale for this decision is documented. (BP5)
- Consistent bidirectional traceability between the system requirements and the architecture is established and maintained. (BP6,7)
- The architecture and any changes to it need to be agreed and communicated to all relevant parties. (BP8)
Experiences, problems and hints
The system architecture describes how the system elements interact. It also includes the identification of the elements, interface specifications with input and output variables, as well as description of the dynamic behavior.
- A common problem is that interfaces are difficult to identify and are not fully defined. This is a problem also for the system integration test.
- Dynamic behavior should be described explicitly with all the different operating modes, timing sequences etc. This applies especially to safety-related systems, e.g. defining the maximum time for fault detection and conversion into fail-safe mode based on the safety requirements and how that is achieved on system level.
- State of the art tools provide different architectural views such physical, logical, dynamic and functional.
- For projects that are based on platforms it must be clear what comes from the platform and which parts are being changed, deleted and/or newly developed. Often, the project-specific architecture is completely missing and there is just a platform architecture. This is a weakness – a project-specific architecture is required.
- Alternatively, often the project team has no understanding of the whole architecture as they inherited the solution from the platform. This is also an unacceptable situation.
- Alternative design decisions and their rationale have to be documented. This is required when a system architecture is newly developed or significantly revised. If the architecture was a carry-over from another project or a platform one can provide their documentation of alternative design decisions. If the platform is adapted to the customer needs using application parameters the decisions regarding which parameters are chosen can be used as evidence.
- Traceability is not enough by itself, consistency has to be demonstrated. Consistency checks (through reviews) have to assure that the system architecture is based on correct interpretations of system requirements and that traceability and links are correct and complete.
Automotive SPICE text of System Architectural Design (SYS.3)
The purpose of the System Architectural Design Process is to establish a system architectural design and identify which system requirements are to be allocated to which elements of the system, and to evaluate the system architectural design against defined criteria.
BP1: Develop system architectural design. Develop and document the system architectural design that specifies the elements of the system with respect to functional and non-functional system requirements.
NOTE 1: The development of system architectural design typically includes the decomposition into elements across appropriate hierarchical levels.
BP2: Allocate system requirements. Allocate the system requirements to the elements of the system architectural design.
BP3: Define interfaces of system elements. Identify, develop and document the interfaces of each system element.
BP4: Describe dynamic behavior. Evaluate and document the dynamic behavior of the interaction between system elements.
NOTE 2: Dynamic behavior is determined by operating modes (e.g. start-up, shutdown, normal mode, calibration, diagnosis, etc.).
BP5: Evaluate alternative system architectures. Define evaluation criteria for the architecture. Evaluate alternative system architectures according to the defined criteria. Record the rationale for the chosen system architecture.
NOTE 3: Evaluation criteria may include quality characteristics (modularity, maintainability, expandability, scalability, reliability, security realization and
usability) and results of make-buy-reuse analysis.
BP6: Establish bidirectional traceability. Establish bidirectional traceability between system requirements and elements of the system architectural design.
NOTE 4: Bidirectional traceability covers allocation of system requirements to the elements of the system architectural design.
NOTE 5: Bidirectional traceability supports coverage, consistency and impact analysis.
BP7: Ensure consistency. Ensure consistency between system requirements and the system architectural design.
NOTE 6: Consistency is supported by bidirectional traceability and can be demonstrated by review records.
NOTE 7: System requirements typically include system architectural requirements. Refer to BP5.
BP8: Communicate agreed system architectural design. Communicate the agreed system architectural design and updates to system architectural design to all relevant parties.
Output Work Products
System architectural design, Communication record, Review record, traceability record, Interface requirements specification
If you wish to continue to the next chapter click here: