Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Get ready as FlexRay hits the road

Posted: 02 Apr 2007 ?? ?Print Version ?Bookmark and Share

Keywords:automotive electronics? FlexRay design? CAN in car electronics?

Over the last few years, car electronics has increasingly defined the driving experience of modern vehicles. Electronics has penetrated all major systems in the vehiclefrom power train, body and chassis to driver-assistance systems, and active and passive safety systems.

The trend to network these systems started in the mid-1980s when CAN was introduced. At that time, every electronic control unit (ECU) still represented an autonomous functional unit in the vehicle. As the number of ECUs has increased along with the technical abilities that electronic control can provide, the trend has shifted from networked ECUs to distributed systems where functions are spread across multiple ECUs.

To address this trend's increasing demands, the car's comms network needs to provide not only high-speed data transfer, but also a deterministic and fault-tolerant one, which can support advanced distributed-control systems. Over the last few years, an industry consortium of more than 120 companies has developed the FlexRay comms system, a time-deterministic protocol with a 10Mbps data rate for advanced control systems in vehicles.

FlexRay is configured in recurring comm cycles at a data rate of 10Mbps. Each comm cycle contains static and dynamic comm segments, and the network idle time, which is a communication-free period that concludes each comm cycle. In addition, each comm cycle can contain an optional symbol window that can be used to runtime-test an ECU's interconnection to the physical network.

Closed loop
In a typical FlexRay communication cycle, the static comm segment accommodates data communication that requires bounded-latency and small-latency jitter. To achieve this, the static comm segment uses a time division multiple access-based communication scheme based on static comm slots.

Combined with a static schedule that is calculated off-line during the design of the system, FlexRay is able to address highly deterministic distributed applications, such as closed-loop control applications where the control loop is closed over the network.

In the static segment, the progression of static comm slots occurs in lockstep on both channels. ECUs may send frames with the same or with different content on each of the two channels within the same static comm slot. It is also possible to allocate the channels to different ECUs within one and the same static comm slot or to leave slots empty. In the dynamic segment, the pattern of dynamic comm slots unfolds independently on the two channels, depending on whether dynamic comm slots are used or left empty.

The temporal characteristics of the FlexRay comm cycle are defined at design time and stored statically in each ECU. ECUs requiring greater bandwidth and those needing shorter update intervals for messages are assigned more slots than those requiring less bandwidth or allowing for longer update intervals for messages.

The comm cycle uses an arbitration grid to provide collision-free communication in the static and dynamic segments. The arbitration grid consists of "macroticks." The macrotick represents the smallest synchronized granularity unit of the global time that is synchronized across all ECUs by a clusterwide clock-synchronization algorithm.

This synchronization ensures that the macroticks between different ECUs are synchronized, such that all macroticks are kept in sync with one another within a defined precision. The precision describes the worst-case deviation between the corresponding macroticks of any two synchronized ECUs in the network.

In a FlexRay communication cycle, the static communication segment accommodates data communication that requires bounded latency and small latency jitter.

This fault-tolerant clock synchronization is the key mechanism of the comms protocol that drives the comm cycle. To support fault tolerance, the decision was made to deploy a fault-tolerant distributed clock-synchronization algorithm as a clusterwide clock-synchronization algorithm. In contrast to a master-slave synchronization algorithm, the fault-tolerant distributed clock-synchronization algorithm will continue to operate even when an ECU fails in the systems. The clock-synchronization algorithm is executed autonomously by the protocol state machine within each ECU without any interaction of the host processor.

Key factors determining the success of FlexRay technology are the availability of IC components implementing the FlexRay protocol and their deployment in automotive-series applications. Throughout the development of the FlexRay protocol, Freescale was able to provide BMW with FlexRay communication controllers.

Multiple technical criteria can be applied in deciding whether to implement a FlexRay network. Key criteria are bandwidth, deterministic communication, specific system-integration properties and the provision of fault-tolerance capabilities. These criteria are outlined and compared with CAN in the table.

The choice to use a FlexRay network depends on multiple technical criteria.

The intention of the FlexRay Consortium was to develop technology to complement established LIN and CAN by enabling the design of new applications (and not to substitute for these established networks). That could be done only by providing lower cost.

It is obvious, however, that introducing new technology with higher performance and increased capabilities results in higher costs. Ultimately, the comparison of business cases has to be done on a comparable level of functionality. Looking at the CAN system, for example, replacing several CAN sub-buses, cables, gateways and redundant sensors, and considering the partitioning challenges and the system-integration effort, the FlexRay system is considered to have comparable costs.

Cross-industry linkage
The FlexRay communications system has become part of a broad range of activities and initiatives. In 2003, the Automotive Open System Architecture (Autosar) Development Partnership was founded to develop and establish a de facto open industry standard for automotive architecture to serve as a basic infrastructure for the management of functions within future applications and standard software modules.

The Autosar partnership defines software application programming interfaces that abstract the details of communication while using the key properties of the protocol. Autosar complements FlexRay by providing a standardized runtime environment that encapsulates communication from higher-level software components in a very flexible way through Autosar interfaces.

In the future, it will be possible to provide innovations on the hardware level of the system hierarchy ideally, in a way that is fully transparent to higher software layers.

- Josef Berwanger
Project Manager

- Anton Schedl
Team Leader
BMW Group

- Christopher Temple
Manager of Automotive Systems Technology, Freescale Semiconductor Inc.

Article Comments - Get ready as FlexRay hits the road
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top