As technology develops, so does the demand on vehicle networking. While the CAN bus is enough to process smaller volumes of data, the ever-increasing need to handle a greater speed and volume of information has resulted in the development of an alternative option. Neil Pattemore explains.
We have all heard of the expression ‘networking’. This usually calls to mind socially networking with friends, or at a business event. Within the context of a vehicle, however, ‘networking’ is not so different from the conceptual viewpoint – it is still about exchanging information with a recipient. As the time needed to do this becomes ever-more critical, it is perhaps becoming a little more like speed dating!
The CAN bus was invented over 30 years ago to reduce the plethora of heavy and expensive wires needed to connect the electronic systems and components of a vehicle. Times have moved on, and the ever-increasing need to communicate faster has pushed the CAN bus to the limit. So, what is being used now to handle this greater volume and speed of data transmission? The answer is FlexRay.
A catchy name, but what does it do?
FlexRay is described as a communications bus that is a deterministic, fault-tolerant, and high-speed system. It was developed in conjunction with vehicle manufacturers and leading Tier 1 suppliers to deliver ‘the error tolerance and time-determinism performance requirements for x-by-wire applications. In other words, it not only provides faster communication, but is much more tolerant of glitches than CAN bus. FlexRay still uses the ‘twisted pair’ found in CAN bus, but this can be of either the two- or four-wire variety. It will not replace the other two dominant in-vehicle standards, CAN and LIN, but will optimise cost and reduce transition challenges.
The next generation of cars will implement FlexRay for high-end applications, with CAN bus for mainstream powertrain communications, and LIN for low-cost body electronics.
What are the differences between these various in-vehicle networks?
There are two key differences – speed and cost of implementation. LIN communicates at 40 kbit/s, CAN at 1Mbit/s, and FlexRay at 10Mbit/s. In relation to costs, they double between LIN and CAN and they rise by another 50% for FlexRay.
There are some similarities with CAN bus, but FlexRay supports both single- and dual-channel configurations, which consist of one or two pairs of wires, respectively. Differential signalling on each pair of wires reduces the effects of external noise on the network without expensive shielding. Additionally, most FlexRay nodes typically also have power and ground wires available to power transceivers and microprocessors.
The dual-channel configurations offer enhanced fault-tolerance and/or increased bandwidth. Most first-generation FlexRay networks only utilise one channel to keep wiring costs down, but as applications increase in complexity and safety requirements, future networks will use both channels.
One important aspect of FlexRay buses is that they require termination at the ends, in the form of a resistor connected between the pair of signal wires. While specific network implementations vary, typical FlexRay networks have a cabling impedance between 80 and 110 ohms, and the end nodes are terminated to match this impedance and to help eliminate problems with signal reflections.
So, what is different in the way that FlexRay works?
Firstly, the FlexRay protocol is time-triggered, which provides options for deterministic data that arrives in a predictable time frame (down to the microsecond), as well as CAN-like event-driven data to handle a large variety of frames.
FlexRay accomplishes this hybrid of core static frames and dynamic frames with a preset communication cycle that provides a predefined space for static and dynamic data. CAN nodes only need to know the correct baud rate to communicate, but nodes on a FlexRay network must know how all the pieces of the network are configured.
FlexRay manages multiple nodes with a Time Division Multiple Access (TDMA) scheme. Every FlexRay node is synchronised to the same clock, and each node waits for its turn to write on the bus. Because the timing is consistent in a TDMA scheme, FlexRay is able to guarantee determinism or the consistency of data delivery to nodes on the network. This provides many advantages for systems that depend on up-to-date data between nodes.
Its communication cycle is fixed when the network is designed but is typically around 1-5ms. There are four main parts to a communication cycle; there is a ‘static segment’ which has reserved slots for deterministic data that arrive at a fixed period, the ‘dynamic segment’ which behaves in a fashion similar to CAN, the ‘symbol window’, typically used for network maintenance and signalling to start the network, and the ‘network idle time’, used to maintain synchronisation between node clocks.
The static segment is the space in the cycle dedicated to scheduling a number of time-triggered frames. The segment is broken up into slots, each slot containing a reserved frame of data. When each slot occurs in time, the reserved ECU has the opportunity to transmit its data into that slot.
Once that time passes, the ECU must wait until the next cycle to transmit its data in that slot. Because the exact point in time is known in the cycle, the data is deterministic, and programs know exactly how old the data is. This is extremely useful when calculating control loops that depend on consistently spaced data. For the dynamic segment, FlexRay prioritises the data by using ‘minislots’ to prioritise data, with higher priority data using a minislot closer to the beginning of the dynamic frame.
Once a minislot occurs, an ECU has a brief opportunity to broadcast its frame. If it doesn’t broadcast, it loses its spot in the dynamic frame and the next minislot occurs. This process moves down the minislots until an ECU elects to broadcast data. As the data is broadcast, future minislots must wait until the ECU completes its data broadcast. If the dynamic frame window ends, then the lower-priority minislots must wait until the next cycle for another opportunity to broadcast.
Most applications require data to be represented in real decimal values with units, scaling, and limits. When you take one or more bits or bytes from a FlexRay frame, apply a scaling and offset, you get a ‘signal’ that is useful for communicating actual parameters between ECUs. Most ECU programs work with FlexRay data as signals and leave the conversion of signals to raw frame data up to the driver or lower-level communication protocols.
Impressive! However, as in-vehicle communication demands continue to increase, the next network will be a new 100Mb/s version of Ethernet – speed dating on steroids!
THANKS TO…
National Instruments for contributing the figures and data included within this article.
