Types of Software Components

Micael Coutinho, • autosarapplicationswc
Back

Kickstart your Autosar journey by learning which software components are available and where they suit your needs

As you come to the Autosar world, you notice the standard takes pride on giving you the right tool for each job. The same can be said for software components, as you have many types available at your disposal, each with its different quirks.

But first, a refresher: a SW-C is a block of software made to work in the Autosar stack. The block is reusable and communicates with the environment through ports (most of the time, more on that later). They can also be grouped together, as you will see later on.

So, here are the software components you will find while working on the Autosar stack:

So, the very basic type of component. It is considered an atomic unit that implements a functionality. It cannot be split any further and has to be assigned to a single ECU. It can contain ports, that make use of interfaces (you can learn more about ports and interfaces in our article Types of Interfaces and Ports (opens in a new tab)), to connect with other components, requiring or providing data or functionalities, contains some kind of internal behavior, where events can be used and mapped to the RTE (to learn more about Autosar Events, please consult our article Overview of Events (opens in a new tab)), along with making use of other functionalities, such as referencing memory sections to be used within the component (you can learn about memory mapping on Autosar in our article Memory Mapping (opens in a new tab)).

As the name implies, it's a specific kind of software component for dealing with sensors and actuators. It's usually sensor/actuator specific, but it is independent from the underlying ECU hardware. How is this achieved? You have another layer between your hardware to abstract the SW-C from the ECU internals. That component is usually a Complex Device Driver or an ECU Abstraction Software Component. Lastly, it follows more or less the same structure as the previous.

An aggregation of SW-C's, nothing else. It does not provide real functionality. It merely organizes the SW-C's in a neat way. Also, contrary to Application Software Components, the composite can be allocated to more than one ECU.

It's a different kind of component, as it does not contain any runnables or events or require ports. It merely contains provider ports for calibration parameters to be accessed in other Software Components (to learn more about calibration, you can consult the article Calibration Overview (opens in a new tab), where you will learn how this translates at the RTE level and the preferred alternative to calibrate in Autosar).

You have probably heard about the NvM module (Non-Volatile RAM Manager), which is a BSW module that allows you to configure non-volatile variables (values will persist when the ECU is powered off). This kind of SW-C allows you to access these blocks on the application layer. To learn more about NvM and the remainder of the memory stack, we recommend the article Autosar Memory Stack (coming soon).

It's a dirty way of making something work in Autosar. Technically, you can write the entire application functionality in a Complex Device Driver. Will you ever do it? Please, don't. It's destined for those functionalities that do not fit anywhere else. This kind of component is usually very specific to the underlying architecture (or needs some very specific functionality), and can interact directly with BSW modules through API calls, without needing ports. By definition, it generalizes the ECU-abstraction SW-C.

It does exactly what you read, abstracts the ECU. It can be regarded as a middle point between your MCAL (Microcontroller Abstraction Layer) and the application layer. It can also access BSW modules via API calls, just like a CDD. Both are located below the RTE, and are the only ones allowed to access the MCAL.

You might be wondering: how do I communicate with BSW modules? The short answer is always the same, ports, through the RTE. The long answer is: some BSW modules (specifically, on the service layer, so we are looking at BswM, EcuM, Dcm, Dem, and so on) will allow you to generate a Software Component with ports to either access or provide some functionality to the module. For example, a common functionality provided by the EcuM is a sender port with the current ECU mode.

Now that you know what are the kinds of Software Components you'll find and their place in the Autosar stack, I hope the stack can make more sense to you. Just remember, the stack is huge, so it's unlikely that you'll ever get to use all of them. Nonetheless, now that you know them, you are one step ahead when it comes to enhancing your stack knowledge. Lastly, a good follow-up would be learning from our article How to Create Software Components with Matlab (coming soon). See you there!

Author: Micael Coutinho (opens in a new tab)

References:

© AutosarToday —@LinkedIn