Marvin L. Stone
Biosystems and Agricultural Engineering
Oklahoma State University
ABSTRACTSAE J1939 is an emerging communications protocol for on-board electronics in agricultural and construction equipment as well as for heavy duty on-highway equipment. The standard supports ECUs with both statically and dynamically configured addresses. This paper examines the dynamic addressing process, the process for ECUs that select addresses during initial power-up. A state diagram is proposed to implement the process described in the standard. Simulation results of systems with up to 100 dynamically configured ECUs are presented. Use of a pseudo-random delay after a power-ON self test was successful in minimizing bus-off collisions and allowed initialization times of under 1 second for 30 ECU systems. Minimum bus-off states during initialization of 30 ECU networks occurred with pseudo-random delays having a range of 0 to 15 ms.
INTRODUCTION Electronic components have become common on agricultural and construction equipment as equipment manufacturers have attempted to build more functionality and efficiency into their products. A natural consequence of the proliferation of electronic components has been the development of multiplexed communications networks on-board the equipment. These networks allow communication between multiple electronic control units (ECUs) over multiplexed or shared communications wiring. Multiplexing simplifies wiring and lowers total system costs while providing a means to share sensor values and other data. On the other hand, multiplexing increases the complexity of the electronics systems, as some technique must be implemented for controlling access by each of the ECUs to the shared wiring. A further complication is the need for ECUs to have some means of unique identity on the shared network.Efforts by agricultural and construction equipment manufacturers to control product costs have also affected development of multiplexed wiring systems. Higher volumes of electronic components reduce cost and have driven standardization of multiplexed wiring systems. The construction and agricultural equipment industry initiated standards development for multiplexed wiring in 1990 in conjunction with the establishment of the ISO TC23/SC19WG1. That working group has focused on development of a standardized multiplex communications protocol (ISO 11783) for agricultural and forestry equipment.An additional pressure to create a standardized multiplex communications protocol for agricultural equipment has been the recent market opportunities in precision farming. Precision farming systems require inter-operation of electronic components of agricultural implements and tractors. This requirement makes a standardized communications protocol between tractor and implement critical.Early in the standards development process, US agricultural and construction equipment manufacturers decided to pursue a joint standard (SAE J1939) with the heavy duty truck and bus industry. Parts of that standard have become working documents for the international standard effort by the industry (ISO 11783).
SAE J1939SAE J1939 specifies
a communications protocol which is intended to allow communication
between electronic control units on-board a vehicle. Figure 1
shows a schematic of a potential agricultural application of the
network with a tractor and implement. SAE J1939 (SAE, 1997) is
based on CAN 2.0b (Bosch, 1991) protocol with 29 bit identifiers.
In this protocol, messages are sent serially on a multiplexed
data bus with a 29 bit message identifier and including an 8 byte
data field. SAE J1939 defines the structure of the identifier
(J1939/21) and creates a physical addressing scheme. Each ECU
connected in a network must have a unique 8 bit address. CAN
requires that identifiers used in messages on the network be unique
for proper arbitration. The J1939/21 specifies that the address
of the sending ECU (source address) be included in the identifier
of each message. The identification of the data is included elsewhere
in the identifier. This allows any ECU to send any data. A consequence
of the requirement of an address for ECUs is that an address must
be assigned at manufacture or some means of address assignment
must be included in the network protocol.
Figure 1. Tractor / Implement Implementation of
SAE J1939
An initialization process is provided in J1939/81, the Network
Management document, to allow ECUs to secure an address during
initialization. The process uses no centralized master and relies
on each ECU to manage its address. The process allows ECUs with
hard coded addresses to co-exist with ECUs which secure their
address dynamically during initialization.ECUs require some form
of unique identification for the purposes of securing and arbitrating
an address. This identification is standardized as a NAME, an
8 byte numeric quantity which includes a manufacturers code and
a manufacturer assigned identity number. Manufacturers must assure
that the NAME value is unique within an interconnected system.Figure
2 shows the message traffic and sequence that occurs during an
initialization process when two ECUs attempt to secure the same
address. The resolution of the conflict is shown. After a power-on
self-test (POST), ECU A sends an address claim message containing
the address it is claiming and its NAME. ECU B completes its
POST at a later time and attempts to claim the same address,
not hearing the original claim from ECU A. In this event, ECU
A compares the value of its NAME with the contender and reclaims
its address because it has a lower value (higher priority) NAME.
Since ECU B is self-configurable, it must seek a new address
and attempt to claim it. If ECU B is unable to select or find
a different address, it will send a Cannot Claim Address message
and be in a state of not being able to claim an address.
Figure 2. Message sequence for a self-configuring
ECU (SAE J1939/81)
The CAN protocol in SAE J1939 uses a prioritized arbitration process
to allow messages access to the bus. When two messages are sent
at the same time, their identifiers are imposed bit-serially onto
the bus. The bus must be designed to allow dominant bits to overwhelm
recessive bits when both are applied by different ECUs on the
bus. This is described in SAE J1939/12, the Physical Layer specification
for construction and agricultural applications. No conflict occurs
as long as the ECUs are sending the same bits, but when one sends
a recessive bit while the other sends a dominant bit, the bus
state is dominant. The ECU sending the recessive bit must sense
the bus is at a dominant state when the bit was sent and must
cease transmitting the message at that time until the next time
the bus becomes idle. This strategy allows more dominant identifiers,
those with a lower value, to have a higher priority on the bus.
To allow this feature to work properly, CAN synchronizes messages
at the beginning of each transmission to assure bits are aligned.The
prioritized message arbitration mechanism built into CAN is only
performed during the identifier portion of the message. A consequence
is that a message error occurs when two messages are sent with
the same identifier at the same time. Both identifiers are sent
without conflict, but when the data are sent immediately following
the identifier, the data of both messages are ORed together resulting
in a garbled transmission. This is detected by the receivers
as a bad checksum in the message, and signaled to the transmitters
via an error frame. The transmitter in most protocol controllers
automatically re-sends the message. Unfortunately, both of the
senders repeat this process. The senders keep an error count
and after repeating the message 32 times with an error, both senders
assume a bus-OFF state and cease transmitting. In most protocol
controllers, the ECU must reset the protocol controller to allow
further transmission.The possibility exists in applying the SAE
J1939/81 specification for the bus-off condition to occur if two
self-configuring ECUs attempt to claim the same address at the
same time. If the ECUs have different NAMES, they generate the
same identifier, an address claim for the same address followed
by different data. The data in the address claim message is the
ECUs NAME which should be unique. In this event, the standard
recommends each ECU retry the claim process after a pseudo-random
delay of 0 to 256 message lengths. This process would be expected
to work well when there are few ECUs attempting to claim the same
address at the same time.
INITIALIZATION STATE DIAGRAM A state diagram can be constructed to describe the address configuration process within a single self-configuring ECU as shown in Figure 3. The state diagram is entered after power-up. A power-ON self-test is assumed, and the ECU then selects an address to claim. This address should be the ECUs preferred address (J1939/81) and may be a single fixed address as found in J1939 or may be computed or selected in a different manner as specified for a particular application. For agricultural and construction applications, J1939/02 specifies application specific requirements including computation of addresses for self-configuring ECUs.
Figure 3. State diagram for Self-Configuring ECUs
After address selection, the ECU sends an address claim message
and waits for any contending claims for the same address. If
none are received for a period of 250 ms, the ECU may begin normal
communications on the network. If a contending claim is received
during the 250 ms period or afterward, the ECU must compare its
NAME with the contender. The ECU with the lower valued NAME may
re-claim its address, while the ECU with the higher valued NAME
must select another address and attempt to claim that address.
The ability to select an alternate address and claim it is the
defining characteristic of a self-configurable ECU. If the ECU
cannot find another address, the ECU sends a cannot claim address
message and waits.This dynamic address configuration process is
likely to be used with agricultural implements. Implements may
be detached and moved from tractor to tractor and multiple implements
may be connected at once. The nature of agricultural implements
required either some mutually exclusive addressing system or a
dynamic configuration process. The later process is now being
written into ISO 11783 and will be included in SAE J1939/02.
To improve the reliability of the process, the current strategy
proposed for ISO 11783 is that ECUs should use the last successfully
claimed address as a preferred address. The result of this constraint
is that address contentions may occur when a new configuration
of implements is connected, but should not occur if no changes
in configuration have been made.There is some concern regarding
the initialization time required with a dynamic address configuration
process using the strategies described above. Some of the implements
for both agricultural equipment and for construction equipment
may consist of many nearly identical ECUs. An example of this
type of system might be a planter where each row might be configured
with a single ECU. Current ECU costs probably prevent large numbers
of ECUs on an implement, but as ECU costs drop, a 30 row/ 30 ECU
planter would be possible. A planter with this many ECUs initializing
the could present long initialization times and merits further
study.
INITIALIZATION SIMULATIONA message by message simulation was developed to allow computation of initialization time and evaluation of the initialization process. The simulation was based on the state diagram in Figure 3. A listing of the time step subroutine of the simulation is included in the appendix. The following assumptions were used:
Figure 4. Effect of the number of ECUs on Initialization timeA potential method of reducing the number of bus-OFF states and minimizing initialization time would be to add a pseudo-random delay before transmitting the initial address claim. This method reduces the probability of simultaneous claims for the same address. The simultaneous claim problem would not be a problem for ECUs constructed by different manufacturers as the variation of the POST time would be expected to be on the order of 100 ms or larger. The problem occurs when a set of nearly identical ECUs are connected from the same manufacturer. In this case, the ECUs would be expected to all have the same POST time and would all attempt to claim an address at the same time. As the number of ECUs increase, the probability that ECUs claim the same address at the same time increases.Figure 5 shows the result of varying the pseudo-random delay with a network of 30 ECUs. The pseudo-random delay is inserted after the POST. A pseudo-random delay after POST of 15 ms nearly eliminated the bus-OFF states that occurred. The slight increase in bus-OFF states at 35 ms was due to a single event and would be eliminated by increasing the number of simulations. Increasing the pseudo-random delay after POST beyond 10 ms increased the initialization time slightly. A prudent selection of pseudo-random delay after POST would appear to be 15 ms as this would nearly eliminate bus-OFF states and provide a short initialization time. The average number of Bus-OFF states at a pseudo-random delay after POST of 10 ms was 0.07, or that 7% of the time, one bus-OFF state could be expected, while this level was 0 or did not occur in 25 tests at the 15 ms pseudo-random delay.
Figure 5. Effect of pseudo-random delay after POST
on Initialization time
Figure 6. Effect of a 15 ms pseudo-random delay
after POST on Initialization time
Figure 6 shows the effect of a 15 ms pseudo-random delay after
POST on Initialization time. The ideal selection of pseudo-random
delay can be seen to be a function of the numbers of ECUs involved
in the dynamic address initialization process. A selection of
15 ms may be appropriate for 30 ECUs, but a larger delay is indicated
for a much larger set of ECUs.Figure 7 repeats Figure 6 except
with 50 ms pseudo-random delay. The 50 ms pseudo-random delay
appears adequate for 100 ECUs. Bus-OFF states are maintained
below 0.5 occurrences per initialization cycle. The necessary
amount of pseudo-random delay to maintain bus-OFF states below
1 per initialization can be computed approximately by multiplying
the number of identical self configuring ECUs in a system by 0.5
ms. Interestingly, this time is the amount that would be required
for one message for each self configuring ECU.
Figure 7. Effect of Number of ECUs on Initialization
time for a 50 ms pseudo-random delay after POST.
SUMMARYThe dynamic address configuration process included in SAE J1939 was examined and a state diagram presented describing the process. Using that process, a simulation was developed to evaluate the average initialization time and number of bus-OFF states that occurred during initialization. The simulation results demonstrate that a pseudo-random delay should be inserted after the POST for ECUs which are manufactured to have the same POST time, and will use dynamic address configuration. This recommendation is especially appropriate for construction and agricultural equipment applications where multiple instances of the same type of ECU are being connected in a system. An example of this type of system would be planters where each row might use a single ECU.Initialization times for 100 ECU systems were found to be less than 500 ms including a 300 ms POST for systems using a pseudo-random delay after the POST. A pseudo-random delay after the POST of 0.5 ms per ECU in the initializing system was found to be adequate with negligible numbers of bus-OFF states during initialization. Initialization times reported here do not include the 250 ms delay that must be used before starting normal network traffic.
REFERENCES
Bosch, Robert GmbH. 1991. CAN Specification. Version 2.0. Robert Bosch GmbH, Postfach 50, D-7000 Stuttgart 1, Germany.
SAE. 1997. SAE Recommended Practices J1939, J1939/12, J1939/21, J1939/81. SAE, Warrendale, PA.
APPENDIX
Single Time Step Segment of J1939 Initialization Simulation
Visual BASIC ===================================
Type a_node
Address As Integer 'Address of ECU
Time As Integer 'Time at which ECU attempts claim
CAN_Arbs As Integer 'Number of CAN arbitrations
Claimed As Boolean 'Whether ECU has claimed
Bus_OFF As Boolean 'Whether the ECU is Bus OFF
Bus_Off_Time As Integer 'Message cycles left in Bus_OFF
End Type
'Module wide variables (max of 150 ECUs)
Dim node(150) As a_node
Sub time_step()
Dim This As Integer
Dim Other As Integer
For This = 1 To ECUs
If node(This).Time = t Then
'Claim (Check other nodes for same address to arbitrate or same time and same address for collision)
ClaimSuccess = True
If node(This).Bus_OFF = False Then
For Other = 1 To ECUs
If (node(This).Address = node(Other).Address) Then
If (This <> Other) Then
If (node(Other).Claimed = True) Then
'Must Claim New Address
'Assume the other node has a lower name (one has to reclaim and it does not matter which)
node(This).Address = 128 + 119 * Rnd()
'Prepare to reclaim new address after hearing other ECU reclaim. Assuming 4 msg lengths until reclaim
node(This).Time = t + 5
ClaimSuccess = False
ElseIf (node(This).Time = node(Other).Time) Then
'ECUs will go Bus_OFF
BusOff_Count = BusOff_Count + 1
'Set up ECUs to transmit again next message cycle
node(This).Time = t + 1
node(Other).Time = t + 1
'Set ECUs to Bus_OFF
node(This).Bus_OFF = True
node(Other).Bus_OFF = True
'Set ECUs Bus_OFF counter
node(This).Bus_Off_Time = 32
node(Other).Bus_Off_Time = 32
ClaimSuccess = False
End If 'If (node(Other).Claimed = True)
End If 'If (This <> Other) Then
ElseIf (node(This).Time = node(Other).Time) Then
'No conflict but one message has higher priority and the other is delayed by CAN arbitration
If (node(This).Address < node(Other).Address) Then
node(Other).Time = t + 1
node(Other).CAN_Arbs = node(Other).CAN_Arbs + 1
Else
node(This).Time = t + 1
node(This).CAN_Arbs = node(This).CAN_Arbs + 1
ClaimSuccess = False
End If
End If 'If (node(This).Address = node(Other).Address)
Next Other
Else 'If node(This).Bus_OFF <> False
'Decrement the Bus_OFF counter
node(This).Bus_Off_Time = node(This).Bus_Off_Time-1
node(Other).Bus_Off_Time=node(Other).Bus_Off_Time-1
If node(This).Bus_Off_Time = 0 Then
node(This).Bus_OFF = False
node(Other).Bus_OFF = False
'Compute the random message delay after Bus Off as per J1939/81 (this is not the delay before initial claim)
node(This).Time = t + 255 * Rnd()
node(Other).Time = t + 255 * Rnd()
'Select a new address assuming the worst, that the node does not listen during the delay for further address claims
node(This).Address = 128 + 119 * Rnd()
node(Other).Address = 128 + 119 * Rnd()
Else 'node(This).Bus_Off_Time <> 0
'Set up for the next cycle
node(This).Time = t + 1
node(Other).Time = t + 1
End If 'If node(This).Bus_Off_Time = 0
End If 'If node(This).Bus_OFF = False
node(This).Claimed = ClaimSuccess
End If 'If node(This).Time = t
Next This
End Sub