milcan

FlexRay Mi1CAN BridgingD.Summers Dr P.Charchalakis Dr E.Stipidis Dr F.H.Ali

University of Sussex University of Sussex University of Sussex University of Sussex

Abstract- In a modern vehicle network, safety-critical sys- of all frames on the bus and preferring recessive bits overtems must co-exist with current deterministic networks such as dominant ones in each place. This has the result that lower-MilCAN. Additionally, it may be advantageous to use MilCAN valued frame identifiers take priority. Controllers transmittingto monitor the performance of a safety-critical system such as frames that lose priority automatically cease transmission butFlexRay.

continue to receive, leaving the "winning" frame alone andFollowing a brief overview of both MilCAN and FlexRay tech- avoiding bus collisions.

nologies, the progress of an ongoing investigation into bridgingthe two standards is presented. The current solution is acceptable MilCAN frames use a custom message identifier format,under test conditions, but unlikely to be suited to real-world use. which includes indication of message primary type and sub-Future plans extending the investigation on to new and more . .suitable hardware are then briefly discussed. type and a priority level. Message types indicate the semantic

content of the frame, typically being drawn from a stan-dardised table of values including Navigation, Lighting andDiagnostics, as well as automotive and other types. Since thenetwork is message-addressed rather than node-addressed, the

MilCAN-A is an open standard interface[1] implemented gesg dniirtbeas nldsa"hsclyadesdin devices destined for use in military vehicles. It defines a

message identifier table also includes a "physically addressed"idideeerministinccommuscations miotoltar ls. taddefioneslay value that allows a message to marked as coming from ordeterministic communications protocol as an additional layer destined for a specific node. Priority levels range from zero toon top of the popular Controller Area Network standard[2], seven, each defining a maximum delivery latency from "oneallowing messages to be exchanged between devices with communications cycle" to "whenever the bus is free". Sincea guaranteed maximum latency. This guaranteed latency of message transmission takes place in order of priority, highdelivery means that MilCAN-compliant devices can safely be priority messages will meet their delivery contract, even ifused in real-tme or deterministhic systems, snce hgh priority the bus is heavily loaded. It is worth noting that messagemessages will be delivered within their latency contract even type and message priority are entirely separate: any devicein cases of high bus load. may transmit at any permitted priority (O is reserved for

The underlying network operates at a speed of either 250 network control messages), depending on the importance ofor 1000 kbps, dependant on application and bus length, and the message function in question. Since MilCAN is based onsupports 29-bit message identifiers, allowing MilCAN devices CAN, frames may have a payload of length varying betweento be interoperated with SAE J1939 networks[3]. The pro- ero and eght octetstocols are bus-compatible, in that they can be run on the Adding the MilCAN layer on top of CAN adds a degreesame bus by different groups of devices without interfering, of determinism to the network, as well as a higher percent-but communication between MilCAN-A and J1939 must be age utilisation since frame transmisson occurs at scheduledfacilitated through a bridge. intervals. This means that transmission can be predicted, to a

The protocol achieves low-latency performance using a peni- degree, and that so long as the schedule is designed intelli-odically repeating transmission schedule (the MilCAN cycle), gently, each PTU can be fully loaded with frames and every

synchro d by a mPTU in the cycle can be occupied. MilCAN-based networkssynchronised by a master node (defined as the responsive ar.on navreyo urn miitr ste,inldgnode with the lowest source address). The schedule is divided the BAE Systems Land Systems (Alvis-Vickers) Challengerinto 1024 Primary Time Units, and frames scheduled to betransmitted in that PTU are queued for transmission at the 2 tank, and the BAE Systems Bofors LEMUR fire-controlrelevant node. Message priority is determined in a two-stage computer and CV9OAD-TD combat vehicle - air defence[4].process: first, the highest priority message in the transmissionqueue at each node is placed on to the bus, then CANarbitration is applied to the message identifier to determinebus priority.

The Controller Area Network standard performs messagearbitration on a bitwise basis, comparing the frame identifiers

1-4244-01 59-3/06/$20.00 2006 IEEE

Authorized licensed use limited to: Instituto Politecnico de Coimbra. Downloaded on April 30,2010 at 11:38:48 UTC from IEEE Xplore. Restrictions apply.

II. THE FLEXRAY PROTOCOL

FlexRay is a new communications protocol, designed bythe FlexRay consortium1 as a safety-critical automotive X-by-wire system more flexible than its contemporaries, such asTTP. Bus data rates range up to a maximum of 10 Mbps, and Fig. 2: Star Topologyeach individual message may be up to 256 octets in length.

The FlexRay system specification[5] lays out most details The static segment is a simple TDMA, with a static messageof both hardware and software, but leaves the choice of schedule that is defined at compile-time for all nodes. Ifsome specifics to the implementor. Systems should use a message transmission takes place only in this segment, anddual-channel bus for redundant communication, although a the segment TDMA is well organised, it is possible to achievegiven node need not necessarily be connected to both. In very high utilisation. The dynamic segment is the source ofparticular, the physical layer is left unspecified: ribbon-cable, much of the flexibility in FlexRay, since message transmissiontwisted-pair cable or fibre-optics can all be used as required, here can be undertaken on an as-needed basis. There is noalthough the development kits available at present concentrate static TDMA, so frames carrying non-urgent or high-volumeon ribbon-cable for reasons of simplicity. The network should data can be transferred as needed on a loose priority basis.ideally be set up as a connected graph of active stars to Additionally, it is possible to increase the available bandwidthmaintain ideal EMI characteristics, but a Bus configuration by desynchronising the buses and sending different data onis acceptable for small networks. each during the dynamic segment, so long as the buses are

re-synchronised before the start of the next slot. The lengthThe active-star topology is a major feature of the FlexRay of both segments can be set during cluster setup, and either

standard, particularly since the great majority of communi- may be set to zero if that segment will not be requiredcations networks use a bus topology, so a moment will be in this application. Finally, the symbol window is used fortaken to explain the concept. The bus topology (Figure 1, network management (one symbol to indicate the network isin which every node is connected to a single backbone via performing according to expectations, a different symbol if aa series of taps) is used by many networks, embedded and problem has occurred) and the network idle time gives eachcommercial, including IN, CAN and SPI. The active star node time to perform local administration and configurationtopology (Figure 2) is somewhat rarer, being found in FlexRay tasks when needed.and switched Ethernet as well as, to a lesser extent, USB.Instead of being connected to a common bus, every node has FlexRay frames are semantically simpler than MilCANa direct connection to a star coupler which then forwards frames, but have a larger payload segment. A single framea received message to every connected node excepting the may carry up to 254 octets of data, but the header is somewhatone from which it originated. This design tends to result in basic, containing a frame ID, a set of flags, a data length codemuch better EMI performance, since any noise induced will and a CRC. This simplicity means that FlexRay networks arebe present only on one segment as opposed to the entire bus. very general and can easily be adapted to new configurations.

Although the lack of a set of suggested type identifiers (suchl 1 as is present in MilCAN) means that disparate systems cannot

K( Y) Y( ) SJ easily share information, the fact that FlexRay clusters arecustomised from scratch for their application means that thisshould not be a problem.

Fig. 1: Bus Topology When considered against MilCAN, FlexRay has severaladvantages. First, FlexRay is fault-tolerant, in several senses.One of the two bus channels can be severed without affecting

The software specification is a little more complete, defining system performance, so long as no transmissions are scheduledclear structures for the communications cycle and data frames to run solely on the compromised channel. A node can fail inthemselves. The system is based around a repeating TDMA, a variety of network-hostile modes, and the low-level busmuch like MilCAN, which is in turn divided into 2048 slots. guardian built into the controller automatically locks out theEach slot is a whole number of macroticks in length, the transmitting component before the garbage data is dumpedmacrotick being an agreed length of time that is constant for onto the bus. If a node falls silent, the nodes expecting toall nodes. Each slot is then divided into four sections: static receive messages from it will log the problem (if logging issegment, dynamic segment, symbol window and network idle supported on the relevant architecture), but will continue totime. operate unless specifically programmed to halt on reception

'A group of interested companies including BMW, Bosch, DaimlerChrysler, failure. Essentially, the system tends to fall back to a reduced-Freescale, General Motors, Philips and Volkswagen. (http://www.fiexray. org) functionality state without compromising the entire network


when damaged. MilCAN is also fault-tolerant to some extent, FlexRay to communicate, or if a safety-critical FlexRay au-but only in that it can continue operations when some nodes tomotive network needs to be connected with MilCAN-basedon the bus are non-responsive. subsystems, a bridge can be used to connect the networks to-

gether. This is typically much more economical than replacingSecond, FlexRay is capable of a much higher data rate, the entire control network and upgrading all devices to the new

since its bus clock rate is an order of magnitude greater than protocol, since FlexRay devices are currently more expensivethe maximum possible rate for the CAN bus upon which than equivalent MilCAN units.MilCAN is based. Finally, it is run-time flexible in that thestatic segment is used to carry expected or safety-critical data, An investigation was undertaken into FlexRay-MilCANwhile the dynamic segment can be kept available to service bridging, using commercially-available development kits. Al-unexpected or high-bandwidth low-priority transmissions. though the investigation centred more on tunnelling than

bridging (a MilCAN message was transported over a FlexRayHowever, it is worth noting that FlexRay is still a developing backbone and re-emitted on the other side), an intelligent

technology: there are very few manufacturers producing con- bridge is the eventual goal of this research.trollers and development kits that can form part of a FlexRaycluster, and building a FlexRay controller from first principles B Hardware set-upis essentially too great a challenge for a research group toundertake. Those kits that are available tend to concentrateon the static segment: at the time of writing, only Decomsys In order to study FlexRay-MilCAN bridging, a customproduce software capable of scheduling data transmission in network was built (figure 3), consisting of two MilCANthe dynamic segment, and their support is not quite mature. networks and a FlexRay backbone.In contrast, CAN development kits are plentiful and availableat a wide range of prices and, if one does not suit a group's MI|CAN CAi CAN MClANneeds, it is entirely possible to construct one. Once a CAN | lcontroller exists, the MilCAN stack can then be established in C167CS C167-CS Node Node

and such timers are in short supply on the Node IV. FURTHER WORKdevices. Although the RTAI system could successfully runa MilCAN stack, it remains to be tested whether doing so The research group has recently acquired a new piecewould interfere with the operation of the FlexRay stack. For of hardware from DECOMSYS: a Node. As thethis reason, running a MilCAN stack on the Node name suggests, the development kit is based around a Re-was deemed non-viable at this time. Instead, a standard nesas M32C/85 processor, and presents the same externalCAN connection was used to transfer messages between the interface as the Node. However, although this de-Node and the MilCAN network: since a MilCAN velopment kit is only clocked at 24MHz, in comparison toframe is a semantic reinterpretation of a CAN frame, this is the Node's 166MHz, there is no operating systemnot greatly complicated. overhead: the entire kit is purely interrupt-driven and remains

in a simple "bare-metal" state during normal operation. It isD. Results worth noting that one of the example applications shipped with

the Node is a FlexRay-RS-232 bridge, suggestingBasic performance testing was done using a laptop running that bridging applications may have been a factor in its design.

the Vector CANoe analysis package, injecting a single frame Over the next three months, we will continue our bridginginto the MilCAN network on one side and receiving the frame research on both platforms with the intention of producing aon the other side. Given the unloaded state of the network, more reliable, scalable bridge with a similar level of perfor-all message reception during this test should be considered a . ' .mance. This will entail integrating a MilCAN stack into thebest-case result. In all test cases, injection and reception times RTAI OS on the Node, as well as investigating thediffered by between 3.4 and 3.8 milliseconds (figure 4). capabilities of the Node in this respect.

Latency of end-to-end message transferREFERENCES

3.75 -

3.7 - [1] "MilCAN A, Application Layer Specification", Qinetiq7 3.65 -__ (available on request from http://www.milcan.org)X________________________________________ s[2] Robert Bosch GmbH, CAN information website

3.6 - / http://www.semiconductors.bosch.de/en/20/can/index.asp3.55 - [3] milcan.org, Introduction to the standard

I, ~~~~~~~~~~~~~~http://www.milcan.org/FAQ/faq.html3-3.48 3 [4] milcan.org, Projects using MilCAN3.45 - http://www.milcan.org/Projects/projects.html

O 1 2 3 4 5 6 [5] FlexRay Consortium, FlexRay Protocol Specification, version 2.0Tlials (available on request from http://www.flexray.com), 2004

Fig. 4: Graph of average latency over multiple trials [6] "Integrated Vetronic Systems - Intelligent bridging of vehicle networksover high speed backbones", Periklis Charchalakis (Doctoral Thesis),University of Sussex, 2005

The above investigation shows what appears to be a viableFlexRay-MilCAN bridge. Unfortunately, although the systemis capable of rapid bridging in this simplified test case, thesituation is likely to change when the system comes underheavy load. This situation could be partially resolved byoperating the MilCAN networks at 250kbps and the CANnetworks at full speed (1Mbps), but this may not be anacceptable solution in production systems.


milcan

Documents