The Open Question About PDU Routing
In previous blogs, we have elaborated on GuardKnox’s CommEngine™, its functions, and how it enables effective and secure communication within a vehicle and towards external networks.
While the product development approach chosen by GuardKnox delivers significant benefits to vehicle network designers, the requirements for most of the functions appear to be quite obvious if one is familiar with automotive networking. There is one question that we keep receiving from many readers about supporting Level 5 AUTOSAR PDU routing.
This requirement can only be understood by a more in-depth consideration of the way information is transported across different types of networks inside a vehicle.
Recap of Automotive Communication
Different functions within a vehicle can have very diverse communication requirements in terms of the amount of information they need to convey, their speed, real-time characteristics, reliability, and security needs. Therefore, ECUs with similar requirements and functional relations are grouped together in zones tied together by a zonal network. A zonal controller acts as a gateway between each zone and a high-speed backbone network, allowing each zone to use the networking technology best suited to the specific transmission requirements and the target cost.
Many functions inside a car only require comparatively simple communications. For example, pushing or releasing a button can be represented by a signal using a single bit that can be transmitted at a low bit rate. Classical CAN is widely used for such functions because the ECUs based on this technology are very mature and have been cost-optimized. However, not every button is represented by a single CAN frame because it would create undue transmission overhead. Instead, the respective ECU can map multiple signals to one transmission frame for payload optimization.
The AUTOSAR PDU
In order to create a level of abstraction for signals from the physical entity of their ECU, AUTOSAR has introduced the concept of an AUTOSAR PDU (Protocol Data Unit). With AUTOSAR, signals are no longer directly mapped to CAN transmission frames but to technology-agnostic PDUs that are transported within frames. In Figure 1 the combination of CAN-ID and the payload forms the AUTOSAR PDU.
Figure 1: Signal to PDU mapping
Thus, these PDUs can travel across the entire vehicle network of networks, independent of the underlying transmission technologies. For example, PDUs with signals resulting from some push buttons or switches can travel across multiple networks to a central computing platform where the necessary actions will be determined.
The transmission technology used in the backbone can have different characteristics compared to those in the zones connected to it. Initially, a new CAN technology – CAN FD - was developed for backbone transmission purposes with a 2Mbps transmission rate. For modern vehicles, however, this bitrate is way too low. Therefore, for vehicle backbones, typically automotive Ethernet (100BASE-T1 or 1000BASE-T1) is used today.
The Old Dilemma – Transmission Efficiency VS. Processing Load
As Ethernet can support larger networks and provide more functionality than CAN, the Ethernet frame header is significantly larger. Every Ethernet frame uses 42 bytes of overhead (including preamble, FCS, inter-packet gap...). The payload must not be smaller than 64 bytes. This means that the shortest Ethernet frame is 106 bytes long. If this frame would only carry a few bytes that represent a few push buttons the transmission efficiency of the backbone network would be extremely low. Therefore, the zonal controllers dynamically aggregate multiple PDUs into a single multi-PDU frame. Every PDU receives a header containing an ID and a data length code (DLC).
Figure 2: PDU mapped to a multi-PDU
Figure 2 shows the arrangement of PDUs in a multi-PDU frame. A header value of 0 marks the end of a sequence of PDUs. This multi-PDU is then mapped into a transmission frame.
In order to better understand the need behind PDU routing, we have to understand what happens at the receiving end of such a multi-PDU “container”.
A multi-PDU receiver has to listen to the entire frame and analyze every PDU header to find out whether the PDU is relevant for it or not. If it is not relevant, it discards the PDU and continues with the analysis, searching for the next PDU. For a low-cost ECU this may result in a processing load that exceeds its capabilities.
PDU Routing Comes To The Rescue
In the case of Ethernet, there are several options for the communication topology but there will only be one directly connected zonal controller per Ethernet interface of an automotive router or for a computing platform. Other controllers can be reached via multiple hops.
Any communication controller, whether it is integrated with a computing platform or a dedicated automotive router, must only send those PDUs on a particular link that are relevant for the endpoints connected to that link.
In addition, if a zonal controller supports multiple CAN buses, it will route the PDUs in the direction of the buses such that only the PDUs relevant for the ECUs on a particular bus will be forwarded to that bus. These ECUs usually would not be able to handle an unnecessarily high load of filtering out irrelevant PDUs.
The modern vehicle is beginning to enjoy backbone capacities of multiple gigabits per second instead of legacy backbones and their respective restrictions. Therefore, the real-time PDU processing should not be performed by an expensive and powerful processor but instead be part of a generic switching and routing hardware implementation. This is the reason why the GuardKnox CommEngine™ contains AUTOSAR PDU routing functionality.
Conclusion
In automotive networks, the AUTOSAR PDU serves as a fundamental element for communication by supporting the abstraction of logical signals from physical devices. Since many of these PDUs are quite small there is a need to aggregate a number of them in order to reduce the relative protocol overhead in the vehicle’s backbone network.
Filtering individual PDUs from a multi-PDU is a compute-intensive task which low-cost ECUs cannot perform. Therefore these ECUs should only receive PDUs that are destined for them. All other PDUs have to be filtered away by a communication controller. Since the backbone bitrates in modern vehicles are in the multi-gigabit per second range this filtering has to be supported by a hardware implementation, like in the GuardKnox CommEngine™.
Don’t forget to share this post
