My Take On...
 The SAE J1939 Standards Collection

After writing “A Comprehensible Guide to Controller Area Network”, documenting the SAE J1939 standard seemed to be a logical choice when it came to investigating CAN based higher layer protocols. As I have learned from a number or professionals in the CAN industry, J1939 is still gaining enormous popularity, even though it is already in business for some years. However, the quality and availability of documentation on J1939 is in utter contrast to its popularity.

Despite the poor condition of the written standard, it was initially a pleasure to investigate the J1939 protocol functions. SAE J1939 is a very ingeniously designed protocol that takes a resourceful advantage of the CAN 29-Bit message identifier. Rather than relying on a myriad of protocol functions, SAE J1939 uses predefined parameter tables, which keeps the actual protocol on a comprehensible level. SAE J1939 is a prime example of good American engineering according to the KISS principle (KISS = Keep It Simple, Stupid!), but it is nevertheless at least as effective as, for instance, CANopen or DeviceNet.

After months of working through the SAE J1939 Standards Collection I have now released "A Comprehensible Guide to J1939". This book is an attempt to create an enjoyable and readable J1939 reference for everybody. It covers SAE J1939/21 - Data Link Layer and SAE J1939/81 - Network Management. Additional information - such as PGNs, SPNs - will be posted on this web site in the future.

Let me, however, be very blunt about the SAE J1939 Standards Collection:
First, I would like to take the opportunity and apologize to all engineers of the SAE who worked on the J1939 standards collection. My comments throughout my book, regarding the condition of the documentation, are not favorable. You have created a great protocol, but the standard is poorly written and lacks any visible structure. Working through the standard was at times tiresome and frustrating.

It was especially irritating to learn that the SAE engineers who created the standard were not fully familiar with the CAN specification. The SAE J1939 Standards Collection contains a number of references to the CAN standard that are misleading in the best case, while others are plain wrong.

 

The most irrelevant document in the SAE J1939 Standards Collection is SAE J1939/11 where the CAN standard was wrecked to uselessness.

 

One would also expect that engineers, regardless of their special expertise, are familiar with the unit of time, “ms” or “msec” (milli-seconds). Instead the J1939 standard frequently uses mS, which is officially milli-Siemens (electric conductance, equal to inverse Ohm - Ω).

The worst, however, is not related to documentation, but the design of the Address Claim process. SAE J1939/81 (Network Management) allows the collision of CAN messages with the same ID, which is, first of all, not allowed under the CAN standard. Secondly, and even worse, the engineers at the SAE are apparently not fully aware of the consequences of a message collision. The results are fairly unpredictable (as emphasized in the CAN standard) and have not been fully investigated by the SAE.

Instead they come up with a peculiar solution that recommends to check for errors due to message collision and then re-attempt the message claim after a "pseudo-random" delay.

The CAN standard is based on highest reliability and it is incomprehensible why the SAE would compromise that very important feature.

Well, after working through the Standards Collection, I do have a list of a hundred questions for the SAE and none of them would be polite... 

Don't get me wrong, the principle design is great, but it does have some few, yet serious short-comings.

Meet me at the
CAN - CANopen - J1939 Seminar Series

For more information log on to
http://www.CANSeminar.com