Hello everyone, I am Pooja, and I work at Luxoft India. Here I would like to provide a brief knowledge about "Part 2-Understanding and Configuring Runnable Entities in AUTOSAR Software".

Introduction
In the realm of Automotive Open System Architecture (AUTOSAR), the concept of "Runnable" entities serves as the foundational building blocks of software components. These runnables, akin to individual functions, are meticulously defined in the software's configuration to encapsulate specific behaviors and functionalities. In this comprehensive article, we will delve deep into the world of Runnable entities, exploring their significance and the array of configurations and properties associated with them.

Defining Runnable Entities

Each runnable entity corresponds to a function within the C code of a software component. To illustrate this, let's consider an example C file containing four distinct functions: "Sum," "Difference," "Multiplication," and "Division." Each of these functions is a runnable entity, and within the AUTOSAR framework, each must have a specific configuration.
Example:-
Fig. Runnable Sw
#include "Rte_SWC_1.h"
void Sum()
{
int x, y;
Rte_Read_RP_X_X(&x);
Rte_Read_RP_Y_Y(&y);
Rte_Write_PP_Sum_Sum(x + y);

}

void Difference(int x, int y, int* diff)
{
*diff = x - y;
}

void Multiplication(int x, y, long* product)
{
*product = x * y;
}

void Division(int x, int y, float* quotient)
{
*quotient = (float)x / y;
}

In this example, the four functions, "Sum," "Difference," "Multiplication," and "Division," are considered as runnable entities. Each of these functions necessitates a corresponding runnable configuration within the AUTOSAR framework.

Fig. RTE Configuration.

Runnable Configuration
A runnable configuration is defined within the "Runnable Entity" tag and encompasses vital information regarding the interfaces or ports accessed within the runnable. Let's dissect the key aspects of a runnable configuration:

Data Access Configuration:
AUTOSAR provides two modes of communication: Explicit and Implicit.
Explicit communication involves the straightforward transfer of data between ports, with no concern for message consistency.
Implicit communication ensures message consistency across receivers by establishing dedicated message buffers for each receiver.

Data Read-and-Write Access:
Data read-and-write access is used for implicit communication, where the RTE manages message consistency between the sender and multiple receivers.
For explicit communication, data can be received either by argument or value.
Data send configuration is employed for queued communication, with the RTE creating a message queue to store data from the sender and forwarding it to the receivers upon request.

Parameter Access:
Parameters are typically read-only and cannot be written by the software.
The "Parameter Access" tag specifies the intent to read calibration parameters from a function.

Mode Switch Ports:
For mode switch ports, two options are available: "Set Mode" or "Access Mode Port."
When accessing a mode port through a receiver port, the "Mode Access Point Configuration" is employed.
When a provider port or function calculates the mode interface itself, it is configured using a "Mode Switch Point."

Local Interface Access:
Local interface access allows the access of interfaces defined within the scope of the component.
"Read Local Variable" and "Write Local Variable" tags are used for reading and writing local variables.
Unlike external ports, local variables are not sent or received from external components.

Client-Server Interface:
Specify if the runnable is accessing client-server interfaces.
Depending on requirements, a client can call the server either asynchronously or synchronously.
For synchronous server calls, use the "Synchronous Server Call Point."
For asynchronous server calls where results are read later, use the "Asynchronous Server Call Result Point."

Triggers:
Triggers can be internal or external and are associated with trigger ports.
Configuration options are based on trigger interfaces.

General Properties:
The "Can Be in Concurrently" option determines whether the runnable can be called recursively or in parallel on different tasks (True or False).
The "Symbol" tag specifies the exact name of the function in the C file, enabling the operating system to call the function correctly during scheduling.

Conclusion
In summary, Runnable entities form the fundamental components of AUTOSAR software, representing individual functions within a software component. These runnables are meticulously configured to define their behavior and interface access. The configurations encompass communication modes, data access, parameter access, mode switch ports, local interface access, client-server interfaces, triggers, and general properties.

This structured approach ensures efficient communication and coordination within complex automotive software systems, making AUTOSAR a powerful framework for automotive software development. Understanding and effectively configuring Runnable entities is crucial for building reliable and robust automotive software applications. As the automotive industry advances, these configurations become ever more critical in ensuring safe and efficient vehicle operation. I hope by now you have understood about Runnable Entity and configuration, for more clearance stay tuned for next article.