Embedded Systems Academy

Learn from Arm’s Christopher Seidl and NXP’s Kyle Dando as they explore how different software layers interact to create efficient industrial systems.

Chris Keydel from EmSA will talk about industrial networking with CANopen and how to integrate Micro CANopen Plus into your own application using Open-CMSIS-Packs.

Perfect for embedded software developers eager to expand their understanding of Open-CMSIS-Packs.

Register now and reserve your spot: https://okt.to/BdKjSE

We are pleased to introduce the latest software update for the CANgineBerry, which now includes a Python example aimed at simplifying network management for developers working across Linux, Windows, and macOS. This new example uses the provided CANopen Manager firmware as an efficient way to visualize and manage devices on a CANopen network.

Unlike basic CAN interfaces (only passing through CAN frames), the CANgineBerry handles the entire CANopen Manager functionality. This allows the module to automatically scan the network, identify new devices, and configure the appropriate Process Data Objects (PDOs) without requiring manual intervention. Through this automated functionality, users can directly access the Object Dictionary entries for both the Manager and the connected devices, reducing the need for writing complex code.

The Python example showcases these features through a lightweight graphical user interface (GUI). Once connected to a CANgineBerry, the script accesses detected devices, retrieves their details on demand, and presents them in an intuitive display. No matter the platform—Linux, macOS, or Windows—this tool provides rapid access to multiple devices on your CANopen network.

By delegating low-level CANopen management tasks to the CANgineBerry, developers are free to concentrate on higher-level application development. The Python-based GUI makes the configuration and monitoring of CANopen networks easy and gives you instant control over your devices.

This update further reinforces CANgineBerry’s position as more than a CAN bus interface. It remains a robust solution that simplifies CANopen network management, providing both flexibility and user-friendliness for embedded systems developers.

To download the example, go to: https://cangineberry.com/

In a blog entry from last year, we announced a “Two-year project for security of CANopen and other small-packet networks.” It is now time to give you an update on where we are with our SPsec (Securing Small-Packet Networks) project.

It comes as no surprise that adding security to small-packet networks like CAN, I2C, LIN, Modbus, and other fieldbuses is a challenge. The small-packet sizes offer only limited space for security information like an authentication tag and often, these networks are handled by microcontrollers with limited computational and memory resources. We are now aiming at protecting all communication in such a network when our initial goal was to protect only selected communication channels. The reason here is that for many industrial applications, recent acts and regulations like the European Cyber Resilience Act (CRA) will require security-by-design in the near future. For several use cases, they will also request that all data at rest and in motion is both authenticated and encrypted.

We defined the following SPsec key points and cryptographic primitives:

• Minimal hardware requirements of participating MCUs
• Cryptographic functions used
• Point-to-point security for configurations or communications with an limited amount of communication channels
• Time-based rolling key derivation for automated refreshing of keys
• Group security for multicast network technologies like CAN

For more detailed information see our white paper “Cybersecurity Primitives for Small-Packet Networks“.

Our first proof-of-concept implementation will be based on the PCAN-Router FD from PEAK-System. These devices have two CAN (or CAN FD) interfaces from which we use one for unprotected communication from a host system. The router implements a SPsec sub layer and uses the second interface for the secure communication. This allows for easy test and debugging, as there will be one CAN bus with the protected and one with the unprotected communication allowing a direct comparison.

Later the SPsec sub layer will be added to our Micro CANopen source code and integrated into various CANopen or CANopen FD devices for further testing.

Stay informed by following this blog or our linkedin page for up-to-date developments.

The current status of the EU Cyber Resilience Act (CRA) is that manufacturers of devices with digital elements or any software have until 2027 to comply with the outlined rules and regulations. These include compliance issues like overall risk assessment, documentation and incident reporting – which have a huge organizational impact. Technology details mentioned in the CRA are limited, so there is some interpretation as to what it all means for embedded systems and fieldbus communication. When it comes to specifics, the annex talks about how to treat data in transit:

Text excerpts from Annex I, 1. (3) (c) and (d) (emphasis ours):

• Products shall protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms.
• Products shall protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, as well as report on corruptions.

In other words:

• When communicating or storing (to non-volatile memory) relevant data then encrypt it.
• When communicating or storing (to non-volatile memory) any data then authenticate it.

There is not much room for exceptions here, discussing what is relevant might be challenging. If it is not relevant, then why communicate or store it in the first place?

There might be some relief in Annex I, 1. (1) which says:

• Products shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.

This can be a way out for some applications if in the risk assessment a security expert can show that there is no risk in not protecting certain data. Nevertheless, the security assessment must also reflect the following two statements:

1. Apply security-by-design to the entire lifecycle (min 5 years), from development process to production, deployment, and use/maintenance.
2. Products integrated in or connected to a larger electronic information system can serve as an attack vector for malicious actors.

These two statements have a huge impact on all microcontroller communication like plain UART, RS-485, CAN or other fieldbuses. The second statement boils down to not making a difference between important and lesser important communication. Even the lesser important communication may serve as an attack vector to the system.

The first statement requires layered security mechanisms given that protecting a single aspect won’t be sufficient. Taking CAN as an example, let us have a look at the known three stages of most common attacks on CAN systems:

1. Get access to the CAN communication.
   For example by accessing the CAN wires or hijacking a device (or interface to another network) already connected.
2. Monitor the CAN communication to learn from it.
   The attacker learns which CAN frames are used for what.
3. Inject or replay CAN communication to maliciously trigger behaviour.
   The attacker “takes over” certain aspects of the system.

By protecting any one of these three stages, the attacker’s success can be thwarted, and the system might seem “secure”. However, what if in the foreseeable future an attacker finds a way around that single protection? Security-by-design requires that we pay attention to all possible stages of an attack and do not focus on a single point of potential failure.

In any future risk assessment of a system using any form of communication (fieldbus or application specific communications), manufacturers will need to show which steps they took to protect all aspects:

1. Which steps were taken to minimize physical access?
   How easy is it to access the network wires? Can diagnostic ports be protected? Which interfaces to other networks are there? How are they protected?
2. Which steps were taken to keep communication confidential?
   To prevent attackers from learning anything about the system, encrypt all relevant communication.
3. Which steps were taken to ensure communication integrity?
   To prevent attackers from manipulating frames, authenticate all relevant communication.

In summary, to be EU Cyber Resilience Act compliant, a lot of the future fieldbus communication needs to be both authenticated and encrypted. To simplify the risk assessment and documentation, this should be done for all communication. Otherwise, manufacturers need to be prepared to have a security expert document every unprotected communication as to why this specific data set is irrelevant enough so that even if read or manipulated it won’t possibly constitute a cybersecurity risk.

Follow this blog and/or our LinkedIn page to learn about latest related developments including our upcoming security solutions for CAN, CAN FD, CANopen and CANopen FD.

This year, Nuremberg’s doors open for the Embedded World (#ew24) from April 9th to April 11th. From EmSA, Peter, Chris and Olaf will be at the event all three days. If you want to talk to us about topics like CAN, CANopen, J1939 and CAN security, meet us at the booth of Peak-System, hall 1, booth 304.

As every year, the conference also features a CAN session. This year it is session “SESSION 2.2 CONNECTIVITY SOLUTIONS | CAN” (April 9th, starting at 1:45PM) with the following presentations:

Thilo Schuhmann: Standardized Cybersecurity in CAN-Based Systems

This paper concentrates on cybersecurity requirements specific to embedded systems employing Controller Area Network (CAN) communication, encompassing CAN, CAN FD, and the emerging CAN XL. Our primary focus lies on CAN XL, which incorporates CANsec, a data link layer add-on facilitating message authentication and encryption,in the data plane. In the control plane the specification of the CANsec Key Agreement protocol (CKA) is defining for key exchange and agreement mechanisms to allow broadcast communication for the authenticated and encrypted messages.

Reiner Zitzmann: Improved Network Start-up for Dynamically Changing Embedded CAN Systems

Controller Area Network (CAN) networks often serves as the conduit for data exchange; on the very deeply embedded level. Devices, connected to these embedded networks may be dynamically added or removed, by the end user. Thus these devices need to show a certain degree of plug and play behavior. Host controllers must have the ability to rapidly identify these devices. Unlike current implementations, the enhanced Layer Setting Services (LSS) enable CAN/CANopen devices to convey their identity to the host controller or LSS manager. This eliminates the need for laborious searches to determine the presence and type of newly added devices. The presentation shows the functioning of the improved Layer Setting Services, and practical use cases.

Olaf Pfeiffer: Collaborative Design of Security Measures for CAN and CANopen Systems

The rise of connected devices in the embedded world has intensified the need for strong security measures, especially in Controller Area Network (CAN) and CANopen systems. These technologies are crucial in a wide range of applications such as industrial automation, automotive systems, and medical equipment. Given the limited resources available in CAN protocols, security often becomes a challenging aspect to address effectively. This paper presents a joint project between Hochschule Offenburg and Embedded Systems Academy, focusing on overcoming these security challenges.
We argue that collaboration among multiple partners is essential for the design and implementation of effective, robust security measures. Our proposed security framework brings together expertise from various stakeholders to identify vulnerabilities, assess potential threats, and formulate countermeasures. A significant aspect of our project is the aim to standardize these security measures through the CAN in Automation (CiA) organization. This makes the security framework transparent and open for public review.
The framework is optimized for CANopen but can also be used by CAN, CAN FD, CANopen FD and other higher-layer protocols.
This paper will outline the architecture of our security framework, showing its applicability to a broader range of CAN or CANopen based applications.

You can’t make it to Nuremberg?

For the latest news and developments in CAN, CANopen and CAN Security, follow us here: https://www.linkedin.com/company/embedded-systems-academy/

For more info on these topics, also see our video collection at https://www.em-sa.com/video

Together with the Institute of Reliable Embedded Systems and Communication Electronics (ivESK, Prof. Sikora of Offenburg University), the Embedded Systems Academy has been awarded a research grant for a collaborative project focusing on embedded network security. The project is dedicated to developing a security framework for small-packet networks, with a specific emphasis on CAN and CANopen systems.

The initiative, internally referred to as “Inter-Layer Multi-Participant Security for Small-Packet Networks,” can be integrated within existing network layer protocols and offers multi-party security. It is adaptable to various small-packet network protocols used in embedded systems. Beyond CAN, CAN FD, CANopen and CANopen FD, it can also be used for I2C or RS-485 based systems. The project aims to combine established security mechanisms in a novel way and adapt them suitable for deeply embedded systems, devices and networks, where resources, such as memory, computing power, data rates and frame length are very much constraint.

The project’s goal is to ensure that the results are openly available and can be reused by the Special Interest Group “Safety/Security” within CiA (CAN in Automation).

We plan to regularly publish updates on our project’s progress. A first presentation is scheduled for the embedded world Conference in Nuremberg: On April 9th, 2024, we will present the paper “Collaborative Design of Security Measures for CAN and CANopen Systems” in the connectivity track, session 2.2 on CAN. If you are interested in contributing to the specification process or in beta-testing early implementations, please feel free to contact us (contact form on this web page or mail to info@esacademy.de).

This Project is supported by the Federal Ministry for Economic Affairs and Climate Action (BMWK) on the basis of a decision by the German Bundestag.

Embedded Systems Academy (EmSA), a leading provider of embedded software solutions for CAN
based industrial networks, is pleased to announce the release of its Micro CANopen libraries as
Open-CMSIS-Pack following the Common Microcontroller Software Interface Standard (CMSIS) by
Arm. This new integration enables developers to easily implement CANopen communication
protocols in their embedded systems.

Until now, these Micro CANopen libraries were already available as part of selected NXP
MCUXpresso Software Development Kits (SDKs). Along with NXP’s recent release of support for MS
Visual Studio Code, SDKs and third-party libraries are moving to Open-CMSIS-Packs, ensuring
compatibility with a wider range of development tools and microcontrollers. For more information on NXP’s step towards VS Code and Open-CMSIS-Packs, follow this link.

The Micro CANopen libraries from EmSA offer a minimalistic implementation of the CANopen and
CANopen FD communication protocols for I/O devices and basic managers/controllers. They are
designed to simplify the development process by providing a compact and efficient solution, saving
valuable time and resources for embedded system developers. Through the Open-CMSIS-Pack
format, developers can leverage the libraries seamlessly, further enhancing the efficiency and
reliability of their CANopen-enabled applications.

The published Micro CANopen libraries may be used at no license charge and are adequate to
implement basic I/O devices with a limited number of parameters or a controller with a limited
number of nodes to handle.

“We are excited to bring our Micro CANopen libraries to the Open-CMSIS-Pack ecosystem,” said Olaf
Pfeiffer, CEO of Embedded Systems Academy. “By making our libraries available as Open-CMSIS-
Packs, we aim to empower developers to effortlessly integrate CANopen or CANopen FD support
into their embedded projects.”

Developers can use any tool that supports Open-CMSIS-Packs to access these CANopen libraries such
as NXP MCUXpresso, Visual Studio Code, Arm Keil MDK and IAR Embedded Workbench. The libraries
are compatible with the latest Arm CMSIS releases and initial support covers several popular NXP
LPC and i.MX microcontroller derivatives.

The current beta release features the Micro CANopen release for selected NXP microcontrollers. Future releases will support NXP’s auto-configuration and more derivatives with CAN or CAN FD interfaces.

The current list of available releases is availabe at: www.keil.arm.com/vendors/emsa/packs

Another year has passed that proved to be challenging for everyone in the position of buying semiconductor components or products based on them. Many of our customers and partners have their own stories to share about “creative solutions” to dealing with supply chain issues. Here is an example from one of our customers:

He approached us over a broken CANopen joystick – used in a very expensive machinery – and the machine could no longer be used. The joystick supplier was not able to deliver the joystick, but he could deliver a generic version without the CANopen interface, using digital and analog outputs instead. The question was, how fast could we modify the firmware of our CANopen generic I/O module so that it could be used with the generic joystick and then integrated into the machine.

Custom firmware requests are quite common, however usually combined with some volume purchase of the modules involved. Here, the required quantity was ‘one’.

Luckily the required changes were minimal and most settings could be made via the CANopen configuration (Node ID and bitrate settings, PDO communication and mapping settings). Within a few consulting hours, we were able to deliver a prototype based on our CANopenIA-M0 starter kit. After just one more minor re-configuration the system worked again. The starter kit was embedded in an industrial rugged housing and mounted into the machine near the operator – and it was back to work.

To ensure continuous availability of the CANopenIA modules we, like so many others in the industry, were forced to do a re-design – not necessarily to add new functionality, but just to have multiple sourcing options for the modules.

As a result, within 2023 we expect that our proven and popular CANopenIA-M0 system- on-module will be available in a total of three hardware versions. The two new modules will offer 100% pin-by-pin backward compatibility. In addition, the latest version will not only support classical CANopen but also CANopen FD and provide direct access to faster and higher resolution analog inputs.

We wish our clients and partners a quiet and relaxing transition to 2023 and may the supply chain issues be less challenging this year.

Andy, Chris and Olaf

Earlier this year, EmSA inherited the CANopen IA product line from ESSolutions. The product line goes back about 20 years and at the time the products were based on the Philip’s XA architecture. The current products are using the NXP LPC11Cxx microcontrollers (ARM Cortex M0). Right from the beginning, EmSA provided the firmware and support software for these products making EmSA a natural candidate to continue this product line after ESSolutions discontinued their operation.

The base product is a small (31.5 x 20mm) 48pin module offering 7 configurable ports with 4 connectors each. Depending on the port number, a port can be configured to be:

• Digital input or output (4 signals)
• Remote access (serial UART, TTL)
• Internal analog input (4 times 8 or 10bit resolution)
• External analog input (4 times 12bit, I2C connected external)
• External analog output (4 times 12bit, I2C connected external)

At EmSA, we now continuously enhance the features of this product line. The latest firmware release V2.2 added remote access support to a host system via a serial TTL channel. This allows the module to be used as a CANopen communication processor in systems that can use a regular serial channel to communicate with the communication processor. A further enhancement added 8bit resolution access to the analog inputs (default use is 10bit resolution) now supporting a variety of CANopen joystick implementations.

An easy entry starter kit is now available, offering basic access to the functionality provided by the CANopen IA M0 module. All 48 pins of the module are made available on standard header rows, all marked with the matching pin names. For quick tests, switches and LEDs can be connected to any of those pins using jumper cables provided.

A CANopen FD version of the module is currently under development and scheduled for release early 2022.

For more information, see:
www.canopenia.com
www.canopenstore.eu

The 17^th international CAN Conference is an online event about the Controller Area Network happening from June 14^th to June 17^th, 2021. Papers presented cover topics such as updates on the physical and data link layer for CAN FD and XL, CANopen testing, CANopen FD and Security.

The tutors of EmSA participate in presenting two papers: “A simplified classic CANopen to CANopen FD migration path using smart bridges” and “Achieving multi-level CAN (FD) security by complementing available technologies”.

The paper about smart bridges introduces a solution to easily combine classical CANopen devices with CANopen FD devices. The bridges developed here offer one classical CANopen and one CANopen FD port and “auto-translate” CANopen and CANopen FD messages transparently. As an example, SDO transfers on the classical CANopen side are automatically translated to USDO transfers on the CANopen FD side.

The paper about security reviews currently available security solutions for CAN (FD) and examines how they complement each other. The security methods combine here are CAN message ID guarding, a CAN crypto layer and (D)TLS.

For the first time, the iCC combines papers with open CiA IG and SiG (Interest Group and Special interest Group) meetings. Here “open” means that after registration anyone can participate to see how the different work groups operate. Our engineers will participate in the SIG special car add-on devices (CiA 447) and the IG CANopen FD.

For more details and registration, see www.can-cia.org/icc