The automotive industry is moving towards the Software-Defined Vehicle (SDV) in combination with the trend of electrification, which requires a different approach to design a vehicle and its network architecture. Both functional flexibility and power optimization will be key in achieving the highest performance and cost efficiency for the Software-Defined Electric Vehicle (SDEV). CAN Partial Networking with Signal Improvement (CAN SIC) is expected to play a vital role in this transformation.

CAN security gateways are commonly deployed to keep untrusted parts of a vehicle away from the trusted part. Although conceptually simple, they often introduce subtle problems that can escape detection in testing and only manifest after a vehicle is deployed or experiences a sophisticated security attack. In particular, there are common problems with the handling of transmitted frames that can lead to the intermittent failure of cryptographic protections, loss or corruption of messages and disruption of the traffic on the protected CAN bus. Avoiding these problems are part of the requirements for a robust security gateway.

CAN XL addresses the increasing bandwidth requirements of modern automotive systems. Due to the easy adaptation and reusability of the already existing CAN protocol, which is probably the most widespread network protocol in vehicles, the flexible data rate and the much higher payload offer a good solution to the constantly growing flow of information. However, the protocol itself presents some challenges to the designer. The dynamic behaviour of a system cannot be predicted by manual calculations. This forces designers to use simulation or measurement to analyse the network for robust design and to investigate critical effects that change as CAN evolves. While the propagation delay was the limiting factor for high-speed CAN networks, this changed completely with CAN FD and SIC. In the case of CAN XL, the impact of the new transceiver and protocol modifications such as the stuffing rule or the switch between SIC and FAST mode must be checked. All of this ends up in having a validation of the physical layer to improve the signal quality and ensure correct communication with accurate results even under worst case conditions.

Eye diagrams are a popular method for quickly evaluating the signal integrity of serial data systems. In this article, we would like to explain how to generate eye diagrams and how they can be applied to CAN. Additionally, we will discuss how to generate separate eye diagrams for the arbitration and data phase of CAN signals, and what valuable information they provide. Finally, we will discuss how to use the information gained from the eye diagrams to evaluate a CAN network.

Host controllers in embedded networks are responsible for a comprehensive network configuration, during start-up and operation. They manage the network, with special regard to the current status of the application. They take care for the availability, the energy consumption, the safety, and the cybersecurity of the application. Additionally, they may host a gateway to web-based applications.

This paper provides an overview about the tasks of embedded host controllers and the harmonized solutions, provided in CiA’s CANopen specifications. Additionally, the update of these specifications with regard to CANopen FD and today’s requirements on future embedded network management are discussed.

This abstract underscores the imperative of achieving functional safety in data communication for industrial machines, with a special focus on the CAN (Controller Area Network) and CANopen protocols. These safety-critical systems, including construction machines, mobile cranes, waste collection vehicles, metal presses, and manufacturing shopfloor machinery, necessitate resilient data communication.

Notably, the international standard EN 50325-5, known as CANopen Safety, has provided a robust foundation for such networks. However, as technological advancements continue to shape the industrial landscape, this standard is undergoing revision. The revised standard offers an opportunity to incorporate new insights and lessons learned over recent years.

Moreover, it‘s essential to recognize the emergence of new embedded networks and protocols, such as CAN FD (Flexible Data Rate), CANopen FD, and CAN XL. These protocols introduce enhanced features, including increased data transmission speeds and larger data payloads. Nevertheless, their adoption may also necessitate reevaluating functional safety requirements, as they differ from the CANopen Safety standard, which relies on the gray channel approach.

Engineers and practitioners are encouraged to leverage the upcoming revision of EN 50325-5 as a foundational reference to develop updated functional safety requirements. These requirements should not only address the evolving CAN/CANopen landscape but also consider the implications of new protocols like CAN FD, CANopen FD, and CAN XL. This endeavor aims to ensure that industrial machinery continues to operate safely and efficiently in a rapidly advancing technological environment.

For well-known reasons (e.g. ADAS), ever faster data connections have been integrated into vehicles in recent years. Consequently, the CAN bus has also been further developed, from CAN via CAN-FD and CAN-SIC to the current CAN-XL. This article shows the current status of EMC investigations in the vehicle. It compares different IC implementations and their EMC behavior in terms of interference emissions and interference immunity in the vehicle.

Message end-to-end (E2E) protection is required for safety critical functions used in automotive, industrial and other applications. A cyclic-redundancy check as it is part of the CAN protocol is not sufficient for these message protection needs. Other failure mechanisms like the ones specified in ISO 26262 must be respected as well.

The presentation describes an E2E message protection proposal for small devices with a monolithic CAN FD light responder implementation. These circuits do not embed a computation core capable of running software. Therefore the implementation must be done entirely in hardware. The proposed E2E message protection scheme is based on AUTOSAR E2E profiles adapted to the constraints and limitations of monolithic integrated devices used for actuators and sensors that are only able to contain a limited amount of digital functions.

NMEA 2000 is a plug-and-play communications CAN-based standard used for connecting marine sensors and display units within ships and boats. It sits amongst other NMEA marine communications protocols from NMEA 0183 at the lower-end through to the Ethernet-based NMEA OneNet standard. NMEA 2000 itself uses many of the features that are in common with SAEJ1939 and ISO11783. The standard has enabled the easy integration of electronic devices into a vessel. However, as with all CAN-based protocols, several vulnerabilities to cyberattacks have been identified. Many are at the CAN level, whilst others are in common with those protocols from the SAEJ1939 family of protocols. Some are unique to NMEA 2000. This paper will discuss the known vulnerabilities that have been identified with the NMEA 2000 protocol. These include weaknesses with the address claim and transport protocols, and covert communication channels using methods based on steganography.

The paper presents the different CAN-based solutions for body builder networks on the example of truck-mounted cranes and other applications provided by Palfinger. It explains also the need of standardized CAN interfaces to the IoT world (telematic gateway unit), to fleet management systems (FMS), and in-vehicle networks (IGU). Additionally, the paper discusses future functionality such as a secondary user interface for body applications located in the driver cabin, for example. The desired (e)PTO (power take-off) management, when implementing several body applications on one vehicle is addressed, too.

The paper presents the current already published standards (DIN 4630, DIN 14704, etc.) as well as the needed improvements to meet the requirements of future body applications on trucks and trailers. Because some body builders use J1939-based higher-layer protocols and others prefer CANopen, both application layers are supported in DIN 4630.

FlexRay was designed to provide a high performance networking technology to cope with time critical communication demands in drive- and powertrain control loops between ECUs distributed throughout the car. Due to its complexity, limitations and involved costs, it only found its use in premium cars and chip supplier as well as OEM market acceptance was not the best.

The VW group has started to consolidate its EE architectures towards E32.0 for all types of cars, e.g. volume, premium, sports etc. and a solution was required to have one technology for all, together with some other handy features and thus, supported the development of the next generation CAN networking technology, named CAN-XL.

This article/presentation will show the challenges and gained possibilities of migrating FlexRay networks to CAN-XL using the example of the powertrain, also considering CAN-FD and why it is only an intermediate solution.

The throughput of a simple point-to-point data link is dependent on two things: the link- speed and the relation between payload and overhead. A multidrop network adds the complication of having to factor in waiting for access to the shared medium. Classical CAN, CAN-FD and CAN-XL comes with built-in multidrop support and a communication protocol beneficial to this kind of structure.

10BASE-T1S and 10BASE-T1M using PLCA or D-PLCA aims to solve the access problem, but for a multidrop Ethernet bus. As these protocols all try to solve a similar problem, comparisons between them can assist a system designer decide which to use. But as they are implemented similarly yet differently it can be difficult to discern which protocol fit better than another. This paper aims to describe a couple of scenarios and show why one protocol may be better suited than another in those cases.

Typical RTOS general-purpose CAN bus subsystems offer interfaces that queue CAN messages for transmission in FIFO order. This leads to bus arbitration priority inversion situations when a critical message is sent after a low-priority one and a bus is fully loaded by another device. This is usually solved by adding FIFOs for different traffic classes. The presented solution allows the dynamic redistribution of a fixed set of CAN controller transmission buffers to these classes. The CTU CAN FD open-source IP core has been chosen as the first supported device because it allows transmission order reassignment of these buffers on the fly.

The current work targets an open-source RTEMS executive because it needs a new full- featured CAN/CAN FD stack. The executive is used in satellites and critical applications and CAN bus popularity is rising in these areas. The project builds on the infrastructure designed for LinCAN driver used in GNU/Linux real-time applications for decades, even before SocketCAN.

When tested on CTU CAN FD and RTEMS, other RTEMS CAN drivers can be ported to the framework. It can even be used for SocketCAN driver updates when Linux kernel network interface multiple queues are used, as well as for NuttX drivers.

The CiA 307 document “Framework for maritime electronics” /1/ was the initial approach to use two CAN cables for mission-critical application in the year 2004. However, this standard was only applicable for classical CANopen and it has been withdrawn meanwhile. Based on the original ideas of the CiA 307 document, a new standard has been developed, called dual-modular redundancy (DMR). The DMR is suitable for CAN as well as CAN FD networks and can be used to implement CAN devices and CAN networks with the need of safety- critical, mission-critical and high-availability communication. The DMR has been designed to be independent from an application layer like CANopen, CANopen FD, J1939 or any other system specific application.

In automotive and industrial applications, the data communication volume increases and the bit rate in these communication technologies has to be increased too. At the beginning of the CAN story, 1Mbit/s was high a speed bit rate. But now with CAN XL, up to 20Mbit/s in the data phase are possible. Compared with other communication technologies CAN physical layer based on a bus structure and supports collision during communication. The article explains the new CAN SIC XL physical layer concept and the impact on the typical CAN bus topologies.

NMEA 2000 is a plug-and-play communications CAN-based standard used for connecting marine sensors and display units within ships and boats. It sits amongst other NMEA marine communications protocols from NMEA 0183 at the lower-end through to the Ethernet-based NMEA ONENET standard. NMEA 2000 itself uses many of the features that are in common with SAEJ1939 and ISO11783. The standard has enabled the easy integration of electronic devices into a vessel.

However, as with all CAN-based protocols, several vulnerabilities to cyberattacks have been identified. Many are at the CAN level, whilst others are in common with those protocols from the SAEJ1939 family of protocols.

This paper will discuss the known vulnerabilities that have been identified with the NMEA 2000 protocol. These include weaknesses with the address claim and transport protocols, and covert communication channels using methods based on steganography. Activities with the aim of making NMEA 2000 robust to cyberattacks are described.

CANopen is used in an ever-growing range of application fields such as railway applications, building automation, medical equipment and more. With the expansion to new application areas, the complexity of the CANopen devices increases as well. At the same time, the devices must adhere to a greater number of standards and requirements. As the complexity and variety of requirements increases, so does the need for a suitable method to ensure that the devices fulfill the chosen requirements. One way to meet this demand is thorough testing which includes hardware-in-the-loop tests. A key feature of such tests is that they are automated in order to provide reproducibility, consistent report generation and fast execution without human involvement. Moreover, fully automated tests can be used as regression tests throughout the entire development cycle. In this paper we present a use case study on how to perform automated hardware-in-the-loop tests for a CANopen NMT server device.

NMEA 2000 is a plug-and-play communications CAN-based standard used for connecting marine sensors and display units within ships and boats. It sits amongst other NMEA marine communications protocols from NMEA 0183 at the lower-end through to the Ethernet-based NMEA ONENET standard. NMEA 2000 itself uses many of the features that are in common with SAEJ1939 and ISO11783. The standard has enabled the easy integration of electronic devices into a vessel.

However, as with all CAN-based protocols, several vulnerabilities to cyberattacks have been identified. Many are at the CAN level, whilst others are in common with those protocols from the SAEJ1939 family of protocols.

This paper will discuss the known vulnerabilities that have been identified with the NMEA 2000 protocol. These include weaknesses with the address claim and transport protocols, and covert communication channels using methods based on steganography. Activities with the aim of making NMEA 2000 robust to cyberattacks are described.

Given the rise of automotive Ethernet and in view of the growing number of communication systems, a consolidation appears reasonable to limit complexity and costs. With Ethernet now covering infotainment, ADAS, telematics and connectivity at 100...1000 Mbit/s, CAN and CAN FD operate in the range of 0.5...5 Mbit/s and are responsible for engine management, and body control. CAN XL or 10BASE-T1S can potentially be used in the future for control systems.

Considering that about 90 % of all network nodes communicate at speeds below or up to 10 Mbit/s, the 10 Mbit/s domain covers a wide field of application.

This paper discusses the two SAE J1939 standards for functionally safe communications on Classic CAN (SAE J1939-76) and CAN FD (SAE J1939-77). For SAE J1939-76, it describes the Safety Header Message (SHM) and Safety Data Message (SDM) pairing approach used to communicate safety-related data from a producing safety application to a consuming safety application. In addition, it details the features of the version as published in 2020 and lists the deficiencies of this version. Finally, it details features of the revision currently under development that make up for these deficiencies. For SAE J1939-77, it describes the use of space allocated for functional safety assurance information in the Multi-PG and FD Transport protocols to communicate safety-related data from a producing safety application to a consuming safety application. In addition, it describes the three profiles currently under development that are tailored to meet different system needs while still meeting functional safety requirements.

When designing a CAN XL bus system, one main target is to achieve a reliable communication under all operating conditions. Therefore, the system designer needs to consider many constraints and to choose the proper bit timing configuration. The two most relevant constraints are the frequency tolerance df of the clock source and the asymmetry of the bit lengths caused by physical layer effects. This paper derives the formulas to calculate the maximal clock tolerance df for CAN XL.

Then it evaluates and compares the df of CAN FD and CAN XL. Furthermore, this paper adapts the metric called “phase margin”, known from CAN FD, to CAN XL. This metric allows to assess the robustness of a CAN XL bus system, i.e., up to which extent physical layer effects can be allowed, without endangering the reliability of the CAN XL communication.

A higher bitrate makes the bits more sensitive to the cable layout. The number of drop lines, the length of the drop lines, the unit impedance and the spread of the drop lines, all together sets the limits for the usable bitrate. This paper will describe how and why those factors effects the signal propagation. There will be some rules of thumbs to follow. One part will show how much that can be gained by using CAN SIC drivers or CAN-XL SIC drivers.

Historically CAN has been used below 0.5 Mbit/s even though it was designed for 1 Mbit/s. CAN’s main cable problem has been the signal propagation delay which, in combination with the protocol’s arbitration method, demands a propagation segment that is at least twice as long as the cable’s propagation delay. This results in that Classical CAN is very robust against signal oscillation (ringing) caused by imperfections in the cable layout. The possibility to increased bitrate in CAN-FD and CAN-XL makes it individual bits more sensitive to phase-noise and inter-symbol interference, which in turn cause an amplitude noise. To succeed using higher bitrates demand more knowledge and tools to understand and secure the cable layout in use.