CANopen and J1939 are two CAN based communication protocols.
Physical Layer of CANopen and J1939
Both protocols use CAN as standardized in ISO 11898-2. CANopen allows various bit rates between 10 kbit/s and 1000 kbit/s, but a fixed set of bit rates is predefined (10, 20, 50, 125, 250, 500, 800, 1000). For J1939 the bit rate is mostly – according to J1939-11- set to 250 kbit/s. There is no definition for the cables for CANopen but J1939 requires a shielded and twisted cable. In the CiA specification 303 there are more than 20 connectors with the pin assignments defined, but no connector is preferred. J1939 only defines to 2 different connectors – one for normal connections and one for diagnostic connections.
There are also definitions for special use cases with higher bit rates and other cables.
J1939-14 define networks with 500 kBit/s and J1939-15 specifies the use of un-shielded twister pair cables.
CANopen theoretically allows up to 127 nodes (devices) in a network and J1939 supports up to 254 nodes but it is limited to 30 per segment. Due to the fixed bit rate the cable length for J1939 networks is limited 40 m, but using CANopen with 10 kbit/s cable up to 5000 m are allowed.
The 11-bit frame format is mostly used by CANopen and the 29-bit frame format is mostly used with J1939, but the other format is not excluded. So the previous statement is mostly true, but not for 100% of the use cases.
Regarding the use of Remote Transmission Request (RTR) messages there are additional differences. No RTR message are allowed in a J1939 network. In CANopen these messages are allowed and used in older networks but it is not recommended anymore for newer designs.
Standardization organizations
CAN in Automation e.V.
The CAN in Automation e.V. is a German non-profit organization. It is often abbreviated as CiA (with a smaller case i) and its headquarter is located in Nuremberg, Germany. The members of the organization are mostly companies, universities or research facilities. Mid of 2016 it had 614 members (30% of them from Germany). The CiA standardizes CANopen with all its communication profiles, devices profiles and application profiles and it assigned the CANopen Vendor-ID, which is a unique ID for all vendors of CANopen components. Additionally, the association organizes trainings and conferences around CAN and CANopen and handles the CANopen Conformance Test.
SAE International
The SAE International was founded in 1905 as Society of Automotive Engineers 1905 in the USA and it is located in Warrendale (Pennsylvania). In contract to the CiA e.V. its members are individuals. Mid of 2016 there were more than 2016 registered members.
Specifications and Profiles
CANopen
CANopen clearly separates between data and services. Data (process data, configuration data, device ID information, ..) are stored globally in a so called object dictionary. Each data can be addressed by a 16-bit index and a 8-bit subindex. To transport these data various services are defined that differ regarding speed, flexibility, access methods and payload segmentation. These CANopen services are SDO, PDO, SRDO and MPDO. Additionally, there are CANopen services to manage the network, to monitor nodes or to signal errors or warnings. Additionally, there is another service defined (LSS) to assign dynamically node-IDs and to configure CAN bit rates.
The structure of the object dictionary, the basic services and the CANopen FSA is defined in the CANopen communication profile CiA 301. CiA 302 defines additional features for CANopen masters and managers and in CiA 305 the LSS service to
configure node-IDs and bit rates. Besides these and other communication profiles, there are various device profiles starting at CiA 401. The device profiles define a set of devices (e.g. digital IO devices, drives or encoders) with their parameters and process data in the object dictionary, the PDO mapping and a defined behavior of the devices. Additionally, there are CANopen application profiles (e.g. CiA 454) that defined a complete CANopen network for a defined use case with all communication relationships.
A subset of the profiles is available for free – after a registration. Other documents are only available for members of the organization. Some documents have been handed over to international standardization bodies (EN, IEC) and can be purchased by everybody from these organizations.
J1939
In J1939 data and transport services are not clearly separated.
Data or signals are identified by a Suspect Parameter Number (SPN). Multiple SPNs are grouped together in a Parameter Group Number (PGN). Most PGNs have a length of 8 bytes to use the payload of CAN in the best possible way. Most PGNs are sent cyclically and the timings of the PGNs and the data types, values ranges and meanings of the SPNs are defined in J1939/71. Additionally, there are services for the address claiming and to transport data larger than 8 bytes both as unicast or broadcast.
All J1939 specifications are available for everybody for a fee.
Development tools and Stacks
Both protocols are based on CAN so a basic CAN analyzer seams sufficient to analyze the CAN data of J1939 or CANopen networks. Anyway, using a specialized tool with CANopen or J1939 interpretation is much more convenient when working with these protocols.
CANopen devices may be masters or slaves. So for the development of CANopen slaves it is useful to have a CANopen master tool available to communicate with the slaves. A dedicated CANopen tool is often much more easier to handle than e.g. a PLC with CANopen of the customer’s master device.
There are commercial protocol stacks from various vendors for both protocols. These stacks provide the communication services, so the developer only has to handle with the application but not with the communication protocol. It is recommend to use commercial products because of available support. Additionally, using stacks from well known vendors it is very likely to pass the conformance tests. To combine CANopen and J1939 a CAN-MultiProtocol stack is required.