FlexRay goes graphical

FlexRay was conceived as a safety-critical network for cars but it is possible to squeeze graphical data onto it, as one experiment shows.

When it was developed in 2001, FlexRay was intended to become the de facto standard in fast and reliable data communication in cars. FlexRay is normally used in control systems found in the chassis and powertrain of a vehicle but is also used by communication backbones and driver-assistance functions. Steer-by-wire, brake-by-wire and drive-by-wire functions can also be implemented on FlexRay because it has features that support safety-critical functions.

FlexRay is now being deployed in automotive electronic architectures, as demonstrated by its introduction in new cars such as the BMW X5 and X6, where it is used for dynamic suspension control. The BMW 7-series will incorporate FlexRay, with further cars from other manufacturers expected to follow.

Potentially, the use of FlexRay could extend beyond the control systems of a vehicle, even as far as passing graphical content around the vehicle.

Graphical data transmission

Fujitsu Microelectronics Europe and the Laboratory for Embedded Systems at the University of Applied Science in Aschaffenburg decided to undertake a feasibility study to investigate FlexRay's potential for transmitting graphical data, such as maps, navigation information and video around the car. The aim, however, is not to replace existing multimedia communication systems such as MOST or IDB1394.

A typical application scenario is a navigation unit that uses FlexRay to transmit data to a cockpit display as a map. The prototype system contains two FlexRay nodes. We used a pair of starter kits, both based around Fujitsu microcontrollers to build the prototype. One transmits graphical data to a second node, which is used to display it.

The control node is responsible for accessing a mass-storage device that contains the map data and for processing global positioning system (GPS) data to calculate routes. Due to their complexity, the GPS and route calculation modules had to be simulated in an easier way, although this did not have too much of an affect on the purpose of the simulation: to gauge whether FlexRay could handle the data-transmission load. The simulation is based on working with a pre-defined list of points along the route.

The second display processes the commands and map data and changes the information on the connected display accordingly. When the navigation starts, the map of the current position is transferred completely only once. As the position of the vehicle changes in the simulation, new sections of the map must be displayed. In order to reduce the required bandwidth for the graphic data transmission the whole map is not transferred at every change. Instead, only the new pixel rows and/or columns are transmitted.

The display node receives a command to scroll down the appropriate number of pixels on the displayed map in the appropriate direction and fills the gaps in this new map section with the received row or column of graphic data. Such a command could look something like "move map in +X direction for the distance of two pixels". The old data that is no longer used in the display is not retained. This reduces the memory requirements of this node. If, during this process, an error occurs, a complete part of the map will be sent to the display node so that an error-free display is realised.

As well as the graphic information, command and control data is also transferred. For example when the information to turn in another direction is sent, the display node will show a pop-up window in the display with an arrow indicating the new direction. This command and control data of the control node and the responses of the display node are all transferred in the static segment. The graphic data uses the dynamic segment because it must only be transferred sporadically, as the position of the vehicle changes.

Bandwidth usage

To find out the bandwidth requirements for an automotive navigation application using distributed embedded systems connected via FlexRay, we used a PC running tools to monitor the FlexRay bus. The graph shows how much graphic data needs to be passed during the dynamic segment and the average net bandwidth usage. The prototype needed 32kb/s in the static segment, which is a fixed amount, and an average of 90kb/s for the dynamic segment.

The bandwidth for the graphic data transfer depends on various factors. If a map view with a higher zoom level is used, the map must be scrolled faster. This consumes more graphic data per time. The average peak bandwidth for the graphic data transfer could also be lowered down to a certain limit. The whole transfer process will last longer if the maximum amount of data is not sent in each FlexRay cycle. The decision of whether to make a peak bandwidth reduction will also depend on the type of other data transferred on the FlexRay network in the dynamic segment.

All the graphic data is uncompressed in this implementation, which can be improved upon easily. There are a lot of equally coloured areas in typical navigation maps. Therefore, the achievable compression factor would lead to an even lower bandwidth requirement. So, the value of 90kb/s for the bandwidth derived from this prototype should be treated as only one possibility.

Apart from the compression of graphic data, the implementation of a data buffer in the display node would also result in better overall system performance. This data buffer may contain predicted graphic data that was sent at low priority to improve bus use. The control node can send graphic data beforehand, because it 'knows' which data will be needed next, unless the driver does not follow the directions, in which case the data will just be discarded.

The work shows that transmitting graphical data over FlexRay is feasible and does not use up the bandwidth of the bus.

Dr-Ing Jörg Abke is professor of computer sciences and electrical engineering at the University of Applied Sciences Aschaffenburg; Christian Eyrich is a junior application engineer at Fujitsu Microelectronics Europe; Matthias Steeg is an application engineer at Fujitsu, and Wolfgang Wiewesiek is the manager for automotive networks at the company.

Recent articles

Info Message

Our sites use cookies to support some functionality, and to collect anonymous user data.

Learn more about IET cookies and how to control them

Close