Sharing with FlexRay
3 November 2014 
By James Dillon
The advance in technology, predominantly driven by the car buyer’s demand for cool ‘in-car’ features, threatens to outpace the advance in technician training and development. The vast majority of technicians may not yet understand CAN, its features, functions or how to diagnose it and here we are today, with FlexRay being utilised in a few of the vehicle manufacturers’ vehicles for the past couple of years. These vehicles will continue to filter into the aftermarket so what will you do, where will you go and what will you test (and with what tool) when you get your first FlexRay diagnostic job?
In addition to FlexRay, many modern motor vehicle models are being equipped with Fast Ethernet, which has a data transfer rate of 100 MBit/s (100 million bits, 1 or 0, per second). The primary reason is for data transfer for programming, software updates. The modern vehicle contains a large amount of processing power and relies on many hundreds of thousands of line of software code to enable the vehicle to operate as an integrated ‘machine’. From time to time, bugs are found and enhancements are made which require some elements of this software to be updated. New software has to be ‘fed’ into the machine. On older vehicles, the update data may have only been a few megabytes in size. On the modern vehicle, the software file sizes are far bigger. A convenient way of considering the difference in old to new style vehicle updates is to compare dial-up networking (using an old style modem and phone line) to the modern fibre optic broadband.
More data requires increased bandwidth. Without the required bandwidth, the time taken to ‘feed in’ the required data is extended past the point of being reasonable, it may take more than four hours to perform a complete vehicle software update. Fast Ethernet looks like it will be the technology used for future diagnostics (something called Diagnostics over Internet Protocol or DoIP), as both the physical and data structure exists and is widely used in other industries. DoIP also enables simpler implementation of telematics, the long-distance transmission of data, remotely.
Figure 1
FlexRay was co-developed by a consortium, as is usually the way with these things. It was established in 1999 with BMW, Daimler Volkswagen, General Motors, Bosch, Freescale Semiconductors and NXP Semiconductors and almost every other major car manufacturer has since joined. The primary objective was to develop a new in-vehicle networking alternative to CAN, which had reached its technical limits. The first production vehicle to have FlexRay implemented was the 2007 model year BMW X5 where it was used in the Adaptive Drive (electromagnetic suspension) system.
The key features of FlexRay can be summarised as: 1) Speed, it is x20 faster than CAN 2) It can be implemented in either single channel mode (one channel backs up the other – redundancy) or dual channel mode where each channel contains different data and passes more data 3) It is deterministic, it can operate in ‘real time’ 4) It can be implemented in three different topology styles (wiring layout) – linear, point-to-point or mixed.
One of the key methodologies behind the speed advantage of FlexRay over CAN is the way in which the network operates. CAN is considered as an event based system, where the system must react to an event, or stimuli, from the controlled system within an interval of real-time. One fundamental issue with CAN is the method by which the various ECUs gain access to the network to share their data. CAN uses a process called Bitwise arbitration. Essentially, each of the ECUs are given a rank within the system. High status, important, ECU’s are prioritised over lower status ECUs. Each time data access is sought by the ECUs, they must compare ranks, using leading zeros in their rank – the higher the rank, the more zeros appear in their rank. Each ECU puts the first character of its rank down. If the first has a 0 and the second has a 0, they move to the second character. If this first ECU has a 0 and the second ECU has a 1, the second ECU is outranked and it stops trying to access the network, allowing the first ECU to get on with its message. This prioritising process wastes a lot of time.
Figure 2
01278 428 699