Communication Services (ComStack) In AUTOSAR
Communication Stack in AUTOSAR is a set of modules like COM (Services Layer), PDU Router(Services Layer), Bus Specific Interface Modules (ECU Abstraction Layer) e.g. CanIf, LinIf, FrIf, etc., External Bus Drivers (ECU Abstraction Layer), Internal Bus Drivers (MCAL Layer). Modules listed here are very basic modules in the Communication Stack. There are modules like the Bus Specific State Manager, Network Manager and Transport Protocol modules in the communication stack but they will be described in a separate set of articles.
Note : Some of the missing modules in the above figure will be taken in the coming articles.
TP — Transport Protocol, NM — Network Manager, Trcv — Transceiver, Ext. — External, Asic — Application Specific Integrated Circuit
Before discussing about the Communication Stack let me take some of the basic terms used in the Communication Stack.
What is a PDU?
Protocol Data Unit as it stands for is a data structure containing an SDU (Service Data Unit) and a PCI (Protocol Control Information). An SDU is the data passed by the upper layer for transmission and extracted from the PDU during reception. A PCI basically contains the source and destination information for the PDU to be exchanged between layers and modules.
A PDU is packed into a structure (SDU + PCI) at the COM layer and is transmitted to the lower layer in the Communication Stack. At every layer during transmission, a PDU from the upper layer acts as an SDU for the lower layer. A PCI is added at the lower layer to this SDU and it is transmitted to the lower layer.
At the receiver side, the received PDU is unpacked by separating the SDU and PCI and passing the SDU to the upper layer which acts as a PDU for that layer.
Signal, Signal Group and Group Signal
Signal in AUTOSAR is a message. Signal Group is a set of signals to be transmitted at the same instance and the signals packed in a Signal Group are known as Group Signals.
AUTOSAR COM is a module between the RTE and the PDU Router. It is responsible for providing a Signal level access to the application layer and a PDU level access to the lower layers independent of the protocol. It packs the signals to a PDU at the transmitter and unpacks the received PDU to provide a signal level access to the application at the receiver. At the PDU level, COM is responsible for grouping of the PDU’s, starting and stopping of the PDU groups.
COM groups the signals in a Signal Group for them to be transmitted at once.
COM is responsible for a signal/signal group level gatewaying. It maps a received signal/signal group to a transmit signal/signal group to be gatewayed.
It is also responsible for filtering, byte order conversion and sign extension of the signals.
PDU Router is a module responsible for routing the PDU to the respective Bus Specific Interface modules. Above the PduR module all the PDU’s are protocol independent and below PduR all the PDU’s are routed to the protocol specific modules.
PduR ia also responsible for PDU level gatewaying i.e. transmitting the received PDU from one Bus Specific Interface module to other Bus Specific Interface module. Gatewaying can also be done when a PDU is to be routed from one controller to another over the same protocol.
Communication stack w.r.t. to CAN protocol in AUTOSAR consist of different modules like AUTOSAR COM(Services Layer), PDU Router(Services layer), CAN State Manager(Services Layer), CAN Network Manager(Services Layer), CAN Transport Protocol(Services Layer), CAN Interface(ECU Abstraction Layer) External CAN Driver(ECU Abstraction Layer) and CAN Driver(MCAL Layer). Some modules related to diagnostics, PDU multiplexing and CAN Transceiver are also part of the stack.
CAN Interface(CanIf) is a module in the ECU Abstraction Layer which is responsible for services like Transmit Request, Transmit Confirmation, Reception Indication, Controller mode control and PDU mode control.
Basic terms used in CanIf :
Hardware Object Handle :
Hardware Object Handles (HOH) for transmission (HTH) as well as for reception(HRH) represent an abstract reference to a CAN hardware object structure, that contains CAN related parameters such as CanId, DLC and data. During transmission these handles are known as Hardware Transmit Handles(HTH) and during reception Hardware Receive Handles(HRH). CanIf calls CAN driver interfaces using these abstract references and never uses the actual hardware CanId, hence CanIf remains hardware independent.
BasicCAN and FullCAN :
CanIf distinguishes between BasicCAN and FullCAN handling for activation of software acceptance filtering.
A CAN Hardware Object for FullCAN operation only enables transmission or reception of single CanIds.
A CAN Hardware Object for BasicCAN operation of one Hardware Object enables to transmit or receive a range of CanIds.
BasicCAN and FullCAN objects can coexist in a single configuration setup.
CanIf abstracts the CAN hardware object i.e. the CAN frame structure from the MCAL CAN driver using abstract handles called Hardware Object Handles(HOH). It routes the PDU to different CAN controllers and transceivers. It controls the CAN controller state transitions request from CANSM and communicates the state changes to upper layer.
In case of Transmission of a PDU, CanIf is responsible for mapping the Hardware Transmit Handles to the CAN hardware objects, determining the CAN driver on which the PDU has to be transmitted, triggering a call to Can_Write api. Once the Can_Write is completed, notifying the upper about the transmission status of the PDU.
In case of Reception of a PDU, CanIf is responsible for filtering of the received PDU, DLC check, buffering of the received PDU and indicating the upper layer about the PDU reception. Most of these features provided by CanIf are configurable.
CAN Driver(CanDrv) module is a part of the MCAL layer and provides hardware access to the upper layer services and a hardware independent interface to the upper layers. CanIf is only module that can access the CAN driver.
It controls the transmission of CAN frames on the hardware and notifies the upper layer of reception by calling the callback functions. It also provides the interfaces to control the state of the CAN controllers.
CanTp
CAN Transport Layer
The basic services offered by the Can Tp module are segmentation of messages which have a payload of more than 8 bytes, transmission of the messages with flow control and reassemble the segmented messages at the receiver.
The CanTp module should comply with the ISO 15765–2 standard for message segmentation, segmented transmission and reassembly of segmented data. Transport protocol is mostly used for peer-to-peer communication in CAN.
Lets go through the basic Network Layer Protocol functions as specified by ISO 15765–2.
Network Layer Protocol performs transmission/reception of data of up to 4095 bytes and reporting of transmission/reception completion.
Single Frame (SF) Transmission :
Transmission/Reception of message of up to 7 data bytes is performed using a unique N_PDU. Single frame is used by the tester only in case of functional addressing wherein the tester is not aware of the physical address of the ECU or if the functionality of the ECU is implemented as a distributed server over several ECUs.
Multiple Frame Transmission :
Transmission of messages with longer data bytes is performed by segmenting the message and transmitting as multiple N_PDU. Reception is performed by reassembling the multiple received N_PDU’s.
First Frame (FF) : The FF data unit mostly contains the length of data in bytes which will be a part of the consecutive frame (CF) and remaining bytes can be used data bytes.
Flow Control Frame (FC) : The receiver has the possibility of adapting the transmitters throughput by using the FC frame. Using the FC frame the receiver can request the transmitter to send data bytes of certain block size(BS — maximum number of N_PDU’s the receiver allows the sender to send before it allows the sender to send the N_PDU’s again) and at a fixed rate(STmin — minimum time the sender has to wait before transmission of the next Consecutive N_PDU) so that the receiver the process the received data.
Consecutive Frame (CF) : It contains the transmitted data bytes along with the sequence number (SN) which specifies the CF number and this SN is used while assembling the data at the receiver.
There are many timing parameters involved in the transport protocol communication. Go through ISO 15765–2 for the description of all of them.
Consider if 49 bytes of data has to be transmitted using normal addressing then the flow of PDU’s might look like, first frame will contain the number of bytes to be transmitted, 49, the number of CF’s that will be used for the transmission of these 49 bytes, 7. The FC frame will have the BS and the STmin values specific to the receiver. The seven CF frames will contain the data bytes.
Interaction of CanTp with other modules
CanIf interacts with CanTp will giving the TxConfirmation and RxIndication about the transmitted and received PDU.
CanTp does not has its own buffer, so it uses the buffer of the upper layers (PDUR, DCM or COM). So to maintain the data consistency during Tx/Rx, buffer are locked. During the reception of data the CanTp module notifies the upper layer (PDUR) and the upper layer reserves the and locks the buffer for reception.
If the upper layer cannot make the buffer available for reception because of some error or resource limitation, it returns with an error. The CanTp then aborts the reception and the FC frame transmission depends on the error code from the upper layer.
During the transmission, the CanTp uses the addressing format to send the SF, FF and the CF frames. Transmission can fail if the upper layers are not able to make the data for transmission available before the internal timers elapse (please refer ISO 15765–2). CanTp resumes the transmission when data is available from the upper layer.
PDU Router module is first notified with a start of reception notification when receiving a first frame (FF) or single frame (SF). This call is be forwarded to the related upper layer module. The payload of each segment (N-PDU) is copied in the destination upper layer module. After reception of the last N-PDU the transport protocol module will indicate the PDU Router module that the complete I-PDU has been received and the PDU Router module will forward this indication to the related upper layer module.
The transmit operation of the PDU Router module is triggered by a PDU transmit request from a source upper layer source module and forwards the request to a destination lower layer module. During transmission PDUR does not buffers the PDU.
Gatewaying-on-the-fly : routing between two TP modules where forwarding of data is started (when a specified threshold is reached) before all data have been received. If larger amount of data is transported between two interfaces it is desirable to be able to start the transmission on the destination network before receiving all data from the source network. This saves memory and time.
CanNm
Network Management Interface :
Network Management Interface is a module between the ComM and the Bus Specific NM module, in this article we will consider CANNM as the bus specific NM. NM interface has two functionalities,
Basic Functionality — is to act as an adaptation module between the Bus Specific NM module and the ComM module. The interfaces for communication between the NM interface and the ComM module are independent of the underlying Bus Specific module.
NM Coordinator — used by gateway ECU’s to synchronously shut down the communication buses. It uses an NM coordination algorithm to shutdown the buses on which an ECU is connected. An ECU using NM Coordinator functionality is referred as NM Coordinator.
Shutdown shall be coordinated on the network which is awake and not in ‘Bus-Sleep Mode’. Network which are in ‘Bus-Sleep mode’ shall only be monitored. As long as one bus in the coordination cluster (NM Cluster — Set of NM nodes coordinated with use of the NM algorithm) is awake the NM coordinator shall still keep the network alive.
When the coordination algorithm is started, a shutdown delay timer is started forthe currently active channels in the coordination network. When the Shutdown Delay timer expires, NM should release the NM network. When all networks have been released and all networks are in ‘bus-sleep mode’, the coordinated shutdown is completed.
CAN Network Management :
CANNM is to coordinate the transition between normal operation and bus-sleep mode of the network. It can also be used to detect all present nodes or all to detect whether all nodes are ready to sleep in the network.
CANNM for every ECU needs to performs activities self-sufficient depending on the Network management PDU’s only that are received or transmitted within the communication system.
The CANNM algorithm is based on periodic Network Management PDU’s, which are received by all nodes in the cluster via broadcast transmission. Reception of Network Management PDU’s indicates that sending nodes want to keep the network management cluster awake. If any node is ready to go to the Bus-Sleep Mode, it stops sending Network Management PDU’s, but as long as Network Management PDU’s from other nodes are received, it postpones transition to the Bus-Sleep Mode. Finally, if a dedicated timer elapses because no Network Management PDU’s are received anymore, every node initiates transition to the Bus-Sleep Mode.
If any node in the network management cluster requires bus-communication, it can wake-up the network management cluster from the Bus-Sleep Mode by transmitting Network Management PDU’s.
Concept of CANNM relies on:
- Network node in the NM cluster should periodically transmit NM messages till it needs access to the Bus otherwise it should not transmit any NM PDU.
- If bus communication in a CanNm cluster is released and there are no Network Management PDU’s on the bus for a configurable amount of time determined by CANNM_TIMEOUT_TIME + CANNM_WAIT_BUS_SLEEP_TIME (both configuration parameters) transition into the Bus-Sleep Mode shall be performed.
The different states in the CANNM State Machine:
Repeat Message State : Each ECU transmits its own NM message cyclically till a configurable timer expires.
Ready Sleep : ECU is ready to sleep, no NM message transmission, timeout timer is restarted when an NM message is received.
Normal : NM message transmission and restart of timeout timer on message transmission and reception.
Prepare Sleep : If the configured timer expires and no NM message has been transmitted or received .
Bus-Sleep : After a configured timer the network transitions to Bus-Sleep mode wherein no communication happens on the bus.
CAN State Manager (CanSM):
The CAN State Manager (CanSM) is a member of the Communication Service layer which interacts with the Communication Hardware Abstraction Layer and the System Service Layer. The CanSM module is responsible for the control flow abstraction of CAN networks. An ECU can have different communication networks in a vehicle. Each and every network has to be identified with a unique network handle. The ComM module requests communication modes from the networks. Based on configuration done in AUTOSAR tools, which handle is assigned to what kind of network. For CAN, it uses the CanSM module. The CAN State Manager Specification defines the main function of this module. Technically CanSM used to modify the communication modes of the CAN network as per the request from the Communication Manager (ComM) module.
