Chapter 1.................................................................................................. 1
1.3 Thesis Organization
This thesis is organized as follows. First, FlexRay protocol is introduced in Chapter 2.
In Chapter 3, message transmission method will be advanced and did a simple transmission experiment. Then the experiment equipment would be introduced. After this transmission experiment, I establish the steer-by wire system via FlexRay.
In Chapter 4, the steer-by-wire system control system architecture will be presented and implement it via FlexRay. Finally, analyze the characteristics of the FlexRay network in chapter 5.
Chapter 2
FlexRay Protocol
FlexRay is a fast, deterministic and fault-tolerant bus system for automotive use, based on the experience of DaimlerChrysler with the development of prototype applications and the byteflight communication system developed by BMW. Byteflight was developed by BMW especially for use in passive safety system. In order to fulfill the requirements of active safety systems, byteflight was further developed by the FlexRay consortium in particular in relation to time-determinism and fault tolerance. Today, the automotive manufacturers BMW, DaimlerChrysler, General Motors, Ford, Volkswagen as well as the companies Bosch, Motorola and Philips Semiconductors are represented in the FlexRay consortium as Core partners.
2.1 Data Transmission and Topology
A very important requirement is the increase of the maximum data transmission rate up to 10 Mb/s or even more. FlexRay supports a transmission rate of up to 10 Mb/s.
The topology of a FlexRay network can be designed in many ways, such as passive bus, active star, active star combined with a passive bus(Figure 2.1). These design alternatives offer important features for in-vehicle network designs like topology scalability and fault-tolerance support.
2.2 The Components of a FlexRay Node
Figure 2.2 illustrates the components of FlexRay node. The host-controller is the link between the application and the FlexRay network. The communication controller codes and decodes the messages, is responsible for time synchronization and controls the bus drivers and the bus guardian. The bus guardian monitors the access of the FlexRay bus and the bus drivers are the physical interfaces to two communication channels.
2.3 Failure Tolerance
A failure-tolerant system must ensure that no participant blocks the communications system. The effect of a physical error on the network, such as a short circuit, can be reduced by shutting down the affected network branch. The failure containment in the time domain has to be controlled by an independent instance. FlexRay offers an optional watchdog, the Bus Guardian, which isolates the communications controller from the network on demand.
2.4 Deterministic Communications
Today’s in-vehicle network systems exchange information in an asynchronous cyclic or noncyclic manner where all existing communications protocols are event based. As the amount of data on the bus increases, the determinism and worst-case response of the network
decrease dramatically.
In time-triggered network systems like FlexRay, however, any network activity is launched in predefined time slots and cannot be changed after launching the cluster. As a result, the FlexRay network can never have an overload of bus traffic.
2.5 Time Synchronization
A FlexRay system adjusts the local time of an electrical control unit with the help of special control algorithms. This ensures that all of the local clocks of the individual nodes in a cluster are running synchronous to a global clock. Offset correction and time correction are the two methods used to achieve this global time synchronization
2.6 Configurable Synchronous and Asynchronous Transmission
The communications cycle is the fundamental element of the media access scheme within FlexRay. The time window, defined by the communications cycle, is composed of a mandatory static segment, an optional dynamic segment, an optional symbol window, and a network idle time. The length of each of these segments is defined and fixed during the network configuration.
The static segment of the communications cycle is used for scheduling time-triggered messages and reserved for synchronous communications, which guarantees a specified frame latency and jitter
through fault-tolerant clock synchronization. The messages transferred in the static segment must be configured before starting communications, and the maximum amount of data transferred cannot exceed the length of the static segment.
The dynamic segment of the communications cycle is used for event-based messages that may emerge at run time and require varying bandwidths. Within the dynamic segment, devices compete for bandwidth using a priority-driven scheme that assigns priority based on a message’s Frame ID. This part of the cycle forms a communications scheme similar to the CAN bus.
Within the symbol window a single symbol may be sent. Arbitration among different senders is not provided by the protocol for the symbol window. If arbitration among multiple senders is required for the symbol window it has to be performed by means of a higher-level protocol.
The network idle time serves as a phase during which the node calculates and applies clock correction terms.The network idle time also serves as a phase during which the node performs implementation specific communication cycle related tasks. The network idle time contains the remaining number of macroticks within the communication cycle not allocated to the static segment, dynamic segment, or symbol window.
In Figure 2.3, the communications cycle is shown over a given time period. It illustrates that the bandwidth used for time-triggered and event-triggered messages is scalable.
2.7 Frame Format
An overview of the FlexRay frame format is illustrated in Figure 2.4 The FlexRay frame divides into three segments: Header, Payload, and Trailer.
The Header includes the Frame ID, Payload Length, Header CRC, and Cycle Count. The Frame ID identifies a frame and is used for prioritizing event-triggered frames. The Payload Length contains the number of words that is transferred in the frame. The Header CRC detects errors during the transfer. The Cycle Count contains the value of a counter incremented each time a communications cycle starts.
The Payload has the data transferred by the frame. The length of the FlexRay payload can be up to 127 words (254 bytes), more than a 30×
increase compared to CAN.
The Trailer has three 8 bits CRCs to detect errors.
2.8 Coding and Decoding
The coding and decoding behavior of the TxD, RxD, and TxEN interface signals between the communication controller and the bus driver.
As shown in Figure. 2.5.
A node may support up to two independent physical layer channels, identified as channel A and channel B. Since the FlexRay protocol is independent from the underlying physical layer, the description in this chapter assumes a binary medium with two distinct levels, called HIGH and LOW. A bit stream generated from these two levels is called a communication element (CE).
A node shall use a non-return to zero (NRZ) signaling method for
coding and decoding of a CE. This means that the generated bit level is either LOW or HIGH during the entire bit time.
The node processes bit streams present on the physical media, extracts frame and symbol information, and passes this information to the relevant FlexRay processes.
Chapter 3
Message transfer between MFR4200 and a host controller
According to the FlexRay specification, messages are transferred inside message frames. Figure 2.4 shows the FlexRay frame format. Every message frame consists of a header, a data part and a trailer block, which contains the cycle redundancy code (CRC) for the header and the data block. Before a message can be transferred, all header and data information must be provided by the host in a defined format, the so called message buffer. Receive, receive FIFO, and transmit message buffers are accessible to the host MCU only through the active receive, active transmit, and active receive FIFO buffers (Figure 3.1). This message transmission need hardware to implement. So I will introduce the hardware at first.
3.1 A Brief Introduction of ECU
In the thesis, I use the TZM FlexNode to be my ECU. Figure 3.2 is its target board and Figure 3.3 is its block diagram.
FlexNode is a flexible and comfortable evaluation platform for the safety relevant FlexRay bus system. It supports two FlexRay bus interfaces, two CAN, one LIN and several other standard bus interfaces.
Therefore this board is an ideal solution for gateway applications routing data between different bus systems. Additionally FlexNode provides several input and output signals that can be used to read sensor signals or
to control specific hardware.
Technical Features
z FlexRay bus interface with 2 channels
z CAN interfaces, both low or high speed selectable z 1 LIN interface
z RS232 interfaces z 1 I2C interface z SPI interfaces
z Host μController 16bit Freescale HCS12
Variant MC9S12DT256B
256kByte internal Flash
4kByte internal EEPROM
12kByte internal RAM
up to 50Mhz Core clock (25MHz bus clock) z 256kByte external SRAM allows word access z Up to 26 digital I/O Ports
z Up to 16 analog inputs with 10 bit resolution z Up to 8 pulse width modulated outputs z Up to 8 capture interrupt inputs
z 10…48V supply voltage
allows 12V, 24V and 42V automotive supply voltages
3.2 FlexNode Module Connections
The FlexNode provides connectors for mounting one FlexCC module and two FlexTiny modules. The FlexCC is the carrier module for the
FlexRay Communication Controller.
The FlexTiny module is the carrier for the FlexRay bus driver. For dual channel operation two modules have to be used, one module for each channel. Figure 3.4 shows FlexNode module connectors.
3.2.1 FlexCC Module
FlexCC® MFR is a protocol module for the FlexRay bus system. The used Communication Controller is the Freescale silicon prototype MFR4200 MAE40.
This FlexRay implementation is based on the protocol specification V1.1.
The FlexCC MFR module has two onboard RS485 bus drivers with the appropriate termination. These drivers can optionally be used together with the communication controller when no FlexRay Physical Layer is present.
The Host interface is designed to be connected to the Freescale HCS12 μController. Optionally the second host interface of the communication controller, the AMI (asynchronous memory interface) can also be used instead of the HCS12 μController.
The FlexCC MFR is designed to be used as a plug-in-module for the FlexNode evaluation platform.
MFR4200 Features
The MFR4200 provides the following features.
z The FlexRay protocol according to FlexRay Protocol Working document (PWD) V1.1, with differences described in the MFR4200 Protocol Implementation Document (PID)
z Data rate of up to 10 Mbit/s on each of two channels
z FlexRay frames with up to 254 payload bytes (padding is used for FlexRay payload data that exceeds 32-byte data size boundary)
z One configurable receive FIFO
z Configurable counters, status indicators, and interrupts dedicated to error signalling
z Measured value indicators for clock synchronization
z The status of up to four slots can be observed independently of CC receive message buffers
z Configurable error signaling
z Fractional macroticks (MT) supported for clock correction z 59 message buffers, each with up to 32 payload bytes z Message buffers configurable with state or event semantics
z Each message buffer can be configured as a receive message buffer, as a transmit message buffer (single or double), or as a part of the receive FIFO
z Receive background buffers for each channel
z The host accesses all buffers by means of three active message buffers (active transmit message buffer, active receive message buffer and active receive FIFO buffer)
z Filtering for frame ID, cycle counter, and channel for receive and transmit message buffers
z Maskable interrupt sources provided over one interrupt line
z Two types of host interface: HCS12 interface and asynchronous memory interfaces
z Minislot action point offset is configurable z Static slot action point offset is configurable
z Hardware selectable clock output to drive external host devices:
disabled/4/10/40 MHz
z Electrical physical layer interface compatible with dedicated FlexRay physical layer. Industry standard RS485 physical layer interface also available.
3.2.2 FlexTiny Module
FlexTiny is a series of small interface modules with physical layer drivers. The modules are connected between protocol devices and the bus cables. They offer bus termination functionality if required in the design.
3.3. Message Buffer Operations
The main principles of the host and the CC data exchange are as follows.
z The host has full control over the CC.
z After the configuration step is performed by the host, the CC can run the FlexRay protocol. The CC does not require any additional support from the host for operation in a cluster
without faults and disturbances.
z Data exchange is based on access requests and acknowledges flags.
The host and the CC provide a set of transmit/receive operations for managing data flow between a FlexRay network and the host.
3.3.1 Data Collection during Receive Operation
Frames are stored if there is at least one receive message buffer or FIFO receive buffer configured. Therefore, it actively participates in the internal buffer filters matching process, which takes place every time the communication controller receives a semantically valid and syntactically correct frame.
An example of operations during a frame reception is shown on the Figure 3.5.
3.3.1.1. The Host Operations during Reception
After every successful frame reception, the CC sets the flag IFLG of a matching buffer. This flag indicates that a frame has been received and stored in a buffer, and the host can read it to empty the buffer for the next reception. All IFLG bits are logically OR’ed and connected to the host interrupt line. The host receives an interrupt if at least one IFLG is set and not masked by the appropriate IENA bit in the BUFCSnR register.
To read a receive message buffer the host must perform the following steps:
1. Process an interrupt by reading the ISR registers, if necessary. or check the IFLG bits of receive message buffers.
2. Locate one IFLG interrupt source register by reading the receive message buffer interrupt vector register.
3. Send a lock request (write LOCK bit with the value ‘1’) for the corresponding message buffer, to make it accessible through the active receive message buffer.
4. Wait for lock acknowledge (LOCK bit reads as value ‘1’).
5. Read the active receive message buffer.
6. Send an unlock request for the message buffer.
3.3.1.2. CC Operations during Reception
The CC receives every frame to a shadow message buffer first, as shown in Figure 3.5.
The CC performs a filtering process based on filter configuration. This process takes place every time the CC receives a semantically valid and syntactically correct frame. In this process, the CC sequentially compares all the receive message buffers filters to the received ones. The first message buffer matching all the filtering requirements will be updated with the new frame. The matching message buffer will be overwritten, if the message buffer was already full (IFLG = 1). If a received frame does not match the filtering fields of any receive message buffer, it will be compared with the FIFO filters. If a frame matches the FIFO filtering parameters, it will be stored in the FIFO; otherwise, it will be ignored. The CC ignores invalid frames and does not store them in buffers.
The received frame will be stored in the first matching receive message buffer. The search engine starts after the end of the FIFO, or at message buffer 0 (if no FIFO is configured), and searches upwards. Thus, if there are two receive message buffers matching the received frame, the frame will always be stored in the buffer with the lower buffer index. The CC does not check which buffer fits the frame best. Thus, if a message buffer holds a filtering subset of another message buffer, that message buffer (with the filtering subset) must be located at the lower message buffer index. The application must manage this.
The matching message buffer will not be updated if it is still locked. If the message buffer is locked after reception, it will be updated as soon as it is unlocked. If the buffer is locked for more than one communication cycle and, if the frame, which matches that message buffer filtering, is received twice during this period, the buffer will be updated with the newer frame, as soon as it is unlocked, and a frame lost error will be raised to the host.
The corresponding IFLG bit (message buffer is full) is set every time the message buffer is updated, and, if enabled, a receive interrupt is generated.
In the case of locking, when the host may lock one receive message buffer, the CC has two shadow message buffers per channel to continue frame reception targeted for any receive message buffers including the locked one.
3.3.2 Data Collection during Transmit Operation
Some or all of the message buffers can be configured as transmit message buffers via the BUFCSnR register sets. The configuration of transmit
message buffers must comply with the buffer configuration procedure and principles. The CC handles transmit operations differently during the static and dynamic segments of transmission; it also handles single and double transmit message buffers differently (This section only introduce the method of handles transmit operations during the static segment and single transmit message buffer, others please refer to datasheet). For transmission, the CC uses data from configured and committed transmit message buffers only.
The host submits a frame for transmission by committing a message buffer for transmission (BUFCMT bit) and by subsequent unlocking of the transmit message buffer. The transmit message buffer remains valid for transmission until its VALID bit = 1.
To prepare a transmit message buffer for transmission, the following steps must be performed.
1. Configure the message buffer as a transmit message buffer in accordance with the buffer configuration procedure and principles.
2. Lock the corresponding message buffer, to make it accessible in the active transmit message buffer. Buffer locking must be done in accordance with the locking/unlocking procedure and principles
3. Write/read the active transmit message buffer to change or update the message buffer content.
4. Commit the message buffer for transmission, by setting the BUFCMT bit to ‘1’.
5. Unlock the message buffer.
Static segment:
For the static segment, if there are several frames pending for transmission, the frame with the ID corresponding to the next sending slot is selected for transmission. The CC checks other filtering fields of those messages. If several frames are suitable for current static slot transmission, the CC performs an internal arbitration.
The CC transmission procedure is described in detail in the frame processing section of the PWD (Protocol Working document). The most important points are as follows.
z Only valid frames (VALID bit = 1) can be transmitted by the CC.
z If there are valid frames with the same frame ID, the CC checks their filter fields. If two or more of them match the conditions of the transmit slot, the message buffer with the lowest message buffer number wins the internal arbitration.
z If two buffers are assigned to the same static slot but to different transmission channels, the CC transmits them simultaneously on assigned channels during transmission of that static slot.
z If a message buffer was committed for transmission (BUFCMT = 1) it becomes valid (VALID = 1) after buffer unlock operation, and the host cannot lock it until it is transmitted at least once.
The CC changes the following bits, if a message from a message buffer has been sent.
z IFLG z BUFCMT
z VALID (depending on the TT bit of the BUFCSnR register)
3.3.2.1. Single Transmit Message Buffer Data Collection during Transmit Operation
The host can configure some message buffers of the CC as single transmit message buffers. If there is at least one transmit message buffer configured, or the sync frame register value is not 0x0, the CC can actively transmit frames out of the connected FlexRay network.
To configure a single transmit message buffer, the following next steps must be performed.
4. Configure the message buffer as a transmit message buffer, in accordance with the configuration procedure and principles.
5. Set the message buffer type bit (BT) to 0 — single transmit message buffer.
After a buffer is configured as a single transmit message buffer and a CC enters the normal mode of operation, The host can start preparation and commitment of frames for transmission. Figure 3.6 shows an example of host and CC operation on a single transmit message buffer during frame
After a buffer is configured as a single transmit message buffer and a CC enters the normal mode of operation, The host can start preparation and commitment of frames for transmission. Figure 3.6 shows an example of host and CC operation on a single transmit message buffer during frame