DEV Community


Posted on

Blocks of AUTOSAR communication Stack

Hello Readers,
My name is Rakshith M working as a junior software engineer at Luxoft India. While Exploring AUTOSAR communication stack I got interest to write article on blocks of Communication Stack. So, I Have written based on my knowledge so let’s begin.

The figure below is a general verbal exchange stack block diagram which suggests simplest community impartial blocks and all the Network based blocks will be replaced by using respective communique protocol block as an instance: CAN have all the CAN associated blocks or Flex Ray can have all the Flex Ray associated blocks.

Image description

1. Generic NM (Network Management) interface:
It is a variation layer among Communication Manager and the bus particular community management or network structured blocks like CAN NM or Flex Ray NM. This module simplest contains dispatcher. This module also can be used in performing the function of NM coordinator wherein networks of different types can synchronously wake or sleep, wherein a separate ECU referred to as gateway ECU can be dedicated. An AUTOSAR NM Interface implementation can either assist.

2. Diagnostic Log and Trace (Dlt):
AUTOSAR has a pleasant function for storing diagnostic statistics and reading these statistics as needed both via developer and renovation engineers with specialized equipment. This module (Dlt) allows accomplishing the transmission of diagnostic records at the verbal exchange bus. This module receives statistics from DET (Default Error Tracer), DEM (Diagnostic Event Manager), SW-Cs and RTE hint statistics. The Dlt transmits this data on communication buses to make these facts seen to different devices on bus. To transmit messages on communique bus, Dlt interacts with PDUR. Dlt has a set of supported commands diagnosed by means of carrier IDs, which start with 0x01 to 0x23. Let’s see the Dlt interactions with other indexed modules.

Dlt interplay with Software components: Dlt module offers interfaces which SWCs can use to send log and hint information to Dlt, which in addition can be study with the aid of maintenance engineers as and while needed.

Dlt interaction with RTE: RTE has a capability known as VFB (Virtual Function Bus) Trace which is nothing however implicit forwarding of communication records which flows from SW-C to Dlt via RTE. Dlt module affords interface for VFB Trace. For it, the Dlt needs to be configured as VFB Trace Client and at the same time as configuring, we will configure which events are traceable in the configuration of RTE module. We will see the configuration of this in element in my configuration related articles.

Dlt interaction with DEM: DEM stores the activities and messages generated from SW-Cs and BSW modules. These activities are numbered by way of occasion IDs. Each time the country of an occasion is changed, DEM calls the Dlt_DemTriggerOnEventStatus characteristic to inform Dlt of this change. Within this function, the DEM module offers the EventID of the occasion whose reputation has changed. In this characteristic Dlt module compares the old to the brand-new event reputation, If the event status is changed then Dlt will construct a Dlt log message with the brand-new fame and ship it by using calling Dlt_SendLogMessage.

Dlt interaction with DET: SW-Cs and BSW modules can file errors to the DET module. Such mistakes may be forwarded to the Dlt module as messages with an appropriate content the usage of the Dlt_DetForwardErrorTrace characteristic and may be visible via developer.

3. Diagnostic Communication Manager (DCM):
The DCM module gets a diagnostic message from the PduR module. The DCM module tactics and tests internally the diagnostic message. As a part of processing the requested diagnostic carrier, the DCM will interact with different BSW modules or with SW-Components (thru the RTE) to attain requested data or to execute asked instructions. This processing may be very provider specific. Typically, the DCM will bring together the accrued facts and ship a message back via the PduR module.

4. Large Data COM (LdCom):
The AUTOSAR LdCom module affords an alternative Interaction Layer Mechanism. By specializing in spontaneous, non-cyclic conversation without serializing, filtering, and conversion a green implementation of the module without nearby buffers is executed. LdCom is an extra way for sending and receiving signals alongside Com.

5. Protocol Data Unit Router (PduR):
PDU router as the call shows is used to direction the I-PDUs between modules like verbal exchange interfaces modules (like CAN IF, LIN IF, etc), DCM, AUTOSAR COM, and so on. PDUs are recognized via static PDU IDs. PDUR determines the destination of PDU by means of the usage of the PDU ID and a static configuration table. PDUR don’t regulate the information, as a substitute it simply routes the PDU to its vacation spot.

6. IPDU Multiplexer (IpduM):
PDU multiplexing method using the equal PCI (Protocol Control Information) of a PDU (Protocol Data Unit) with more than one precise layout of its SDU (Service Data Unit) for more records on PCI and SDU study article on not unusual terms of AUTOSAR on PDU. A selector subject is a chunk of the SDU of the multiplexed PDU. It is used to differentiate the contents of the multiplexed PDUs from each different. On sender-side, the I-PDU Multiplexer module is responsible to combine suitable I-PDUs from COM to new, multiplexed I-PDUs and ship them lower back to the PDU Router. On receiver-side, it's far accountable to interpret the content material of multiplexed I-PDUs and provide COM with its appropriate separated I-PDUs considering the fee of the selector discipline.

7. Secure Onboard Communication (SecOC):
The SecOC module targets for aid-green and attainable authentication mechanisms for crucial information on the extent of PDUs. SecOC module receives I-PDUs from PduR, on it the SecOC module adds or method the security related data and reverts again the effects inside the form of I-PDU to PduR. PduR then similarly routes the I-PDU. SecOC module utilizes the cryptographic services and interacts with the RTE for key and counter control.

Conclusion: By this I am concluding that I have written some of the basics of blocks of Communication stack please let me know if any improvements or concerns are there thank you all.

Top comments (0)