Arxml Files and Software Components

Micael Coutinho, • autosarapplicationarxml
Back

Arxml is the most common file type found in an Autosar. Learn how to create them here

During the past articles, you may have seen us throwing around some Arxml snippets around. We even created our own, in the article How to Create Arxml for Software Components (opens in a new tab). That said, we never got around to explaining in detail why they are so useful in the Autosar environment.

Firstly, Autosar praises itself on being extremely modular, and Arxml is on the heart of this modularity. Imagine a world where your Software Component (if you want a better overview on what is a Software Component, pelase check our article Types of Software Components (opens in a new tab)) is merely a bundle of .h and .c files. Either your development teams are incredible, and everything is aligned with your Tier-1's to Tier-N's, and you have a seamless way to integrate everything (by this point, you realise how ludacris this is) or your software integrators will have nightmares.

The solution for a hassle-free integration of an Autosar environment is mostly through interfaces (to learn about Autosar interfaces, please consult the article Types of Interfaces and Ports (opens in a new tab)).

So, imagine the case of a Software Component. The integrator will not care what are the source files (for the most part, because not everything is perfect, but this is only 5% of the time), and will only connect everything in the Arxml to the Autosar environment. That's it.

That sounds very simple. As we said, it usually is. The steps involved, although dependent on the Autosar environment you're using, can be summed up as such:

  1. Import the Arxml files into the Autosar environment
  2. Connect the SW-C to the other components, creating the necessary service ports in the BSW modules (for example, diagnostics. We already covered some diagnostics-related BSW modules in the article What are DEM, DLT, DCM and DET (opens in a new tab)), mapping the signals to the COM stack
  3. Map the component to a partition and its runnables to the RTE
  4. Generate the code
  5. Add the module source code to the makefile and compile

Obviously, this is a very superficial kind of integration. There can be more to it, depending on the necessities of the component. Some of these necessities can be the safety concept, specific memory mappings (to learn about memory mapping, you can check our article Memory Mapping (opens in a new tab)), and configuration of other BSW modules for the required functionality. And if it's a Complex Device Driver, well, that's a completely different story.

As we wrap this up, the key takeaways you should extract from this article are the importance of Arxml files and their role in Software Component integration.

Author: Micael Coutinho (opens in a new tab)

References:

© AutosarToday —@LinkedIn