SAE J1939 ECU Simulation With Raspberry Pi
by Wilfried Voss, owner and president of Copperhill Technologies
The Raspberry Pi with its various versions is a great embedded system not only for prototyping but also, to a certain degree, for industrial and vehicle/automobile applications. There are, however, some restrictions that have the potential of excluding the Raspberry Pi from industrial-strength applications such as the operating temperature and power supply voltage range. Another factor, depending on the application, may be the very long startup time. All these factors are, of course, highly application-dependent, and there are solutions for a simple workaround such as environmental control to keep the temperature within the operating range or DC/DC modules that convert from 24 VDC (industrial) or 7 to 32 VDC (Vehicle applications) to the 5 VDC needed by the Raspberry Pi. All these additional measures are easily compensated by the Raspberry Pi's undeniable strengths of low price and ease of programming under a Linux/Windows operating system.
My special interest in the Raspberry Pi is the mere fact that we are very successfully selling CAN (Controller Area Network) Bus interface boards for the Raspberry. They are:
- PiCAN 2 - CAN Interface for Raspberry Pi
- PiCAN 2 - CAN Interface for Raspberry Pi With SMPS (Switch mode power supply)
- PiCAN 2 - CAN DUO Interface for Raspberry Pi
- PiCAN 2 - CAN DUO Interface for Raspberry Pi With SMPS (Switch mode power supply)
Both SMPS versions take care of one downside of the Raspberry Pi, i.e. the restricted power supply range. The SMPS versions support a range from 6 VDC to 30 VDC.
The availability of CAN Bus interfaces for the Raspberry Pi also offers the potential of running an SAE J1939 protocol stack on the Raspberry Pi, may it be for J1939 data monitoring or ECU simulation. The mere monitoring of J1939 data traffic is fairly simple and is directly supported by the current software that comes with the PiCAN 2. However, things get a bit more complicated when it comes to bi-directional data communication, i.e. read and write operations (Note: Not all PGNs under J1939 are transmitted automatically; some of them must be requested. Any request of data involves writing to the J1939 network). Any write-operation requires the installation and operation of an SAE J1939 protocol stack.
The current situation is that an SAE J1939 protocol stack comes with a hefty price tag in form of either object code licenses (single-user, single-application) or full C source code (which is usually royalty-free). A C source code package from various vendors in the market place runs easily into the range of US$5,000 and more, which makes it virtually impossible for the hobbyist to runJ1939 on the Raspberry Pi (which runs about US$45 a piece). The only exception in the market is ARD1939, a J1939 protocol stack for the Arduino Uno and Mega 2560, which is provided as a free download.
With all these aspects in mind, I have contemplated several options of integrating an SAE J1939 protocol stack on the Raspberry Pi. They are:
- SAE J1939 Library for PiCAN 2: This would be a mere software addition to the current PiCAN 2 interface board and for me that is actually easy to accomplish. The idea would be to provide a free programming interface (library code) for the Raspberry Pi. There are, however, some concerns in regards to real-time performance. SAE J1939 is, per default, not a real-time protocol, but there are numerous timers involved with running the protocol stack. It is my experience that Linux/Windows operating systems will require some tremendous efforts to accomplish timers with an acceptable accuracy. Nevertheless, for some simple J1939 applications, the library will do, provided the application does not involve other, time-consuming tasks such as frequent hard-drive (SDD card) access.
- External SAE J1939 hardware: The idea behind this concept is to create a J1939 to UART/USB gateway that runs the protocol on-chip, which also replaces the PiCAN 2 as the CAN interface. This concept guarantees exact timing and also reduces the burden on the Linux/Windows operating system. The function calls would be 100% identical to the before-mentioned software library. The hardware would come in two versions: 1. USB connection or 2. UART connection to COM0, which is driectly available through the 40-pin header on the Raspberry Pi.
I am currently working on both solutions more or less simultaneously. The software solution will require some extensive testing in regards to timing accuracy (and a long and detailed disclaimer). I have also successful connected our jBoard-X2 (running a J1939 to USB gateway software) to a Raspberry Pi B+ per USB port and am in the process of testing the communication. In this case, I am applying our jCOM1939 - SAE J1939 Gateway Protocol and Programming Interface.
Last, but not least, I will write more posts about the various solutions and the progress of creating them, and I will add references (links) at the bottom of this page. For further questions or comments, please feel free to write to me through our Contact Us page.
A Comprehensible Guide to J1939
SAE J1939 has become the accepted industry standard and the vehicle network technology of choice for off-highway machines in applications such as construction, material handling, and forestry machines. J1939 is a higher-layer protocol based on Controller Area Network (CAN). It provides serial data communications between microprocessor systems (also called Electronic Control Units - ECU) in any kind of heavy duty vehicles. The messages exchanged between these units can be data such as vehicle road speed, torque control message from the transmission to the engine, oil temperature, and many more.
The information in this book is based on two documents of the SAE J1939 Standards Collection: J1939/21 - Data Link Layer J1939/81 - Network Management A Comprehensible Guide to J1939 is the first work on J1939 besides the SAE J1939 standards collection. It provides profound information on the J1939 message format and network management combined with a high level of readability.
=> Read More...