

AUTOSAR Communication and Networking
02-11-2023

<p class="MsoNormal"><b><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif"><font color="#ffffff">OVERVIEW
OF AUTOSAR COMMUNICATION AND NETWORKING<o:p></o:p></font></span></b></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"><b><span style="font-family:"Segoe UI",sans-serif"><font color="#ffffff">AUTOSAR
COMMUNICATION INFRASTRUCTURE AND PROTOCOL STACKS<o:p></o:p></font></span></b></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;mso-bidi-font-weight:bold"><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:.5in;mso-para-margin-left:0gd;
text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><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><!--[endif]--><b><span style="font-family:"Segoe UI",sans-serif">AUTOSAR
COM:</span></b><b><span lang="JA"> </span></b><b><span style="font-family:"Segoe UI",sans-serif"><o:p></o:p></span></b></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><b style="text-indent: -0.25in; font-size: 1rem;"><span style="font-family:"Segoe UI",sans-serif">PDU
Router</span></b></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><b style="text-indent: -0.25in; font-size: 1rem;"><span style="font-family:"Segoe UI",sans-serif">Bus Specific Interface Modules</span></b></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><b style="text-indent: -0.25in; font-size: 1rem;"><span style="font-family:"Segoe UI",sans-serif">External
Bus Drivers</span></b></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><b style="text-indent: -0.25in; font-size: 1rem;"><span style="font-family:"Segoe UI",sans-serif">Internal
Bus Drivers</span></b></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;mso-bidi-font-weight:bold"><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:.5in;mso-para-margin-left:0gd;
text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><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><!--[endif]--><b><span style="font-family:"Segoe UI",sans-serif">Section
A: Data Transmission and Reception Management<o:p></o:p></span></b></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:.5in;mso-para-margin-left:0gd;
text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><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><!--[endif]--><b><span style="font-family:"Segoe UI",sans-serif">Section
B: State Management</span></b><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:.5in;mso-para-margin-left:0gd;
text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><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><!--[endif]--><b><span style="font-family:"Segoe UI",sans-serif">Section
C: Network Management</span></b><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"><b><span style="font-family:"Segoe UI",sans-serif"><font color="#ffffff"> </font></span></b></p><p class="MsoNormal"><b><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif"><font color="#ffffff">AUTOSAR
ETHERNET AND CAN BUS PROTOCOLS<o:p></o:p></font></span></b></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:.5in;mso-para-margin-left:0gd;
text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><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><!--[endif]--><b><span style="font-family:"Segoe UI",sans-serif">CAN
Bus Protocols<o:p></o:p></span></b></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;mso-bidi-font-weight:bold"><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:.5in;mso-para-margin-left:0gd;
text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><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><!--[endif]--><b><span style="font-family:"Segoe UI",sans-serif">Ethernet
Protocols<o:p></o:p></span></b></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;mso-bidi-font-weight:bold"><font color="#ffffff">Figure 4: Image
of Automotive Ethernet Protocols<o:p></o:p></font></span></p><p class="MsoNormal"><b><span style="font-family:"Segoe UI",sans-serif"><font color="#ffffff"> </font></span></b></p><p class="MsoNormal"><font color="#ffffff"><b><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif">AUTOSAR
DIAGNOSTIC AND ERROR HANDLING</span></b><b><span style="font-family:"Segoe UI",sans-serif"><o:p></o:p></span></b></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:.5in;mso-para-margin-left:0gd;
text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><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><!--[endif]--><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:.5in;mso-para-margin-left:0gd;
text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><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><!--[endif]--><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:.5in;mso-para-margin-left:0gd;
text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><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><!--[endif]--><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"><b><span style="font-family:"Segoe UI",sans-serif"><font color="#ffffff">Reference
Link<o:p></o:p></font></span></b></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>