AUTOSAR Classic & Adaptive Made Easy with Model-Based Design

Hello everyone. Welcome to the webinar on AUTOSAR Classic and adaptive made easy with model-based design. So I am Shwetha Bhadravathi Patil, product manager for AUTOSAR Blockset at MathWorks. Here is our agenda I have for today. First, I'll give you an overview of AUTOSAR, then talk about Simulink for AUTOSAR Classic and the latest support we provide from AUTOSAR Blockset, then I'll talk about Simulink for AUTOSAR Adaptive.

Let me start providing you an overview of AUTOSAR. Over here, you can see the non-AUTOSAR and Classic AUTOSAR. As you see here in the non-AUTOSAR architecture, application software and basic software is tightly integrated. The layer looks pretty rigid. Application software is dependent on hardware, whereas in the AUTOSAR Classic, it has a layered architecture. 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 the horizontal layers. This reduces the development time and cost. The reuse of software also increases at OEM, as well as at the suppliers. This enhances quality and efficiency by reducing the time to market.

The Classic software architecture follows signal-based communication and statically allocated software components and supports monolithic updates to the ECUs. This is great for traditional automotive applications, including body-control modules, powertrain, and so forth. To satisfy the needs for highly autonomous driving applications, Adaptive AUTOSAR was introduced by the AUTOSAR organization. It leverages more computing power and meets the demand for scalability and easy updates. Adaptive AUTOSAR is created based on a new paradigm of service-oriented architecture, in which the applications are realized composing the services available in the system.

So with this concept, the applications can dynamically reconfigure themselves based on new and updated services to meet scalability and easy updates. The good news is with Simulink, you can design your software once, then configure and deploy it to many targets  following multiple architectures. The important point about this is the developers can start from the legacy model and configure it for Classic or Adaptive architectures instead of starting from scratch every time.

You can also migrate the existing components to new architectures through using existing workflows. So with Simulink, you can design, deploy, and simulate your models to legacy ECUs to an AUTOSAR Classic or Adaptive applications or to FPGAs and GPUs for demanding applications such as motor control and autonomous driving applications. AUTOSAR Classic is very popular, and it is already on the road. We are providing Classic AUTOSAR support from past 10 years for production purposes.

So in this slide, I have compiled a list of user articles and presentations from our AUTOSAR customers. FCA describes their complete development process from requirements to modeling and code generation in Simulink up to in-vehicle testing for AUTOSAR software. So BMW, one of the founding members of AUTOSAR consortium, talks about using model-based development and AUTOSAR in an agile workflow with continuous integration.

John Deere provides an interesting talk about how they used AUTOSAR and model-based design to deal with challenges of complex agricultural machinery. LG Chem and Magneti Marelli discuss developing AUTOSAR software in context of standard compliance for ISO 26262 and A-SPICE. Finally, IDNEO provides a different perspective of using AUTOSAR tool chain for development of complex device drivers. They have reported 70% faster development time and discovered 80% of the errors in the design phase instead in hardware testing.

OK, now let me talk about Simulink for AUTOSAR Classic. Here, we see a zoomed-in representation of the AUTOSAR Classic architecture. The application layer contains the algorithm part of the software, which is divided into software components. All the communication between software components and basic software is routed through the RTE over standardized interfaces. In this way, the RTE acts like a virtual function bus.

Simulink is used by our customers for modeling and code generation of application software. If you're using an AUTOSAR authoring tool for architecture definition, you can import or export the software description files or ARXML files in Simulink. From the release 2019b, you can use System Composer to create composition models directly in Simulink environment and have a version of architecture model which is tightly integrated with Simulink implementation. So we will discuss this in more detail later. So lastly with AUTOSAR Blockset, you can simulate basic software services. So in this way, you can simulate functional behavior of application software calling basic software services directly in Simulink.

OK, now I will show you how to convert a non-AUTOSAR model to an AUTOSAR model. So here, I have a simple Simulink model I would like to convert direct to AUTOSAR. For that, I'm going to launch an AUTOSAR component app. It will go to launch the quick start. And over here, you can choose the Component type. Create the model reference so you can map model to a software component.

Over here, you can create default based on Simulink model or import from an ARXML.

OK, the quick start tool has done the mapping. Now let me launch the code mappings, and you can see how these functions are mapped to runnables in AUTOSAR. And on the right side, you have an option to change the code properties. And here, you can see how Simulink ports are mapped to AUTOSAR elements. And again, over here, you can change the Communication attributes and so forth.

In the AUTOSAR dictionary, you can see how these receiver ports are configured and runnables are configured. You can click a runnable, and then change the [INAUDIBLE] event. So by default, it is set to TimingEvent. And there is one interrunnable variable. And this is how data elements are associated to send a receiver interface.

And over here, you can change the XML options, as per your need. Once you are happy with this, now you can go to the config parameter settings. And you can go to AUTOSAR code gen pane. Here, you can choose the schema you would like to generate code in an ARXML 4.

Now we are all set to do a code generation. Let me go ahead and Generate Code. OK, here you can see the code generation report is created. And with this in [INAUDIBLE] view, you can click on a generated code function. It will show in corresponding block. Or if you click on a Simulink block, it will show a corresponding code as well. And you can also view the generated ARXML files.

In this way, you can convert a non-AUTOSAR model to an AUTOSAR model. Now I'm going to talk about AUTOSAR workflows. If you already have an existing Simulink model, you can configure that for AUTOSAR directly in Simulink. Or you can also start from authoring your architecture in System Composer. So then link the AUTOSAR configured Simulink model to an architecture model in System Composer. Once you are happy with your development, you can generate code and ARXML using embedded coder. And this is called a bottom-up workflow.

On the other hand, if you start in an third-party authoring tool, you can export an ARXML, which can be imported into Simulink or in the System Composer. So this creates a pre-configured skeleton model in Simulink and an architecture model in System Composer where you just have to add the implementation. This is called top-down workflow.

The last workflow is a combination of the first two. If you are using an authoring tool, you can still make architectural changes with System Composer or Simulink. In this case, a generated ARXML file must be imported back to a third-party authoring tool to maintain consistency. This is called round tripping.

Here, I'll show you an demonstration of bottom-up workflow by creating AUTOSAR architectures in Simulink. I'll demonstrate the authoring to ARXML code generation by building a AUTOSAR compliant throttle position control system. So here are the component model implementations. For example, the controller model and throttle sensor model. Next, we can author an architecture by launching the Simulink start page.

So let me open the software architecture template. A new AUTOSAR architecture model opens. In this new Simulink tool strip, the Modeling tab supports common tasks for architecture modeling. Over here, the palette includes icons for software component, software composition, and for basic software modeling, including diagnostics and NvM service component to act with the model.

This purpose built editor is called Composition Editor. It provides a view of AUTOSAR software architecture based on the AUTOSAR virtual function bus. Now let me clear the default content from the window so that I can construct a new composition. Since we have a bunch of sensor components, let me create a sub-composition architecture for sensors. Inside sensors, we can add a component and call it probably TPS_Primary.

Notice there are options to create a new Simulink model for this component. You can link to an existing Simulink model and create a component from an ARXML. Here, we will link to a AUTOSAR_Throttle_sensor1 model. Notice the badge on the component changes to reflect component kind specified by the Simulink model. Similarly, we will add the rest of the sensor components and connect them up.

The Composition Editor reuses all the great things you like about Simulink's intuitive editing capabilities. It automatically reduces line clutters as you wire your connections.

OK, now that we have assembled our composition hierarchy, we can update the model to flush out any integration issues. All good to go here. We will now save our model and call it myTPC under composition. You can use the same extension as any regular Simulink model.

Now that we have created our composition, I'll show you an integration with Simulink requirements. Let me open the Requirements Manager app. It opens the Requirement tab so that we can open requirement set. Notice that it contains four of the throttle position control application components. To link in AUTOSAR component to a requirement, we can drag the requirement from the browser to the component block.

Now the natural next step in the workflow is to apply the V and V by simulating the composition. For that, we will turn on Function Connectors to visualize the function calls that the component models may be calling. The throttle sensor model calls in to demining NvM service functions and also diagnostics function. To simulate, let me add the reference implementation for both diagnostics and NvM service component blocks.

Let's update the model again. OK, now we can configure the IDs for the client ports. The next thing, I would like to connect the composition inputs and outputs to the real stimulus data. I have our test on this model with a throttle body plant and pedal input. We'll add a model block and reference TPC composition and then connect inputs and outputs.

Now I will schedule all the entry point runnables for my composition components using the Schedule Editor. I can visualize and control the order of execution of the runnable. Looks great. Now let me hit play to make sure your algorithm is conforming to your requirements. It looks cool.

Now let me generate AUTOSAR code for the components and export the whole composition ARXML. Now with composition, one usually is dealing with the number of components and therefore, a number of generated artifacts. So here, we have made it easy for you to collect all these artifact so you are ready with the next step in the workflow, which is likely to integrate without the external environment.

So this has started to build the component models one by one and show progress on this viewer. Notice that there are six components where it is building component by component. And now it is creating composition ARXML as well. OK, there are two subfolders called ARXML and source. So in the ARXML folder, each AUTOSAR component has component and implementation description files, while the architecture model has composition, data type, and interface description files.

And in the source folder, you'll see code for each components. In this way, you can create architecture model for compositions and then generate code. So furthermore, you can try this example using this live script available in the documentation.

Now let me show you a demo of top-down workflow. I'll start by importing composition descriptions. The process of importing a composition to the architecture should be familiar to those of you used to the component importer. But here are our important composition description and System Composer where we had created architecture models in the previous demo.

So here is an ARXML that is created in a third-party tool. Notice that it's created for 4.2.2. I can create a new architecture model and object using this API. So does that API I'd opened an architecture template. So here, I'll go to Modeling tab. And then use this Import from ARXML option.

So this imported app will ask you to choose the ARXML you would like to import. And you can configure modeling options if you want. And this imported app is creating an skeleton architecture model. Notice that it's creating architecture model for all the five components.

OK, so this is a architecture model. Let me go ahead and look at the modeling settings. And let me go to Code Generation pane. Yeah, it has imported in schema 4.2. And in this composition model, in this component, you can scale it down to add a Simulink model. And also you can see a logo represents the component type. Now after you add your logic, it is ready to export code in ARXML.

To summarize, in the demo, we had imported an ARXML using this option. Additionally, you can also use this importFromARXML API to import this composition descriptions into our architecture model. And again, this example is also available as a live script demo. You can try this to understand more about this feature.

Now let me talk about AUTOSAR timing extensions specification. As you are aware that the complexity of automotive issues are growing as it includes two to three cores, probably 15 to 20 tasks, hundreds of RTE event to task relationships. Some tasks may be mapped to 50 to 60 runnables events. So the integration becomes an essential and crucial task, allocate tasks to cores.

Therefore, AUTOSAR introduced a concept called timing extensions to provide timing requirements that guide the construction of systems and to analyze and validate the temporal behavior of a system. Here, you can see there are number of runnables mapping to tasks and then to a code. At the same time, it is important to preserve the functional behavior and timely execution.

The question here is what order shall the runnables be executed? So how do you know what order you have evaluated or simulated this model? It is hard to tell with the data dependency. Let me try this to figure out how the execution order affect the end result. Here, our port is connected to a scope to check the end results. If runnable R1 executes before runnable R2, you would get a graph like this. But if I flip the execution order, the result would change. The delay is completely different with different values.

Our customers mentioned this information is very important. So we exported the execution order for further use. So here, I have an example to show how we support execution order constraints in Simulink. So here, there is a Simulink model, which has multiple runnable. And you can see its execution order can be viewed in the Schedule Editor. And I'm changing the execution order by just dragging and dropping. Now I'll go on to validate and then generate code. And you can see the execution order constraint in this ARXML.

To summarize, in the release 20b, we supported the importing and exporting of execution order constraints, including the Schedule Editor modification to runnable and execution order and to ARXML files and update an AUTOSAR component model with ARXML changes to execution order constraints as well. To summarize, with AUTOSAR Blockset, you can model and simulate AUTOSAR Classic software, and you can adopt multiple design workflows for importing, updating, and exporting software description files, including its timing extensions. And then you can author AUTOSAR compositions in System Composer and import and export composition ARXML files and generate optimized C code for production purposes.

So I would like to mention that AUTOSAR Blockset can be used on every stage of the development cycle. You can link models with requirements and model your software on a composition, component, and subcomponent level. And also, you can verify your design through simulation and tune your software. This includes simulation of AUTOSAR basic software services.

Generate C code from your components. Verification workflows using SIL and PIL are Simulink tests to ensure sufficient coverage of your algorithms. We also generate ARXML, including composition ARXML, and package it up to take onwards to the next elements in a tool chain. Example, an RTE generator.

Then with using embedded code and an AUTOSAR Blockset, you can generate AUTOSAR code for applications up to ASIL D. The IEC certification kit helps you streamline your ISO 26262 development process. It contains the mapping between the tables in ISO 26262 and the corresponding model-based design tools such as back-to-back tests that can be performed, also engineering AUTOSAR compliant code.

OK, now let me talk about Simulink for AUTOSAR Adaptive. The layers of Adaptive are similar to Classic in that there are components, runtime, basic services, and hardware. Perhaps the biggest difference between Adaptive and Classic is that application called the public interfaces of the foundation are services directly, so the API service area is much larger.

Perhaps it is useful to note that Adaptive is not necessarily running on bare metal, but could be running on a virtual machine. Here also MathWorks tools are used for modeling code generation of adaptive applications. I'm going to go through some of the key concepts for Adaptive.

Now for key concept one, the OS provides multiprocess POSIX OS capability. Then each adaptive application is an OS process on its own, with its own main function, logical memory space, and name space. Now if you look at process management, the OS also provides process scheduling. The Execution Manager provides process life-cycle management, starting, running, terminating processes. The Communication Manager provides interprocess communication.

Now for key concept two, the use of service-oriented interprocess communication. If you look at IPC between processes, IPC can be local over the Communication Manager or over a network, again via the Communication Manager. Now if you look at the type of communication, Classic has sender receiver client server. Adaptive has service oriented, which can be broken down into methods-- it's more like functions-- communication via events-- think like messages-- and communication over fields-- think like data. So far, we support modeling of events in the form of messages in Simulink.

The third key concept is that everything is C++. All modules and applications need to be written in C++. Those were the three key concepts for AUTOSAR Adaptive. So this is the AUTOSAR Adaptive road map. We are now onto the fourth version of the standard. I am pleased to say that MathWorks started to support Adaptive standard from the release 2019a.

Over the next few slides, I'll take those Adaptive concepts and show you how to model and generate code for an Adaptive application in Simulink. An adaptive application has required and provided ports, which are typed by a service interface as we discussed. In Simulink, an adaptive application would map to a model. A required port events would map to a message in Simulink. Here, I'm converting a message to a signal using shipping AUTOSAR blocks for this application.

On the provided port side, this is very similar. Again, an adaptive application maps to a model, even would map to an out port. Now I will show you how the adaptive workflows can be done in Simulink. You can also import or export an adaptive ARXML file into Simulink like we do in the Classic ARXML workflow.

Can start with Simulink model, and you can convert that Simulink model to AUTOSAR Adaptive by using their data dictionary. Then once you are happy with your design, you can generate code and then ARXML. And this is called bottom-up workflow. Or you can start from authoring your architecture for adaptive application, then export that ARXML, and then import that into Simulink. And that's called top-down workflow. Iterating between the top-down and bottom-up workflow is called round tripping.

Now let's see that in action. So here, I have an ARXML, created in an authoring tool. Now I would like to import that into Simulink using these two lines of code. OK, now this has created an skeleton adaptive Simulink model. Notice that the in ports and out ports are created. So now let me look at the code mappings. Notice how the Simulink in ports are mapped to AUTOSAR properties and how these required ports are configured.

Here, the Service Discovery Mode is set to OneTime. I can switch that to dynamic discovery. Then the corresponding Service Interface has the imported events and name spaces. And here are the XML options you can choose. Now in the Code Mappings Editor, we see which Simulink port is mapped to which AUTOSAR event.

Now let's go to the Settings. Notice that the System target file set to AUTOSAR Adaptive and language is set to C++. Here, you can see the schema of the imported ARXML. I'll just keep the same schema for code generation. OK, now let me add the example implementation to the lane guidance skeleton model.

OK, now let me go ahead and generate our code in ARXML. So in the generated code, it has ARA calls at the corresponding places. We can see application, manifest, and service manifest ARXML files also being generated.

As you just saw in the demo, you can configure your applications to either use one-time service discovery or dynamic service discovery mode. In one-time discovery, applications find and subscribe to adaptive services one time during the initialization. One-time discovery may require adaptive services to start before applications and prevent applications from using new services as they become available.

With the release 2020a, you can also use dynamic service discovery so it monitors service availability in the background and subscribes to adaptive services as they become available. This leads to a more robust system. And in the release 2020b, as part of the adaptive code generation, you can create an executable for a run-time calibration on your Linux host machine. You can run the executable as a standalone application as well.

The adaptive AUTOSAR Linux executable tool chain provides AUTOSAR Adaptive functional cluster libraries for compiling the generated code. Using the ASAP2 Generator app, you can configure your ASAP2 file generation to specify an ASAP2 file version. You can choose to exclude or include comments upon the A2L file generation as well.

In summary, with AUTOSAR Blockset, you can model, simulate, and test AUTOSAR Adaptive software by modeling adaptive applications with event communication and dynamic service discovery. You can also import and export adaptive ARXML files. And finally, you can generate optimized AUTOSAR C++ code for code generation.

All right, now it is your time to build your AUTOSAR application algorithm in Simulink. To get started, you can try these shipping examples and also explore the latest features with support from AUTOSAR Blockset. To learn more about AUTOSAR support, you can visit our AUTOSAR Blockset page on MathWorks.com. Thank you for listening.