With TargetLink into the Adaptive Future of Model-Based Development

Adaptive AUTOSAR, the new standard of the AUTOSAR Consortium, is intended to cover a wide range of applications, including autonomous driving and networked cars. This will be achieved by means of a service-oriented architecture, among other things. This type of architecture, however, changes some fundamental development paradigms. Whereas in Classic AUTOSAR, all specifications and the architecture were defined in advance, Adaptive AUTOSAR focuses on the flexibility and adaptability of the functions. In addition to these fundamental changes to software architecture in general, model-based development is also facing some changes. For example, how can you represent a service-oriented architecture in MATLAB®/Simulink® or dSPACE TargetLink? And how can you test these applications, which can be dynamically loaded and unloaded, at all? These very detailed and technical questions show that the new world of Adaptive AUTOSAR development still holds some challenges. I also believe that our customers strongly differ in their approaches, methods, and uncertainties regarding the use of Adaptive AUTOSAR. So we all still have a long way to go.

All Roads Lead to Rome: The dSPACE Approach to Adaptive AUTOSAR

Dynamic environments such as this particularly require a systematic approach. At dSPACE, we work towards a solution from several angles. For example, we are part of an Adaptive AUTOSAR working group: the Working Group Adaptive Platform Demonstrator (WG-AP-DI). This group is responsible for delivering the AUTOSAR Adaptive Platform Demonstrator and improving the quality of the demonstrator requirements. It is also in charge of the integration environment and testing of the Adaptive Platform Demonstrator code. As in the Classic AUTOSAR field, the work in this group does advance the standard, but it also helps our customers, as we can directly incorporate the experience gained from the working groups and the discussions with our colleagues and customers into our products and workflows.

In SystemDesk and VEOS, for example, this is done for the modeling of Adaptive AUTOSAR applications, the creation of Adaptive AUTOSAR V-ECUs as well as their validation in offline simulations. The release of TargetLink 5.0 gives developers the first options for model-based development of Adaptive AUTOSAR in their familiar development environment and lets them generate Adaptive AUTOSAR code for the first time.

Adaptive AUTOSAR and TargetLink

The current focus of the TargetLink implementation is to create individual functions of Adaptive AUTOSAR software in TargetLink and generate code for the controller. At the moment, some tasks are the user’s responsibility. Specifically, this means that a TargetLink developer can create a function in Adaptive AUTOSAR in TargetLink very much like a Classic AUTOSAR runnable. These individual Adaptive AUTOSAR functions are combined in a common main function after creation.

The manifest and the required ARXML files also require manual integration with the Adaptive AUTOSAR middleware. The Adaptive AUTOSAR applications can ultimately be executed on the ECU only after integration with the middleware.

To overcome all obstacles, small and large, in the introduction of Adaptive AUTOSAR, we offer interim Releases for TargetLink Adaptive AUTOSAR Support several times a year. This way, we try to reduce the volatility of the standard and our customers’ uncertainty regarding the individual features. This also gives our customers the opportunity to participate directly in product development and influence the implementation of Adaptive AUTOSAR in TargetLink. Discussing workflows and the entire development process with our customers is helpful as well, because the standard is work in progress, even in terms of processes.

Model-Based Development and Service-Oriented Architecture – How Does That Work?

So far, in the development of ECU software, e.g., in Classic AUTOSAR, the communication of individual functions and of software in general has been based on well-defined and static access to memory areas. This static approach is completely abandoned with Adaptive AUTOSAR. As described above, Adaptive AUTOSAR is based on a service-oriented architecture. Individual applications have predefined interfaces as in the Classic AUTOSAR context. However, when an application requests a service on the software server, these interfaces request information from or send information to the software server. This means that higher-level functions have to be provided only at one central point; the particular implementation is carried out in the client. This loose interface-based binding of the application software to the service allows for the dynamic loading and unloading of applications (Explanation of Adaptive Platform Design - SOA). It is clear that this type of architecture still raises many open questions and poses problems. By providing interim Releases and keeping in close contact with our customers, we try to analyze and solve them together.

In principle, however, the TargetLink model and the TargetLink Data Dictionary can be used to represent the service-oriented access of services. In the Data Dictionary, the specifications of the Adaptive AUTOSAR model are stored and used in the model at the appropriate point. Currently, developers can avail of the events, methods, and fields communication kinds of the ara::com functional cluster, which are important for model-based software development. The current prerelease of TargetLink Adaptive AUTOSAR now includes support for the next functional cluster, the Persistency Cluster, of the Adaptive AUTOSAR middleware.

This cluster in particular could become very important for many applications in the long term. The basic idea behind it is accessing information in persistent memory, i.e., in non-volatile memory (Explanation of Adaptive Platform Design - Persistency). This information is available even after several boot or start cycles. In TargetLink, access via the Persistency Cluster is modeled using data store memory blocks. This is similar to modeling NVRAM access in Classic AUTOSAR.

However, supporting certain functional clusters is merely the first step in Adaptive AUTOSAR.

(#ifndef __SIL__ …

… #endif)

After all, the way I see it, the classic rules of testing will remain the same for Adaptive AUTOSAR. In this respect, I expect that at least the functionality modeled in TargetLink will be tested by means of a classic MIL/SIL test to check whether the function does what it is supposed to. At this point, of course, MIL simulation is simple as it uses the Simulink functionality. The SIL part is much more complex because it actually requires Adaptive AUTOSAR middleware. However, I personally do not think communication with the middleware is crucial for the functionality of the TargetLink function. Therefore, we do not communicate with it and ‘bend’ the Adaptive AUTOSAR calls with preprocessor macros so that the calls are executed in the background, independently of Adaptive AUTOSAR.

But this is not the end of the story about validated software. After all, our customers and dSPACE are about to face another paradigm shift.

In addition to the ideas for validating individual parts of the software functions on the host PC that we have already put forward in the TargetLink environment, we have to make a range of fundamental decisions about the tool chain for us to take the next steps in validation. After all, to be able to test more than just parts of a function, the individual functions must be combined into an Adaptive AUTOSAR application, as described above. However, the application has to be tested with the middleware, which runs on a native POSIX operating system. In most cases, Linux is used. This requires a change of thinking not only for a single test, but for the entire tool chain. The important question: How do we get to the application to be tested while taking into account the operating system and middleware? We need an entirely new build environment and have to collect as well as configure new, different artifacts. All this on Linux. This requires a universal solution, from the development of the ECU functionality and its validation to the final ECU. We are also facing this challenge head on, and are grateful to have found collaborators in some of our customers.

Still, we have already taken another step: We have deliberated what it means to test an entire Adaptive AUTOSAR application and its interaction with the middleware. We believe that this requires one or several complete Adaptive AUTOSAR applications, which are then used to build an Adaptive AUTOSAR V-ECU. The V-ECU can then be conveniently tested in VEOS using Adaptive AUTOSAR middleware. Our colleagues from the VEOS team have already written a blog entry on the process.

Strength in Unity

We are currently working on this interface to the middleware with our partners to achieve joint technical solutions and offer our customers the best solution available.

In keeping with the dSPACE promise "Your Partner in Simulation and Validation", we aim to enter a new era alongside our customers by introducing Adaptive AUTOSAR. Be a part of this journey and get in touch with us to talk about Adaptive AUTOSAR in your development scenario or, better yet, become part of the TargetLink Adaptive AUTOSAR beta program.