Software architecture

Intro

Software architecture is often something which is worked out internally at a company with each company having their own specific procedure. There are, however, many reasons to want to standardise the software architecture. One reason is that subcontractors could deliver functions which can easily be integrated into existing architectures, without any modifications. Naturally, the same is true within a company, where it becomes easier to reuse functions between projects. Another reason is the utility support; with a greater user base the relative maintenance costs decrease and focus may be shifted towards improved functionality.

This process example describes how a process may look when working with the AUTOSAR standard, a standard developed within the automotive industry but which is also implementable within other areas. Even when not working with AUTOSAR today, it is possible to benefit from AUTOSAR simulation possibilities to perform early functional integration tests.

The following pages describe how to design the architecture, how implementations are connected to it, and which steps need to be taken in order to reach the finished software.

AUTOSAR

AUTOSAR was developed by a consortium of automotive manufacturers, subcontractors and utility suppliers.

A decoupling between functions and hardware is achieved by performing all communication through calls to an intermediate layer (RTE). If an internal call is performed on the same platform, or over the network, it is performed through a mapping.

One of the strengths of AUTOSAR is that it is constructed for early verification through simulation. Using the concept of Virtual Function Bus (VFB), functions may be connected on a functional level while disregarding a later possible separation between different nodes.

Modeling

Software architecture design is conveniently performed in a visual environment where it is easy to see how components are interconnected. Since all communication in AUTOSAR is accomplished through the operating system, the structure becomes flat and it is therefore important to be able to inspect specific parts separately.

Preliminary specifications consist mainly of:

  • Which software components to include (Application Software Components within AUTOSAR)
  • Which functions to include (Runnables within AUTOSAR)
  • How functions and software components should communicate (Ports, interfaces)
  • Which occurrences should trigger the functions (Cyclic, event based etc.)

Implementation

Once all or parts of the architecture is complete, it must be distributed to those responsible for implementation. Complete does not imply finished, since modifications will likely be performed with time; rather, it means that enough definitions have been set in order for a function developer to be able to integrate their function.

In the exporting stage, the export is preferably divided so that function developers only receive parts relevant to them. A function developer may then import the appropriate architecture and insert their implementation. The function developer subsequently exports an updated version of the architecture which will then also contain this implementation.

The architecture model is usually divided into a few different files in order to separate specific parts from general parts which are reused throughout the architecture. Adding to this are files containing implementations (the code) and all files will, in time, exist in different versions with dependencies between the files. In order to maintain low complexity, it is beneficial to have utility support for keeping track of file dependencies.

Integration

When an implementation is finished it must be integrated into the project. Through importing, an updated architecture is obtained with references to the implementation and the code itself.

Once all software components are connected to an implementation all functional code is available. This can be exploited through functional integration tests. The entire functional code may then be tested with a decoupling from hardware implementations such as drivers and an electrical interface. Read more on this subject in this process example for verification.

Integration is an iterative process of updated implementations.

Hardware distribution

A system can be an isolated controller or be distributed onto several physical controllers (Electronic Control Units – ECU’s). These ECU’s must be created and represented in the system description. The system is also described by the network topology facilitating communication between software components on the different ECU’s.

Finalisation

When the configuration is complete and implementations exist for all software components, it remains to generate code for the configuration and connect this to the operating system.

Subsequently, residual tasks comprise compilation and downloading of the application and parameter set; however, the code is now complete.

Menu