AUTOSAR tutorials: Communication Stack

Generic Blocks of Communication Stack

In my last two posts (Intro to AUTOSAR and AUTOSAR BSW) we have discussed the AUTOSAR Layered architecture in brief and in detail. But now we will go even more deep from today by focusing different stacks one by one. First we will see Communication Stack and will study stacks for each communication protocol like CAN, FlexRay, etc. in different posts for each type of protocol.

This post will only focus on network/bus independent blocks of communication stack of AUTOSAR. This will help in relating while reading posts explaining network/bus dependant blocks in communication stack by linking this post.

Generic Communication stack block diagram

Above figure is a generic communication stack block diagram which shows only network independent blocks as this post is only focusing it. All the Network dependent blocks will be replaced by respective communication protocol block for example: CAN will have all the CAN related blocks or FlexRay will have all the FlexRay related blocks.

In this figure, only blocks like: communication services, communication hardware abstraction, communication drivers are considered, but this time with detailed blocks in them. All blocks are network independent (in orange color), these independent blocks exist as one instance per ECU or in other words the independent blocks will be reused if more than one type of network bus is used for example CAN and FlexRay. Let us see them in brief:

1. Generic NM(Network Management) interface:

It is an adaptation layer between Communication Manager and the bus specific network management or network dependent blocks like CAN NM or FlexRay NM. This module only contains dispatcher. This module can also be used (optionally) in performing the role of NM coordinator where networks of different types can synchronously wake or sleep in which a separate ECU called as gateway ECU can be dedicated. An AUTOSAR NM Interface implementation can either support:

NM Interface functionality without any NM coordinator functionality
NM Interface functionality with NM coordinator functionality limited to support synchronous shutdown of busses with AUTOSAR NM running on the busses
NM Interface functionality with NM coordinator functionality to support synchronous shutdown of busses with AUTOSAR NM and direct OSEK NM running on the busses

This module provides services to Communication Manager (ComM) and uses services of respective bus specific or network dependent Network Management adaptation layers like CanNm, FrNm, LinNm. This module converts the generic function calls to bus specific function calls of the bus specific Network Management layer. It also converts the bus specific callbacks to generic callbacks to the Communication Manager.

2. Diagnostic Log and Trace (Dlt) :

AUTOSAR has a nice feature for storing diagnostic information and also reading this information as needed either by developer or maintenance engineers with specialized tools. Dlt helps achieving the transmission of diagnostic information on the communication bus.This module receives information from DET(Default Error Tracer), DEM (Diagnostic Event Manager) , SW-Cs and RTE trace information. The Dlt transmits this information on communication buses to make this information visible to other ECUs or devices on bus. In order to transmit messages on communication bus, Dlt interacts with PDUR (explained further).Dlt has a set of supported commands identified by service IDs start with 0x01 to 0x23. Lets see the Dlt interactions with above listed modules :

Dlt interaction with Software components: Dlt module offers interfaces which SW-Cs can use to send log and trace information to Dlt.

Dlt interaction with RTE: RTE has a functionality called as VFB (Virtual Function Bus) [VFB will be discussed in future posts] Trace which is nothing but implicit forwarding of communication data which flows from SW-C to Dlt via RTE. Dlt module provides interface for VFB Trace. For it the Dlt has to be configured as VFB Trace Client, while configuring we can configure which events are traceable in the configuration of RTE module. We will see the configuration of this in detail in my configuration related posts.

Dlt interaction with DEM: DEM stores the events and messages generated from SW-Cs and BSW modules. These events are numbered by event IDs. Each time the state of a event is changed DEM calls the Dlt_DemTriggerOnEventStatus function to notify Dlt of this change.Within this function, the DEM module provides the EventID of the event whose status has changed.In this function Dlt module shall compare the old to the new event status. If the event status are not the same Dlt shall build a Dlt log message with the new status and send it by calling Dlt_SendLogMessage.

Dlt interaction with DET: SW-Cs and BSW modules can report errors to the DET module. Such errors can be forwarded to the Dlt module as messages with a suitable content using the Dlt_DetForwardErrorTrace.

3. Diagnostic Communication Manager (DCM):

AUTOSAR based ECU have the functionality by which the ECU can communicate with external diagnostic tool which can be used during manufacturing of ECU or maintenance. DCM is used for attaining this functionality. DCM provides the OSI layers 5 to 7.At OSI-level 7, the DCM module provides an extensive set of ISO14229-1 services.In addition, the DCM module provides mechanisms to support the OBD(on board diagnostic) services $01 - $0A. With these services, Autosar OBD functionality is capable of meeting all light duty OBD regulations worldwide (California OBDII, EOBD, Japan OBD, and all others). At OSI-level 5, the DCM module handles the network-independent sections of the following specifications:

ISO15765-3 : Implementation of unified diagnostic services (UDS on CAN)

ISO15765-4 : Requirements for emission-related systems.

In the AUTOSAR Architecture the Diagnostic Communication Manager is located in Communication Services block. DCM handles the diagnostic sessions, diagnostic states, security states. The diagnostic session is the session during which the external tool requests for diagnostic information. DCM also checks if the requested diagnostic service is supported or not and also if the service should be executed according diagnostic states. DCM module is network/bus independent. All network-specific functionality (the specifics of networks like CAN, LIN, FlexRay or MOST) is handled outside of the DCM module. The PDU Router (PduR) module provides a network-independent interface to the DCM module.

The DCM module receives a diagnostic message from the PduR module. The DCM module processes and checks internally the diagnostic message. As part of processing the requested diagnostic service, the DCM will interact with other BSW modules or with SW-Components (through the RTE) to obtain requested data or to execute requested commands. This processing is very service-specific. Typically, the DCM will assemble the gathered information and send a message back through the PduR module. Lets see interactions of this module with other modules:

Diagnostic Event Manager (DEM): The DEM module provides functionality for retrieving information related to fault memory (memory locations where faults are stored) using which the DCM responds to requests from tester by reading data from fault memory.

Protocol Data Unit Router (PduR): The PduR module provides functions for transmitting and receiving data.

Communication Manager(ComM): ComM module provides functions using which the DCM can indicate the "active" and "inactive" states in diagnostic communication. The DCM module provides functionality to handle the communication requirements from ComM “Full-/ Silent-/ No-Communication”. Additionally, the DCM module provides the functionality to enable and disable Diagnostic Communication if requested by the ComM module.

SW-C and RTE: The DCM module has the capability to analyze the received diagnostic request data stream and handles all functionalities related to diagnostic communication such as protocol handling and timing. Based on the analysis of the request data stream the DCM module assembles the response data stream and delegates routines or IO-Control executions to SW-Cs .If any of the data elements or functional states cannot be provided by the DCM module itself the DCM requests data or functional states from SW-Cs via port interfaces or from other BSW modules through direct function-calls.

BSW Scheduler Module (SchM) : The SchM module provides functions to activate/cancel main processing functions.

EcuM: The EcuM is able to initialize the DCM module.

Mcu: The Mcu allows the DCM to perform a controller reset.

4. AUTOSAR COM:

This is one of the most important module of AUTOSAR communication. This can be understood well once I explain some basic terms of AUTOSAR communication.

Signal: AUTOSAR implements signal based communication. A signal is the smallest amount of information in a CAN message. A signal can be of any size from 1- bit to all 64 bits of CAN message. In other words the CAN message is divided in bits called signals and the application works on signal. For this primitive data types is supported like int, char, etc. There can be even Signal Groups used when signals needs to be kept tightly with each other. Signal groups can be used to support complex data structure like structs.

PDU: In AUTOSAR context, the CAN message is called as PDU (Protocol Data Unit). Different signals are packed in I-PDU. This packing or unpacking of signals in a PDU is done by AUTOSAR COM while transmitting or receiving CAN data respectively. PDU can be named based on the layer it is in. When it is in COM or DCM or PDUR then it is called I-PDU , when it is in TP layer it is called N-PDU, and when it is lowest layer it is called L-PDU. Each layer adds more information to the PDU, which is needed by next layers.

Thus COM main function is packing/unpacking the signals in PDU during transmission or reception respectively. COM provides signal oriented interface to RTE. Below COM no module understands signal oriented interface. It also performs the function communication transmission control. Monitors received signals. External signal exchange between SW-Cs on different ECUs are routed through RTE via COM to PDU-Router and then to a bus system as configured during system design.

Note: Although extra information is added to the PDU but it is removed by the layers and only PDU is transmitted on the network as normal CAN cannot transmit payload greater than 8 bytes. COM is further used for :

1.Route signals from received I-PDUs
2.Start or Stop I-PDUs.
3.Byte order conversion

5. Large Data COM (LdCom):

The AUTOSAR LdCom module provides an alternative Interaction Layer Mechanism. By focusing on spontaneous, non-cyclic communication without serializing, filtering and conversion an efficient implementation of the module without local buffers is achieved. LdCom is an additional means for sending and receiving signals. It handles mainly following functions:

Provision of signal oriented data interface for the RTE

Provision of received signals to RTE

Support of large and dynamic length data types

Support of IF- and TP-based communication

Provision of PDU oriented data interface towards PduR

6. Protocol Data Unit Router (PduR):

PDU router as the name suggests is used to route the I-PDUs between modules like communication interfaces modules (like CAN IF, LIN IF, etc ), DCM,AUTOSAR COM,etc. PDUs are identified by static PDU IDs. PDUR determines the destination of PDU by using the PDU ID and a static configuration table. PDUR don't modify the data instead it just routes the PDU to its destination.

The PDU Router module provides an API for modules below the PDU Router module (communication interface modules and transport protocol modules) and an API for modules directly above (e.g. DCM and COM) . Furthermore the PDU Router module provides an interface for the I-PDU multiplexer (IPDUM) which is located beside the PDU Router. All these interfaces are constructed such that the operations required to pass data between the lower and upper layers are minimized.

The PDU Router module is part of the AUTOSAR Basic SW, and is mandatory instantiated in every AUTOSAR ECU.

7. IPDU Multiplexer (IpduM) :

PDU multiplexing means using the same PCI (Protocol Control Information) of a PDU (Protocol Data Unit) with more than one unique layout of its SDU (Service Data Unit). A selector field is a piece of the SDU of the multiplexed PDU. It is used to distinguish the contents of the multiplexed PDUs from each other. Multiplexing of PDUs is currently known from CAN, but is not restricted to this communication system.
On sender-side, the I-PDU Multiplexer module is responsible to combine appropriate I-PDUs from COM to new, multiplexed I-PDUs and send them back to the PDU Router. On receiver-side, it is responsible to interpret the content of multiplexed I-PDUs and provide COM with its appropriate separated I-PDUs taking into account the value of the selector field.

8. Secure Onboard Communication(SecOC):

The SecOC module aims for resource-efficient and practicable authentication mechanisms for critical data on the level of PDUs. SecOC module receives I-PDUs from PduR, on it the SecOC module adds or process the security related information and reverts back the results in the form of I-PDU to PduR. PduR then further routes the I-PDU. SecOC module utilizes the cryptographic services and interacts with the RTE for key and counter management.

Don't worry if you don't understand any network/bus independent modules from above, I will be explaining them in detail in future posts. I just gave a brief information about them to help in understanding the bus/network dependent modules which I will be discussing in future.

Still if you have any doubts please comment them in comment box.