AUTOSAR Communication and Networking

OVERVIEW OF AUTOSAR COMMUNICATION AND NETWORKING

Communication and Networking play a critical role in the AUTOSAR Architecture; as they facilitates different components of an automotive system to be distributed across different ECUs, while still communicate with each other in an effective and reliable way regardless of the hardware and software platforms they are running on.

AUTOSAR COMMUNICATION INFRASTRUCTURE AND PROTOCOL STACKS

Communication Stack, or ComStack for short, whose modules in three sub layers of the BSW Layer provides a range of communication services to both Basic Software Modules and Application Layer. As shown in AUTOSAR Architecture Diagram, ComStack is an essential part of the Basic Software (BSW) Module.

Figure 1: Components of AUTOSAR COMStack

 

Some of the important software modules in this stack are as follows:

・       AUTOSAR COM: 

The AUTOSAR COM module is situated within the services layer, and it functions as a mediator between the RTE and the PDU Router. Its primary responsibility is to enable the application layer to access the signals and the lower layers to access the PDU, in a protocol-independent manner. Specifically, it packages the signals into a PDU during transmission, and unpacks the received PDU to provide signal level access to the application at the receiver. Additionally, at the PDU level, the COM module is accountable for grouping the PDUs, as well as initiating and stopping the PDU groups.

 ・       PDU Router

Protocol Data Unit Router (PDUR) is a component located within the services layer of AUTOSAR. Its primary function is to route the Protocol Data Unit (PDU) to the corresponding Bus Specific Interface modules. All PDUs above the PduR module are protocol independent, whereas all PDUs below are directed to the protocol-specific modules. Moreover, the PduR module is also responsible for PDU-level gatewaying, meaning that it transmits a received PDU from one Bus Specific Interface module to another.

 ・       Bus Specific Interface Modules

They are a part of the ECU Abstraction Layer such as CanIf, LinIf, FrIf, EthIf, and FlexRayIf, etc whose functions as the interface between hardware abstraction and service layer.

Among these modules, the Interface Module is responsible for providing services, for instance, Transmit Request, Transmit Confirmation, Reception Indication, Controller Mode Control, and PDU Mode Control.

 ・       External Bus Drivers

As a part of the ECU Abstraction Layer, for example – External drivers like CANDrv, LINDrv, FlexrayDrv, etc. This module function is to provide bus-specific transceiver access to upper layer services through a hardware-independent interface.

 ・       Internal Bus Drivers

This part belongs to the AUTOSAR MCAL Layer such as CanDrv, LinDrv, FrDrv, etc., with the purpose of giving hardware access to the upper layer services and a hardware-independent interface to the upper layers. Bus If is the only module that can access the CAN Driver.

Figure 2: Flow of Communication Stack

 

The above ComStack Flow can be divided into three sections A, B, C in respective.

・       Section A: Data Transmission and Reception Management

It is responsible for transmitting data/signal/PDU from the application layer to the physical bus, outlining the process of signal flow from the application layer to the physical bus. There are two interfaces available for the application layer to send signals:

IF interface, which is used when the length of the data is equal to or less than what the BUSIF can send, and TP interface, which is used when the length of the data is greater than what the BUSIF can send.

・       Section B: State Management

In this section, it executes certain conditions requested by the application layer before sending data. Once the request has been executed, the application layer will receive feedback via a call-back mechanism. Only if the feedback is positive, the application can send data on the bus. When the bus is no longer required, the application can put certain conditions like the controller and transceiver state inactive for no communication, which helps to save power.

・       Section C: Network Management

For any communication to occur, there must be at least two nodes involved. The management and maintenance of node activity are necessary to ensure that they are in sync with the network condition.

 

AUTOSAR ETHERNET AND CAN BUS PROTOCOLS

CAN Bus and Ethernet Protocols, two out of various common-used communication protocols in AUTOSAR, are implemented across different automotive platforms to better interoperability and compatibility among different ECUs.

・       CAN Bus Protocols

CAN stands for Controller Area Network, which referred to a logical bus topology protocol. It is extensively used in Automotive Electronics. In the past, each ECU had to be connected to each other so as to communicate among them, resulting in a large mesh of wires. With the introduction of the CAN bus helps reduce the wire length as well as the overall complexity of connections in an automotive system although each ECU only need be connected to a single bus. As a result, the CAN bus protocol enables ECUs to communicate with each other without any complex and dedicated wiring in between.

Figure 3: Example of CAN Bus in an automotive vehicle

 

・       Ethernet Protocols

Ethernet is a communication infrastructure with the interconnection of units and components, which provides advantages over traditional fieldbus systems such as CAN bus, LIN bus, or FlexRay.

 Single-Pair Ethernet (SPE) is a version of Automotive Ethernet with single-pair twisted-pair cable that fulfills the stringent requirements for electromagnetic compatibility (EMC). Single-Pair Ethernet supports data rates ranging from 10 Mbit/s to 1 Gbit/s using 10Base-T1, 100Base-T1, and 1000Base-T1. This makes it capable of providing sufficient bandwidth while also ensuring low latency, equivalent to real-time behavior, thanks to Time Triggered Ethernet. IEEE 802.3 1000Base-RH is another approach to automotive Gigabit Ethernet. The physical layer of Automotive Ethernet operates in full-duplex mode with pulse amplitude modulation (PAM3).

The Ethernet standard is a highly reliable standard developed and tested over decades. Besides single-pair Ethernet (SPE), there are other Ethernet-based standards, such as AudioVideoBridging (AVB) and Time-Sensitive Networking (TSN), which offer low latency and high availability. Automotive Ethernet uses standard data transport protocols, such as IP, TCP, UDP,  ARP, ICMP, and DHCP. Specific application protocols for Automotive Ethernet include Diagnostics over IP (DoIP) and Scalable Service-Oriented Middleware over IP (SOME/IP). To properly connect different systems to Automotive Ethernet, interfaces such as Autosar, AVnu, or Open Alliance follow the Automotive Ethernet standard.

Figure 4: Image of Automotive Ethernet Protocols

 

AUTOSAR DIAGNOSTIC AND ERROR HANDLING

Diagnostic is a process to detect and classify symptoms, then determine the identify the root cause of abnormal operation so that a repair can be performed. A diagnostic protocol defines a set of conventions between a diagnostic device and an ECU in the vehicle.  There are three well-know diagnostic protocols widely used by OEMs and suppliers in the market as below:

・       KWP2000 – Keyword Protocol 2000

・       Diagnostics on CAN Protocol

・       UDS – Unified Diagnostic Services

AUTOSAR addresses error handling at the application level, which describes a sequence of steps of Fault Detection, Isolation, and Recovery (FDIR). Detection involves identifying when a fault has occurred, for instance, if a value is out of the range. Isolation refers to preventing the erroneous system from affecting other systems that depend on it, and Recovery involves restoring the system to its usual operation or with degraded functionality. Several types of errors are listed, including data, program flow, access, timing, and asymmetric errors. AUTOSAR provides a list of 13 error handling mechanisms that can be used at various levels of FDIR, but the developers are responsible for choosing the appropriate mechanisms.

Reference Link

https://www.autosar.org/nc/document-search/

https://www.autosar.org/fileadmin/standards/R22-11/CP/AUTOSAR_EXP_ApplicationLevelErrorHandling.pdf

https://www.autosar.org/fileadmin/standards/classic/4-0/AUTOSAR_SRS_Ethernet.pdf

https://www.autosar.org/fileadmin/standards/classic/4-4-0/AUTOSAR_SWS_CANInterface.pdf

Related blogs

Blog

20-11-2024

Gear Up for Next-Gen E/E Architecture with Zonal Compute: The Automotive Industry’s Game Changer

The road to software-defined vehicles is paved with innovative E/E architecture. OEMs and chipmakers, make strategic choices now! Today's car market is all about digital features, just like smartphones.  Features...

Blog

09-11-2024

Hitting the road faster with virtual ECU based on AUTOSAR

The Automotive Landscape The automotive industry is entering the era of Software-Defined Vehicles (SDVs), where vehicles' features and functions are predominantly driven by software. Users expect the same convenience from...

Blog

07-11-2024

Introduction to AUTOSAR

As modern vehicles become more complex and sophisticated, with hundreds of electronic control units (ECU) and thousands of lines of code, standardizing the software architecture and interfaces has become ever...

Top