3 The ASPICE-Processes (VDA Scope)

3.4 SWE.2 – Software Architectural Design

What is the purpose?

Software architectural design describes the elements of the software, their interfaces, and their dynamic behavior. It also links the software requirements to the detailed design and implementation.

What is the benefit?

It is impossible to develop automotive software without defining an architecture first. It provides a systematic structuring of the software into its elements which is consistent with the requirements. It also defines the dynamic behavior of the software and the resource consumption of its elements. The quality of the architecture highly impacts the efficiency, maintainability, testability, reusability, and the maintenance cost of the product.

The architecture is also a must to satisfy the requirements of the ISO 26262 standard. Safety requirements need to be traceable to software elements. This is the basis for the safety concept (required at project start) and the safety case (required at the end of the project).

What is the content?

  • Based on the functional and non-functional software requirements (and safety requirements, if applicable) the software architecture is developed (BP1, BP2). State of the art is:
  • a physical breakdown into elements and down to the components (BP1)
  • modeling of the dynamic behavior (BP4)
  • optionally the modeling of the functionalities (particularly if a completely new product is developed)
  • Alternative architectures are considered (BP6) based on factors such as maintainability, expandability, scalability, reliability, security, and usability. Rationales for architecture decisions are documented.
  • The interfaces and the dynamic behavior (BP3, BP4) are specified, as well as resource consumption targets (e.g., regarding ROM, RAM, EEPROM, flash memory, CPU load, etc.) for the architecture elements (BP5).
  • Bidirectional traceability and consistency between software requirements and architecture elements is established (BP7, BP8). Traceability ensures that one knows which requirements shall be implemented in which elements and vice versa. Traceability is a prerequisite for consistency. Consistency means that the links between requirements and architecture elements are correct and complete.
  • The architecture is communicated to all relevant parties (BP9).

Experiences, problems and hints

  • Software architecture design is typically supported by design tools. There is also a trend towards automatic code generation from the design models created within the design tool.
  • State of the art tools support the structural decomposition into elements, dynamic modeling (e.g., task sequence diagrams) and functional modeling. UML, SysML and XML tools typically provide consistency checks between different representations of the architecture thereby avoiding manual effort.
  • Functional modeling is relatively new in automotive. It took many projects huge efforts which seemed to be not always justified, especially when the functionality of existing legacy software was modeled.
  • A significant goal of the architecture is to provide simplified views into the software system. It is meant as an abstraction, hiding details so that a higher order understanding of the software pieces and their purposes can be described and understood easily.
  • When organizations build platforms, they often intend it to be a basis architecture for which a customer/application team can then tune aspects to their specific needs. This cannot be successfully achieved unless both parties, the platform and customer/application team both understand and maintain a common understanding of the underlying software architecture.
  • Simply put, the architecture is often too complicated, and the architect unable to express it concisely and simply. This impacts the whole project negatively, as the team is unable to work from a common foundation of understanding.
Example of a software architecture
Example of a software architecture
  • Considering alternative architectures is new to this Automotive SPICE version. This is a great tool when developing completely new software. Probably 99% of automotive projects, however, implement changes to existing software often without modifying the architecture. Providing evidence of alternative architectures can be challenging for this reason. However, configuring the platform in a structured way can be considered as an evaluation of alternative architectures. If the configuration is done by means of application parameters, for instance, alternative parameter combinations can be analyzed and the rationale for choosing one particular set can be documented.
  • If the architecture was a carry-over from another project or a platform one can provide their documentation of alternative design decisions.
  • While traceability has improved a lot in the last years, consistency is still troublesome. The root causes are that consistency has not been understood well for a long time and that it requires substantial review effort.

Automotive SPICE text of Software Architectural Design (SWE.2)

The purpose of the Software Architectural Design Process is to establish an architectural design and to identify which software requirements are to be allocated to which elements of the software, and to evaluate the software architectural design against defined criteria.

SWE.2.BP1: Develop software architectural design. Develop and document the software architectural design that specifies the elements of the software with respect to functional and non-functional software requirements. [OUTCOME 1]

NOTE 1: The software is decomposed into elements across appropriate hierarchical levels down to the software components (the lowest level elements of the software architectural design) that are described in the detailed design.

SWE.2.BP2: Allocate software requirements. Allocate the software requirements to the elements of the software architectural design. [OUTCOME 2]

SWE.2.BP3: Define interfaces of software elements. Identify, develop and document the interfaces of each software element. [OUTCOME 3]

SWE.2.BP4: Describe dynamic behavior. Evaluate and document the timing and dynamic interaction of software elements to meet the required dynamic behavior of the system. [OUTCOME 4]

NOTE 2: Dynamic behavior is determined by operating modes (e.g. start-up, shutdown, normal mode, calibration, diagnosis, etc.), processes and process intercommunication, tasks, threads, time slices, interrupts, etc.

NOTE 3: During evaluation of the dynamic behavior the target platform and
potential loads on the target should be considered.

SWE.2.BP5: Define resource consumption objectives. Determine and document the resource consumption objectives for all relevant elements of the software architectural design on the appropriate hierarchical level. [OUTCOME4]

NOTE 4: Resource consumption is typically determined for resources like Memory (ROM, RAM, external / internal EEPROM or Data Flash), CPU load, etc.

SWE.2.BP6: Evaluate alternative software architectures. Define evaluation criteria for the architecture. Evaluate alternative software architectures according to the defined criteria. Record the rationale for the chosen software architecture. [OUTCOME 1, 2, 3, 4, 5]

NOTE 5: Evaluation criteria may include quality characteristics (modularity, maintainability, expandability, scalability, reliability, security realization and
usability) and results of make-buy-reuse analysis.

SWE.2.BP7: Establish bidirectional traceability. Establish bidirectional traceability between software requirements and elements of the software
architectural design. [OUTCOME 5]

NOTE 6: Bidirectional traceability covers allocation of software requirements to the elements of the software architectural design.

NOTE 7: Bidirectional traceability supports coverage, consistency and impact analysis.

SWE.2.BP8: Ensure consistency. Ensure consistency between software
requirements and the software architectural design. [OUTCOME 1, 2, 5, 6]

NOTE 8: Consistency is supported by bidirectional traceability and can be
demonstrated by review records.

SWE.2.BP9: Communicate agreed software architectural design. Communicate the agreed software architectural design and updates to software architectural design to all relevant parties. [OUTCOME 6]

Output Work Products

Software architectural design, Software detailed design, Traceability record, Verification results, Verification criteria

If you wish to continue to the next chapter click here: