Hello Readers,

My name is Nithyanand T, 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 ASWC data types and its port interfaces.

Data Types in Application Software Component:

Application Data type- Application Data Type should be defined for all port interfaces that we create for software component type. It is abstract data type (degrees, kms etc). The application data type must be combined with the Implementation data type to generate RTE.

Implementation Data type: Implementation Data Type exists on the code level. A specific data type used in C (Boolean, uint8, etc.).The Implementation data type is related to the base data type.

Base data Type: The base type is not required if the implementation type is a known platform type.

If you have a specific monitor temperature for application software, an application data type temperature is created and can be mapped to an application data type (eg unitt8).

TYPES OF APPLICATION INTERFACES IN AUTOSAR

AUTOSAR supports six types of application port interfaces They are.

• Sender Receiver port Interface(ASWC)
• Client Server Port Interface
• Calibration Port Interface
• Mode Port Interface
• NV Data Port Interface
• Trigger Interface

Port interface: Each software port (all types of software - application or BSW) is connected to a port interface. The user interface of a port describes information (such as structure) or functionality that a software component provides or requests through that port. A port interface describes the data provided or required by a software component port.

Sender-Receiver Port Interface: A sender-receiver (S/R) interface is a port interface used for communication between a transmitter and a receiver. If you want to exchange data (eg variables, structure) between software components, you use the sender receiver interface.

Client Server Port Interface: Client Server Interface (C/S) is equivalent to Sender-Receiver interface. Instead of defining the data to be passed between software components, an interface defines a set of operations that can be invoked based on a client-server model. Here, the client initiates communication and requests the server to provide a service.The starting direction of the message can be used to identify whether the AUTOSAR software component is a client or a server.

Calibration Port Interface: The calibration port user interface allows software components to access either standard data, fixed data, or calibration data. It should be noted that the compatibility rules apply depending on the usage type (ie fixed, permanent or equivalent). For example, a calibration port interface that uses a fixed deployment policy must not connect to a parameter SW component port if the provider uses a variable data implementation (i.e. standard).

NVData Port Interface: It provides element-level access (read-only or read/write) to persistent data. If we want to access the NV BLOCK through NVRAM or from an application software or NVM software component, we use the NVData port interface.

Mode Port Interface: The state change interface is used to inform a software component about the state of the application. Mode Management (Communication Manager, BSW Manager) provides modes that allow mode users to customize actions according to modes or synchronize functions with mode switches. Software components access state and request state changes through the mode port.

Trigger Interface: Trigger interface allows software components to trigger the execution of software components. The purpose of the trigger interface is to enable fast response times for a trigger that may occur randomly or with a variable cycle time. Example: Start based on crankshaft and camshaft position.

SENDER RECEIVER COMMUNICATION IN AUTOSAR

Sender-receiver communication enables the exchange of data/information, where the sender shares information with one or more recipients. We can use the Sender Receiver interface to exchange data, exchange events and status groups.

The Sender-receiver interface associated with these ports consists of data elements that define the information sent by the transmitter and received by the receivers. The data type can be something very simple (eg "integer") or a complex (perhaps large) data type (e.g. an array or a string).

SenderReceiverPortInterface is a traditional interface used to send and receive signals for cars. It integrates well with buses like CAN and LIN (which are mainly signal-based buses).

The RTE function prefixes are:

Rte_Write (P-Port, Non-Queued)
Rte_Read (R-Port, Non-Queued)
Rte_Send (P-Port, Queued)
Rte_Receive (R-Port, Queued)

ClientServerPortInterface:

Software components use ClientServer ports when they request services in BSW (typically through service mapping) or another software component. A function call can be set to be either synchronous or asynchronous via configuration.

The RTE function prefixes are:

Rte_Call (R-Port)
For server ports (or P-ports), the user can choose any function name as long as the RTE knows it at generation time.

ParameterPortInterface:

Parameter ports are used for parameter data, sometimes called calibration data. These are usually read-only values ​​that control the behavior of software components.

The RTE function prefixes are:

Rte_Prm (R-Port)

ModeSwitchPortInterface:

Mode ports are used to respond to ECU status changes.

The RTE function prefixes are:

Rte_Mode (R-Port)
Rte_Switch (P-Port)

NvDataPortInterface:

The non volatile data port interface is only used by the NvBlock Software Component.

Conclusion:
AUTOSAR affords a complete framework for automotive software. It defines special facts kinds and APIs to make certain standardized communique and functionality. The distinction among utility data types, implementation data types, and middle data types lets in for abstraction and versatility in software improvement. Six utility interface kinds, such as transmitter-receiver, purchaser-server, calibration, fame, NV records and trigger interfaces, meet the various communication and capability requirements of the car ecosystem. This dependent approach, with unique RTE characteristic prefixes for every interface kind, allows green and standardized software development for automotive programs.