The Importance of Experienced Engineers with Distributed CAN Networks and Embedded Device Development

A long-term customer approached DE Design Works with a need for a new embedded device and user interface (UI) that would add to their existing multi-faceted system. The new device would be installed on an existing CAN network where it would be communicating with, and in some cases controlling, other network embedded devices. This specific CAN network also adhered to an industry protocol standard. However, what we sometimes find is that depending on the application environment, not all standards are always followed. Luckily, this was not the first time that our experienced firmware engineers at DE Design Works had encountered non-compliant devices, and we came prepared.

There are many CAN protocol standards in use across many different industries. In the case of this customer, they wanted a device developed using the SAE J1939 standard. This is a common communications protocol standard used in automotive-related applications used for its cross-device compatibility, dynamic addressing, and flexible data structure. However, even on a network with a standard communication protocol in place, any CAN-capable device can still be connected and operate on the network so long as it follows the physical requirements of a CAN device. Depending on the field of application, a standard like J1939 is not always required to be strictly enforced, which can give flexibility in the system for use with legacy devices, custom developed devices, or generic CAN devices. Embedded firmware engineers refer to any of these devices that are not following the in-place protocol standard as being non-compliant. As for this customer’s system, it was found that there were multiple different devices that were non-compliant and for various reasons, although they did not break the specifications of the system.

With a communications standard like J1939 in use, there is automatic handling of unique identifiers which prevents cross-talk from non-compliant devices, but care must still be taken when considering the whole system design or adding a new device.

How did we perform a CAN network analysis?

Understanding the ins and outs of the functioning system is a key to success.

DE firmware engineers began by analyzing the makeup and messaging structure of the existing CAN network system. This is a critical step in the beginning of a project to ensure that all aspects of what the new network device will perform are clearly documented and understood. This process involved performing these core steps:

API Retrieval and Review: Gathering Application Programming Interface (API) documentation from device manufacturers of the system devices is critical in understanding how those devices operate and communicate over the network. While often, in a distributed system, other devices can be looked at as so called black boxes, it is still imperative to know what data format those device messages follow to exchange information and data. Without that specific information, we do know how to interpret the messages exchanged with that device on our newly developed network device.

Direct Messaging Observation: The most effective way to visualize the transmission of messages between devices in a system like this is to monitor it directly using a CAN network analyzer tool. The CAN tool allows us to see messages sent and received from individual embedded devices in real time and also allows us to record system events to review the order and timing in which messages are exchanged between active devices. These recordings and live viewings become invaluable for developing our new device’s messaging schemes, especially in cases where our device needs to directly control or read from those other devices.

Critical Device Identification: Depending on the system architecture and environment, there may be specific devices on the network that are considered high priority and are critical for the base functionality of the entire system. Recognizing which devices are critical, and others that simply provide secondary functionality, in the system is crucial as to not interfere with critical system operations once our new device is on the network.

Identifying Non-Compliant Devices: Protocol standards exist as a way to help keep device-to-device communication uniform. This helps both in the development of standardized messaging, but also in simplifying the receiving and parsing of messages from other devices. However, no distributed device network is without some imperfection. When you have a collection of network devices from a wide variety of different manufacturers, often outside of our customer’s control, it is not uncommon to discover a device that does not perfectly adhere to the communication standard. It then becomes up to the firmware development team to learn that specific device’s nuances so that our new device can properly communicate with it.

Our customer’s CAN network consisted of various types of devices from multiple different OEM manufacturers. Most of the devices were developed in accordance with the SAE J1939 standard, but there were also devices that didn’t follow the dynamic addressing specification of J1939, devices that were developed for legacy standards but were still CAN compatible, and a device that did not follow any specific standard and instead had its own custom data structure. While static addressing is allowed within the J1939 specification in a controlled network system, the reason these devices presented as non-compliant was because this particular network was made up of a mix of static and dynamic addressing devices. These devices were developed by their respective manufacturers at different times, for use with various end user applications, which resulted in an amalgamation of devices with differing communication firmware design choices. Since the project at hand was on a shared network, our customer did not have total control over the selection of these additional devices and therefore it was up to the product development team to work with them rather than modify or replace them in the system.

What were the technical implementation details?

Developing firmware for a new device that has to adhere to a network protocol standard, while also being able to communicate with non-compliant devices, has its own difficulties. On top of that issue, implementing a new device on an existing distributed network can be challenging in itself. Approaching these problems in a smart, effective way takes experience and some intuition, which is exactly how our DE firmware engineer approached this customer’s needs:

Protocol Standard Specification Review: When developing a new device to meet a standard, the first step is understanding the standard itself. Reviewing the CAN protocol standard specification document(s) and learning the byte-by-byte makeup of each message type used on the network is imperative for development and testing validation. These are typically generic data formats for messages alongside timing/order specifications.

An API of Our Own: With the protocol standard well understood, it became time to develop our own device API for added functionality that our device provided to the system. When designing this API, the DE firmware engineer designed all new messages so that they adhered to the protocol standard. This made implementation of the sending and receiving of these messages very clean and straightforward. It also ensured that other devices existing or added to the network in the future would be able to clearly read the API specification for our device and easily implement bi-directional data messaging with our device knowing it adheres to the in-place standard.

The Challenges to Overcome: Writing firmware code to interact with custom messaging in another device is not necessarily complicated, but what our DE firmware engineer had to tackle was implementing this custom messaging alongside the standardized J1939 messaging. The collision prevention is handled by the CAN protocol and physical layer, but at a higher firmware level these two different messaging pathways had to co-exist so that any and all devices required on the network could be communicated with while sharing resources in the firmware itself. This also applied to parsing messages received from devices on the network. Messages from standard-compliant devices could be fed into a single parser code block which could determine the sender and parse the data packet accordingly, but messages from the non-compliant devices had to be detected-out and sent into a different parsing block for each individual device. Our engineer had to balance uniformity with clean coding architecture to keep the firmware efficient but also equipped specifically for the needs of this particular product. In the end, this resulted in a device with firmware designed to be adaptable to any extra-device messaging required.

These kinds of custom firmware adaptations are not always known at the time of project proposal, which is why we try our best at DE Design Works to account for the time needed to do a proper network analysis and review in the early Assessment stage of the project. Depending on the number of unknown devices on the network, this can certainly add complexity which can lead to scope-creep from the initial estimate in order to ensure our new device’s full compatibility with all necessary compliant and non-compliant devices, but by taking this key step in the first phase of the project, the customer becomes well informed early about any budgetary changes. The DE firmware engineering team is well-versed in working with CAN networks and related distributed system networks like these, but ultimately without knowing the details of the other devices we are working with on the network it is impossible to perfectly predict the time and effort required to communicate effectively with these devices.

In this case, how can a product development team lessen the uncertainty facing your embedded development budget?

It can significantly help the accuracy of the firmware effort when a customer has pre-existing knowledge and/or documentation of all other devices on the network. DE certainly understands this is not always possible and in either case, an analysis of the network is the sure-fire way to ensure what we expect on the network is what we see. This step reduces risk for the remainder of the firmware development project.

Testing and Confirmation

It is commonplace to perform basic code testing and validation during firmware development of features in an embedded device. In a distributed system environment where our single device is communicating with a multitude of other devices over CAN, testing communications with individual devices is just as important as testing the system as a whole.

How did our firmware engineer test over this CAN network?

Direct Device Testing: Whether it be the standard compliant or non-compliant system devices, our new device was testing rigorously on a closed network with each device individually to ensure that all communication back and forth with that particular device was working properly. In some cases, this requires simulating other device messages, but this type of testing setup allows for controlled conditions and settings via those messages so that the only variables are in the direct device-to-device messaging with our new device. Once validated, a next device was chosen and this process continued until all individual devices were tested with our new firmware.

Event Testing: Once all of the individual device testing was complete, a mock network with all devices was created to test real communication with all the devices interacting in real time. This mock network allows for a simulated environment that cannot damage or cause undesired events to occur to components the system controls but still allows for the system devices to be put through the paces of their real functionality for rigorous testing of all the events and conditions that can occur in that system. Once any needed software updates were complete, our device was installed on a real-world system where it was again tested to its full functionality to ensure all data messaging and interaction with other devices was error free. In addition to this complete system testing, the DE firmware engineer also ensured that other system functionality that occurred outside of the scope of our device was not impacted by having our device present on the network. With all testing completed, the customer was free to begin production of their newly developed embedded product.

Synopsis and Takeaways

Identify the anomalies early

Adapting to unexpected anomalies in dealing with external devices on a shared network such as this can sometimes cause weeks or even months of additional necessary coding in order to ensure device compatibility and functionality in the system. While this has the potential to disrupt initial project schedules and budgets, the consequences of blindly developing and adding a new device to a shared network without having a full understanding of the existing network and its individual components can end up causing much larger delays due to extensive debugging and code compatibility updates during system testing, and use.

The most critical issue that can also arise by avoiding this early testing step is when real-world problems begin to occur down the road while the product is in the field which result in use-case failures that could have been avoided by performing a proper analysis of the network.

Had our customer and firmware engineer made the assumption that all of the devices present on this system’s CAN network were following the SAE J1939 standard, not only would our device not have been able to communicate with some of the devices, but there would have been potential for messaging inconsistencies which can lead to erroneous control of system components and ultimately system failure. A safe system is a predictable system, and depending on our customer’s application, this can sometimes even mean the difference between life and death.

Taking the time and effort to perform a proper analysis of the existing network and its devices is perhaps the most critical step in developing a new network device to ensure the devices compatibility, functionality, and system safety. No system made up of multiple devices performing individual key tasks, developed by different engineers over varying time periods, can be perfect. Adapting to our customer’s specific network’s needs, whether it be non-compliance or other exceptions, is exactly what our firmware team at DE Design Works is experienced at executing.

Do you have a need for product development in a CAN system with unknown devices? Does your industry have communication protocols or standards in place, but also has a need for product-specific customization? Give DE Design Works a call today and let our expert firmware engineers take care of the communication challenges for you.