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

Tools simplify FlexRay designs

Posted: 16 Jul 2007 ?? ?Print Version ?Bookmark and Share

Keywords:FlexRay system designs? CAN? automotive electronics design? FlexRay controllers?

By Roman Pallierer and Arnold Zimmermann

FlexRay is still in a very early stage of its entrance into the automotive electronics market. Thus, many companies and engineering design departments are beginning to evaluate this new communication standard.

Automotive electronics designers are currently faced with questions such as "How to design a FlexRay system?" "What kind of conceptual and technical difficulties are looming ahead of us?" and probably, the most important, "How can I design a FlexRay system as fast and hassle-free as possible and run it on evaluation hardware?"

Why FlexRay?
Due to the increasing number and complexity of new electronic applications in the car, the now predominant automotive communication system, CAN, will not be able to meet all requirements. Therefore, an industry consortium has joined forces and has developed FlexRay. This new communication technology is deterministic, highly reliable and geared for fault tolerant systems. Due to its high bandwidth (2 x 10Mbps compared to CAN's 1Mbps), complex applications can be realized, even visions such as X-By-Wire (steering and braking) will be feasible.

All these advantage have, however, to be planned in advance. This protocol has not only to deal with a lot more parameters than CAN, they also have to be designed consistently. For example, more than 40 global protocol parameters and more than 30 parameters per controller have to be managed.

In designing FlexRay systems, it is not sufficient to prioritize the messages as it is the case with CAN. Here, you must define an exact scheduleout of a set of more than 130,000 cells. These examples give a vivid insight of how complex FlexRay design is. Consequently, development tools need to efficiently relieve the user from FlexRay tasks and allow him or her to concentrate on application development.

For all those questions and others, there are tools based on a four-step design flow that can facilitate the adoption of this complex technology. An engineer can configure a simple setup, such as two communication controllers, each sending one frame to the other controller, within minutes. A FlexRay evaluator just has to follow the workflow steps (window on left side) of the DECOMSYS: DESIGNER PRO design and configuration tool shown in Figure 1.

Figure 1: The FlexRay communication technology is deterministic, highly reliable and geared for fault tolerant systems.

Step 1: Hardware architecture
First, define the hardware architecture including the FlexRay network and the connected electronic units (ECUs). A FlexRay network consists of one or two communication channels. ECUs contain one or more MCUs, each with one or more FlexRay controllers. The FlexRay controllers are connected to one or both communication channels of the FlexRay network.

In our example, one FlexRay network and two ECUs must be defined. As default, the tool generates for a FlexRay network two communication channels and for an ECU, it generates exactly one MCU with one FlexRay controller. The FlexRay controllers are automatically connected to both communication channels of the FlexRay network. Thus, the FlexRay evaluator defines the FlexRay network and the two ECUs with just a few mouse clicks.

Step 2: Protocol configuration
The protocol configuration containing all FlexRay protocol parametersglobal as well as node-specificis next to be specified. The global protocol parameters include the communication cycle length, the length of the static and dynamic segment and more detailed parameters such as action point offsets. The node-specific parameters include parameters to specify whether the node is allowed to perform a startup, in which slot it is allowed to send such a startup frame (pKeySlotID), whether its frames should be used for clock synchronization and much more.

To simplify this step, the tool comes up with a correct configuration specifying a communication cycle length of 5ms and enough static slots. The only parameter that has to be specified is the pKeySlotID for the nodes that shall perform a startup. For this step, 2mins should be more than enough for the FlexRay evaluator to get a correct FlexRay protocol configuration.

More advanced users may want to change one, more or all parameters of the given protocol configuration. Thus, a smart configuration wizard is provided, indicating on each change of one parameter, whether and which constraint of the FlexRay specification is violated. The involved parameters are highlighted in red and correct values for these parameters are suggested.

Step 3: Communication planning
The most time-consuming job in configuring FlexRay is the communication planning. In this step, the frames and their position in the FlexRay communication schedule are defined (Figure 2).

Figure 2: The most time-consuming job in configuring FlexRay is the communication planning.

The communication schedule contains static and dynamic slots. Each slot is subdivided by 64 cyclesthe pair of slot and cycle is defined as a cell. A frame may be sent within one or more slots of the schedule. To allow data multiplexing within one slot, two or more frames may be scheduled so that each is transmitted in different cells of the one and the same slot.

The tool provides a powerful grid view of all these configuration data. The user edits so-called frame-triggerings specifying the frame, the slot, the occupied cells within this slot, the channel, the sender, and the receivers. With select features, a set of frame-triggerings can be easily shifted several slots up or down in the schedule or parameters such as sender or receivers can be changed.

This straightforward example includes only two frame-triggerings: The first frame-triggering is transmitted in each cell of slot 1 by the first controller and received by the other controller and the second is transmitted in each cell of slot 2 by the second controller and received by the first controller. In specifying these two frame-triggerings, the FlexRay evaluator needs less than 5mins.

Driver configuration
Finally, to get the FlexRay controllers running, the controller registers and the buffers need to be configured. Thus, the global and node-specific FlexRay protocol parameters are mapped to the controller registers. The frame-triggerings including the frame and slot are mapped to buffers. These configuration data are then written in an output file. On each MCU, a FlexRay communication driver is running that reads this output file to configure its FlexRay controller and to provide frame-based API functions to the buffers of the controller.

The tool provides a smart configuration wizard performing this mapping of protocol parameters to controller registers and an automatic mechanism for the buffer assignment. Of course, this buffer assignment can then be manually changed by the user.

When all adjustments are finished, the configuration file is generated for the FlexRay communication driver.

In our example, the FlexRay evaluator just uses the automatic mechanisms and generates the output files. This step should take only 2mins so that in total no more than 10mins are spent to get the final configuration data ready to be downloaded to the hardware.

More complex systems
The example was chosen to offer an easy and fast start into the design of a FlexRay system. Within more complex systems, an application engineer will want to use a signal-based API, instead of, or at least in addition to, the pure frame-based API to access the data transmitted via FlexRay. Thus, signals and the mapping to frames need to be defined and a specific signal-based layer needs to be configured.

For this case, the presented workflow can be easily extended. The definition of signals and the mapping of these into frames are done in step 3, the communication planning. The configuration of the signal-based layer is done in step 4, the driver configuration.

More possibilities
The presented workflow and tool offers basic functions for easily setting up hardware and supports the user per default with valid parameter settings and smart configuration wizards. For more advanced users, a smooth upgrade path exists to the full tool family including the SIMTOOLS and BUSMIRROR. These tools support features such as model-based design, simulation and application code generation, and configuring cluster emulations (restbus-systems).

This example presented an easy-to-follow four-step workflow for getting started with FlexRay systems. A design tool embedding this workflow guides a FlexRay evaluator through the hurdles of defining the huge set of FlexRay configuration data. In a fairly short time, the first FlexRay networks are designed and ready for the evaluation on the hardware. Corresponding tools with upgrade-paths are available to support the engineer, from first, FlexRay evaluators, to finally, series engineers. There are also NODE StarterKit, or the more powerful NODE StarterKit hardware packages available to further facilitate coming up to speed in tool use.

Article Comments - Tools simplify FlexRay designs
*? 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