Introduction
What is the goal of the software architecture? The expectation is that you already have software requirements, which describe what the software shall do. The purpose of the software architecture is to define how the functionality documented in the software requirements is going to be implemented. In short, the requirements describe the “what,” and the architecture describes the “how.”
Three aspects of the software architecture
Architectural views
Often, the architecture comprises of a physical view, a block diagram of the software only. Especially in complex projects, which applies to most projects nowadays, this is not enough. Surely you want a hierarchical breakdown of the software that demonstrates and explains how the functionality and nonfunctional requirements are going to be implemented in the different components and subcomponents.
Other views are dynamic views, specific functional views that show a breakdown of a specific feature, state-flow diagrams, interfaces and so on.
Typically, the more complex a system, the more different views are required.
As the different views have to be kept consistent an appropriate UML or SysML tool should be used. The tool will support consistency checks.
Interfaces
A pitfall often encountered in assessments is the lack of a detailed description of the interfaces. Expected content of interface documentation includes:
- Name
- Type
- Unit
- Resolution
- Range
- Default value
Without this information, a proper testing of the interfaces in the integration test is impossible. Again, describing these interfaces in an appropriate UML or SysML tool will support consistency between the different views.
Traceability
This process also requires that you demonstrate traceability between your software architecture and the software requirements.
Normally, there is a tool break between the requirements and the architecture, which makes the traceability difficult.
The purpose of traceability is:
- Supports consistency checks, i.e., checking the completeness and accuracy of the coverage of software requirements.
- Supports the impact assessment in case of change requests or bugs.
- Supports the reporting of stakeholder expectations and identifies which requirements have been tested — often referred to as coverage reports.
What is the benefit of Software Architectural Design?
It is impossible to develop automotive software without defining an architecture first. It provides a systematic structuring of the software into its elements that 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 of the Software Architectural Design process?
- Based on the functional and nonfunctional 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 establishes 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 toward 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.
Example of a software architecture
- 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 is 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.
- Considering alternative architectures is new to this Automotive SPICE® version. This is a great tool when developing completely new software. However, the vast majority of automotive projects implement changes to existing software often without modifying the architecture. Providing evidence of alternative architectures can be challenging for this reason. 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 carryover from another project or a platform, one can provide their documentation of alternative design decisions.
- Although traceability has improved a lot in recent years, consistency is still troublesome. The root causes are that consistency has not been understood well for a long time, and it requires substantial review effort.
Deepen your knowledge of Automotive SPICE®
If you’re serious about learning Automotive SPICE®, participate in one of our Automotive SPICE® trainings.
About the Author
Bhaskar Vanamali has been working on process improvement for nearly 20 years and served as secretary of Working Group 13 of the VDA QMC.
He is Principal Assessor and Trainer for Automotive SPICE® and has performed more than 140 assessments and trained more than 250 assessors.
To access the rest of this engaging content, please fill out the form below:
Please wait…