loader image

Test Solutions for Simulink Models & Production Code

Virtual Validation for ADAS/AD

How can I create the needed millions of scenarios?

How can I avoid the test explosion problem?

How can I find out if my tests are passed or failed?

Products

Test Solutions for Simulink Models & Production Code

Virtual Validation for ADAS/AD

How can I create the needed millions of scenarios?

How can I avoid the test explosion problem?

How can I find out if my tests are passed or failed?

Blog

AUTOSAR – What is the Best Approach to Handle Reusable Code?

Nabile Khoury

Paris, France

Component reuse is a common use case in any type of software and this is particularly true in automotive applications. Consider the equipment in the cars such as wheels, seats, doors, lights, clutches (e.g., in a dual-clutch transmission), and so on. They are controlled by software and as they exist by pairs, it makes sense to repeat their control algorithm. Indeed, the code can be developed once, instantiated as many times as needed and parametrized. This contributes to an efficient usage of the ROM memory. In this blog article, we will present three options to handle AUTOSAR reusable code.

First of all, I want to give a warm thank to Hriday Ranjan, Modeling Lead at Ford Motor Company in the United States who inspired me writing this blog article. His team develops AUTOSAR software components in model-based which contains reusable code. They use BTC EmbeddedPlatform to test the software. We discussed three possible approaches to develop reusable code as well as their pro and cons arguments. I’m happy to summarize our discussion outcomes as follow:  

Approach #1: Define a multi-instance Software Component in the AUTOSAR (Classic) architecture.

To reuse code in several components of the same type, AUTOSAR provides a multi-instance concept for the Software Components. For example, an Application Software Component of a window lifter can implement the functionality and be instantiated four times in the ECU for the respective windows. In the AUTOSAR description, this is specified with the attribute SUPPORTS-MULTIPLE-INSTANTIATION of the component “Internal Behavior”. The instantiated components share the same code but separate memory (RAM) for the internal states. The internal states are typically handled as AUTOSAR PerInstanceMemory (PIM). When coding the function manually, the developer shall take care of a proper management of the PIMs. In model-based development, the code generator automatically converts the state variables into PerInstanceMemories.

The port interfaces (e.g., sender/receiver) of the component instances have to access instance specific data. Therefore, the runnable functions as well as the RTE API calls use an additional function argument to manage the instance specific data.

With this approach, the entire software component is reusable. The “reusability” is specified in the AUTOSAR description and the RTE takes care of the implementation and handling of the instances. However, we should keep some challenges in mind: Shifting the definition of all repeatable code at the component level could increase the number of software components and complicate the AUTOSAR architecture work. The internal states of the algorithms have to be managed via PerInstanceMemories which either have to be anticipated or fed back to the AUTOSAR ARXMLs after the component implementation. Testing the component requires to handle the additional instance specific parameters of the runnable and the RTE functions.

Approach #2: Use AUTOSAR Client/Server interface to define the reusable code a Server function and call it in many Clients.

A Client/Server (C/S) communication is a mechanism based on function definition and function call. A Client/Server interface can define reusable code as an Operation (function) carried by the interface. The operation can have as many input and output variables as needed, configured as Operation arguments. A Server component (the provider of the reusable code) can reference the C/S interface and implement the function. The server component can have additional calibration parameters if needed. Then, several Client components can reference the C/S interface to call the operation. In the example of the window lifter, this would result in:

  • 1 server component implementing the reusable code as a server function
  • 4 client components (one for each door) calling the server function.
 

With this second approach, the “reusable” component is defined (again) in the AUTOSAR description and the relationship with the client components is established via the C/S interface. The RTE manages the integration between the server and the client components. During the development, the server component can be implemented and tested once. The implementation of the client components includes the call to the server operation and can add additional client-specific functionally around the call when this is needed. Testing the client component requires that a stub implementation of the server is part of the simulation environment. Depending on the development environment, this is more or less easily handled. The biggest challenge with this C/S approach is the management of internal states. The server function cannot manage the states for the clients. Therefore, if this is required, state variables have to be handled in the client implementation and exchanged with the server function using arguments of the type “INOUT”.

Approach #3: Manage the reusable code as a traditional non-AUTOSAR reusable C-code

In this scenario, we consider that the Application Software Component is implementing the reusable code as a subfunction. The subfunction is defined as a regular C function called inside the component. With the window lifter example, a single software component can control the four windows by calling the same subfunction four times.

In model-based environment such as dSPACE TargetLink or Mathworks Embedded Coder, this is supported with Reusable Subsystems. The configuration starts by defining a library block configured to generate a reusable function. Several information can be configured such as the function name, the function input/output arguments and the definition files. Then, the block is instantiated as many times as needed in the component model. 

The management of internal states is much more easier. In fact, during code generation, the state variables of each instance are automatically combined in a structure and passed as pointer argument to the reusable function. The developer effort to manage internal states is almost null compared to the first two AUTOSAR mechanisms. Calibration parameters can be defined in the reusable function or if they are specific to each instance, they can be passed as function arguments.

The traditional non-AUTOSAR reusable code can even be extended to share the code across several software components. This simply requires to manage a modular and independent file structure. The reusable subsystem can declare the function in a specific header file which gets included in each component source file and define the function in its own c-file. While generating code for each component, the reusable subsystem files could be regenerated each time but since their content would be identical (coming from the same library block), only one set of the files can be kept and archived for the final integration. An alternative workflow could be to generate the reusable function from a separate model and the software component models integrate it as external code.

In general, the traditional non-AUTOSAR reusable code is very flexible. The downside is that it cannot be specified with native AUTOSAR elements. Plus, we have to be aware of potential naming conflicts which are normally avoided by the AUTOSAR naming scheme for functions and variables when using native AUTOSAR mechanisms.

The component model has to be designed with the inner reusable subsystems in mind. For practical simplicity, I can recommend to start developing the model as if there was only on instance of the reusable subsystem and once the algorithm is matured, convert it as a library and create the other instances. During testing, unit test can be conducted on one instance of the reusable function and, to test the behavior of the all instances combined, an integration test can be performed on the component level.

Conclusion

In conclusion, several approaches are available to address reusable code in AUTOSAR components. From an approach which is fully handled in AUTOSAR with the multi-instance concept to the one where the reusable function is managed with traditional methods inside the development environment, the project can decide which one fits the best. Configuring everything in AUTOSAR reinforces the architecture definition but reduces the flexibility since any architecture change requires updating the overall AUTOSAR description, plus the management of internal states is a challenge. The traditional method is more flexible but this actually depends on how flexible the development environment can manage the modularity and the independencies between the shared source files.

Thank you again Hriday Ranjan for the interesting discussions!

Nabile Khoury

Paris, France

Senior Application Engineer

Nabile Khoury studied Electronics and Computer Science at the University “Conservatoire National des Arts et Métiers” in Paris. From 2010 to 2016, he worked in automotive companies, mainly in the powertrain department of the French car maker PSA Peugeot Citroën, as software engineer specialized in Model-Based Development involving AUTOSAR and ISO 26262 compliant processes. He then joined BTC Embedded Systems AG where he currently works as a Lead Application Engineer - Autonomous Driving in Paris/France.    

Connect on LinkedIn

Popular Videos

Play Video
Play Video

Request Evaluation License

If you would like to try out our tools, we will gladly provide an evaluation license free of chargeEvaluations include a free launch workshop and also provide an opportunity for you to meet one-on-one with our support and engineering teams.

Schedule a Meeting

Do you have any questions or want to see our tools in action? If so, please use the link below to schedule a meeting, where a member of our engineering team will be happy to show you the features and use cases and directly answer any questions you might have.

Events

Join upcoming Webinar

Join our newsletter

Your email address will be submitted to the privacy-certified newsletter software CleverReach for technical distribution. For further information go to our privacy policy.

Videos

Discover some of the main features of our products in these short videos.