FROM EDN EUROPE: Network protocols compete for highway supremacy

Today's vehicles routinely marry established networks such as CANs (controller-area-networks) with newer, low-cost, low-bandwidth links such as LINs (local-inter-connect-networks) to connect diverse, decentralised systems. Further complicating the issue, the rise of infotainment and telematics is spawning new connectivity models, such as MOST (media-oriented system transport). Such systems have hugely varying bandwidth and timing constraints ranging from low-speed, non-time-critical applications, such as autonomous wash/wipe control, to high-speed power-train and safety-system links that require close synchronisation. From a vehicle manufacturer's viewpoint, these multiple network technologies are a necessary evil that they'd rather avoid. But the onset of x-by-wire systems to replace hydraulic and mechanical functions, such as braking and steering, is stretching today's automotive networks, forcing designers to consider new approaches to problems such as deterministic behavioural patterns and intrinsically safe operation.

It's important to acknowledge that developments in network technologies that target automotive use aren't limited to the automotive arena. Indeed, many of the technologies that now vie for highway supremacy inherit design approaches that derive from well-established aerospace practice. But, as any new networking technology matures to meet the aggressive cost and performance metrics that the auto industry demands, you can expect to see all manner of applications appear in any industry that employs automation. An obvious example is CAN, which you now find operating lifts, controlling machine tools, signalling within railway networks, monitoring engine-room activity aboard ships—wherever embedded systems demand robust serial links to exchange relatively short messages at maximum speeds of 1 Mbps. One sign of maturity is that a vendor such as Motorola is offering microcontrollers that combine CAN (controller-area-network) and Ethernet connectivity to serve factorywide automation and data-collection tasks. Another significant development is Volcano Automotive's Networking Series—a tool set for designing and implementing deterministic CANs that enjoys widespread use in the automotive industry (Reference 1).

Before focusing on recent developments, it's helpful to identify the characteristics that a new network technology must provide to support systems such as brake-by-wire, as well as any related requirements that impact design. For example, in the near future, safety systems that combine multiple radar sensors will network with power-train and braking systems to provide autonomous crash-avoidance capabilities (Reference 2). As vehicle manufacturers purchase such system elements from multiple third-party suppliers (the so-called Tier One suppliers), it's critical that systems are "composable"—or in practical terms, that you can exchange prequalified ECUs (electronic-control units) from various suppliers with impunity. However and, perhaps, amazingly, this ability does not exist today. A functionally equivalent ECU is unlikely to work across one vehicle manufacturer's model range, let alone in a competitor's product.

Now that automotive manufacturers finally recognise the massive cost of custom ECUs, the industry is cooperatively seeking a solution. The IT industry sets an example here, because widespread standardisation permits wholesale changes to products without impacting design. Facilitating this objective within a vehicle similarly requires a hierarchical view of the system architecture that allows you to decompose the top level to a set of functional subsystems, or "clusters." In this way, you can ideally add or remove a function, such as electronic stability control, without impacting other contributing functions, such as braking. But, unlike your desktop PC, safety-critical functions such as brake-by-wire mandate a hard-real-time response. Hence, composability in this sense requires that the interface characteristics of each ECU in the system are known in both time and value domains.

Architecturally, today's vehicles typically include multiple CANs that communicate via gateways, separating high-speed buses, such as power-train-control buses, from lower speed ones, such as body-function buses (Figure 1a). Manufacturers may further partition buses to reflect functions within, say, the vehicle's left- and right-hand sides, so there are a growing number of microcontrollers with gateway capabilities via multiple CANs and other serial ports. One example is Motorola's HCS12 family. You'll also find alternative device families with varying serial-connectivity options from other companies with strong automotive/industrial-control involvement, such as Infineon, Fujitsu, Hitachi, and NEC. Below the system-architecture view, each cluster is a distributed system that comprises a number of nodes connected by a network. Below this network level, individual nodes possess varying levels of application-dependent I/O coupling that is hidden from the network view via the CNI (communication-network-interface). In a well-designed system, such as CAN in Automation's CANopen, a COI (controlled-object interface) then abstracts application software from standardised profiles of the sensors and actuators that it controls (Figure 1b).

A typical analysis exercise to establish network requirements yields a list of metrics that describe the maximum allowable message latency, operational frequency, and bandwidth of each node on the bus. By nature, x-by-wire and similar systems comprise many sensors and actuators that demand low message latencies and guaranteed responses, such as a vehicle's front wheels turning in response to a driver's steering corrections. Often, these sensors and actuators compete for network resources. As a result, the network must guarantee adequate bandwidth and support fully deterministic behaviour in both static and dynamic domains—"static" in the sense that a scheduler ensures that messages arrive at their destination within a deadline that you can guarantee at the system-design stage, and "dynamic," ensuring that an interrupt-service routine responds within a given deadline following an event. It must also complete these tasks within the scheduler's timing constraints. Because missing a deadline may compromise safety, x-by-wire systems demand hard-real-time response and safety mechanisms that detect and correct transmission errors. Together, these requirements suggest a bus that has a minimum bandwidth of 1 Mbps, latencies of less than 5 msec, and error-detection and -correction mechanisms that reduce the probability of uncorrected errors to less than 1×10^–11. Other essential attributes include the ability to detect all failure modes that render the bus unusable, such as screening out "babbling-idiot" failures due to a node's failing and monopolising the bus by transmitting useless information.

So far, you may expect a conventional CAN to fulfill these objectives. But CAN employs a nondestructive CSMA/CA (carrier-sense multiple-access/collision-avoidance) arbitration technique for bus access rather than the TDMA (time-division multiple-access) technique that better suits deterministic data transmission. Because events trigger message transmission, CANs are susceptible to peak loading when multiple devices compete for bus access. Although CAN's arbitration mechanism guarantees that competing messages transmit in order of priority, you can't determine exactly when each transaction will occur. In other words, you may be able to quantify the maximum latency for any message, but you can't eradicate latency jitter. Real-time control systems, such as electrically operated valve trains are typically highly sensitive to latency jitter. As a rule of thumb, latency jitter should be two orders of magnitude lower than the latency metric. To address this objective, CAN's developers at Robert Bosch came up with TTCAN (time-triggered CAN)—an extension of the protocol that controls time-triggered message transmissions in accordance with a predefined schedule (see sidebar "CAN adopts time-triggered architecture"). TTCAN now benefits from international standardisation in ISO (International Organization for Standardisation) 11898-4 (Reference 3).

Even so—and as TTCAN's authors freely admit—the protocol can't address every facet of a safety-critical system. There's also a 1-Mbps ceiling to CAN's speed over copper in the de facto standard ISO 11898-2 implementation. Because emerging x-by-wire applications require greater bandwidth as well as determinism and composability, BMW began developing the Byteflight protocol in 1999. A collaborative effort between BMW and core partners that comprise Bosch, DaimlerChrysler, General Motors, Motorola, and Philips Semiconductors has resulted in FlexRay, which you can regard as a copper-media-compatible superset of fibre-optic Byteflight. Preceding BMW's initiative, TTP (time-triggered-protocol) research at the Technical University of Vienna resulted in the 1998 formation of spin-off company TTTech, which aims to bring TTP technology to market. As a result, FlexRay now vies with TTTech's own TTP/C (where the C signifies 125 kbps or greater) for supremacy in x-by-wire and similar applications (see sidebar "For more information").

Both Byteflight and TTP address similar requirements but apply subtly different design strategies due to trade-offs between conflicting safety, composability, and flexibility needs. Beyond these prerequisites, desirable attributes include a 10-Mbps bit rate over copper; arbitration-free transmission; a fault-tolerant synchronised global timebase; fault-tolerant and time-triggered services implemented in hardware; dual-redundant transmission channels; physical-layer error containment via bus-guardian logic; rapid error detection and signalling; and support for bus and star topologies over copper and fibre media. Before exploring operational characteristics, it's worth noting that you can freely download the TTP specification from www.tttech.com, but you'll need to join the FlexRay Consortium to examine the protocol's implementation. (Only a requirements specification appears at www.flexray.com.) Core FlexRay membership is no longer available, but you can subscribe to an associate membership that provides access to the specification and enjoy equal free-license use. Or, you can subscribe to a premium membership that allows you more close involvement with the specification's development. The annual fees for the associate and premium memberships are €7500 and €15,000, respectively. To encourage their rapid support, FlexRay offers them this membership class for free. You can also apply for three similar membership levels within the TTA (Time-Triggered Architecture) Group, which promotes the TTP technology for annual fees of €7500 to €25,000.

Unlike traditional CAN's event-triggered architecture, FlexRay and TTP employ TDMA media access to implement a time-triggered communication system that's intrinsically free of arbitration conflicts. In TTP, each node has a unique message-sending slot in the TDMA round that you determine during system design. Each node's communications controller stores sending- and receiving-slot schedule information for every node within the cluster, along with a delivery or collection address for each message. This information is common knowledge to all nodes in the cluster and appears in each communication controller's message-descriptor list, together with direction, length, initialisation, and a mode-change-protection field (Figure 2). Accordingly, the message-descriptor list's length depends on cluster-cycle length—that is, the number of TDMA rounds before the cycle repeats. For safety reasons, a TTP node's host controller can't access the communication controller's message-descriptor list during operation; this precaution blocks unauthorised mode changes. FlexRay's designers don't agree on the need for common knowledge among nodes, citing the better memory usage, easier system reprogramming, and lower system cost that their need-to-know strategy offers.

FlexRay and TTP simultaneously transmit messages over two channels whenever the time-slot value matches a message's send-time value. In a typical safety-critical application, TTP and FlexRay mirror information between the channels. But FlexRay permits sending different information on both channels in the same time slot and allows different nodes to use the same slot on different channels. These options support single-channel operation and increase system bandwidth in non-safety-critical applications. TTP also allows different information on both channels but not from different nodes. In TTP, the message comprises a normal or an initialisation frame. Both frame types comprise a start-of-frame field, a 4-bit header field, a data field as large as 240 bytes, and a 24-bit CRC (cyclic-redundancy-check) field. The header field differentiates between frame types and activates mode changes, such as restarting an errant node following a transmission failure. During an initialisation frame, the data field carries controller-state information, such as the global time value, the index of the current message-descriptor-list entry, and a membership field. Each node has a bit in the membership field whose position uniquely defines it within the cluster, so the length of the membership field equals the number of nodes. Internally, each TTP communications controller maintains a message area for received frames comprising a 16-bit frame-status field and as many as 120 16-bit words (Figure 3). The frame-status field holds 5 bits of message-reception status, together with an 8-bit receiver concurrency-control field. This concurrency field helps implement the protocol's nonblocking-write mechanism, preventing the host controller from concurrently accessing data that the communications controller is using.

A top-level view shows that FlexRay shares much in common with TTP; a global clock times TDMA rounds whose length depends on cluster composition. Similarly, slot timing is identical between the two channels, and each slot has a unique identifier for the message that it carries. TTP accommodates variable-length slot timings up to the protocol's maximum 240-byte payload; in FlexRay, slots have equal lengths. FlexRay accommodates as many as 16 slots per node and allows multiple slots per node to ensure that its majority-vote mechanism reaches global state agreement within one TDMA round. FlexRay's frame format includes a header section, a data section, and a 24-bit CRC trailer section (Figure 4). The header comprises frame-identification, length, synchronisation, header-CRC, update, and cycle fields; two further 2-bit fields are reserved for network-management use. The frame-identifier field allocates the message's transmission time slot, and the protocol ignores unused slots. The length field specifies the number of data bytes in the message, which ranges from 0 to 244 bytes, plus an optional 16-bit identifier. (The protocol supports padding for small messages.) When active, the synchronisation bit signifies that the communications controller use the frame for global clock synchronisation. The 6-bit cycle field reflects the current communication cycle within the TDMA round, and the data-update flag reports new message information since the last TDMA round. A run of eight zeros precedes each frame, and all frames in a cluster have equal length. Therefore—as for TTP—static bandwidth allocation during system design eliminates runtime contention, and the distributed control loop closes every TDMA round.

But rather than adhere to the static schedule that TTP's designers prefer, FlexRay's designers also wanted to accommodate event-driven messages. This difference is one illustration of the conflicting balance between a static schedule's guaranteed composability and the greater flexibility that event-driven messaging provides. FlexRay's approach employs a "flexible-TDMA" technique that appends a dynamic segment containing a number of "minislots" to the traditional static segment. To guard against latency jitter but accommodate a message-priority mechanism, FlexRay's dynamic segment allows arbitration but limits bandwidth consumption. You allocate time for a scalable number of event-driven messages during system design, such that the dynamic segment effectively becomes another static segment. To avoid concurrent transmissions and prevent collisions, each event-driven message has its own identifier that matches its minislot allocation. The protocol allows new data to transmit only within the dynamic segment; if there's insufficient bandwidth for new data, messages with numerically higher identifiers wait until the next TDMA round. The dynamic segment also inhibits synchronisation frames and suspends bus-guardian activity, so the bus-guardian logic treats the dynamic slot as a static slot. In any case, FlexRay enables bus-guardian logic only for nodes that are directly participating in a message exchange.

Like FlexRay, TTP includes multiple error-recovery mechanisms but offers some implementation differences, such as sending each node's controller-state information within the frame's CRC field calculation. TTP identifies transmission failures by negating the membership bit of any node that didn't correctly send a message during the last TDMA round. In this way, receivers continuously ensure global state agreement by appending their own controller-state information to the sender's header and data-field contents. If the resulting CRC calculation differs at the receiver, the transmission fails. In such cases, the receiver discards the message and negates the sender's membership bit, informing the sender and all other nodes of the failure within the next TDMA round. Of course, this action is based solely on the receiver's view and could signify receiver hardware failure. Accordingly, the protocol includes a voting mechanism whereby a majority of nodes that agree their controller-state information excludes the minority. If the receiver is at fault, TTP's membership rules ensure that the minority clique will include the receiver, and the receiver will freeze; the protocol will then attempt to reintegrate the receiver within the next TDMA round. In the case of an undisputed transmission failure, the would-be sender detects this state from the implicit acknowledgment of the next two senders and negates its membership bit to "failed." No reintegration is necessary for this node, and it can try to send again in the next round. Accordingly, you ensure during the design phase that some nodes periodically transmit initialisation frames.

At the physical-layer level, both protocols support flexible combinations of bus, star, or multiple-star configurations and run as fast as 10 Mbps over copper. Both protocols mandate precise global clock synchronisation that hardware and software must guarantee using low-cost crystal oscillators. To eradicate bit-stream jitter, neither protocol allows CAN's bit-stuffing technique to nullify data-dependent dc offsets on the transmission line. Instead, CAN's NRZ (non-return-to-zero) modulation cedes to TTP's MFM (modified-frequency-modulation) and FlexRay's NRZ-8N1 (NRZ plus one start and stop bit per byte), which ensure run length independent of data contents. Both systems include bus-guardian hardware to guard against hardware and software failures, although the arrangement of these mechanisms differs. To reduce the likelihood of, for example, accidental damage compromising transmission integrity, TTP explicitly sites the central bus-guardian in a star-coupler far from the node that it protects. TTP bus guardians include an independent power supply and a clock with autonomous synchronisation. The protocol uses these resources to reshape transmission signals and thus mask slightly out-of-specification timing and voltage parameters. FlexRay mandates no such independent resources, but both protocols include never-give-up mechanisms that endeavour to maintain transmission in the presence of multiple faults. Either protocol's bus-guardian hardware ensures that babbling-idiot nodes gracefully fail silent.

Implementation details aside, other issues inevitably affect and may ultimately determine which protocol dominates applications. First, you might ask, is there room for more than one hard-real-time automotive protocol? Gerd Teepe, manager of Motorola strategy and advanced systems laboratories in Munich, thinks not: "Vehicle manufacturers perceive that there are already too many protocols, and they want to simplify their systems." In a demonstration of collaboration between erstwhile competitors, Motorola is working alongside Philips to bring FlexRay silicon to market; Motorola is responsible for controller development, and Philips lends its expertise in physical-layer implementations to build transceivers and the bus-guardian logic. Teepe also gratefully acknowledges that Atmel and NEC recently joined the FlexRay consortium, contending that more suppliers add impetus to the protocol's market penetration; STMicroelectronics and Texas Instruments joined the consortium last year. According to Teepe, Motorola is on track to make first silicon available for sampling early next year and expects full production to begin in 2006, with steady volume growth in the following years. Meanwhile, prototype FlexRay designs rely on FPGA implementations that currently fail to meet the protocol's full specification. But Teepe points to the number of tool makers, such as Cadence, Decomsys, dSpace, and National Instruments, that are already working on FlexRay support: "Hardware models and software tools are available today that allow you to prototype designs," he says.

Making the case for TTP, TTTech's marketing director, Markus Plankensteiner, PhD, points to the protocol's maturity in safety-critical systems. The protocol has been in development for more than 20 years and has seen only minor changes since 1998. Airbus Industries has adopted TTP for cabin-pressure control in its model A380 airliner; Honeywell is using the protocol for jet-engine control in the F-16 fighter and has a fly-by-wire cockpit project under way. Other nonautomotive applications include Alcatel's railway-signalling systems, which are operating in Austria, Hungary, and Switzerland. TTP's automotive customers include Audi, PSA Peugeot-Citroen, and Renault, with Tier One suppliers Delphi, Denso, and Visteon. As proof of concept, the protocol has appeared in by-wire prototype cars from companies such as Audi, Bertone, Daimler, General Motors, and SKF. Controller silicon is available from Austriamicrosystems and NEC, and Hitachi recently signed a licensing agreement; physical-layer transceiver chips will be available by year's end from these and other suppliers, such as Infineon. The protocol is now in its sixth generation, and TTTech can supply an entire tool chain, including a four-node development-cluster starter kit that costs around €30,000. You can also use third-party tools, such as The Mathworks' Simulink, to model TTP systems.

Taking an independent view, Eric Medan, co-founder of French system-integration company NSI, believes that FlexRay and TTP complement each another in many ways. NSI works with both automotive and aerospace customers to help them develop new systems and to provide appropriate training for their engineers, but Medan notes that the company is "neutral regarding FlexRay and TTP promotion" and exists "exclusively to help [its] customers implement their technology choices." Current projects include building a prototype ECU in partnership with FlexRay tool supplier Decomsys. Although Medan suspects that FlexRay may eventually dominate mainstream automotive applications, he expects TTP to retain a large chunk of the aerospace market: "Whichever protocol wins the automotive market, TTTech's renowned expertise in by-wire applications perfectly positions the company to help manufacturers bring time-triggered systems to market."

From an application developer's viewpoint, according to Peter Bell, associate director and business-unit manager for Cambridge Consultant's automotive and transport group, network architects should pay more attention to higher layer protocols. He agrees that the existence of too many protocols complicates the lives of vehicle manufacturers but observes that software complexity is hugely challenging and costly to the industry. Bell points to the middleware solution that the IT industry conventionally applies to abstract physical-layer issues from application-level development. He says that the industry has made various unsuccessful attempts to make an RTOS provide adequate abstraction. As automotive engineers typically come from a hardware background, they tend to think in terms of components rather than the overall system architecture. This situation is changing, Bell says, albeit slowly: "Currently, rather than following the seven-layer structure that ISO/OSI (Open Systems Interconnection) suggests, you have huge gaps where individual or multiple layers are missing" (Figure 5). By focusing on system architectures, Cambridge Consultants is helping customers overcome these wider issues and is paving the way for truly reusable systems. Bell notes, "A unified architecture also creates the opportunity for tool makers to provide aids, such as automatic code generators, that further reduce development time and cost within tightly specified system-qualification constraints."