Designing Sub-Systems around FlexRay Bus Architecture

Click here to view and simulate the VisualSim ABS Model

1         Introduction

Architects can utilize the FlexRay based modeling in VisualSim for validating the operation of the sub-system, evaluate performance for different FlexRay bus topologies, sizing the Electronic Control Units and optimizing the FlexRay protocols for future revisions.  Architects can also use the bus structure to optimize the individual component for size, cost, power or performance.

 

This bus library works with the rest of the VisualSim libraries.  The demonstration system in Figure 1 and available in VisualSim uses the FlexRay for creating an advanced braking system.  The statistics on the bus traffic, the ECU processing speed and memory are generated on-the-fly for a variety of interactive communication between the Electronic Control Units of the individual sub-systems.  These can be Gyro sensors, engine sensors and number of devices connected to the single FlexRay bus unit. 

 

The architecture elements such as processor, sub-system/component bus, memory and cache are modeled using the architecture library elements.  A variety of parameters including speed, width, cache size, burst rate, overhead and hit-ratio can be varied for the different processing entities.  The performance of the total system and the ability to deliver the required performance can be modeled.  The advanced braking system triggers the ABS and slows the engine when the Gyro indicates an abnormal yaw value and exceeds a threshold of 66 degrees.  The model results show:

 

 

  

 

Figure 1&8209;0 Multiple Sensor FlexRay Bus Model

2         FlexRay Bus Model Capabilities

 

The FlexRay Bus Model provides the following modeling capabilities:

  

3         FlexRay Bus Model Overview

The FlexRay Bus Model shown in Figure 1-0, has three sensors on the left side of the diagram and two FlexRay bus segments in between the actual Engine Control Unit (ECU) processing on the right hand side.  Sensor traffic enters the model from the left proceeds through the model, and enters a FlexRay bus node, and transfers information to the destination port that reads the channel/ports needed to transmit the original transaction.

 

Each FlexRay bus node fragments incoming data into FlexRay frames, based on the Static Slot sizes the user has configured in the Communication Controller.  If a Dynamic Slot sends information the only restriction is that a Dynamic Slot consists of a multiple of a Static Slots.  On the receiving side of each bus node one can identify which slots it will accept as Channel_1_Read or Channel_2_Read parameters.

 

For detailed information on FlexRay bus operation refer to the FlexRay Overview document.

 

Once, a receiving bus node accepts the transaction it is sent out of the FlexRay to the destination, in this model the first transaction is sent to a second FlexRay bus node to be transmitted to the ECU for processing.  Once, the transaction crosses the second FlexRay bus, and is output from a bus node, all transactions are sent to the ECU node.

 

The ECU is a simple script to accept incoming a sensor transactions, and write them to cache and SDRAM.  The sensor information is first processed by the ECU, and then written to cache as a write-through to SDRAM.  When the Write to SDRAM completes the ECU processes the return transaction, and if an Anti-Roll transaction it writes a short message back to the Anti-Roll sensor on the left-hand side where the model started processing.

 

The FlexRay Bus Model consists of the following Hierarchical blocks:

 

(1)     Bus_Node

(2)     Communication_Controller

(3)     Star_Node

 

These blocks and their parameter windows are shown on the following pages.

Figure 1&8209;1 Bus_Node Hierarchical Block

                         

Figure 1&8209;2 Bus_Node Parameter Configure Window

 

Figure 1-2 shows the parameters available at each Bus_Node the user can set.  Many of the parameters can be linked to the top level, such as Bytes_per_Static_Slot, etc. that configure the bus.  The most important parameters to set at this level are the Channel Write and Read slots, and the color associated with the write channels.  The Port_Name parameter must be unique.

Figure 1&8209;3 Communication Controller Hierarchical Block
                              

Figure 1&8209;4 Arbiter Parameter Configure Window

 

Figure 1-4 shows the parameters available at each Communication Controller in the model.  Most of these values are the same name as the FlexRay specification, such as Frame_Start_Sequence, Byte_Star_Sequence.  In the model they are defined as bit times, based on the FlexRay_Speed_Mbps parameter.  This saves user entry of detailed timing information.

Figure 1&8209;5 Star_Node Hierarchical Block

                              

Figure 1&8209;6 Star_Node Parameter Configure Window

 

Figure 1-6 shows the parameters available at each Star_Node in the FlexRay topology.  Star_Name is the unique name of the Star_Node and is used in message passing within the model.  The User needs to set the Star_Speed_Mhz setting, used to introduce some delay for a star to transmit the incoming slot to the remaining ports, much like a broadcast message.  The FlexRay Bus Model shown does not have any Star Nodes, but could easily be added.  The FlexRay specification allows for two Star Nodes on the same Channel, and the VisualSim model allows for two or more on the same Channel for modeling purposes.

 

4         FlexRay Bus Model Analysis

The FlexRay Bus Model Block Diagram, shown in Figure 1-7, reflects the actual system modeled. This block diagram matches the model in terms of the actual subsystems and how they are inter-connected; see Figure 1-0, Multiple Sensor FlexRay Bus Model.

 

 

 

 

 

 

 

 

 

 

 



                              

 

 

 

 

 

Figure 1&8209;7 FlexRay Bus Model Block Diagram

 

Figure 1-7 shows the top flow as a modeling representation of the entire system, showing traffic generators on the left-hand side, the system in the middle, and statistics gathering on the right-hand side.  The bottom flow is a more conventional block diagram of the system with three wheel sensors on the left-hand side, entering FlexRay_1, via FlexRay_2 bus, to the ECU microprocessor.  The ECU writes sensor information through the cache to SDRAM.  Once, ECU processing is complete for the Anti-Roll data, information is sent back to Anti-Roll sensor to record the end-to-end system latency for Anti-Roll processing. 

 

Each FlexRay bus in this model uses Channel 1 and Channel 2 as completely redundant paths, meaning bus node data is written to the same slots on both channels.  One could actually remove the same channel on each FlexRay bus, and the model will continue to operate normally.

 

The behavior sensor blocks on the left-hand side generate sensor traffic using the same VisualSim block inside, namely the Traffic block.  The traffic block can accept *.CSV files directly from an EXCEL spreadsheet, meaning one can create a *.xls file and then save it as *.CSV file that the model can read and generate model Data Structures directly.  The Anti-Roll traffic was created in an EXCEL spreadsheet, using fill series to generate the Anti-Roll angles, for example.

 

Figure 1-7 does not show the Communication Controller blocks used to configure the Communication Cycle, however, do appear in the model block diagram.  This is the main difference between the above block diagram and the top level modeling diagram.

 

 

 

 

 

 

Figure 1&8209;8 FlexRay Bus 1 Channel/Slot Activity

Figure 1-8 illustrates the Channel 1, Channel 2 Slot activity based on the port colors selected in the Bus Node hierarchical blocks.  For example, Channel 1 (orange), Channel 2 (dark_green) signifies the bus traffic for Bus Node, Port_3 in the model.  This makes it easy to see the bus traffic for one or more Bus Nodes graphically.  FlexRay_1 Bus Summary:

 

FlexRay_Speed_Mbps  : 10.0

Number_Static_Slots : 5

Number_Dynamic_Slots: 3

Transmission_Start_Sequence: 8

Frame_Start_Sequence: 1

Byte_Start_Sequence : 2

Dynamic_Trailing_Sequence  : 4

Static  Slot Time   : 1.3E-5

Dynamic Slot Time   : 1.3E-5

Mini    Slot Time   : 3.0E-7

FlexRay Time Array  :

{1.1E-6, 1.41E-5, 2.71E-5, 4.01E-5, 5.31E-5, 6.74E-5, 6.77E-5, 6.8E-5}

Channel_1 Name Array:

{"Port_1", "Port_2", "Port_3", "Port_4", "Port_5", "Port_2", "Port_3", "Port_4"}

Channel_2 Name Array:

{"Port_1", "Port_2", "Port_3", "Port_4", "Port_5", "Port_2", "Port_3", "Port_4"}

B_Channel_1_Max_Kbps       = 598.1308411214952,

B_Channel_1_Mean_Kbps             = 24.7897156260859,

B_Channel_1_Min_Kbps       = 0.0,

B_Channel_1_StDev_Kbps            = 74.0830597490079,

C_Channel_1_Max_Delay             = 0.0991568,

C_Channel_1_Mean_Delay            = 0.0475577821435,

C_Channel_1_Min_Delay             = 0.0,

C_Channel_1_StDev_Delay    = 0.0317876777322,

D_Channel_2_Max_Kbps       = 598.1308411214952,

D_Channel_2_Mean_Kbps             = 24.7897156260859,

D_Channel_2_Min_Kbps       = 0.0,

D_Channel_2_StDev_Kbps            = 74.0830597490079,

E_Channel_2_Max_Delay             = 0.0991568,

E_Channel_2_Mean_Delay            = 0.0475577821435,

E_Channel_2_Min_Delay             = 0.0,

E_Channel_2_StDev_Delay    = 0.0317876777322,

 

 

 

Figure 1&8209;9 Anti-Roll Sensor Angle, ECU Utilization Percent vs. Simulation Time

 

Figure 1-9 shows the ability of the model to relate Anti-Roll sensor angle data sent to ECU processing, i.e., utilization of the ECU for emergency processing.  Once, the Anti-Roll angle reaches 66 degrees, the ECU increases its processing to handle the emergency Anti-Roll angle.  If the baseline ECU utilization was higher, in the range of 50% to 60%, then the added ECU processing for the Anti-Roll emergency would be impacted by longer response latencies, or inability to complete the necessary actions needed. 

 

If the baseline ECU utilization is in the range of 50% to 60% for normal operations, then an Anti-Roll emergency may require a faster ECU microprocessor, internal bus, or cache to insure a minimum response time.  In addition, a larger cache/SDRAM may also be necessary.

 

The Multiple Sensor FlexRay Bus Model can address these types of issues, or similar issues related to the interaction of the FlexRay bus and subsystem processing external to the bus:

 

(1)     Does the ECU have sufficient capacity to process emergency requests?

(2)     Can the ECU process emergency requests in sufficient time, based on end-to-end delay?

(3)     Is the FlexRay Channel/Slot bandwidth allocation a factor in end-to-end delay?

(4)     What happens if one FlexRay Channel fails for a redundant path; is the remaining path throughput and latency sufficient for reliable system operation?

 

 

 

 

 

 

 

 

 

Figure 1&8209;10 Anti-Roll Response Time

 

Figure 1-10 shows the Anti-Roll sensor response to ECU processing, i.e., the round trip delay to processing emergency angles less than or equal to 66.0 degrees.  One will notice that the maximum Anti-Roll latencies occur at the same timeframe as ECU processing increases on the previous plot.  In addition, one can see the effect of the two FlexRay busses on the latency from the Anti-Roll sensor, to ECU for processing, and back to the Anti-Roll subsystem. 

 

The stair step nature of the latency indicates that the sensor data is being sent at a rate that is different from the FlexRay Communication Cycle timing, or rate.  The resultant sensor rate then arrives at a different point in the FlexRay Communication Cycle, whether Static or Dynamic slots, and drifts slowly through the entire FlexRay bus timing.  This is also an interesting outcome of the FlexRay Bus Model, in that the sensor rate, and the setup of the FlexRay Communication Cycle can have unintended consequence to sensor to ECU processing, namely increased variance of end-to-end system latency.

 

The setup of the FlexRay bus becomes important to the sensors and processing associated with the FlexRay bus.  If there are more Static and Dynamic Slots to allocate FlexRay bandwidth more precisely, then the unintended consequence may be to allocate more bandwidth to some ports and increase the latency to others.  Or, if the number of Static and Dynamic slots are decreased, with larger slot byte sizes, then the unintended consequence may be to allocate too much bandwidth to lower bandwidth sensors, such as wheel sensors, and reduce the overall bus utilization, for example.

 

The FlexRay bus provides deterministic timing and added bandwidth, however, the setup of the Communication Cycle, based on input/output quantity, and throughput must be optimized for both slot allocation and end-to-end system latency.  The FlexRay Bus Model provides the capabilities to optimize slot allocation and end-to-end latency, based on Sensor and ECU processing needs.

 

 

 

Mirabilis DesignŠ Copyright 2006, All Rights Reserved.