How to Leverage Model Based Development for Delivering AUTOSAR Software Components

The ‘coveted’ standardization in the development of automotive software has been greatly facilitated by AUTOSAR. This made the automotive industry to embrace AUTOSAR Architecture with open arms..

And rightly so!

AUTOSAR follows an open software architecture. This enables OEMs, Suppliers, Product Engineering Service Providers to collaborate on projects without worrying too much about the underlying hardware platform.

For instance, as per the AUTOSAR Architecture, a software component is implemented in the Application layer that has an interface with a standard Run Time Environment (RTE) and not directly with the ECU Hardware.

Such software components of the AUTOSAR Architecture (like RTE, BSW and MCAL) that are developed as plug and play modules, can be deployed across different projects.

In certain projects, the AUTOSAR development team may need to design an additional component called the Complex Device Drivers (CDD).

At times, there are certain non-AUTOSAR software components (components not compliant to AUTOSAR Architecture) that need to be added to the control unit.

Or, a few hardware components such as Real Time Clock, I/O Expander or H-Bridge are required to be interfaced with the ECU hardware.

In such scenarios, CDDs are developed for each of the software or hardware components so that they can communicate directly with the microcontroller ( by by-passing the RTE and BSW modules).

In this pursuit of standardization, the most dependable approach to software and CDD development is the Model Based Development paradigm.

While the AUTOSAR Authoring tools like Da Vinci Developer helps the automotive engineers to create software architecture, the MBD tools (SIMULINK) are deployed to model the behavior and interfaces defined in the architecture.

The most compelling reason for leveraging the Model Driven Development approach ( MBD), is its well-established workflow and availability of robust and industry-proven tools (MATLAB-SIMULINK).

Also, SIMULINK has a native support for AUTOSAR and there is no need for creating AUTOSAR-specific models separately. SIMULINK along with Embedded Coder tool also provides seamless support for development of an AUTOSAR compliant software.

Based on what you have read so far in this blog, you must have realized that Model Based Design and AUTOSAR go along very well.

But the ‘devil lies in the details’!

So, let’s dig a little deeper to understand the intricacies.

Understanding the Importance of Workflow in AUTOSAR Compliant Model Based Development

When AUTOSAR and Model Based Development work in tandem, there are several tools involved. And there is a lot of cross-functional flow of data as well.

Therefore, compatibility between these tools such as SIMULINK (MBD) and Da Vinci Developer (AUTOSAR Authoring tool) must be seamless.

As these development processes are iterative, compatibility between the tools is a must-have. Therefore, understanding the workflow becomes of great importance.

The diagram below will help you understand the flow better:

Source: MathWorks
As shown in the diagram, following is the flow of data:

• Software Architecture is created in AUTOSAR authoring tool w.r.t software components that are required to be developed.
• As per the AUTOSAR software architecture, the Software component description files are exported through AUTOSAR XML file format, called the .arxml
• These files are imported to modelling tools. ( most popularly used modelling tool is the SIMULINK tool from MATHWORKS).
• Functional behavior of the software component is modelled and tested in SIMULINK tool.
• Finally, the tested model is used to create code using E-Coder (code generation tool)
• Simultaneously with Production Code, updated Software Component Description files are generated. This is done to maintain consistency between the final artefacts, which are the software code (.C) and description files.
• Both these files are now integrated with the target hardware platform

Decoding the Top-Down, Bottom-up and Round-Trip Workflows

Development teams have choice of Different workflows for modelling of AUTOSAR software components.

A workflow can be chosen based on several factors; however, it is the specific project’s requirements that will help you to take the final decision.

Whichever workflow one chooses, it involves importing the SWC description file (arxml) to SIMULINK and generating the model and the code.

Let’s start with the Top down approach!

The Top Down Workflow generally starts with Software Component description file. The Following Steps are executed:

1. The Software Component architecture and interfaces are first defined in the AUTOSAR authoring tool viz Da Vinci Developer tool. Based on the architecture and interfaces, SWC description files (arxml format) are exported.
2. Next, the description files are imported to SIMULINK in order to create a skeleton model with interfaces exactly similar to the ones created in the Da Vinci tool. Alternatively, the ARXML file can also be imported to update an existing AUTOSAR model.
3. This skeleton model with all the integrated interfaces, forms the base for simulating the logic of the required application. Stateflow tool is used for this purpose.
4. An additional step to maintain traceability is performed using Requirement management tools like IBM DOORS. In this step, the model is matched with the requirements specified for the project.
5. Now, the simulations are run to check the design. Verifications are conducted using Test Cases; these test-cases are defined using Simulink Test tool. Additional verification is performed with Equivalence tests (SIL testing).
6. Once, the verification is done, MISRA C compliant code is generated from this Model (using Embedded Coder tool).

The next workflow that is widely used in Model Based Development of AUTOSAR components is Bottom Up workflow. The only difference in Bottom-up approach is that the modelling process starts with SIMULINK and later followed by the AUTOSAR Authoring tool.

Steps Involved in Bottom-Up Workflow:

1. AUTOSAR software component description from arxml files is imported into a new Simulink model.
2. The model is evolved and configured (based on application logic) to make it ready for AUTOSAR code generation. Verifications and Equivalence tests are performed.
3. E-Coder tool in SIMULINK environment is used to generate code. Alternatively, AUTOSAR component builder can also be used to create the AUTOSAR software component.
4. The code is then exported as C code and XML Description, which in turn is imported to AUTOSAR Authoring tool (Da Vinci etc.) for configuration.

The core part of the Round-Trio workflow is quite similar to the top-down approach and bottom-up workflow. The only difference is the point where the development starts.

A Round-trip workflow is a combination of Top-down and Bottom Up approach. Here, the flow starts from the AUTOSAR authoring tool (AAT), goes through SIMULINK, E Coder etc. and comes back to AAT.

A Stepwise breakdown of Round-Trip Workflow:

1. Previously specified AUTOSAR component with description file is imported to SIMULINK
2. Model is developed based on this file, by configuring the AUTOSAR elements, mapping the SIMULINK model to AUTOSAR component and validating the configuration.
3. C Code and newly generated description files are exported using the E Coder tool.
4. SIL and PIL testing is performed to verify the generated code.
5. The verified code and description file are now merged with other systems in AAT (Da Vinci developer tool etc.)
6. If there is any change in the description file, it can be imported back to SIMULINK and the model can be updated accordingly.

Value Adds of Using Model Based Development for AUTOSAR Software Components and CDDs

Whatever be the workflow, there are proven benefits of deploying MBD approach to AUTOSAR software development. We have listed a few here:

• Development time can be reduced to half as code is generated from the AUTOSAR model library of implementing any new or additional feature through software component or CDD, ensures great amount of flexibility for the developers.
• Projects that involve integration of existing AUTOSAR components to a larger system becomes simple due to .arxml files. It reduces the time by up to 70%.
• Due to continuous testing at every stage of development, 80% of the errors are identified at the design phase itself
• Ensuring ISO 26262 standard compliance becomes easier, as MBD tools have the required provisions.

Best Practices for AUTOSAR Modelling Using SIMULINK

AUTOSAR modelling using tools like SIMULINK comes with certain set of challenges and hence, following the industry-recognized best practices is a must.

Let’s talk about some of these best practices :.

• There should be a well-defined strategy and roadmap for migration of the existing SIMULINK models to the AUTOSAR This is to ensure that different teams working on the project use a uniform approach, common processes and tools.
• The workflow should be decided at the onset and the teams should stick to one workflow whether it is top-down, bottom-up or round-trip. Using different workflows in a single project can create ambiguities and cause unnecessary iterations and re-work.
• There is a lot of design data that changes hands during an AUTOSAR modelling project. Thus, the data management strategy is a crucial part of the process and should be defined properly.
• Modelling Standard needs to be established for both AUTOSAR and SIMULINK so that the models can be re-used and scaled up in future. It is also one of the pre-requisites of the ISO 26262 standard compliance
• ISO 26262 standard is almost a de facto standard in automotive industry and all your activities in AUTOSAR modelling projects should be aligned to it. Planning for functional safety from the very beginning is very important, as introducing it a later stage will only cause re-works.

Summary

Considering the several value-adds of using model-based development for AUTOSAR modelling, it is quite evident that they are a match made in heaven.

Even the MBD tools like SIMULINK are designed to natively support the AUTOSAR architecture. The flexibility of AUTOSAR architecture and robustness of the MBD paradigm are destined to become game-changers for software development in Automotive Industry.