SAE J1939 was designed in an embedded world, where distributed control was just the future, and the aim of SAE J1939 has been to interconnect units to transmit status information, rather than to realize real distributed control systems. It can be said that SAE J1939 is a “distributed information system,” rather than a distributed control system protocol network.
Conversely, in the very near future controlled machines are expected to simultaneously communicate, both with each other and with human operators, through Wi-Fi, for instance, exchanging their position, direction, and speed; their tasks and task objectives; and other data relevant for the common task to be performed, providing a distributed production system for construction and farming.
Thus, electronic systems' architecture complexity, given by installed modules and their interoperability network structure, will obviously rise, increasing software complexity, exchanged data amounts, and challenges for electronics companies.
Nowadays, SAE J1939 at hardware and data-link layers, as defined by the ISO-OSI stack, still remains based on the CAN2.0B protocol for several reasons. The CAN bus is maintained due to its large diffusion in the automotive field, but might be considered at its limits in terms of throughput in that kind of application.
Specifically designed to provide a communication channel with a sufficient real-time and low probability of unrecognized fault, since its introduction in the early 1980s, it has been enriched with the complete ISO-OSI stack layers definition in various standard protocols, to meet the market requirements, becoming today's most used technology for automotive and industrial applications. Due to its preponderant market share, CAN is the best solution from a cost efficiency point of view, and it is used by a wide range of applications.
From another point of view, CAN protocol has various drawbacks, especially in terms of bandwidth, maximum network length, and topology. Prospectively, the “future SAE J1939” shall require more bandwidth in future systems than the CAN bus can now provide, so it is important to appoint an alternative.
Ethernet could be easily modified to become suitable for industrial purposes. Internet Protocol (IP)-based solutions can provide the required bandwidth for future SAE J1939 (or next powertrain future network) applications and improve the functionalities of the system, in a perspective of more interactions and integration with a machine distributed control system and fleet management IT infrastructure, as requested, for example, by newest parts of the ISOBUS standard under development.
The state of the art
Ethernet is without any doubt the most widely adopted standard in data exchange, in non-real-time environments. Its best-effort policy successfully supports an incalculable amount of data every day, all around the world. Truth is, that Ethernet is not specifically designed to provide real-time, fault-free communications; rather the contrary, given the extreme dynamicity of the target network topologies.
The arbitration policy used, CSMA/CD algorithm, is not reliable for time-critical applications, because message transmission might be randomly delayed by network congestion.
IP is the key protocol for what regards Ethernet technology, and it is perfectly appropriate for achieving independence from individual network technology. It is supported by all modern operating systems; in conjunction with TCP (Transmission Control Protocol) and UDP (User Datagram Protocol), its functionalities are extended for both an appropriate transport infrastructure management and data delivery. Due to its availability in computer networks, Ethernet has also become the most cost-efficient technology among the other broadband network technologies.
Conversely, CAN protocol was designed with real-time communication in mind, to ensure communication between devices with high reliability level functions. It is based on the “broadcast communication mechanism,” and it is based on a message-oriented transmission protocol.
It defines message contents rather than network nodes and node addresses. Every message has a message identifier, which is unique within the whole network, since it defines content and embeds also the message priority, directly managed by the controller hardware. The CAN protocol is based on the basis of CSMA/CA access method, with a bit-wise arbitration system, that avoids the collisions between messages: in fact, if more than one node starts to transmit at the very same moment, the message with the lowest ID will be transmitted without delay or retransmissions, thanks to hardware signal dominant voltage level evaluated by the controller, during the arbitration field transmission.
All the ECUs attempting to transmit messages with higher IDs (lower priority) will fail to transmit. For example, more critical data from the control real time or safety point of view shall be planned to own a lower ID in the network design phase. This feature is well known and exploited in SAE J1939 compliant powertrain networks: The TSC1 message—Torque/Speed Control 1, that is responsible for torque and/or speed regulation or limitation, based on the engine override control mode SPN—has the Parameter Group Number (PGN) 0, that is the lowest possible message ID planned in the part 71, defined to win arbitration against all possible messages. The system designer can utilize this feature to minimize network traffic while still maintaining the integrity of the network dependent control loops.
Making reference to the ISO-OSI stack, the CAN protocol covers only the first two layers, eventually deferring the higher-level functionalities to other protocols. The most sophisticated functions are demanded to application-specific protocols, such as SAE J1939, for heavy-duty vehicle powertrain networks, ISOBUS protocol for agricultural and forestry machine application functions and implement networks, and CANOpen for industrial systems and application and special vehicles.
Focusing on SAE J1939 network management structures, the protocol defines a Transport Protocol (TP) over CAN2.0B protocol, to transfer contents whose dimension in bytes is not treatable by single CAN messages (8 bytes maximum payload) both point-to-point and broadcast over the bus.
Those contents are necessary, for example, to define the engine torque characteristic calibration curve and to broadcast the diagnostic data, coherent with the warning lamps status. In the future, this can be used to sequentially perform complex series of functions, directly managed by electronic controls, distributed over the network toward the complete machine automation, as for example in ISOBUS.
The legacy support for the existing standards, such as CAN and SAE J1939, imposes severe and quite deprecated limitations to the technology that can be implemented on a machine.
However, in the previously described scenario, this should not be allowed because it has been tested that also with present applications, the CAN legacy has become a bottleneck. Due to CAN limitations, in an SAE J1939 system, no more than 30 nodes are allowed; furthermore, the network length is restricted to 40 m with a maximum 250 Kb/s bandwidth, not sufficient for a complex system.
As for SAE J1939 (or ISOBUS), the protocol alone cannot ensure either deterministically bounded transmission times for single RT data exchanges or a feasible share-out of the network bandwidth, between RT and non-RT application processes. Ethernet-based field-busses will deal with it.
Rather, the protocol will deliver the same services of SAE J1939 using or adapting well-established protocols of the “Internet protocol suite” (TCP/IP), taking advantage of Ethernet's bandwidth and flexibility.
These capabilities can be easily achieved by industrial Ethernet-based solutions to improve the SAE J1939 standard, giving it much more bandwidth and flexibility. The SAE J1939 TP may benefit from UDP and TCP functionalities.
Porting SAE J1939 over Ethernet
The analysis of all aspects and limits of SAE J1939 over an Ethernet, or better a TCP/IP-based protocol, is very difficult; thus, Imamoter analysis focused on the demonstration that the porting is not only feasible and relatively simple, but also could allow some protocol services simplification (as, for example, the TP that could be resolved with a single TCP message). For what concerns network design, mixed architectures are possible, due to the easiness of implementation of a gateway between CAN and Ethernet, and due to the limited bandwidth of CAN that, even at maximum bandwidth occupation, represents a very small percent of the maximum bandwidth allowed by Ethernet based protocols.
The main reason to use the IP protocol and other fourth-level protocols, such as TCP and UDP, is the possibility to unify most different kinds of traffic, still keeping security and performances (exploiting the enormous performance improvements CU have achieved in the last years).
Laying over the TCP/IP stack gives enormous opportunity to adopt hugely well-established protocols such as Dynamic Host Configuration Protocol (DHCP), for CU network initialization, or IPsec, for secure communications bound to Internet, in an absolutely transparent way, where any CU can rely on existing local services for local communication and remote services for what may concern data logging or secure upgrade or support (up to remote fault detection).
Indeed, many existing protocols such as DHCP may be adapted or used in particular ways to fulfill the needs of SAE J1939, but this topic must be dealt with more deeply and surely will be in future studies.
The SAE J1939 standard completely defines the whole ISO-OSI stack, from the lowest layer specified by CAN protocol, through the higher layer such as application description, and network management. Some level of the ISO-OSI standard is not referred by a specific document, but the functions and services are referred by documents related to other levels.
Whereas the standard CAN network is based on a message-oriented protocol, SAE J1939 introduces the node concept and allows it to identify each node, making it directly addressable with point-to-point messages. In a node-oriented network, this protects the network from the node and message falsification, preventing different ECUs from using the same ID to identify different messages.
SAE J1939 also defines the Protocol Data Unit (PDU) as the communication unit to be transferred. To classify the communication unit characteristics, the 29-bit CAN 2.0B standard identifier is divided and classified into seven fields here listed by bit order priority: Extended Data Page (EDP), Data Page (DP), PDU Format (PF), PDU Specific (PS), Source Address (SA), Data Length Code (DLC), and Data Field.
Two PDUs are specified: PDU1, for point-to-point and broadcast communication, while PDU2 is used for broadcast/multicast communication only. Each node in the network has a unique identifier that is used as SA or Destination Address (DA) during the communication. SAE J1939 defines an address range from 0 to 253; the address 254 is used as the null address for the address claiming procedure and the 255 is used in the PDU1 as DA for broadcast communication.
Due to the “plug-and-play” nature of the SAE J1939 protocol, it has been specified an addressing procedure to avoid conflicts between the ECUs, called Address Claiming.
The Address Claiming procedure could be made in either requesting all already claimed addresses in the network (and take the first available) or trying to get one particular address, chosen a priori. Address conflicts between nodes are resolved by using unique device names, which at the same time describe each node's functionality, the manufacturer, and the serial number.
The PGN of SAE J1939 is used to identify message type, message content, and message recipients (type). To optimize the message latency on the bus, a priority can be set in the specific PDU field, raising or lowering the PGN's priority, to perform a network tuning. The maximum payload dimension that can be transmitted with a single CAN frame is limited to 8 bytes, but some PGNs may require more than one CAN data frame to send the corresponding data, so the PDU can be divided into several CAN frames that are transmitted separately. An example of this multi-packet data is the Engine Configuration message, PGN 65251, with a payload of 34 bytes. The SAE J1939 TP provides to this, ensuring the message packetization, reassembly, and providing also for the connection management.
When analyzing the TCP/IP Stack, some similarities to the SAE J1939 Stack can be found. For what concerns addressing, UDP and TCP work over IP, that defines a 32-bit address, usually represented in dot notation. In IP there are different classes of network, depending on the number of hosts. For example a local class C network (e.g., 192.168.0.0/24, so 192.168.0.[0..255]) should be suitable to represent the address range of an SAE J1939 powertrain network.
Furthermore, IP provides several delivery methods for sending datagrams such as multicast, unicast, and broadcast, all of them required by the standard. The similarity with unicast and SAE J1939 broadcast communication is straightforward.
Regarding multicast, the SAE J1939 standard protocol uses PDU2 messages. On the contrary, in IP, protocol is defined as a class of multicast networks: in this case the equivalence isn't easy to be identified, so every PGN will have a transposition into a multicast group and each ECU shall register only groups relevant for its purposes.
The SAE J1939 TP implements some services, such as connection management, flow-control, error control, message fragmentation, and reassembly, features that are also provided by the TCP/IP.
For these reasons, it is possible to figure out an extent of SAE J1939 over Ethernet. Furthermore, Ethernet provides a larger bandwidth and other higher-level functionalities that can be used to enhance the possible application range and performances. On the other hand, the SAE J1939 Protocol has some timing and maximum delay constraints.
UDP presents interesting characteristics for real-time communication, as it doesn't require a connection management. So UDP should be efficiently suitable for CAN communication different from TP, but can be used also for TP protocol, for a plain first protocol migration and transposition.
A more efficient method can be found in TCP protocol to meet the SAE J1939 TP functionality (for example, an FTP session). As a proof of concept, some tests have been made to verify the feasibility of the functionalities discussed above.
During preliminary tests, a “gateway” was implemented for bridging the CAN bus and the Ethernet network, providing the encapsulation of any type of SAE J1939 messages into UDP packets to transfer the communication from CAN to Ethernet and vice versa. This may represent the first step for future work in the ultimate direction of switching the SAE J1939 protocol away from CAN and over to an Ethernet architecture.