At the beginning of 2007, the AUTOSAR development partnership defined, in its Release 2.1, a practice-tested software architecture that is used as a foundation for the development of reusable applications. With the publication of these specifications, in the future it will be possible for all companies belonging to the AUTOSAR development partnership to develop AUTOSAR-conformant components. However, the practical implementation of these specifications is not trivial. The transition from individual to standard software has to be well-planned and is certainly only conceivable if a stepwise approach is taken. The AUTOSAR philosophy and description language create a diverse environment for using standardised software. In practice, this may be a mixed installation of AUTOSAR and non-AUTOSAR components or an integration of basic software for specific platforms by a number of different software suppliers. For both types of implementation, it is necessary to clarify and define the relevant constraints from various perspectives.
Vehicle perspective
Basic and technological platforms are being developed with the OEMs' requirements in mind; the next generations of cars will be derived from these platforms. The underlying goal here is to integrate one and the same ECU in many vehicles and thereby reduce costs. At the same time, the quality and the stability of vehicle electronics should be improved. This results in a dilemma between the imponderables of a newly introduced technology and the stability of the product.
Architectural perspective
For use in an ECU, individual software components are discernible. At the same time, two contradictory approaches are being followed with regard to the base software of today's ECUs. On the one hand, many OEMs require specific software components or at least specify them. On the other hand, control-module producers are striving internally to always use the same architecture for a control-module platform. Added to this is the fact that the degree of standardisation of the software is not as comprehensive as described by AUTOSAR. The goal here is to apply a standard to software that does not serve the purpose of competitive differentiation, thereby creating space for new innovations. Optimally, low investment costs would be incurred by new tools, since those tools already in service can - for the most part - be reused.
Clear migration strategy
When these two perspectives are applied to a decision on introducing AUTOSAR, it makes sense to select a multistage approach. Stage I consists of setting up the architecture and expanding its use. The first step is to compare the existing custom software and the AUTOSAR architecture. After analysing overlaps and integration potentials, a decision is made regarding which modules will be preserved and which ones can be replaced by standard software. At this stage it is recommended that a separating layer be introduced between application software and base software, as well as a standardised interface. The RTE (run-time environment) serves as the link for the necessary data exchange, and as a buffer with a defined interface it enables modular programming without dependencies. This is how AUTOSAR components can be integrated without making additional changes to the custom and application software. The custom software is linked to the system architecture via an adaptation layer to enable data exchange with the AUTOSAR components via the RTE (Figure 1).
To minimise cost and effort and arrive at an optimal overall solution, it is helpful at this point to integrate the custom software in the configuration tools. In stage II, non-AUTOSAR components can now be replaced gradually by AUTOSAR ones without putting the overall architecture at risk or requiring reprogramming of other modules. The goal is to set up an AUTOSAR architecture and to use the appropriate tools. After the initial individual ECUs, the entire vehicle is conceptualised with AUTOSAR software, from system design to integration.
AUTOSAR architecture in ECUs
Essential parts of the individual software can also be reused in the framework of an AUTOSAR architecture (Figure 2). They are then linked to the application via an adaptation layer to form a complex device driver. An overlap matrix shows the portions in which AUTOSAR software can be introduced without great risk. Primarily, the memory section and the IO-hardware abstraction can be migrated smoothly. Cluster-memory management in particular has very clear and easy-to-use interfaces that enable its early migration to new ECUs. In communication and diagnostics, on the other hand, there are considerable overlaps between proprietary vehicle software and the standard modules of the AUTOSAR basic software. In the interest of stability in the vehicle, a more conservative approach is required here. Many OEMs utilise platform ECUs, in which existing software modules are transferred to new vehicle models. One implication is that the network and communications strategy cannot be changed in the short term. In the case of an immediate migration, ECU calibration and off-board diagnostics would also need to be adapted, which in practice would lead to significant problems. Therefore, the simplest path is to use the existing communication stack in the AUTOSAR environment, too. This stack can be linked to the RTE via an adaptation layer.
Easy migration path
Solutions such as Vector’s XCP protocol can be integrated in a migration architecture, so that existing measurement and calibration tools, such as CANape, can be used. The described technique is not a pure top-down approach, since in many cases, AUTOSAR software can even be integrated on lower hardware-related layers. Its modular structure and defined interfaces help in implementing the standard software on the SPAL level without affecting the upper layers. This offers an enormous advantage with regard to reuse. Vector utilises the concept of product clustering: based on AUTOSAR specifications, the products offered range over a number of layers and provide total solutions for memory, communication, diagnostic and system areas. These are independently functioning areas, some of which can also be implemented without AUTOSAR architecture. Cluster memory for example can be integrated quickly and easily in many ECU applications.
Support by tools
An important pillar in the introduction of AUTOSAR relates to the tools. They must be able to operate the AUTOSAR interfaces, yet they must remain open to integration of third-party components. Above all, configuration tools should be able to master this challenge and also support the user in validation of the system configuration. The tool world servicing AUTOSAR can be subdivided into three categories: design, configuration and test/simulation. Above all, suitable test instruments are an essential component for successful development. An ECU operates as a part of a whole. Checking for and assuring consistency in the overall system requires a high-performance simulation tool. For example, Vector proposes comprehensive tool solutions such as the DaVinci Tool Suite, the MICROSAR Configuration Suite
(Figure 3) and CANoe; support in terms of project work and consultation complement the products offered.
Summary
When considered from different points of view, a stepwise introduction of the standard components defined by the AUTOSAR development partnership into an individual company's software architecture appears to be the path to follow. This approach guarantees quality and consistency, and there are proper tools to support this process. Moreover, gradual migration instead of an immediate total conversion leads to an overall AUTOSAR solution that minimises risks.
Figure 1: Early introduction of a uniform interface and RTE simplifies migration.
Figure 2: Integration of custom software in the AUTOSAR architecture.
Figure 3: Vector offers MICROSAR, which contains the entire range of
AUTOSAR-BSW including RTE.
