How to Simulate and Test Heterogeneous AUTOSAR Software Compositions in Simulink - MATLAB
Video Player is loading.
Current Time 0:00
Duration 20:24
Loaded: 0.80%
Stream Type LIVE
Remaining Time 20:24
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 20:24

    How to Simulate and Test Heterogeneous AUTOSAR Software Compositions in Simulink

    Martin Römpert, Senior Expert, Model-Based Development, Autonomous Mobility and Safety Division, Continental Automotive

    In our software at Continental Automotive, we have nearly 1,000 AUTOSAR software components (SWCs). These are a combination of handwritten C-code SWCs and Model-Based Design SWCs.

    As we decided to use Model-Based Design as the standard development method for all AUTOSAR SWCs, we set up a project called Modular Software. The goal is to use one unified toolchain to develop and test both types of AUTOSAR SWCs.

    In this talk, we describe how to simulate and test complex AUTOSAR software compositions that contain Model-Based Design and handwritten SWCs using one unified, ASPICE-conformal tooling.

    We bring handwritten AUTOSAR SWCs and software compositions together into the Simulink® environment, simulate it using software-in-the-loop mode and test the system using Simulink Test™.

    As we bring the handwritten code into Simulink and set up the software testing using Simulink Test, we facilitate the transition from handwritten code to Model-Based Design, identify software integration issues, and enable software testing early in the process, reducing time and costs

    Published: 4 Jun 2024

    Welcome to the presentation, How to Simulate and Test Heterogeneous AUTOSAR Software Compositions in Simulink.

    Let's have a short look at the agenda for the next 20 minutes. We will start with a brief introduction of the Continental Automotive Technologies GmbH. After that, I'll describe the motivation to introduce the two workflows that are sketched in the solution part of this agenda-- in detail, handwritten AUTOSAR component simulation and unit testing and heterogeneous AUTOSAR software composition simulation and integration testing.

    In the next step, we describe how these two solutions can create synergies using Process Advisor. The end of the talk will be a conclusion and an outlook.

    Most of you will think about tires if they hear Continental. Continental Automotive Technologies is an OEM. So these products are not for end customers but for car manufacturers. As you can see, we develop products for autonomous mobility, interior, and safety and motion.

    Within safety and motion, we have the areas dynamics and comfort, passive and integrated safety, and the area I belong to is brakes-- in detail, the electronic brake systems. To get an idea of what we produce, on the bottom right, you can see our actual second-generation one-box brake system, MK C2.

    As you may imagine, the software that is part of a brake system became more and more complex over the last decade. Moreover, there's the need to provide software as a product for integration into high-performance computers or central control units.

    The context of the introduction of Process Advisor, or the CI/CD automation for Simulink Check, was a Continental internal project called Modular Software. The idea was to introduce separate Git repositories for interfaces, software components, and software compositions, each repository with its own Process Advisor-based CI/CD pipeline. This is shown on the left. The key aspects are the granularity and the multilevel integration.

    We introduced the Process Advisor workflow for model-based software components. But we soon realized that a lot of our approximately 1,000 software components that are today handwritten C code need to be handled too. Due to a lack of resources to convert the handwritten software components into model-based design, we had to find an efficient way to handle C code.

    We thought about bringing handwritten software components into the Simulink environment, too, to facilitate a long-term transition from handwritten C code to model-based development. Pardon. Based off this idea, we defined the following goals for our next steps.

    We want to use similar workflows for all software components, enable the simulation and unit test of handwritten software components within Simulink, simulate and test heterogeneous software composition, and heterogeneous means software compositions that are assembled out of handwritten and model-based software components. And we want to use a common toolchain for these heterogeneous software compositions. These goals should help us to transition from software as a part of a brake system to brake system software as part as product by introducing more flexibility and reusability.

    For IP protection reasons, the following demo is based on MathWorks examples and does not show our internal models. Let's first have a look at the environment we are using for this demonstration. As you can see, we are using MATLAB 24a, update 2.

    To handle handwritten software components and compositions, we need to install the AUTOSAR Software Component Importer Toolbox, developed by Ulrich Wahner and Amrish Karchuli, from MathWorks. Here, you can see the Getting Started documentation of this toolbox. This provides detailed descriptions of the functionality provided.

    As mentioned, this demo is based on two MathWorks examples. The first example, Design and Simulate AUTOSAR Components and Generated Code, shows a Simulink representation of an AUTOSAR software composition with detailed behavior. Here, you can see the software component and software composition implementations in Simulink.

    The second example, Import AUTOSAR Composition into AUTOSAR-- into Architecture Model, shows how to import an AUTOSAR software composition ARXML into an AUTOSAR architecture model. If you use the detailed behavior of the first example as implementation of the software components of the second example, you get an AUTOSAR software composition that allows you to export it as a whole by pushing the Export button for AUTOSAR software compositions.

    The results are the generated C, H, and ARXML files you can see here on the left. Now we take some of these generated files and simply state that these are handwritten software components. Here, we copied the needed ARXML, C, and H files into a new folder and created a simple MATLAB script to import this handwritten software component into a Simulink model.

    As you can see, the script calls the toolbox command AUTOSAR software component create to create a Simulink model and a Simulink data dictionary.

    As arguments, you provide the ARXML file list. The name of the component to be imported. The name of the Simulink model that should be created. The name of the C source files. The directories where the header files are stored. If needed, additional defines that should be used in the C code.

    How the runnable should be modeled-- in our case, as atomic subsystem. If bus element ports should be used as I/O, which is true here. The name of the Simulink data dictionary that should be created. And finally, if the model should be opened automatically after creation.

    The second command in this script is a Simulink test standard command that creates a test harness for this model. It has a signal, a block as input, a scope block as output, and the verification mode is set to SIL. Let's run this script now.

    As you can see, the Simulink model and the Simulink data dictionary are created. And the Command window shows what happened in the background.

    The generated model contains the following elements-- the controller initialize block, an atomic subsystem for each AUTOSAR runnable, and the software component description block. You can see that the dialog of this block shows exactly the same information that were provided to the AUTOSAR software composition create command as input arguments.

    Let's look at the runnable implementation. As you may have expected, this is a dummy only. A block was added to allow SIL/PIL simulations only. So we would get an error message if we would click the Run button. Then let's use the SIL/PIL Manager app to run a SIL simulation.

    You can see that the executables are built. And the SIL simulations are executed for the handwritten parts. So goal achieved. Simulation of handwritten software components is working now.

    You may remember that the second command in our script created a test harness for the software component. Let's see if this can be executed too. As expected, this harness can be simulated too. So we can start to open a test manager and implement the unit tests for this software component.

    Goal achieved. Unit testing of handwritten software components is working now. So let me clean up a little bit after the simulation is finished.

    After we imported a software component and added a test harness for later use in a Simulink Test Manager, you may ask yourself, but what happens if the C code changes? Let me open a slightly enhanced version of the harness we just created. The signal editor block was modified to provide some inputs other than zero. And signal logging was activated.

    We will run now two simulations and change the controller C file between the runs. Of course, changes to the H and even the ARXML files are possible too. If the ARXML file changes, you have to rebuild the software component using the Recreate Software Component Model button in the software component description block I just showed.

    Now that the simulation is finished, I simply change the gain value in the controller C file and start a second simulation. After the second simulation is finished too, we can see different outputs in the Simulation Data Inspector.

    Let me clean up a little bit. Now let's have a look how this works in context of an existing AUTOSAR software composition. We simply add a software component and choose Create Component Model from ARXML. We specify the ARXML files and import them using the ARXML importer behind the scenes.

    After that, we select the component and define the C and H files. As soon as the software component is created, we are able to connect the ports. So let me again clean up a little bit.

    We will now open a slightly modified version of this software composition. So what did we change? A profile was added to show all handwritten software components in red and all model-based software components in green.

    Multiple test harnesses were added to the software components and the software composition. And the Test Manager file was created to run unit and integration tests. So let's run the tests now. Goal achieved. Simulation and test of heterogeneous software compositions is working now.

    Now that all tests are executed, you can see that you have a mixture of MIL and SIL simulations as well as different model and code coverages. As always, you can navigate the results, generate reports, dig into the coverage details, and visualize the logged signals.

    As the last part of this demo, I want to show how to export the whole heterogeneous software composition. We navigate to the Modeling tab and simply run Generate Code and ARXML. We select an output folder and choose to create a zip file.

    The export takes some time, even I speeded it up a little bit. As you will see, the generated zip file contains all the C, H, and ARXML files needed for the software composition.

    Now that we've seen the workflow in detail, how is this related to Process Advisor and the workflows that have been defined for the model-based software development so far? Process Advisor is based on tasks that have input artifacts, output artifacts, and assessments as sketched up on the upper right. As we have the tasks for the model-based workflows defined already and bring the handwritten C code into Simulink models and architecture models too, we are able to reuse some tasks for the handwritten parts.

    Tasks like SIL/PIL tests, including coverage, memory profiling, and runtime profiling can be reused as well as the policy-based analysis tasks. In addition, we can reuse our self-written tasks for Conan2, package import, package creation, and package upload to JFrog Artifactory.

    To sum it up, simulation of heterogeneous AUTOSAR software compositions is possible. We are able to simulate the communication between handwritten and model-based software components, including interfaces like client/server, sender/receiver, inter-runnable variables, and per instance memory, or shared parameters. Multiple instances of model-based and handwritten component-- software components are possible within software compositions.

    Unit testing and integration testing are possible using Simulink Test. We can debug handwritten software components and software compositions during simulation or test execution using Microsoft Visual Studio Code. We are able to use System Composer as powerful cosimulation environment. And we have a simplified Process Advisor workflow due to reusable tasks. By focusing on partial integration, together with high-quality integration tests, we should be able to discover more issues in the early development cycle and save costs.

    So what's next? We plan the direct import of mixed or heterogeneous software compositions so that no manual steps are needed. The support of AUTOSAR variant management is on the agenda too. In a final step, the alignment between the model-based and handwritten workflows needs to be finished in detail, as shown on the slide.

    Last but not least, we want to continue the successful strategic partnership between Continental and MathWorks. And this leads me to the end of my talk. Thank you for your attention. And now it's time for Q&A.

    [APPLAUSE]

    View more related videos