Develop AUTOSAR Classic & Adaptive Applications with Model-Based Design
Overview
Model-Based Design affords many advantages over traditional development by offering high-level design abstractions and automatic generation of production code. Modeling and code generation for AUTOSAR software components lets you automate the process of specifying and synchronizing lengthy identifiers in designs, code, and description files.
Join us to learn about Simulink Advance Support for AUTOSAR features modeling AUTOSAR Classic and Adaptive Software applications, Authoring AUTOSAR software architectures and interfaces, Simulating AUTOSAR compositions and ECUs, and C/ C++ production code generation.
A MathWorks engineer will provide a brief overview of the latest AUTOSAR standards including Classic and Adaptive Platforms, provide product demonstrations showing how you can use Simulink, AUTOSAR Blockset and Embedded Coder to design, simulate, verify, and generate code for AUTOSAR application software components.
Highlights
- Simulink for AUTOSAR Classic
- Simulink for Adaptive Platform
- Authoring Software Architectures and Interfaces
- Production C and C++ code generation
About the Presenter
Shwetha Bhadravathi Patil is a Product Manager at MathWorks, working on AUTOSAR, DDS and code generation products. Prior to MathWorks, Shwetha worked as an embedded software engineer for Delphi Automotive on AUTOSAR based projects and worked as a technical marketing engineer at Analog Devices Inc.
Recorded: 13 Dec 2022
Hello, everyone. I'm Shwetha, product manager at MathWorks focused on AUTOSAR Blockset. Today I am going to talk about MathWorks support for both AUTOSAR Classic and Adaptive platform that enables you to move smoothly through model-based design all the way from requirements to deployment.
First I'm going to give you a high-level overview of AUTOSAR. AUTOSAR stands for AUTomotive Open-System ARchitecture. Let me explain by identifying the difference between AUTOSAR and non-AUTOSAR architecture. As you see here, in the non-AUTOSAR architecture, the application basic software is tightly integrated. The layout looks rigid and the application software is dependent on the hardware, whereas the AUTOSAR Classic has a layered architecture. So this will provide a clear division of hardware-dependent and standard software versus the higher-level application features. Effectively hardware and software will be widely independent of each other and the software will have increased modularity and transferability of features. Consequently development can be decoupled by horizontal layers, and this reduces development time and cost. The use of software increases at OEM as well as at suppliers. This enhances quality and efficiency while reducing time to market. So the Classic architecture follows signal-based communication, statically allocates software components, and only supports monolithic updates to the ECU.
This is great for traditional automotive applications like body control modules, powertrain, and so forth. But to satisfy the needs for highly autonomous driving type applications AUTOSAR R introduced AUTOSAR Adaptive standard a few years ago. So it leverages more computing power and meets the demand for scalability, as well as easy updates. So this AUTOSAR Adaptive is created based on a new paradigm of service-oriented architecture, in which the applications are realized composing the services available in the system. With this concept, the applications can dynamically reconfigure themselves based on new and updated services to meet this scalability and easy updates. So in a future car, you can see all non-AUTOSAR, AUTOSAR Classic, as well as Adaptive ECUs. So this new Adaptive standard will continue to coexist with AUTOSAR Classic as well as non-AUTOSAR architectures which are available in the market.
OK. Now we've learned about AUTOSAR, now we are going to talk about how Simulink can be used to develop your AUTOSAR Classic as well as Adaptive applications. First, let me get started with AUTOSAR Classic. So AUTOSAR Classic is already on the road. And it is very popular. We are providing AUTOSAR Classic support for more than 10 years for production purposes.
On this slide, I have compiled some interesting technical articles and presentations from our AUTOSAR customers. So here you can see FCA describes the complete development process, from requirements to modeling and code generation, in Simulink up to in-vehicle testing for AUTOSAR software. Then Ford, who was one of the founding members of AUTOSAR consortium, talks about using model-based design for their development of AUTOSAR software applications. Then A123 Systems, who is a battery maker, talks about CI within a model-based workflow for AUTOSAR development. LG Chem and Magneti Morelli discuss developing AUTOSAR software in the context of standard compliance for ISO 26262 and A-SPICE. Then finally IDNEO provides a different perspective of using MathWorks AUTOSAR Toolchain for the development of complex device drivers. They reported a 70% faster development time and discovered 80% of errors in their design phase instead of in hardware testing.
OK. Now let us take a look at some common design workflows followed by AUTOSAR Classic customers. Say if you already have an existing Simulink model. That could be a legacy model and you can convert that into AUTOSAR right in Simulink using AUTOSAR dictionary. Or if you want to get an architectural view of it, you can use System Composer along with AUTOSAR Blockset and then create an architecture model. And then you can link that architecture model to your Simulink model. So from there, you can directly generate code using Embedded Coder. So it will also generate ARXML simultaneously. And this is called as Bottom-Up Workflow.
Or on the other hand, if you want to start in a third-party authoring tool, you can start from an architecture and then create an architecture that exports an ARXML file, which then can be imported right into Simulink. So whether you can import that into System Composer, that will create an architecture model, or it can import directly into Simulink as well. So from there, again, it's the same process. As it has already created an architecture model you can just develop your algorithm then generate code and ARXML simultaneously. And this is called top-down workflow. And the combination of this workflow is called round-tripping. And furthermore, you can perform software-in-the-loop and processor-in-the-loop testing on the generated code for the verification purposes.
OK. Now let me focus on how to design the AUTOSAR software in System Composer. Some of you are probably familiar with how to create a new architecture model in Simulink. So from the Simulink stack page, we offer a few out-of-the-box templates for the appropriate architecture or domain one of them is the AUTOSAR Architecture model template, which is the AUTOSAR platform profile, built in and already configured for you to get started. Now, let's zoom in and have a closer look at this.
So this template provides a purpose-built canvas and resources for developing AUTOSAR composition and components. This editor understands the AUTOSAR platform, so we ensure that what you draw and author in this editor is supported for the AUTOSAR domain. So you can create components and composition of hierarchy, including ports and connections. Then you can author ports, interfaces-- which I will show in our demo later. And then you can author runnables. This will also be shown in a demo later. Then you can link or create models to implement internal behavior. So once we are done, we can simulate the architecture model.
Then we also offer basic software reference implementation blocks, to enable you to click the Play button. These BSW blocks implement calls from the application layer. So finally when we are done with the simulation and verification, we can configure XML options to generate code and ARXML for the whole hierarchy, including exporting timing extensions and optionally an ECU extract. The output of this file is a ZIP file with source code and ARXML that can be imported into an RT-generated tool.
As you can see in this, the AUTOSAR Architecture model is more than an authoring tool. It offers a complete end-to-end workflow using model-based design. And I would like to highlight that authoring interfaces and runnables using this function editor are the latest features which we had introduced in the release 22b.
Now before I show you the feature, let's recap on what's in AUTOSAR port interfaces by looking at the anatomy of the ARXML descriptions. There is this interface kind and some properties that are structure-capturing interface elements. Then the interface elements are properties. They also have a reference to data types, which could be an app or an implementation type. Well, how do you model this in Simulink today? Well, we sort of can. We can create a Simulink bus to represent the interface, then create the structure, capture the elements, configure design data.
But I still need to capture the AUTOSAR side of things. As you know, we have an AUTOSAR dictionary that you can use for that. But today I have to manage the information in two different places and keep them in sync. This does not really scale well when I have 10 models that I need to share this info. So you might be thinking, someone surely at MathWorks is looking at this. Indeed, I would like to share this with you, the feature shipped in 22b. That's Interface Editor.
We call this as Interface Dictionary. It is an SLDD file, purpose-built for authoring and managing this non-graphical aspect of system design, which is shared definitions of interfaces' data types across Simulink System Composer and deployment across multiple platforms. So I'll show this in action.
This is our popular throttle position control authoring architecture demo. So here I've created an interfaces.sldd file. Underneath, using this Interface Editor, I've added an interface and its properties. And then I'm adding in its data types, adding min and max value, and in the Properties, you can choose that particular value type.
So once you add all the interfaces, it is ready to export and ARXML file. So I'm just exporting ARXML from the architecture model. Now I'm going back to the Interface Dictionary view. Here you can see all the interfaces associated with this example. And it is throwing an error that the interface name mismatch. OK. I updated it. And now I'm linking this architecture model to a Simulink model. So inside the Simulink model, it has created under-skeleton ports. And once you are ideologic, you can generate code for this. So this creates an ZIP file. And then under that, you have two folders, as you see, one folder for source file, and another folder is for ARXML, which has ARXML for both compositions as well as components.
So I have another demo. And I would like to show you how we are leveraging the functionalities where you can add un-periodic runnable as well as periodic runnables. As you see here, under the software component I have added two runnables, Runnable1 and 2. And then I'm creating a Simulink model from this architecture model. And notice that it has two runnables. OK. And I have launched the component quickstart tool to take a look at these two runnables. And that is attached to TimingEvent, which is a periodic runnable. So in this way you can create your runnables right in the architecture model using the Function Editor and link it to a Simulink model or create a new Simulink model.
We have made a lot of progress in this area of authoring architectures recently. I would like to highlight some key features which is released in 22b. One is the ability to use Profiles and Stereotypes interface adoption. Then parameter authoring for top-down creation of parameters and specify their values from the architecture. And all the features which you have seen just now is also released in 22b.
All right. Now I'll switch gears a little bit to the middle-stage implementation. We offer support for AUTOSAR Simulink as a seamless extension of the Simulink environment. So we are doing this by making continuous improvements every release, by adding new features, and supporting enhancements in the wider Simulink environment. As you saw, we are improving the AUTOSAR authoring capabilities and round-tripping workflows. So we offer a comprehensive set of tools to model an AUTOSAR software component in Simulink. We support a number of modeling styles, rate-based execution, exported functions, asynchronous and triggered runnables, and a combination thereof. And then ports can be defined to describe communication with other components. And we support sender-receiver for signals, client-server for function calls, mode-switch triggers, and also NV interfaces for the exchange of nonvolatile data.
We support AUTOSAR variants as an extension of the ancient modeling built into Simulink. This applies to ports, runnables, dimensions, values, and much more. And then lastly, I have listed internal data. This is the support for the data inside your implementation. We support parameters, lookup tables. inter-runnable variables, PerInstanceMemory, and other calibratable memory, then finally Constant and StaticMemory.
OK. Now let me talk about the latest schema versions we support. So we are keeping up to date with the schemas released by the AUTOSAR org. We are supporting the AUTOSAR Classic schema R20-11 from the release 22b.
So in AUTOSAR Blockset, we offer a range of blocks to make modeling easier. To start with, we support basic software by offering caller blocks, making it easy to call into these services from a component, as well as service component to support simulation. Then we support the Diagnostic Event Manager, to send and query diagnostic events, then the Function Inhibition Manager to inhibit functionality within your component based on your diagnostics reporting, and the NvM Manager, to control the access to nonvolatile memory. We provide a set of blocks to support the IFX and IFL interpolation and lookup library. Then we have a block for signal invalidation. This is an AUTOSAR concept that is not present in Simulink. So we provide a block for it. And then we have added two blocks to support message-based communication, mainly for AUTOSAR Adaptive, which is Event Send and Event Receive. I'll explain this in the upcoming slide. Then in the release 22a, we have added two new blocks to our basic software library supporting test invalidation workflows, Dem Status Inject and Dem Status Override. You can use this as a tool for gaining coverage on AUTOSAR components which are making calls into basic software.
Now I'm going to show you an example of Override and Inject diagnostic statuses from the Test Harness. I can find that by opening the Simulink start page and going to the Examples tab and then looking for AUTOSAR Blockset examples. I can save you all and then go down the list to find for basic software examples. And this is the one I'm looking for. This is the Throttle Position Monitor Component. It takes input from a primary and secondary sensor. There are four calls into basic software, to if/or each sensor to see if each sensor is stuck too high or low. If the primary sensor is failing, we switch to the secondary sensor. If both are failing, we use another caller to report a monitor more general failure for this component. And the component itself outputs a default value.
In order to check the coverage of this component, I can use the Coverage Analyzer app. I can enable the tool and Simulink to analyze the coverage. All right. We can see here, we don't have full coverage yet. This is due to the basic software callers, which currently output default values. Now this is my Test Harness model. The component we looked at before is in this top right model. I have an AUTOSAR Diagnostic Service Component block, which shows those five basic software client ports which are associated with unique IDs. We can focus on the first one.
Here I have our Dem Status Override block, which is associated with the same EventId. I am using it to override the test fail, but with the value provided by an input port signal. This is the one which the get fail caller block in the component model is monitoring. I also have control over the other bits of the audio status, if I want to enhance.
OK. I have set up some test conditions to permute through these true and false values for these four callers, to gain full coverage. Now I can see that, after running the coverage analysis of these conditions, I see that I have full coverage of my component. So this is a review of how to gain coverage on another component, which is making software calls by overwriting bits of the UDS status.
Now let's move on to variants. Variants are supported by Simulink natively, and your modeling style does not need to change when working on an AUTOSAR target. Variant subsystem sources and things will directly translate to AUTOSAR during co-generation. You will see these blocks when importing ARXML that defines variations. In this case, data access of this component is behind a variant source. And AUTOSAR defines a lot of binding times, allowing variation to occur throughout the MBD process. We support three of these, CodeGenerationTime, preCompileTime, and PostBuild. Which map to Simulink variation activation times update diagram, code compile, and startup, which is supported from the release 22a. So then these variants will appear naturally in the generated code. As you would expect, there is no branching for the CodeGenerationTime, Binding Time, as only the active path will appear. And at preCompileTime, a pre-processor statement will branch the code. And at PostBuild, the condition is resolved via an Rte call. All of these variation approaches are supported for SIL, enabling validation workflows on the generated code.
And then we have comprehensive support for ARXML generation. You'll see variation points on any elements affected by variation, as well as variation point proxies generated from the condition. Then we'll also export system constants and value sets based on the configuration of the workspace. Then PostBuild variation has slightly different set of tags for PostBuild variant criterias and conditions which we support, alongside the other variation definitions.
So to summarize, we provide capabilities and blocks to model, simulate, AUTOSAR Classic application as well as ECU software, where the basic software services a block. And you saw that we support multiple adaptable design workflows for import, update, and export AUTOSAR description files, too, including their extensions. And then you saw a demo about how do we author AUTOSAR compositions, components with its interfaces, data types, profiles, and stereotypes in System Composer as well as AUTOSAR Blockset. And finally you can generate optimized C production-quality code.
So I can say that AUTOSAR Blockset are available on every stage of the development cycle. So you can verify your design through simulation and tuner software. This includes simulation of AUTOSAR basic software services, and then generate C code from your components, verification workflows using SIL/PIL, or Simulink test to ensure sufficient coverage of your algorithms, then finally generate ARXML, including composition ARXML, and package it up to take on what strict next elements in a Toolchain example like an RT generator.
All right. Now let me talk about how you can use Simulink for developing your AUTOSAR Adaptive applications. Here I'm focusing on AUTOSAR Adaptive, which is used for autonomous driving, vehicle-to-vehicle communication, and so forth. AUTOSAR Adaptive is an emerging and evolving standard to design service-oriented applications for automotive industry. It implements the AUTOSAR Runtime for Adaptive Applications, which is called as ARA, which is very similar to RT Runtime Environment and AUTOSAR Classic.
So for connectivity, AUTOSAR Adaptive allows a consistent communication between multiple software platforms, like AUTOSAR Classic, ROS, GENIVI, Automotive Grade Linux, which use automotive communications like SOME/IP, DDS, rest. So it brings features like over-the-air update, dynamic reconfiguration of services on runtime, and support for higher computing powers and data rates in automotive software. All modules and applications need to be written in C++.
So how do you plug such a AUTOSAR Adaptive applications in the Simulink environment? Or how do I plug your Simulink SOA models into AUTOSAR Adaptive platform? So let's get into a little more detail on how you can develop your AUTOSAR Adaptive platform in Simulink.
So in Simulink, you can design your software once, then to configure and deploy to many targets following multiple architectures. The developers can start from the legacy model and configure it for either AUTOSAR Classic or Adaptive architecture, instead of starting from scratch every time. So you can also migrate their existing components to newer architectures, reusing existing workflows. But Simulink, you can design, simulate, and deploy your models all the way from legacy ECUs to AUTOSAR Classic or Adaptive applications or the FPGAs and GPUs for demanding applications, such as motor control and autonomous driving.
So with Simulink and AUTOSAR Blockset, as well as Embedded Coder, you can model and generate C++ code for the AUTOSAR Adaptive applications. So Elektrobit has used our tools to develop their driver monitoring system, which is based on the AUTOSAR Adaptive standard, where they were able to accelerate the development of their end-to-end AUTOSAR Adaptive software system. So there is a nice user article here. I would encourage you to go through this and see how this project has been done.
Now let's take a look at the type of communication used in the AUTOSAR Adaptive. It uses service-oriented communication, whereas in AUTOSAR Classic, it uses sender-receiver, client-server type communication. In AUTOSAR Adaptive, it uses service-oriented communication, which consists of Service Interface that can contain events, methods, or fields. Methods allow a subscriber to issue remote procedure calls, which are executed on provider side Request/Response method, which can make asynchronous or synchronous calls. There is method Fire/Forget feature, that makes a feature to request the server, but does not receive any response from the server. This can be useful when you have a specific task on the server. In addition, if it is difficult to request data from the server each time, there is even feature that periodically sends data to the server without requesting a separate request by requesting to the server only once.
Then there is field feature, which you can think of it as a method that combines the method feature and event feature. Fields are a combination of one or more of the three. One is Notify, which sends data on change from the provider to the subscriber, or a Getter, which can be called by the subscriber to explicitly query the provider for the value. Or it can be a Setter, which can be called by the subscriber when it wants to change the value on the provider side.
Now we will see how these Adaptive concepts are mapped to Simulink. So an Adaptive application can have Required and ProvidedPorts, which are typed by a service interface. As we discussed, the service interfaces could be events, methods, or fields. So in Simulink, an Adaptive application would map to a model, like an entire model. Then a RequiredPort event would map to a message in Simulink. Here, I'm converting a message to a signal using this event RSU block, and then processing the signal, and then again converting the output signal back into messages using event send block for further processing. And these two blocks are shipped with the AUTOSAR Blockset. And then this event port maps to Simulink import.
Similarly on the ProvidedPort side, again Adaptive Application maps to a model. And event would map to an out port. This modeling of event communication is done using polling mechanism. So this maps well into use case, when event sender and receiver applications follow a periodic schedule. For sporadic events, Simulink supports the modeling of event-triggered execution. So here, the executions happens when the receiver is invoked when an event has arrived. So with this approach, it saves some computing resources in the absence of events. As you can see on the right, it can be modeled using a route in port and a message-triggered subsystem. On the generated code, you can observe the event getting Subscribe in a model initialize function and registering a SetReceiveHandler that is executed on event arrival.
So we also support modeling of Adaptive methods in Simulink for both Request-Response and Fire and Forget. Here, the BrakeLightManager provides the service implementation of two methods, that's GetBrakeLights and SetBrakeLights. This can be realized in Simulink Canvas by using a function element port and corresponding Simulink functions. So BrakingSystem uses function element port and function-caller block to realize the method client behavior. And in the generated code for client, after the method is called in the required port, the client blocks on GetResult API to extract the method output. So once the method is serviced by the server, this API unblocks, and client can retrieve the method output for further use.
So while there are valid use cases for blocking methods, they introduce delay for any other logic of the client that is not dependent on the method outcome. So such a delay can be avoided by opting to a synchronous method, where client makes the method call and then registers a callback to process the method output. While the method is still executing at the server, the client processes other non-independent logic. So in the release 22b, we support modeling of asynchronous methods in Simulink. Users can model this using function ports, function caller blocks, and message-triggered subsystem. The function caller emits a message line that shows the response subsystem is triggered asynchronously. And in the generated code, you can see that after the method call, the client registers a callback. And this callback executes when the server completes the method request, and extracts the method output, and calls the response subsystem.
So this slide summarizes the supported semantics for AUTOSAR Adaptive. So we have started out support with events in 2019a for Polling mode, and then added event-triggered execution in 22a, as you saw in the previous slides. And we have added methods support to model client-server communication in 22a for synchronous semantics and asynchronous semantics in 22b. Then added support for ARA port, that's persistency, in the release 21b, where the persistency offers mechanisms to Adaptive applications, to store information in the nonvolatile memory of a machine. So this data is available over boot and ignition cycles. So we help to configure the persistence reports and interfaces using the AUTOSAR Adaptive Dictionary. And further, you can generate C++ code for accessing persistency via our app or APIs. And this will also support import and export ARXML files that describing persistent supports and interfaces.
So the AUTOSAR Adaptive Standard evolution has come through successive releases. So we are keeping our tools up to date with the latest and greatest schema releases, as you see in this table. As the standard is moving, so does our support, that you can rely on AUTOSAR Blockset to stay compatible with other tools in your Toolchain. The latest work we support is R20-11 from our latest release, 22b.
Now let's take a peek at the AUTOSAR Adaptive workflow. So this workflow is very similar to AUTOSAR Classic workflow. So here you can import, R export, and adapt the ARXML and also do round-tripping. So starting with Simulink model that could be a legacy model, convert your legacy model to AUTOSAR Adaptive, then generate ARXML file as well as C++ code. That's bottom-up. Or you can start from an architecture tool, export in ARXML, and then import that back into Simulink, which will create a skeleton model. Then add in your logic, generate code, and ARXML. And this is top-down workflow. And the combination of this is round-tripping.
All right. Now let's move on to the AUTOSAR deployment support, mainly for Adaptive application. So we introduced a new Embedded Coder Support Package for Linux. So that is support package help to deploy and calibrate your AUTOSAR Adaptive applications on Linux, which will help you to start, stop, or suspend any applications in the PC environment, and then tune the parameters and measure the signals in the Simulink Data Inspector. Finally you can view the log generated from the applications.
So this brings us to the summary of AUTOSAR Adaptive. So so far, I showed features that are related to AUTOSAR Adaptive which help you model, simulate, and test your software. You saw that you can model both events and methods-based Adaptive applications in Simulink. And furthermore we also support import, export, as well as the round-tripping of Adaptive ARXML with Simulink. With the Embedded Coder Support Package for Linux applications, you can achieve AUTOSAR Adaptive deployment. And finally you can generate optimized AUTOSAR C++ code for production purposes.
So I'd like to end this webinar with a few resources for you to try after this session. We provide a full suite of demos. That's Examples, which is available in AUTOSAR Blockset documentation. And also you can go over here, click on Videos, and then you can access all this AUTOSAR Blockset demo example videos, and also past webinars and an overview of what we support.
So recently we attended the AUTOSAR Open Conference, where we presented a paper on interoperability between AUTOSAR Adaptive. DDS, and ROS over the DDS network. And then we also presented a demo of how to develop and integrate AUTOSAR Classic and Adaptive applications, based on SOME/IP at Embedded World. So I would definitely encourage you to go through this and understand how you can achieve interoperability across multiple middle-ware platforms.
All right. This brings us to the end of this webinar. So if you want to learn more about AUTOSAR Blockset, I would encourage you to visit MathWorks website. We have a dedicated page, which talks about how you can develop AUTOSAR-based applications in Simulink. So I have left the link on this page.
And that's all I have for today. Thanks for listening.