Generic Blocks of Communication Stack
Translate in your language
In my last two articles (Intro to AUTOSAR and AUTOSAR BSW) we have discussed the AUTOSAR Layered architecture in brief and in detail respectively. 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.
For ease of understanding, I have divided communication services block in network/bus dependent and independent blocks for ease of understanding.This article will only focus on explaining network/bus independent blocks of communication stack of AUTOSAR in brief. I will also be explaining each block in detail in my future articles. This will help in relating while reading posts explaining network/bus dependent blocks in communication stack by linking this post.
Above figure is a generic communication stack block diagram which shows only network independent blocks and 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.
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 buses with AUTOSAR NM running on the buses
- 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. So whatever communication related functions calls are called from upper layer, this module forwards it to respective bus specific calls. It also converts the bus specific callbacks to generic callbacks to the Communication Manager. Now this is vice versa, all the callbacks received from lower layers (bus specific modules) are converted to generic callbacks, because above layers don’t “understand” network or bus they are just interested in data i.e. Signals. For more detailed explanation of Generic NM check out this article.
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. This module (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 devices on bus. In order to transmit messages on communication bus, Dlt interacts with PDUR. Dlt has a set of supported commands identified by service IDs, which start with 0x01 to 0x23. Lets see the Dlt interactions with other listed modules :
- Dlt interaction with Software components: Dlt module offers interfaces which SWCs can use to send log and trace information to Dlt, which further can be read by maintenance engineers as and when needed.
- Dlt interaction with RTE: RTE has a functionality called as VFB (Virtual Function Bus) 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 and 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 articles.
- 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 compares the old to the new event status, If the event status is changed then Dlt will 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 function and can be seen by developer.
3. Diagnostic Communication Manager (DCM):
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 can 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. For more detailed information on signal check out this link.
- PDU: In AUTOSAR context, the message is called as PDU (Protocol Data Unit). PDU can be roughly considered as a package of signals. This packing or unpacking of signals in a PDU is done by AUTOSAR COM while transmitting or receiving data respectively. For more detailed information on PDU check out this link.
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 of communication transmission control and 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 configuration.COM is further used for :
- Route signals from received I-PDUs
- Start or Stop I-PDUs.
- 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 along with Com but with more features as listed below. 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 (for more information on this checkout I-PDU) 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) for more information on PCI and SDU read article on common terms of AUTOSAR on PDU. 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. 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 each of them and network dependent blocks in detail in future articles. In this article, I just gave a brief information about them to help in understanding the bus/network dependent modules from high level which will help in understanding the network or bus dependent modules.
Still if you have any doubts please comment them in comment box.
And if you find any mistake or errors please report it.
Thanks for reading 🙂
Nice one!
Thanks for such valuable posts. This is very useful for engineers trying to learn Autosar. One request, would be possible to post something related to Adaptive Autosar. I like your analyses and your style of posting.
Thank you for your kind words! I am also new to adaptive AUTOSAR, but will post articles related it soon.