Software architecture is often something that is developed internally in a company and each company has its own unique approach. However, there are many reasons to want to standardize the software architecture. One reason is to make it so that subcontractors can deliver functions that can be easily integrated into existing architectures, completely without adaptations. This also applies within a company, where it becomes easier to reuse functions between different projects. Another reason is tools support. With a larger user base, the relative cost of maintenance decreases and the focus can instead be shifted to improved functionality.
This example addresses what a process can look like when working with the AUTOSAR standard: a standard developed in the automotive industry. Even if you do not work with AUTOSAR today, it is possible to take advantage of the simulation possibilities in AUTOSAR to do early functional integration tests.
The following pages describe how the architecture is designed, how implementations are connected to it and what steps need to be taken to reach a finished software product.
The example is top-down, where the specification comes first and the implementation comes later. Often, however, there is no specification when the implementation is to be done, which leads to a more bottom-up-oriented approach, where the specification grows with the implementation. Even if the order is different, it is basically the same things that must be done.
Related Content:
AUTOSAR is developed by a consortium of vehicle manufacturers, suppliers, and tool vendors.
A separation of the functions from the hardware is done by sending all communication taking place via calls to an intermediate storage (RTE). If an internal call is made on the same platform or over the network, it is made via a pre-determined mapping.
One of the strengths of AUTOSAR is that it is designed for early verification via simulation. Through the concept of Virtual Function Bus (VFB), functions can be connected on a functional level without regard to any later physical separation between different nodes.
AUTOSAR is now divided into Classic and Adaptive. The process described in the following steps is written from a Classic perspective, but the principle and tools can also be applied within Adaptive.
Related Content:
Design of the software architecture is done with advantage in a graphical environment where you can easily see how components connect to each other. As all communication takes place to the operating system within AUTOSAR, the structure becomes flat and it is then important to be able to highlight relevant parts in a separate view.
What needs to be specified in a first stage is mainly:
- Which software components should be available (Application Software Components within AUTOSAR).
- What functions should be available (Runnables within AUTOSAR).
- How functions and software components should communicate with each other (Ports, interfaces).
- Which events should trigger the functions (cyclical, event-driven, etc).
Relaterat Innehåll:
When all or parts of the architecture are complete, it must be distributed to those responsible for the implementation. Complete does not imply finished, as modifications are likely to be performed over time, it means that enough is defined for a function developer to be able to integrate their function.
In the export phase, the export is preferably divided so that function developers only receive the parts that are relevant. A function developer can then import the architecture insert their implementation in it. The function developer then exports an updated version of the architecture which now also contains the implementation, the code.
The architecture model is usually divided into a few different files to keep specific parts separate from general parts that are reused throughout the architecture. In addition to these, there are files with the implementation. All these files will eventually be available in different versions with dependencies between the files. To keep the complexity down, it is an advantage if there is tool support to keep track of file dependencies.
Related Content:
When an implementation is finished, it must be integrated into the project. Through an import, an updated architecture is obtained with references to the implementation and the code itself.
When all software components are connected to an implementation, all functional code is available. An early integration kan be utilized by perform functional integration tests. The entire functional code can then be tested with a decoupling from hardware implementations such as drivers and electrical interface. You can read more about this in the process example for verification.
Integration is an iterative process with updated implementations and can advantageously be automated.
Related Content:
A system can be a single control unit or distributed on several physical control units (Electronic Control Units – ECUs). These ECUs must be created and represented in the system description. The system is also described by the network topology, which enables communication between software components on the various ECUs.
Some functions are dependant on fast interaction with hardware and therefore have natural placements in the topology, while others are more free in their placement as the signals they need to take part in can just as easily be sent over networks.
Related Content:
When the configuration is complete and implementation is available for all software components, all that remains is to generate code for the configuration and connect this with the operating system.
After this, the code is now complete and ready to be compiled and downloaded onto the hardware.
Just like in the section for integration, you now want to verify the behavior even after the configuration. Since the configuration is standardized, it is possible to verify most things in a virtual environment where almost the entire production code is used, with the exception of hardware-dependent parts, which need to be simulated.
You can read more about this in the process example for verification.
Relaterat Innehåll:
