The ubiquitous CAN in-vehicle network technology has been with us for quite a long time, originally developed in the mid-1980s to solve the problem of inter-control unit (ECU) communication. At that time vehicle electronic systems were becoming more complicated, with a greater need for communication between nodes. This need has developed exponentially over time with more nodes and greater bandwidth required. However, CAN has stood the test of time and is now being developed further to increase bandwidth in order to support future driving assistance sensor technology, involving computer vision and imaging, that requires much higher bandwidth than the original CAN protocol can handle.
In parallel, the original developer of CAN – Bosch – saw that other protocols were being developed and were highlighting the limitations of 1st generation CAN. In order to retain their dominance, Bosch developed CAN-FD, this uses a “flexible” data rate within a data message, in order to optimise the message structure and be able to transfer data faster within a given message – thus increasing the overall data throughput. This was a good interim solution and is fully compatible with older CAN hardware, allowing a mix of CAN and CAN-FD transmission, using existing network systems – saving costs for OEMs and allowing them to retain the elegant simplicity and robustness of CAN networking.
In most applications, CAN operates at a transmission rate of 500 KBit and is used in automotive areas such as engine and powertrain management. It can be deployed along with complimentary networks such as CAN-FD or Flexray, that have transmission rates in the range of 1 to 10 MBit. These latter systems are more applicable to time-critical applications in body and chassis control, for example, ABS, Traction control etc. MOST is another bus network that should be mentioned, it is used for infotainment applications, with higher bandwidth but reduced focus on robustness and determinism of transmission, it covers the 25 to 150 MBit transmission frequency range
In current times though, requirements are shifting again. The advent of driver assistance systems and intelligent mobility functions, along with increasingly complex powertrains means that CAN based data throughput is again becoming limited with respect to the application – due to the adoption of vehicle based computer vision systems, i.e. imaging systems that transfer huge amounts of data for obstacle and signage recognition systems.
So, it looked like CANs future was in the balance, especially as Automotive Ethernet is also in the pipeline and can support the required needs for ECU access and data transfer. In response, CAN is taking another step forward, in the form of CAN XL.
CAN XL fills the gap between CAN-FD and Automotive Ethernet (Source: Bosch Semiconductors)
Mixed CAN-FD / XL networks are possible (Source: Bosch Semiconductors)
This is an incremental development of CAN/CAN FD and operates largely on the same principles of transmission and protocols. A CAN message can be considered in 2 parts - arbitration and data phases. CAN XL uses low transmission speeds of 500 KBit to 1 Mbit in the arbitration phase, but the speed in the data phase is scalable over a wide range of 2Mbit to 10 Mbit. The benefit of this is that it can potentially enable future automotive communication systems, to package Ethernet frames within a CAN XL message, thus allowing the use of IP communication via CAN XL. These provides the system designer with full flexibility to adjust the network to the system requirements. Note that this bit rate switching within a message concept was first introduce with CAN-FD (i.e. flexible data rate).
Service and Signal oriented data on vehicle networks
High-performance driver assistance sensor systems such as RADAR, LIDAR and Video systems are essential for autonomous driving. But they generate massive amounts of data, to meet this challenge the industry has introduced Automotive Ethernet for fast transmission of data, covering primarily bandwidths of 100...1,000 Mbit/s (100BASE-T1,1000BASE-T1). This protocol has mostly been applied only in the areas of the ADAS systems so far. Note that this type of data relies on service-oriented communication, and this works well with Ethernet and IP technology. These applications basically need data and services, but it does not matter where it comes from or what node on the network provides it. The volume of data to be transmitted in these sensor data fusion applications is generated during the runtime of the application, such that data of this type cannot be mapped statically; instead, the communication system must serialize the data during run time. This requires a dynamic link connection between data sink (consumer) and data source (provider). So, the ability to transmit dynamic data structures is an inherent advantage of service-oriented communication.
CAN XL is designed to be able to incorporate Automotive ethernet data within the message packets (Source: Vector)
In contrast, the current automotive networks (such as CAN/CAN FD and Flexray), employ signal-based communication technology (CAN XL is also signal based) – and this is dominant in Automotive control applications. A significant feature of signal-based communication is the predefined static communication matrix. Signals such as temperatures, pressures, speeds or positions always represent the same fixed parameters, and those are mapped to a pre-defined CAN frame and broadcast on the network to all connected ECU nodes. With respect to classical ECU tasks, the signal-based approach has been tested and proven for almost three decades – along with the CAN message priority principle – as this system constellation can really satisfy the necessary level of performance for real-time control requirements.