

AUTOSAR Communication and Networking
02-11-2023

<p class="MsoNormal"><span style="font-weight: bolder;"><span style="font-size: 12pt; font-family: "Segoe UI", sans-serif;"><font color="#ffffff">OVERVIEW OF AUTOSAR COMMUNICATION AND NETWORKING<o:p></o:p></font></span></span></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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.<o:p></o:p></font></span></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff"> </font></span></p><p class="MsoNormal"><span style="font-weight: bolder;"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">AUTOSAR COMMUNICATION INFRASTRUCTURE AND PROTOCOL STACKS<o:p></o:p></font></span></span></p><p class="MsoNormal" align="center" style="text-align: center;"></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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.<o:p></o:p></font></span></p><p class="MsoNormal"><font color="#ffffff"><img src="https://imagemaaz2023.blob.core.windows.net/images/autosar-communication-1.png" style="width: 902px;"><br></font></p><p class="MsoNormal" align="center" style="text-align: center;"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">Figure 1: Components of AUTOSAR COMStack<o:p></o:p></font></span></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">Some of the important software modules in this stack are as follows:<o:p></o:p></font></span></p><p class="MsoListParagraph" style="margin-left: 0.5in; text-indent: -0.25in;"><font color="#ffffff">・<span style="font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-alternates: normal; font-kerning: auto; font-optical-sizing: auto; font-feature-settings: normal; font-variation-settings: normal; font-variant-position: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: "Times New Roman";"> </span><span style="font-weight: bolder;"><span style="font-family: "Segoe UI", sans-serif;">AUTOSAR COM:</span></span><span style="font-weight: bolder;"><span lang="JA"> </span></span><span style="font-weight: bolder;"><span style="font-family: "Segoe UI", sans-serif;"><o:p></o:p></span></span></font></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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.<o:p></o:p></font></span></p><p class="MsoNormal"><font color="#ffffff"><span style="font-family: "Segoe UI", sans-serif;"> </span><span style="text-indent: -0.25in; font-size: 1rem;">・</span><span style="text-indent: -0.25in; font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-alternates: normal; font-kerning: auto; font-optical-sizing: auto; font-feature-settings: normal; font-variation-settings: normal; font-variant-position: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: "Times New Roman";"> </span><span style="font-weight: bolder; text-indent: -0.25in; font-size: 1rem;"><span style="font-family: "Segoe UI", sans-serif;">PDU Router</span></span></font></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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.<o:p></o:p></font></span></p><p class="MsoNormal"><font color="#ffffff"><span style="font-family: "Segoe UI", sans-serif;"> </span><span style="text-indent: -0.25in; font-size: 1rem;">・</span><span style="text-indent: -0.25in; font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-alternates: normal; font-kerning: auto; font-optical-sizing: auto; font-feature-settings: normal; font-variation-settings: normal; font-variant-position: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: "Times New Roman";"> </span><span style="font-weight: bolder; text-indent: -0.25in; font-size: 1rem;"><span style="font-family: "Segoe UI", sans-serif;">Bus Specific Interface Modules</span></span></font></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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.<o:p></o:p></font></span></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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.<o:p></o:p></font></span></p><p class="MsoNormal"><font color="#ffffff"><span style="font-family: "Segoe UI", sans-serif;"> </span><span style="text-indent: -0.25in; font-size: 1rem;">・</span><span style="text-indent: -0.25in; font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-alternates: normal; font-kerning: auto; font-optical-sizing: auto; font-feature-settings: normal; font-variation-settings: normal; font-variant-position: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: "Times New Roman";"> </span><span style="font-weight: bolder; text-indent: -0.25in; font-size: 1rem;"><span style="font-family: "Segoe UI", sans-serif;">External Bus Drivers</span></span></font></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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.<o:p></o:p></font></span></p><p class="MsoNormal"><font color="#ffffff"><span style="font-family: "Segoe UI", sans-serif;"> </span><span style="text-indent: -0.25in; font-size: 1rem;">・</span><span style="text-indent: -0.25in; font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-alternates: normal; font-kerning: auto; font-optical-sizing: auto; font-feature-settings: normal; font-variation-settings: normal; font-variant-position: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: "Times New Roman";"> </span><span style="font-weight: bolder; text-indent: -0.25in; font-size: 1rem;"><span style="font-family: "Segoe UI", sans-serif;">Internal Bus Drivers</span></span></font></p><p class="MsoNormal" align="center" style="text-align: center;"></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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.<o:p></o:p></font></span></p><p class="MsoNormal"><font color="#ffffff"><br></font></p><p class="MsoNormal"><font color="#ffffff"><img src="https://imagemaaz2023.blob.core.windows.net/images/autosar-communication-2.png" style="width: 723px;"><br></font></p><p class="MsoNormal" align="center" style="text-align: center;"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">Figure 2: Flow of Communication Stack<o:p></o:p></font></span></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff"> </font></span></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">The above ComStack Flow can be divided into three sections A, B, C in respective.<o:p></o:p></font></span></p><p class="MsoListParagraph" style="margin-left: 0.5in; text-indent: -0.25in;"><font color="#ffffff">・<span style="font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-alternates: normal; font-kerning: auto; font-optical-sizing: auto; font-feature-settings: normal; font-variation-settings: normal; font-variant-position: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: "Times New Roman";"> </span><span style="font-weight: bolder;"><span style="font-family: "Segoe UI", sans-serif;">Section A: Data Transmission and Reception Management<o:p></o:p></span></span></font></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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:<o:p></o:p></font></span></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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.<o:p></o:p></font></span></p><p class="MsoListParagraph" style="margin-left: 0.5in; text-indent: -0.25in;"><font color="#ffffff">・<span style="font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-alternates: normal; font-kerning: auto; font-optical-sizing: auto; font-feature-settings: normal; font-variation-settings: normal; font-variant-position: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: "Times New Roman";"> </span><span style="font-weight: bolder;"><span style="font-family: "Segoe UI", sans-serif;">Section B: State Management</span></span><span style="font-family: "Segoe UI", sans-serif;"><o:p></o:p></span></font></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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.<o:p></o:p></font></span></p><p class="MsoListParagraph" style="margin-left: 0.5in; text-indent: -0.25in;"><font color="#ffffff">・<span style="font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-alternates: normal; font-kerning: auto; font-optical-sizing: auto; font-feature-settings: normal; font-variation-settings: normal; font-variant-position: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: "Times New Roman";"> </span><span style="font-weight: bolder;"><span style="font-family: "Segoe UI", sans-serif;">Section C: Network Management</span></span><span style="font-family: "Segoe UI", sans-serif;"><o:p></o:p></span></font></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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.<o:p></o:p></font></span></p><p class="MsoNormal"><span style="font-weight: bolder;"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff"> </font></span></span></p><p class="MsoNormal"><span style="font-weight: bolder;"><span style="font-size: 12pt; font-family: "Segoe UI", sans-serif;"><font color="#ffffff">AUTOSAR ETHERNET AND CAN BUS PROTOCOLS<o:p></o:p></font></span></span></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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.<o:p></o:p></font></span></p><p class="MsoListParagraph" style="margin-left: 0.5in; text-indent: -0.25in;"><font color="#ffffff">・<span style="font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-alternates: normal; font-kerning: auto; font-optical-sizing: auto; font-feature-settings: normal; font-variation-settings: normal; font-variant-position: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: "Times New Roman";"> </span><span style="font-weight: bolder;"><span style="font-family: "Segoe UI", sans-serif;">CAN Bus Protocols<o:p></o:p></span></span></font></p><p class="MsoNormal" align="center" style="text-align: center;"></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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.<o:p></o:p></font></span></p><p class="MsoNormal"><font color="#ffffff"><img src="https://imagemaaz2023.blob.core.windows.net/images/autosar-communication-3.png" style="width: 1040px;"><br></font></p><p class="MsoNormal" align="center" style="text-align: center;"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">Figure 3: Example of CAN Bus in an automotive vehicle<o:p></o:p></font></span></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff"> </font></span></p><p class="MsoListParagraph" style="margin-left: 0.5in; text-indent: -0.25in;"><font color="#ffffff">・<span style="font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-alternates: normal; font-kerning: auto; font-optical-sizing: auto; font-feature-settings: normal; font-variation-settings: normal; font-variant-position: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: "Times New Roman";"> </span><span style="font-weight: bolder;"><span style="font-family: "Segoe UI", sans-serif;">Ethernet Protocols<o:p></o:p></span></span></font></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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.<o:p></o:p></font></span></p><p class="MsoNormal"><font color="#ffffff"><span style="font-family: "Segoe UI", sans-serif;"> </span><span style="font-family: "Segoe UI", sans-serif; font-size: 1rem;">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).</span></font></p><p class="MsoNormal" align="center" style="text-align: center;"></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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.<o:p></o:p></font></span></p><p class="MsoNormal"><font color="#ffffff"><img src="https://imagemaaz2023.blob.core.windows.net/images/autosar-communication-4.png" style="width: 1040px;"><br></font></p><p class="MsoNormal" align="center" style="text-align: center;"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">Figure 4: Image of Automotive Ethernet Protocols<o:p></o:p></font></span></p><p class="MsoNormal"><span style="font-weight: bolder;"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff"> </font></span></span></p><p class="MsoNormal"><font color="#ffffff"><span style="font-weight: bolder;"><span style="font-size: 12pt; font-family: "Segoe UI", sans-serif;">AUTOSAR DIAGNOSTIC AND ERROR HANDLING</span></span><span style="font-weight: bolder;"><span style="font-family: "Segoe UI", sans-serif;"><o:p></o:p></span></span></font></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">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:<o:p></o:p></font></span></p><p class="MsoListParagraph" style="margin-left: 0.5in; text-indent: -0.25in;"><font color="#ffffff">・<span style="font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-alternates: normal; font-kerning: auto; font-optical-sizing: auto; font-feature-settings: normal; font-variation-settings: normal; font-variant-position: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: "Times New Roman";"> </span><span style="font-family: "Segoe UI", sans-serif;">KWP2000 - Keyword Protocol 2000<o:p></o:p></span></font></p><p class="MsoListParagraph" style="margin-left: 0.5in; text-indent: -0.25in;"><font color="#ffffff">・<span style="font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-alternates: normal; font-kerning: auto; font-optical-sizing: auto; font-feature-settings: normal; font-variation-settings: normal; font-variant-position: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: "Times New Roman";"> </span><span style="font-family: "Segoe UI", sans-serif;">Diagnostics on CAN Protocol<o:p></o:p></span></font></p><p class="MsoNormal"></p><p class="MsoListParagraph" style="margin-left: 0.5in; text-indent: -0.25in;"><font color="#ffffff">・<span style="font-variant-numeric: normal; font-variant-east-asian: normal; font-variant-alternates: normal; font-kerning: auto; font-optical-sizing: auto; font-feature-settings: normal; font-variation-settings: normal; font-variant-position: normal; font-stretch: normal; font-size: 7pt; line-height: normal; font-family: "Times New Roman";"> </span><span style="font-family: "Segoe UI", sans-serif;">UDS - Unified Diagnostic Services<o:p></o:p></span></font></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif; font-size: 1rem;"><font color="#ffffff">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.</font></span></p><p class="MsoNormal"><span style="font-weight: bolder;"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff">Reference Link<o:p></o:p></font></span></span></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff"><a href="https://www.autosar.org/nc/document-search/">https://www.autosar.org/nc/document-search/</a><o:p></o:p></font></span></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff"><a href="https://www.autosar.org/fileadmin/standards/R22-11/CP/AUTOSAR_EXP_ApplicationLevelErrorHandling.pdf">https://www.autosar.org/fileadmin/standards/R22-11/CP/AUTOSAR_EXP_ApplicationLevelErrorHandling.pdf</a><o:p></o:p></font></span></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff"><a href="https://www.autosar.org/fileadmin/standards/classic/4-0/AUTOSAR_SRS_Ethernet.pdf">https://www.autosar.org/fileadmin/standards/classic/4-0/AUTOSAR_SRS_Ethernet.pdf</a><o:p></o:p></font></span></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff"><a href="https://www.autosar.org/fileadmin/standards/classic/4-4-0/AUTOSAR_SWS_CANInterface.pdf">https://www.autosar.org/fileadmin/standards/classic/4-4-0/AUTOSAR_SWS_CANInterface.pdf</a><o:p></o:p></font></span></p><p class="MsoNormal" align="center" style="text-align: center;"></p><p class="MsoNormal"><span style="font-family: "Segoe UI", sans-serif;"><font color="#ffffff"> </font></span></p>