Autosar Application SWC and Its interfaces with RTE

Hello Readers,

My name is Rajesh M, and I work at Luxoft India as a Junior Software Developer. Luxoft has given me several opportunities to work on various projects, which has inspired me to learn the essential processes involved in developing AUTOSAR Modulеs and Add-Ons in Autosar Application SWC and Its interfaces with RTE.

Introduction

In AUTOSAR, the application is divided into different SWCs. A SWC or software component is a component that has application logic. In AUTOSAR, functions are encapsulated in SWC. For example, the use of an electric window in a car, for which a separate SWC fulfills this function. SWCs communicate with each other or access lower layers using RTE.

AUTOSAR has categorized SWCs based on its use into following types:

Application SWC: This is normal SWC which has only application or part of it.

Sensor Actuator SWC: This is a special type of SWC that deals with sensors or actuators.

Parameter SWC: This SWC is used to share calibration parameters to external devices. Unlike an Application SWC or SensorActuator SWC, these SWCs have no internal workings.

Composition SWC: Composition is nothing but a group of SWCs which is assigned to a single ECU during System Configuration. Such grouping helps in abstracting the SWCs and standardizing software development that is what AUTOSAR aims for. This grouping is logical, that is, no memory is used for such a grouping.

Service Proxy SWC: It will act as a proxy to provide internal services to one or more remote ECUs. Its main use is to share vehicle status information with the entire system.

Service SWC: It provides services defined by BSW module AUTOSAR.

ECU Abstraction SWC: This type of SWC allows access to I/O by communicating directly with specific BSW modules. Other SWCs cannot be used to access I/O, only this one can be used.

Complex Device Driver SWC: This SWC is used to develop complex device drivers (CDD) for peripherals that are not supported by AUTOSAR or have time-critical functions.

Nvblock SWC: This SWC is used to communicate with NVRAM or memory.

Assembly Connector:

These connectors are used when communication between SWCs is required in a composite SWC. These connectors connect the ports of the SWCs to be connected. These connectors are the next step in port configuration, all ports of the SWCs to be connected are connected to the configuration connectors. You will use this while System Configuration.

Delegation Connector:

Delegation Connectors are used when some ports of SWCs need to be exposed to outer world of Composition SWC this exposure can be connection with other SWCs using Assembly connectors or connection with BSW. This is because AUTOSAR does not allow SWCs to communicate directly outside the compound, so delegation connectors are used to communicate outside the compound and communicate data from the internal SWCs to the outside world. Again, you use this term when configuring the system.

Example for Assembly and Delegation connection:

Runnable Entity:

The executable is the part of the SWC where the logic of the behavior of the application is written. Runnable is analogous to functions in C. In AUTOSAR, we create Runnable in a SWC during configuration and that runnable or function skeleton is generated in respective source files of SWCs.The name of the Runnable function is the same as what we give to the Runnable function during the definition. We have to write our code in this function/executable file which will then be executed by AUTOSAR OS. This code is an application that SWC must execute. Executables also have variables, and some executables also have trigger points that "call" or run the executable when a certain condition is met. Such conditions can be specified during configuration, the conditions can be: Init Runnable, which is called on initialization, a regular call to a runnable that can be used to send a periodic data, different RTE events based triggering, etc.

Below is the example of runnable skeleton generated after configuration, this runnable is of Indicator SWC named Runnable1. Such runnable skeletons are generated in SWC.c files.

/Indicator.c/
void Runnable1(){
/runnable logic code here/
}

The image above shows how executables are encapsulated in a SWC and how other SWCs are encapsulated by a composition. Looking at this image, we can understand how well AUTOSAR summarizes and groups things for standardization. As we know, SWC can be reserved for each ECU function, but its behavior or functionality implementation is done using Runnable.

There are generally three types of runnables:

Init Executable: This executable is called in ECU Initialization stage.

Periodic Executable: This executable is used when we need to run this executable from time to time to perform some function regularly.

Server Executable: This executable is used to implement the client/server port interface server. Executable settings can be configured to run on RTE events, for example:

Runnable can be configured to run on RTE events such as:

Time Event: As explained above, this event starts/triggers a special executable when a specified time is reached and executes the logic written in it. This is related to the timer interrupt we use in general embedded programming, where an ISR is called whenever the timer overflows.

Received Data Event: As the name suggests, this event fires an executable whenever the ports receive data.

Action Invoked Event:This event is invoked by the client when invoking the server, which can be executed on the client/server port interface.

State Change Event: When the state of the ECU is changed, an executable file can be started to do some work. For example, the ECU shutdown mode, if the ECU needs to do some work before shutting down, such an event must be connected to an executable that performs the work before shutting down.

Data Received Error Event: Again, this is self-explanatory. If an error occurs while receiving data, the executable can be called to take action on such an event.

Data Send Completed event: This event launches an executable file when data is successfully sent, so that actions can be taken after the data transfer is complete.

Conclusion:
In this article I have talked about Application software components and its interfaces with the help of RTE more about RTE, I will be covering in the upcoming article.