Chapter 2.................................................................................................. 4
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 transmission in normal operation.
As shown in Figure 3.6, The host sends a lock request for a message buffer and always checks for the lock request acknowledge bit LOCK to be a ‘1’ before it starts to update the message buffer content.
After a transmit message buffer is locked, the host can update it, via the active transmit message buffer, and can commit it to transmission by setting the BUFCMT bit to ‘1’ and unlocking the message buffer.
After transmission, the CC sets the IFLG bit of a message buffer, and
clears BUFCMT. The CC changes the VALID bit after transmission depending on the TT bit.
Above-mentioned method is realized to FlexRay protocol. The next chapter will use the method to reconstruct the sin wave which produces by function generator. This experiment proves that the transmission is correct.
Further, the steer-by-wire system will be designed via FlexRay .
Chapter 4
Experiments and application
In this chapter, I implement the transmission depend on the methods which been taken before. Then, I apply this transmission in steer-by-wire system.
4.1. Transmission Rate Calculation
Now I will test our device and its performance. First, I need a function generator to produce the sin wave, then use A/D converter of the FlexNode_0 to sample the sin wave to produce the data.
Subsequently transmit data by the FlexNode_0 and receive data by the FlexNode_1. Finally use PWM output to reconstruct the sin wave. As shown in Figure 4.1. If the sin wave reconstruct completely, it represent that the data which transmit by FlexRay doesn’t lost.
The communications cycle is the fundamental element of the media access scheme within FlexRay. The static segment and NIT (network idle time) of the communications cycle is used for the experiment. 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. These configurations are set by FlexConfig tool. The FlexConfig tool is an instrument for configuring communication controllers for the time-triggered FlexRay protocol. The FlexConfig tool is designed, intended and authorized for
laboratory applications. All other use needs the prior written permission of the TZM.
In the experiment, I configure the communication cycle length, the max static payload length, the number of static slots and other parameters (For example: End of dynamic segment, End of symbol window, Start of offset correction MT...) as shown in Figure 4.2. If I transmit more frame in a fixed communication cycle length, it represent the transmission rate is faster. For example, the communication cycle length is 2 ms, and this moment if I transmit 10 frames, then the transmission rate is 1,280,000 bit/s (10 * 32 * 500 * 8). And so forth. But I only transmit 3 frames when the communication cycle length is 2 ms in this experiment. The results show in Figure 4.3. In the next section, the reason for this issue will be discussed.
4.2. Transmission Rate of The Reasons for Not Upgrading
The FlexRay specification allows a payload up to 254 bytes. But the MFR4200 I use has a limitation of 32 bytes payload. This causes under the same frame number, the rate differs about 8 times. Additional, there is also a reason. If the host has locked a receive message buffer, and two semantically valid frames for that buffer are received during this locked time. The first frame will be lost. This is because the buffer is locked for more than one communication cycle. So we know that the limitation of the FlexNode.
4.3. Steer-by-Wire System
Steer-by-wire system is a related-safety new system comparing to the traditional mechanical, hydraulic, or electric steering systems that are currently used for automotive vehicles. It provides the potential benefits of enhancing vehicle performance, improving handling behavior, and fully integrating vehicle dynamic control.
In a steer-by-wire system, there is no mechanical coupling between the steering wheel and the steering mechanism, i.e., the vehicle’s steering wheel is disengaged from the steering mechanism during normal operation.
Even though the mechanical linkage between the steering wheel and the road wheels has been eliminated, a steer-by-wire system is expected not only to implement the same functions as a conventional mechanically linked steering system, but it is also expected to provide the advanced steering functions.
4.3.1 Steering Function Requirement
There are several main steering function requirements for a steer-by-wire system:
(1) Directional control and wheel synchronization.
Directional control is the basic requirement for vehicle steering systems, including steer-by-wire system. It is required the wheels follow the driver’s input command from the steering wheel and the possible input command from the supervisory vehicle control system according to vehicle dynamics requirements. The road wheels should maintain synchronization
with the steering wheels in real time without bias, offset, or time delay.
(2) Adjustable variable steering feel.
The steering feel provides information on the force (or torque) at the road wheel tire-road surface contact and varies depending on road conditions. This force/torque information should be fed backed to the steering wheel to produce steering wheel torque that can be felt by the vehicle driver. The vehicle driver relies on the steering feel to sense the force of road wheel tire-road surface contact and maintain control of the vehicle. Thus, steering feel has been becoming one of most important vehicle attributes to maintain vehicle directional control and stability. In a steer-by-wire system, it is required to generate not only a familiar steering feel to the vehicle driver just as in the conventional steering wheel systems with mechanical connection, but also adjustable variable artificial steering feels.
(3) Adjustable steering wheel return capability.
The steering wheel should return automatically to the wheel center or a predefined angle if the hands of vehicle driver leave the steering wheel.
The return rates of the steering wheel can be adjusted based on the vehicle speed.
(4) Variable steering ratio.
The steering ratio is a ratio between steering wheel angle and road
The steering ratio is a ratio between steering wheel angle and road