Industrial Network Protocols

Some industrial network protocols

This section will brie y introduce other protocols used in the automotive industry. Some of these are old ones, which appear to be falling out of use, and others are new ones being developed, many for so-called \drive by wire” applications. The protocols will be described in rather less detail than was CAN above. There is also a brief section on the SAE standards. These descriptions will be followed by a section that will discuss di erences and similarities between these protocols, from a modelling point of view. The protocols introduced here can be divided into two general classes, CSMA ones, such as CAN, and TDMA ones such as TTP/C. Some of the sources referred to for the
TDMA protocols use the distinction “asynchronous” and synchronous. This means that in the case of the TDMA protocols, all the nodes use a common notion of time, rather than being prompted to transmit by an external event (the terms \event driven” and \time
driven” are also used). In fact CAN also uses synchronous transmission.

 

  • SAE standards

The Society of Automotive Engineers has de ned three categories for in-vehicle networks:
 Class A, low speed (less than 10Kb/s) for convenience features such as entertainment.
 Class B, medium speed (between 10 and 125Kb/s for general information transfer, such as emission data, instrumentation.
 Class C, high speed (greater than 125Kb/s) for real-time control such as traction
control, brake by wire, etc.
CAN is class C, SAE J1850 (Ford SCP etc, see sections 3.2) is class B. It is, of course, not inconceivable that both protocols are used for di erent functions in the same vehicle. SAE standards exist for these categories. The document Digital Networks in the Automotive
Vehicle  also lists a Class D for speeds greater than 1Mb/s. Although no (SAE) standards exist, such systems are apparently being referred to as \class D”.
The SAE has various standards for vehicle networks in these classes (i.e. of di erent speeds). They have adopted J1850 as the standard for class A and B networks. There is more on this standard below, section 3.2. CAN has been selected as the basis for J1939 -a class C network for truck and bus applications. There is also an SAE standard for high speed CAN (500 Kb/s), J2284-500. I have also seen a mention of a J2411 single wire CAN. These standards (and others) can be bought from the SAE web-site . Some ISO standards are also available from this source.

 

  • SAE J1850

This is the SAE standard for Class A and Class B (slow and medium speed) networks. It is a combination of Ford’s SCP (see below) and General Motors’ Class 2 Protocol. These protocols di er, for example in operating at di erent speeds. The need for a standard was
apparently driven by a need to interface with diagnostic equipment (for emission control testing). Fault codes have to be available through a diagnostic port through a standard protocol | J1850 or ISO 9141. OBD-11 requires the implementation of diagnostic tools
for emission related systems. As J1850 developed from two proprietary protocols, there are two alternative J1850
protocols, 41.6Kb/s with pulse width modulation and 10.6Kb/s with variable pulse width. I have found a paper on the latter, Implementing the J1850 Protocol [15]. Ford SCP seems to be the former. J1850 (in both versions) is a CSMA/CR protocol, in which collisions are handled by arbitration, in much the same way as CAN, so the higher priority message is not corrupted by the collision. There is a bit on this in Intel’s Introduction to In-Vehicle Networking . In both versions the data eld can be from 8 to 64 bits and both versions use a cyclic redundancy check. SCP (which apparently stands for Standard Corporate Protocol) is Ford’s version of
SAE J1850. The Jaguar example circuits referred to in appear to use this protocol, but it is apparently being superseded by CAN.
It is the faster version of J1850, so runs at 41.6Kb/s and uses pulse width modulation. It uses a two wire bus, unlike the General Motors J1850 protocol, which uses a single wire.

 

  • UBP

This protocol is mentioned in Generic Network FMEA . It appears to be a proprietary UART based protocol intended for SAE class A applications. There are various such proprietary protocols, which are likely to be replaced by standard ones (such as SAE J1850 or CAN) in future. Smart Engineering Tools [22] build network simulation and analysis tools. They list several protocols under \UART” including UBP. A UART (Universal Asynchronous Receiver / Transmitter) is an integrated circuit used for serial
communications. One di erence between UBP and other protocols is that it uses a checksum rather than a cyclic redundancy check (CRC), so undetected errors are more likely than in SCP or CAN. The risk is quoted as \low” in [25], rather than \extremely low”.
We have been told that Ford’s UBP is not used in the UK, as it interferes with the Radio 4 cricket commentary!

 

  • ISO 9141

This is an alternative standard to J1850 (see section 3.2) for protocols that must interface with a diagnostic port. While Ford’s \domestic” products use J1850 (SCP), their inter national ones use ISO 9141. There is a protocol referred to as \Ford 9141″ which appears to be distinct from Ford’s UBP and based on ISO 9141. It is referred to in . The NSI web-site  has an introduction (in French) to ISO-9141. These notes are based on Google’s automatic translation. According to this site, it speci es “the characteristics of numerical exchange of information between the electronic control units embarked aboard road vehicles and suitable equipment of diagnosis.” There are alternative con gurations of the physical layer, one or two wire. It also speci es speed (5 baud for addresses and between 10 baud and 10 k baud for other transmissions), time intervals between key words and data transmission, message format and so on. Whether communication is point to point or multipoint is speci ed by individual manufacturers, so network access appears not to be speci ed in this standard.

 

  • J1939

J1939 is a high speed (Class C) network to support real time closed loop control functions between ECUs within a vehicle. Its documentation covers all layers in the ISO/OSI stack, so its scope is broader than, say CAN. J1931 does not necessarily formally de ne all layers. It uses CAN so network access and message format are consistent with it. The CAN 2.0B format is used with 29 bit message identi ers. The format of these 29 bits is de ned in the standard and explained in the Kvaser tutorial, available from the Kvaser web-site
. The speed of J1939 is 250 Kb/s, so it is slower than J2284. The physical medium is intended to be shielded twisted pair. The standard can be purchased from the SAE .

 

  • TTP/C

TTP stands for Time Triggered Protocol. It is a deterministic protocol intended for SAE class C applications. It was developed by the Brite Euram Project \X-by-Wire” and ESPRIT OMI Project \TTA” at the Technical University of Vienna . The speci cation
has been transferred to TTTech  since the ending of these projects. There is a TTP group with a web-site  from which the speci cation can be ordered, for free. The companies listed on the web-site include VW/Audi and Honeywell. TTP/C can apparently manage higher data rates than CAN. The time triggered architecture is discussed in Bus architectures for safety-critical embedded systems .
TTP is “time triggered” as opposed to “event triggered” so all nodes on the network have a common concept of time, through roughly synchronised clocks. All activities are carried out at certain points in time, decided at system design time, rather than network
activities being triggered by external events, as in a CSMA protocol such as CAN. As TTP is a TDMA protocol, latency is deterministic. There is a bus guardian that \guarantees” that no node can monopolise communication media outside its transmission slot, so the
network should be safe from “babbling idiots”. The network appears to be peer-to-peer, as each node has its own controller and bus
guardian. Therefore failure of a bus guardian will presumably only result in failure of that node, but does that not allow the node to become a babbling idiot? There is a lower cost version, called TTP/A, for SAE class A applications. This version is also TDMA and is a master/slave architecture. It can be used for branching several sensors from a single TTP/C node. As TTP/A is intended for low cost systems, a standard UART and an 8-bit controller are sucient for implementation.

 

  • LIN

LIN is an acronym for Local Interconnect Network and is a low cost eld bus network intended to t below CAN’s functionality (i.e. for SAE class A applications?). I have found a paper comparing LIN with TTP/A, from the TTP forum , but on checking this paper appeared no longer to be available from there. The standard is described at . The LIN consortium includes VW/Audi, Daimler-Chrysler and Motorola. Unlike TTP its development was driven by industry, rather than by academic institutions.
It is a single master/multiple slave architecture, so no need for arbitration. Speed is 20Kbit/s so while it is considered to be most appropriate for SAE class A applications, the speed is actually at the lower end of class B. As it is time triggered, message latency
is guaranteed. Silicon implementation is cheap, based on common UART/SCI interface hardware. SCI stands for serial ommunications interface.

 

  • Volcano

Volcano might be described as “TTP on CAN” and the Volcano web-site  describes the protocol as CAN-based and deterministic. The protocol is used by Volvo on the S80 and V70 cars, and is coming into use on Volvo buses. According to the Volcano Communications Concept , Volcano appears to be a technique in which the CAN network is integrated in such a way as to guarantee the latency of all the messages. It does this by specifying the latency and periodicity of messages at design time. This allows the maximum latencies to be calculated, so the system integrator (designer) can specify the network set up in such a way as to juggle
these speci cations to guarantee the speci ed parameters, by avoiding arbitration as far as possible. This seems to imply that the sending of network communication is time triggered rather than event triggered, so the description “TTP on CAN” seems a pretty
good summing up. This apparently means that network loadings can be considerably higher than using CAN conventionally, maybe 60% loading, whereas for latency of lower priority messages to be contained to reasonable limits, CAN loading may need to be around 10%.

 

  • Byte ight

Byte ight is a high speed, deterministic protocol developed by BMW and several semiconductor manufacturers for safety-critical automotive applications. There is a web-site on the protocol, from which the speci cation can be downloaded . It is capable of speeds of up to 10Mbps gross, (better than 5 Mbps net) using an optical bre physical layer to avoid electro-mechanical interference problems, in a star con guration. It has also been tested using a bus con guration, on twisted pair, but at lower speeds. The protocol combines time and priority controlled bus access, but claims collision free operation, so no arbitration loss. Latency is guaranteed for “a certain amount of high priority messages” and there is an analytical check for worst-case latency for high priority messages. There is exible bus access for low priority messages, but latency cannot be guaranteed for these. According to the description in , one node (it can be any) sends a periodic signal that marks the beginning of a \slot”. In the current standard each slot has a duration of
250 microseconds. After transmission of the slot signal, each node starts a counter and can send a message when the counter reaches its own number. When a transmission is made, the counters pause for the duration of the message, so no slots are missed. If there is no message, there is a brief pause before the counters increment. Therefore there is a number of messages that can be certain of reaching their time in each slot, so can be sure of transmitting every 250 microseconds. Lower priority messages cannot be certain of transmitting in a given slot (or in any slot, in principle).

 

  • FlexRay

FlexRay is a protocol that combines time triggered and event triggered messaging. It is being developed by BMW and  aimlerChrysler with Philips and Motorola. It is capable of a net data rate of 5Mbps (10 Mbps gross). Information on the protocol is available on
the Web . The Requirements Speci cation can be downloaded from here. It is one of four protocols discussed in Bus architectures for safety-critical embedded systems. Not surprisingly, in view of its developers, FlexRay has a certain amount in common
with Byte ight. There is a signal indicating the beginning of a network slot, like Byteight’s, but this slot is divided (at design time) into static (time triggered) and dynamic (event triggered) portions. In the static part, each message source has its own slot, during
which the network is idle if that source does not transmit. This is followed by the dynamic portion of the slot in which any node can transmit, using the Byte ight protocol, so it is still free of arbitration and transmission is priority based. The example in the FlexRay
introductory presentation  shows the highest priorities having slots allocated in the static (time triggered) part, and lower priority sources in the dynamic (event triggered) part, so a source (id) has a slot in one or the other. This presumably reduces jitter for
messages allocated slots in the static portion (as compared to Byte ight) as their timing is constant, unlike in Byte ight, where vacant slots are shortened.

 

  • TTCAN

This protocol is a session layer (from the ISO/OSI stack) extension to CANbus, currently being standardised by the ISO, which allows CAN to be used for time triggered messages, so increasing determinism, reliability, composability and synchronisation over CAN. The
summary here is taken from Leen and He erman . In TTCAN a speci c node (the “time master”) transmits a reference message, indicat-
ing the start of a time cycle. The message is recognised by other nodes (by its identi er). A time cycle is divided into a number of slots each of which can be assigned statically to a speci c node, or to a group of nodes that compete for it by CAN arbitration, though without retransmission. Slots can also be designated as idle time to allow for expansion. A transmission must be started early in the time slot (during the so called Tx Enable window) so as to avoid the message over-running its allocated slot. The only time retransmission is allowed is when two or more arbitration slots follow consecutively, so the message that lost arbitration can retransmit during the combined Tx Enable window of the successive slots. A complete cycle can cover several successive transmissions of the reference message. This message includes a cycle count value to indicate which row of the resulting “matrix cycle” has been reached. Each row can have its individual slots allocated di erently from the other rows. As there is now a master node that transmits the reference message, the protocol needs to ensure fault tolerant behaviour of the time master. If a time master fails, another potential time master takes over. Any one of eight nodes can be potential time master.

 

From Jon Bell