{"id":1630,"date":"2012-04-04T02:48:24","date_gmt":"2012-04-03T23:18:24","guid":{"rendered":"http:\/\/fxplans.com\/web\/?page_id=1630"},"modified":"2012-08-31T10:14:18","modified_gmt":"2012-08-31T06:44:18","slug":"industrial-network-protocols","status":"publish","type":"page","link":"http:\/\/fxplans.com\/web\/industrial-network-protocols\/","title":{"rendered":"Industrial Network Protocols"},"content":{"rendered":"<p><span style=\"color: #003366; font-size: large;\">Some industrial network protocols<\/span><\/p>\n<p>This section will brie y introduce other protocols used in the automotive industry. Some\u00a0of these are old ones, which appear to be falling out of use, and others are new ones\u00a0being developed, many for so-called \\drive by wire&#8221; applications. The protocols will be\u00a0described in rather less detail than was CAN above. There is also a brief section on\u00a0the SAE standards. These descriptions will be followed by a section that will discuss\u00a0di\u000berences and similarities between these protocols, from a modelling point of view.\u00a0The 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<br \/>\nTDMA protocols use the distinction &#8220;asynchronous&#8221; and synchronous. This means that in\u00a0the case of the TDMA protocols, all the nodes use a common notion of time, rather than\u00a0being prompted to transmit by an external event (the terms \\event driven&#8221; and \\time<br \/>\ndriven&#8221; are also used). In fact CAN also uses synchronous transmission.<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>SAE standards<\/li>\n<\/ul>\n<p>The Society of Automotive Engineers has de\fned three categories for in-vehicle networks:<br \/>\n\u000f Class A, low speed (less than 10Kb\/s) for convenience features such as entertainment.<br \/>\n\u000f Class B, medium speed (between 10 and 125Kb\/s for general information transfer,\u00a0such as emission data, instrumentation.<br \/>\n\u000f Class C, high speed (greater than 125Kb\/s) for real-time control such as traction<br \/>\ncontrol, brake by wire, etc.<br \/>\nCAN is class C, SAE J1850 (Ford SCP etc, see sections 3.2) is class B. It is, of course, not\u00a0inconceivable that both protocols are used for di\u000berent functions in the same vehicle. SAE\u00a0standards exist for these categories. The document Digital Networks in the Automotive<br \/>\nVehicle \u00a0also lists a Class D for speeds greater than 1Mb\/s. Although no (SAE)\u00a0standards exist, such systems are apparently being referred to as \\class D&#8221;.<br \/>\nThe SAE has various standards for vehicle networks in these classes (i.e. of di\u000berent\u00a0speeds). They have adopted J1850 as the standard for class A and B networks. There is\u00a0more 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\u00a0is also an SAE standard for high speed CAN (500 Kb\/s), J2284-500. I have also seen\u00a0a mention of a J2411 single wire CAN. These standards (and others) can be bought from\u00a0the SAE web-site . Some ISO standards are also available from this source.<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>SAE J1850<\/li>\n<\/ul>\n<p>This is the SAE standard for Class A and Class B (slow and medium speed) networks. It\u00a0is a combination of Ford&#8217;s SCP (see below) and General Motors&#8217; Class 2 Protocol. These\u00a0protocols di\u000ber, for example in operating at di\u000berent speeds. The need for a standard was<br \/>\napparently driven by a need to interface with diagnostic equipment (for emission control\u00a0testing). Fault codes have to be available through a diagnostic port through a standard\u00a0protocol | J1850 or ISO 9141. OBD-11 requires the implementation of diagnostic tools<br \/>\nfor emission related systems.\u00a0As J1850 developed from two proprietary protocols, there are two alternative J1850<br \/>\nprotocols, 41.6Kb\/s with pulse width modulation and 10.6Kb\/s with variable pulse width.\u00a0I have found a paper on the latter, Implementing the J1850 Protocol [15]. Ford SCP seems\u00a0to be the former.\u00a0J1850 (in both versions) is a CSMA\/CR protocol, in which collisions are handled by\u00a0arbitration, in much the same way as CAN, so the higher priority message is not corrupted\u00a0by the collision. There is a bit on this in Intel&#8217;s Introduction to In-Vehicle Networking\u00a0. In both versions the data \feld can be from 8 to 64 bits and both versions use a cyclic\u00a0redundancy check.\u00a0SCP (which apparently stands for Standard Corporate Protocol) is Ford&#8217;s version of<br \/>\nSAE J1850. The Jaguar example circuits referred to in appear to use this protocol,\u00a0but it is apparently being superseded by CAN.<br \/>\nIt is the faster version of J1850, so runs at 41.6Kb\/s and uses pulse width modulation.\u00a0It uses a two wire bus, unlike the General Motors J1850 protocol, which uses a single wire.<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>UBP<\/li>\n<\/ul>\n<p>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\u00a0such proprietary protocols, which are likely to be replaced by standard ones (such as\u00a0SAE J1850 or CAN) in future. Smart Engineering Tools [22] build network simulation\u00a0and analysis tools. They list several protocols under \\UART&#8221; including UBP. A UART\u00a0(Universal Asynchronous Receiver \/ Transmitter) is an integrated circuit used for serial<br \/>\ncommunications.\u00a0One di\u000berence between UBP and other protocols is that it uses a checksum rather\u00a0than a cyclic redundancy check (CRC), so undetected errors are more likely than in SCP\u00a0or CAN. The risk is quoted as \\low&#8221; in [25], rather than \\extremely low&#8221;.<br \/>\nWe have been told that Ford&#8217;s UBP is not used in the UK, as it interferes with the\u00a0Radio 4 cricket commentary!<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>ISO 9141<\/li>\n<\/ul>\n<p>This is an alternative standard to J1850 (see section 3.2) for protocols that must interface\u00a0with a diagnostic port. While Ford&#8217;s \\domestic&#8221; products use J1850 (SCP), their inter\u00a0national ones use ISO 9141. There is a protocol referred to as \\Ford 9141&#8243; which appears\u00a0to be distinct from Ford&#8217;s UBP and based on ISO 9141. It is referred to in .\u00a0The NSI web-site \u00a0has an introduction (in French) to ISO-9141. These notes are\u00a0based on Google&#8217;s automatic translation. According to this site, it speci\fes &#8220;the characteristics of numerical exchange of information between the electronic control units embarked\u00a0aboard road vehicles and suitable equipment of diagnosis.&#8221; There are alternative con\fgurations of the physical layer, one or two wire. It also speci\fes speed (5 baud for addresses\u00a0and between 10 baud and 10 k baud for other transmissions), time intervals between key\u00a0words and data transmission, message format and so on. Whether communication is point\u00a0to point or multipoint is speci\fed by individual manufacturers, so network access appears\u00a0not to be speci\fed in this standard.<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>J1939<\/li>\n<\/ul>\n<p>J1939 is a high speed (Class C) network to support real time closed loop control functions\u00a0between ECUs within a vehicle. Its documentation covers all layers in the ISO\/OSI stack,\u00a0so its scope is broader than, say CAN. J1931 does not necessarily formally de\fne all layers.\u00a0It uses CAN so network access and message format are consistent with it. The CAN 2.0B\u00a0format is used with 29 bit message identi\fers. The format of these 29 bits is de\fned\u00a0in the standard and explained in the Kvaser tutorial, available from the Kvaser web-site<br \/>\n. The speed of J1939 is 250 Kb\/s, so it is slower than J2284. The physical medium is\u00a0intended to be shielded twisted pair. The standard can be purchased from the SAE .<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>TTP\/C<\/li>\n<\/ul>\n<p>TTP stands for Time Triggered Protocol. It is a deterministic protocol intended for\u00a0SAE class C applications. It was developed by the Brite Euram Project \\X-by-Wire&#8221; and\u00a0ESPRIT OMI Project \\TTA&#8221; at the Technical University of Vienna . The speci\fcation<br \/>\nhas been transferred to TTTech \u00a0since the ending of these projects. There is a TTP\u00a0group with a web-site \u00a0from which the speci\fcation can be ordered, for free. The\u00a0companies listed on the web-site include VW\/Audi and Honeywell. TTP\/C can apparently\u00a0manage higher data rates than CAN. The time triggered architecture is discussed in Bus\u00a0architectures for safety-critical embedded systems .<br \/>\nTTP is &#8220;time triggered&#8221; as opposed to &#8220;event triggered&#8221; so all nodes on the network\u00a0have a common concept of time, through roughly synchronised clocks. All activities are\u00a0carried out at certain points in time, decided at system design time, rather than network<br \/>\nactivities being triggered by external events, as in a CSMA protocol such as CAN. As TTP\u00a0is a TDMA protocol, latency is deterministic. There is a bus guardian that \\guarantees&#8221;\u00a0that no node can monopolise communication media outside its transmission slot, so the<br \/>\nnetwork should be safe from &#8220;babbling idiots&#8221;.\u00a0The network appears to be peer-to-peer, as each node has its own controller and bus<br \/>\nguardian. Therefore failure of a bus guardian will presumably only result in failure of that\u00a0node, but does that not allow the node to become a babbling idiot?\u00a0There is a lower cost version, called TTP\/A, for SAE class A applications. This version\u00a0is also TDMA and is a master\/slave architecture. It can be used for branching several\u00a0sensors from a single TTP\/C node. As TTP\/A is intended for low cost systems, a standard\u00a0UART and an 8-bit controller are su\u000ecient for implementation.<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>LIN<\/li>\n<\/ul>\n<p>LIN is an acronym for Local Interconnect Network and is a low cost \feld bus network\u00a0intended to \ft below CAN&#8217;s functionality (i.e. for SAE class A applications?). I have\u00a0found a paper comparing LIN with TTP\/A, from the TTP forum , but on checking\u00a0this paper appeared no longer to be available from there. The standard is described at\u00a0. The LIN consortium includes VW\/Audi, Daimler-Chrysler and Motorola. Unlike\u00a0TTP its development was driven by industry, rather than by academic institutions.<br \/>\nIt is a single master\/multiple slave architecture, so no need for arbitration. Speed is\u00a020Kbit\/s so while it is considered to be most appropriate for SAE class A applications,\u00a0the speed is actually at the lower end of class B. As it is time triggered, message latency<br \/>\nis guaranteed. Silicon implementation is cheap, based on common UART\/SCI interface\u00a0hardware. SCI stands for serial ommunications interface.<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>Volcano<\/li>\n<\/ul>\n<p>Volcano might be described as &#8220;TTP on CAN&#8221; and the Volcano web-site \u00a0describes\u00a0the protocol as CAN-based and deterministic. The protocol is used by Volvo on the S80\u00a0and V70 cars, and is coming into use on Volvo buses.\u00a0According to the Volcano Communications Concept , Volcano appears to be a\u00a0technique in which the CAN network is integrated in such a way as to guarantee the\u00a0latency of all the messages. It does this by specifying the latency and periodicity of\u00a0messages at design time. This allows the maximum latencies to be calculated, so the\u00a0system integrator (designer) can specify the network set up in such a way as to juggle<br \/>\nthese speci\fcations to guarantee the speci\fed parameters, by avoiding arbitration as far\u00a0as possible. This seems to imply that the sending of network communication is time\u00a0triggered rather than event triggered, so the description &#8220;TTP on CAN&#8221; seems a pretty<br \/>\ngood summing up.\u00a0This apparently means that network loadings can be considerably higher than using\u00a0CAN conventionally, maybe 60% loading, whereas for latency of lower priority messages\u00a0to be contained to reasonable limits, CAN loading may need to be around 10%.<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>Byte ight<\/li>\n<\/ul>\n<p>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\u00a0on the protocol, from which the speci\fcation can be downloaded .\u00a0It is capable of speeds of up to 10Mbps gross, (better than 5 Mbps net) using an\u00a0optical \fbre physical layer to avoid electro-mechanical interference problems, in a star\u00a0con\fguration. It has also been tested using a bus con\fguration, on twisted pair, but at\u00a0lower speeds. The protocol combines time and priority controlled bus access, but claims\u00a0collision free operation, so no arbitration loss. Latency is guaranteed for &#8220;a certain amount\u00a0of high priority messages&#8221; and there is an analytical check for worst-case latency for high\u00a0priority messages. There is exible bus access for low priority messages, but latency cannot\u00a0be guaranteed for these.\u00a0According to the description in , one node (it can be any) sends a periodic signal\u00a0that marks the beginning of a \\slot&#8221;. In the current standard each slot has a duration of<br \/>\n250 microseconds. After transmission of the slot signal, each node starts a counter and\u00a0can send a message when the counter reaches its own number. When a transmission is\u00a0made, the counters pause for the duration of the message, so no slots are missed. If there\u00a0is no message, there is a brief pause before the counters increment. Therefore there is\u00a0a number of messages that can be certain of reaching their time in each slot, so can be\u00a0sure of transmitting every 250 microseconds. Lower priority messages cannot be certain\u00a0of transmitting in a given slot (or in any slot, in principle).<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>FlexRay<\/li>\n<\/ul>\n<p>FlexRay is a protocol that combines time triggered and event triggered messaging. It is\u00a0being developed by BMW and \u00a0aimlerChrysler with Philips and Motorola. It is capable\u00a0of a net data rate of 5Mbps (10 Mbps gross). Information on the protocol is available on<br \/>\nthe Web . The Requirements Speci\fcation can be downloaded from here. It is one of\u00a0four protocols discussed in Bus architectures for safety-critical embedded systems.\u00a0Not surprisingly, in view of its developers, FlexRay has a certain amount in common<br \/>\nwith Byte ight. There is a signal indicating the beginning of a network slot, like Byteight&#8217;s, but this slot is divided (at design time) into static (time triggered) and dynamic\u00a0(event triggered) portions. In the static part, each message source has its own slot, during<br \/>\nwhich the network is idle if that source does not transmit. This is followed by the dynamic\u00a0portion of the slot in which any node can transmit, using the Byte ight protocol, so it is\u00a0still free of arbitration and transmission is priority based. The example in the FlexRay<br \/>\nintroductory presentation \u00a0shows the highest priorities having slots allocated in the\u00a0static (time triggered) part, and lower priority sources in the dynamic (event triggered)\u00a0part, so a source (id) has a slot in one or the other. This presumably reduces jitter for<br \/>\nmessages allocated slots in the static portion (as compared to Byte ight) as their timing\u00a0is constant, unlike in Byte ight, where vacant slots are shortened.<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>TTCAN<\/li>\n<\/ul>\n<p>This protocol is a session layer (from the ISO\/OSI stack) extension to CANbus, currently\u00a0being standardised by the ISO, which allows CAN to be used for time triggered messages,\u00a0so increasing determinism, reliability, composability and synchronisation over CAN. The<br \/>\nsummary here is taken from Leen and He\u000berman .\u00a0In TTCAN a speci\fc node (the &#8220;time master&#8221;) transmits a reference message, indicat-<br \/>\ning the start of a time cycle. The message is recognised by other nodes (by its identi\fer).\u00a0A time cycle is divided into a number of slots each of which can be assigned statically to\u00a0a speci\fc node, or to a group of nodes that compete for it by CAN arbitration, though\u00a0without retransmission. Slots can also be designated as idle time to allow for expansion.\u00a0A transmission must be started early in the time slot (during the so called Tx Enable\u00a0window) 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\u00a0message that lost arbitration can retransmit during the combined Tx Enable window of\u00a0the successive slots. A complete cycle can cover several successive transmissions of the\u00a0reference message. This message includes a cycle count value to indicate which row of the\u00a0resulting &#8220;matrix cycle&#8221; has been reached. Each row can have its individual slots allocated\u00a0di\u000berently from the other rows.\u00a0As there is now a master node that transmits the reference message, the protocol\u00a0needs to ensure fault tolerant behaviour of the time master. If a time master fails, another\u00a0potential time master takes over. Any one of eight nodes can be potential time master.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: center;\"><span style=\"color: #c0c0c0;\"><em>From\u00a0Jon Bell<\/em><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Some industrial network protocols This section will brie y introduce other protocols used in the automotive industry. Some\u00a0of these are old ones, which appear to be falling out of use, and others are new ones\u00a0being developed, many for so-called \\drive by wire&#8221; applications. The protocols will be\u00a0described in rather less detail than was CAN above. &hellip; <\/p>\n<p><a class=\"more-link block-button\" href=\"http:\/\/fxplans.com\/web\/industrial-network-protocols\/\">Continue reading &raquo;<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"template-twocolumnsleft.php","meta":[],"_links":{"self":[{"href":"http:\/\/fxplans.com\/web\/wp-json\/wp\/v2\/pages\/1630"}],"collection":[{"href":"http:\/\/fxplans.com\/web\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/fxplans.com\/web\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/fxplans.com\/web\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/fxplans.com\/web\/wp-json\/wp\/v2\/comments?post=1630"}],"version-history":[{"count":5,"href":"http:\/\/fxplans.com\/web\/wp-json\/wp\/v2\/pages\/1630\/revisions"}],"predecessor-version":[{"id":1632,"href":"http:\/\/fxplans.com\/web\/wp-json\/wp\/v2\/pages\/1630\/revisions\/1632"}],"wp:attachment":[{"href":"http:\/\/fxplans.com\/web\/wp-json\/wp\/v2\/media?parent=1630"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}