17^th international CAN Conference

The electronics, sensor assemblies and networks in automobiles are currently undergoing fundamental changes. Many new tasks can only be handled through use of modern information technology, including Automotive Ethernet and Internet Protocol (IP). Thus, in addition to classic signal-oriented communication, service-oriented communication has also become an aspect of automotive technology. The coexistence of classic and IP-based networks has resulted in an overlapping situation in the transmission speed range of 10 Mbit/s. While a suitable system is available from above in the form of 10 Mbps Ethernet (10BASE-T1S), the newest CAN development „CAN XL“ is pushing into the 10-Mbit/s domain from below. The two technologies are characterized by opposite operating principles, and for this reason the conditions under which CAN XL can handle service-oriented communication tasks – in addition to signal-based communication – is the subject of the current investigation. The following discussion focuses primarily on networks in automobiles.

CAN Signal Improvement technology can greatly simplify the creation of CAN FD networks at 2Mbps and allow much larger topologies to be supported than with standard High Speed CAN (HS-CAN) transceivers. However, increasing interest is also appearing to use CAN Signal Improvement technology to enable 5Mbps networks, further accelerating the achievable bandwidth with CAN FD. Traditional HS-CAN transceivers have been more or less limited to point-to-point networks at 5Mbps, impractical for use in many applications. In this paper, the background to this limit is explained and guidelines are shared on creating robust 5Mbps CAN FD networks based on our experiences of working with customers.

Security threats on In-vehicle-Network may compromise the safety of the vehicle, showing the importance of security in safety critical application like in the automotive industry. The current CAN communication protocols like Classical CAN and CAN FD use Secure Onboard communication (SecOC) to provide authenticity and replay protection for the CAN frames. Due to security overhead in the payload, it is most likely that the authentication code is truncated, leading to security compromises. Now being in the verge of defining a new protocol CAN XL, which expands the payload size up to 2 Kbytes of the data, gives the opportunity to use complete authentication code as part of the payload. Further, SecOC does not provide encryption of the payload (Confidentiality), unified freshness management, key management methods and easy adoption to future security ciphers. In this paper, we propose a CADsec protocol, which is efficient to implement, performant and flexible for future security needs to achieve secured CAN XL communication.

The “Classic” CAN bus has been the workhorse protocol used for automotive powertrain monitoring and control for decades. With demands for increased electronic content in next-generation automobiles, many systems are migrating to CAN FD (CAN with Flexible Data). This shift in technology to transmit and receive more bits in less time over relatively long distances brings with it new design and test challenges. This paper shows in a practical sense how to perform critical dynamic pulse parameter measurements including transceiver loop delay and recessive bit width using oscilloscopes. Also discussed is eye-diagram mask testing. Eye-diagram testing provides a physical layer analog signal quality test in one composite measurement.

The next generation of CAN communication is currently being specified inside the CiA’s CAN XL Special Interest Group. The new frame format combines Ethernet style frames with the non-destructive collision-resolution of CAN arbitration. Newly developed CAN XL transceivers with symmetrical bit levels in the data phase will enable a net bit rate of 10 MBit/s, but existing CAN FD transceivers may also be used, at lower bit rate. The new CAN XL frame format introduces a header CRC, a payload type describing the contents of the data field, and up to 2048 data bytes. After the arbitration is decided, the bit timing is switched from arbitration bit rate to data bit rate and the CAN XL transceivers are set into a high-speed operating mode. They return to arbitration mode before CAN style acknowledgement. This paper explains the CAN XL frame format in detail, especially the differences and the compatibilities between CAN XL and CAN FD. Further emphasis is placed on the introduction strategy of CAN XL nodes into existing CAN FD systems and on new communication concepts. Finally, the paper shows the impact of the longer payloads on the hardware implementation of CAN controllers.

CAN-XL as an improvement of the well-established CAN FD protocol increases payload and increases the average bit rate in a CAN network up to 12 Mbit/s. This article explains the new CAN XL transceiver approach and concept, the challenges in the networks and how to combine the CAN XL protocol with the existing CAN FD transceiver and CAN SIC Transceiver and the new CAN XL transceiver.

Today’s increasing demands on automotive system bandwidth cause a gap between well-established protocols like CAN and recently launched technologies such as 100BASE-T1 and 1000BASE-T1. To close this gab, system designers could choose one of three automotive protocols for 10-Mbit/s multi-node communication. While FlexRay is already available on the market, CAN-XL and 10BASE-T1S are currently under development, as they are still in the standardization phase. The basic question is the following: Which technology fits my system best? The answer given by the underlying analysis, with focus set on differences in protocol (data link), performance (physical layer), components and suitable in-vehicle network topologies, will help to take the right decision. General evaluations and comparisons are used to facilitate the correlation between a selected automotive use case and the reasonable communication protocol.

This paper presents the current state of CANopen FD conformance testing at CAN in Automation (CiA). CiA working group SIG testing works on next generation conformance test plan. The test plan should cover all necessary test cases to evaluate compliance of a designed CANopen FD device. Since the CiA 1301 conformance testing is required for any CANopen FD device, the test plan should cover every aspect and diversity of requirements to each kind of devices such as master-capable and slave devices. The conformance testing utilizes the lower test concept such as testing a device as a black box and testing only conformance of the implemented communication protocols and object dictionary to CiA 1301 specification. The upper test requires an application related simulator and therefore is not a part of a CANopen FD conformance testing. It is considered to describe test cases in CiA 1310-1 test plan specification in a scripting language such as JavaScript or PythonScript.

Classical CANopen devices that are confronted with a CANopen FD message will produce an error frame. Therefore, classical CANopen devices and CANopen FD devices cannot directly share the same transmission media. This is a challenge when migrating existing classical CANopen systems towards CANopen FD. The CANopen FD Smart Bridge introduced in this paper physically separates the classical CANopen and CANopen FD devices from each other. One port of the bridge runs in classical CANopen mode while the other runs in CANopen FD mode. The bridge physically separates the networks, but logically combines them to a single network. Where possible, the smart bridge hides protocol specific details and allows a single CANopen (FD) manager to communicate and handle all devices connected, no matter if they are “classical” or “FD”. Especially the service requests are converted from SDO to USDO and vice versa by the bridge. This paper shows both, the possibilities but also the limits of smart bridging different CANopen protocol variants.

The future of CAN is linked to the future of architectures in vehicles. This article considers the future of architecture from a physical layer point of view, too. The requirements for future architectures will developed by analyzing the past and the present.

Limitations in data communication bandwidth are caused by the layout of the CANbus. This is a general description and is valid for any communication cable with more than two devices connected to a common transmission line, such as CAN, LIN and 10BASE-T1S. All technology is evolved from point-to-point communication, where energy comes from a source at one end and is absorbed at the other. For a multidrop installation where devices are connected along the transmission line, the source can be anywhere along the line, whilst any other device can be the receiver. To absorb the energy, two terminations are placed at the furthest ends of the cable layout and all connected receivers will reflect the energy back to the CAN-bus. The best way to prevent oscillation is to use as low a slew-rate as possible.

CAN XL offers data rates and payload sizes that are many times higher than in Classical CAN and CAN FD [1], [2]. Besides this, CAN XL also provides improved error detection capabilities. Error detection is a crucial functionality provided by communication protocols. A receiving node has to be able to judge if a frame was received with or without errors. Autonomous driving and other safety relevant applications require that frame errors are detected with a very high probability. The acceptance of an erroneous frame should be practically impossible. This paper first introduces the three CAN Error Types known in literature that might occur in a frame in harsh environments: (1) bit error, (2) bit drop and bit insertion, (3) burst errors. The two main pillars of the CAN error detection mechanism are: (A) the cyclic redundancy code (CRC) check and (B) the format checks. Both pillars are strengthened during the currently ongoing specification of CAN XL, to fit to tomorrow’s applications. This paper explains how these pillars were improved. Therefor it shows the reasons for the chosen CRC concept of having both a header CRC and a frame CRC in a CAN XL frame. Further, it introduces the available format checks in CAN XL. Finally, the paper shows systematically how the CAN XL error detection mechanisms master to detect the three error types. A deep dive into the properties and strengths of the used CRC polynomials is given in [9].

Securing existing industrial communication protocols like Controller Area Network - CAN (FD) - requires a look at all protocol layers. Although security solutions are known on separate layers, there are practical limits to their application. As an example, adding multiple security layers to a simple I/O node like an encoder might not always be feasible due to resource constraints in small microcontrollers. Our paper examines, how security solutions for individual layers can be combined to best complement each other in a real-world CAN/CANopen system. The discussed complementary security mechanisms are: Black- and white-list filtering of the received and transmitted CAN (FD) frames, plus limitation of the transfer rate of individual devices (flood protection) and secure configuration methods; Authentication of CAN (FD) frames and secure grouping with CANcrypt; End-to-end security protocols like TLS to typically secure communications beyond the local network and to implement remote end-to-end security, for example for remote diagnostics We investigate on the entire lifecycle of a system from production to integration, commission/adding/removing components, key distribution and management, as well as diagnostics and service. Always considering resource requirements, we examine the limits of each method and show how they can complement each other and significantly improve overall system security with a smart combination of security mechanisms.

The increasing complexity and size of modern CANopen and CANopen FD networks creates new challenges for system designers and device developers how to decide which CANopen node-ID should be used for their CANopen devices. This becomes more difficult in systems which are highly dynamic or having multiple devices of the same type in the network, like cascaded battery systems. Sometimes it is doesn’t even matter for the system which node-ID a device has. This paper discusses a theoretical approach how devices in a CANopen or CANopen FD network could negotiate their node-ID by themselves.

There are many reasons for a CAN system to be benchmarked or reverse engineered. An example is when full documentation unavailable and conversion to an electric powertrain is needed. A technique is described that uses an electrical signal fingerprint of a CAN message. This fingerprint is a way of associating messages to an ECU without any prior knowledge of the system. Its use is discussed in a number of case studies. In an automotive application, diagnostic responses from an ECU, whose identifiers are standardised, are matched with the unknown real-time CAN messages, so that the transmitting ECU is determined. Diagnostics parameters can then be used to discover real-time CAN signals by taking advantage of knowledge of typical automotive electronics. For example, wheel speed signals are transmitted by the braking ECU and the diagnostic parameters relating to vehicle speed can be correlated with only the braking real-time CAN messages. A similar approach is carried out on a truck based on the J1939 protocol it is typical that a significant number of messages are not standard and therefore unknown. Finally, in a marine application with little info known, electrical fingerprinting was used to confirm which ECUs were on the network.

An increasing number of small actuator and sensor devices require a lightweight communication protocol based on and compatible to CAN FD that is integrated in monolithic silicon devices and works without the need of costly external components like crystals. The controller of these actuators uses a subset of the standard CAN FD protocol for communication.

System monitoring features are needed throughout the systems life cycle, but development and maintenance of such are experienced as lower priority and less important than primary controls. This paper presents an automated workflow for generation of such GUI, based on CANopen projects and targeted for typical embedded displays. Main challenge is that CANopen projects are not capable of define logical device locations relative to each other. The challenge has been solved by creating a connection to electric schematics in order to determine logical device locations and device interconnections. Further challenge is how to assign device screen coordinates. It is impossible to automate assignment in general and computer aided manual assignment has been developed instead. All information has been merged into a GraphML project file, from which the target specific GUI configuration may be generated. Main focus has been in a workflow enabling efficient work. Computer aids has been selected to phases, where full automation does not make sense. Schematic parsing has been isolated as a component, enabling flexible adaptation to various schematic formats. The presented workflow intrinsically supports iterative development and efficient information re-use. It is also compatible with the most common CANopen and application development tools in the market.

Cybersecurity is getting more attention as devices, systems, companies are getting hacked. At previous iCCs different solutions have been presented, which solve singular problems. Different standards have been developed or are still work in progress like ISO 27001 (IT), IEC 62443 (industrial) and ISO 21434 (automotive). Those standards do not specify any technology as such to solve the problem of cybersecurity but define processes and procedure to classify security threats and how to cope with it.

In many applications ranging from the utility vehicle, industrial and building technology fields to the medical field, automation components work together based on the CANopen standard. It should be easy to couple sensors, actuators, operating units and controllers to one another according to the plug and play principle. To meet this demand, significant testing effort is required on the part of the manufacturer, as is a proper device description file. This article presents a new approach to testing where the virtualization of CANopen devices, a clever abstraction principle and test automation play a central role. The concept reduces the time and effort required for testing while also ensuring both a greater depth of testing and quality of CANopen devices.

In this paper, CRC generator polynomials for detection of transmission errors in headers and frames of the upcoming CAN XL standard are proposed. Their properties, which are chosen such as to provide state of the art error detection performance (compared to competing standards) in the CAN XL scenario, are described. These properties include achieving Hamming distance six for the full range of possible message lengths. At the beginning of the paper, a self-contained recap of CRC codes is given.

Since the CAN in Automation (CiA) has published the CiA 1301 – CANopen FD in September 2017, one CiA technical group discusses how CANopen Layer Setting Services (LSS) should be adapted to CANopen FD. LSS Fastscan service (CiA 305) used in the CANopen for identifying unconfigured LSS slaves is complex and requires up to 128 messages exchanged. Benefited from the larger payload of the CANopen FD, the full 128-bit LSS address can be sent in one request of the new service – LSS switch state selective FD service. This new service is totally different to Fastscan and will be specified in the CiA 1305 document, which is currently under development. This article introduces the operating principles of the new service, the service and protocol specification, and the operation sequences, as how to identify LSS slaves if LSS addresses are known or unknown.

The CAN XL data link layer protocol provides a data field with up to 2048 byte. It can be used for backbone networks. Due to the long data field, this protocol is able to transmit multiple Data-PDUs even in one single CAN XL data frame. This means, a CAN XL network can be shared by several applications using different application layer approaches. This paper shows the options and limits as well as the requirements on the header/footer supporting homogeneous and heterogeneous multiple Data-PDUs.

The CAN network is designed to serve local systems with a relatively small number of nodes and bitrate. Transferring CAN frames over Ethernet is an efficient way of connecting multiple CAN domains using proven and cost-effective technology. The set of Time Sensitive Networking (TSN) standards made possible very low latency, low jitter and reliable communication and enabled the use of Ethernet networks for real-time control applications. CAN and TSN Ethernet endpoints and networks are expected to co-exist and cooperate in the same systems in the near future. The development of such hybrid-protocol systems requires gateways enabling communication between the CAN and Ethernet domains. This paper describes the architecture of a CAN-to-TSN gateway providing bridging functionality between CAN/CAN-FD buses and a TSN Ethernet network.