Research on FlexRay Vehicle Network Management

Research on FlexRay Vehicle Network Management Faculty of Information Engineering and Automation, Kunming University of Science and Technology, Kunming 65005,China Abstract This paper summarized the different characteristics of CAN (Controller Area Network) bus protocol and FlexRay bus protocol. To protect the network effectively and reliably, this paper studied the network management function based on CAN/FlexRay bus and designed the network management solution of CAN-FlexRay gateway. This paper designed network management related diagnostic contents in accordance with the special role of the gateway. The FlexRay network diagnostic method is proposed to solve some key issues based on ISO49 and ISO5765 protocol, such as flow control, error handling, etc. The realization of FlexRay network diagnostic function requires the support of CAN-FlexRay gateway, which solved the protocol conversion and data forwarding and other related issues of the gateway in FlexRay network diagnostic process. Network management and diagnosis of CAN/FlexRay bus system are simulated. And the results show that they are feasible. Keywords: CAN Bus Protocol, FlexRay Bus Protocol, CAN-FlexRay Gateway,Flow Control. Introduction Auto control field has been changed greatly with the rapid development of auto electronic technology. It is developing in the direction of vehicle bus. CAN bus has been used by many auto companies with the continuous development. And FlexRay is being rapidly pushed forward for next generation vehicle bus standard. This paper analyzes and studies the network management and diagnostic of CAN/FlexRay bus system in order to improve the reliability and safety of the vehicle network and find the position of the cars faults [-4]. This will shorten the gap of auto electronic technology between our country and foreign countries, which will improve our core competitiveness and accelerate the industrialization [5]. The vehicle bus is applied in the car more and more widely, and vehicle network is constantly evolving [6-7]. Many vehicle bus protocols are developed now, such as LIN (Local Interconnect Network) bus, CAN bus, MOST (Media Oriented System Transport) bus and FlexRay bus [-3]. So far, mature network management software and protocols include: Mentor Graphics in WilsonvilleOregon developed Volcano Network Management (VNM) [6], and AUTOSAR members of CG-Smith Software Private Limited (CGS) developed based on OSEK network management, the Windthe River System Company developed OSEKworks, and Germany Esslingen University developed Network Management for the FlexRay [8-0] and CCP protocol.. Diagnosis of the CAN network.. Diagnostic application layer CAN network diagnostic application layer is consists of two parts: the application layer services and the application layer communication protocol. ISO49 protocol defines six major categories of services: diagnosis and communications management services, data transmission services, sending service of the storing data, input and output control services, remote wake-up routine services as well as upload and download services. Service requests and feedback data transmission between the sender and the receiver, using the ISO49 protocol is defined service primitives: the service request primitive, the service request confirming primitive, the service indication primitive, the service feedback primitives, the service feedback confirming primitives and the service confirming primitive. ISO49 diagnostic service data unit A_SDU contains the parameters shown in Table. International Journal of Advancements in Computing Technology(IJACT) Volume5,Number8,April 03 doi:0.456/ijact.vol5.issue8.7 5

Table. Diagnostic service data unit Parameter Parameter Parameter 3 Parameter 4 Parameter 5 Other A_SDU SA TA TA_TYPE RA Result parameter, SA and TA are on behalf of the diagnostic apparatus or ECU node identifier in the network in order to address to the diagnostic equipment or ECU node. The difference is that SA is the identifier of the representative to initiate the service request diagnostic equipment and TA is on behalf of the need for this service request to make the identifier of the feedback the ECU. For service feedback, SA is on behalf of the identifier of the feedback ECU and TA is on behalf of the identifier of the service requests of diagnostic equipment. TA_TYPE on behalf of the addressable type: physical addressing or functional addressing. RA is optional. Result parameter is the service feedback or confirmation primitives used to indicate that this message is a negative response or confirmation or positive response or confirmation. The other parameters are set according to each service. ISO49 defines the application layer protocol data unit A_PDU. A_PDU is A_SDU and application-layer control information A_PCI as shown in Table. Table. Diagnostic protocol data unit Parameter Parameter Parameter 3 Parameter 4 Parameter 5 Other A_PDU SA TA TA_TYPE RA A_PCI parameter, A_PCI has two formats according to the service primitives and the Result value. If Result = Positive, A_PCI is the diagnostic services SI. If Result = Negative, A_PCI consists of N_SI and SI. Which NR_SI represents the negative response to the error type. SI is the same as the above. ISO5765-3 protocol is partly used by the application layer communication protocol. ISO5765-3 protocol is protocol diagnostic services data transfer between the diagnostic apparatus and diagnostic node communication control of ISO49. The application layer timing parameters are defined as shown in Table 3. Table 3. Timing parameters of the application layer Description Min Max Time parameters Pcan_client The time from the client requesting the information successfully transmitted to the feedback starting to send. P*can_client Pcan_server P*can_server The time from the client receiving the feedback information of 78 to the next feedback starting sending. The time from the server receiving the request information to issue feedback The time from the server sending successfully the feedback information of 78 to issued by the feedback again. Pcan_server_max + Pcan P*can_client_ma x+ Pcan_rep N/A N/A 0 50ms 0 5000ms Application-level services and application layer communication protocol for data transmission between the ECU nodes characteristics are shown in Fig.. 53

.. Diagnostic network layer Figure. Diagnostic services agreement The network layer of CAN network diagnostics adopts ISO5765- protocol. The network layer protocol data unit format is as specified in Table 4. Table 4. Network layer protocol data unit Address information Protocol control information Data field N_AI N_PCI N_Data The network layer protocol data unit is to ensure that the layer data transmission between nodes. N_AI is the address information including the source address (N_SA), destination address (N_TA), addressing (N_Tatype) as well as the extended address information (N_AE). N_PCI corresponds to A_PCI of the application layer protocol data unit. N_Data is used to transmit user service data. The mappings of the network layer protocol data unit and the application layer protocol data unit are as shown in Table 5. Table 5. A_PDU and N_PDU mapping A_PDU parameters N_PDU parameters A_SA N_SA A_TA N_TA A_Tatype N_Tatype A_RA N_AE A_PCI.SI N_Data[0] A_Data[0]-A_Data[n] N_Data[]-N_Data[n+] At the same time, the service interface of the network layer mainly include: N_USData.request, N_USData_FF.indication, N_USData.indication and N_USData.confirm. 3. FlexRay network diagnostic protocol 3.. Diagnostic protocol stack At present, there is no uniform diagnostic protocol standard of the diagnosis of FlexRay networks.the diagnosis of CAN network uses ISO5765 protocol. ISO5765 protocol is used for FlexRay bus. FlexRay network diagnostic protocol stack is as shown in Table 6. 54

OSI model Diagnost ic protocol Table 6. Corresponding relationship of the diagnostic protocol and OSI model Diagnos Applica The Session Transpo Network Data tic tion presentat layer rt Layer layer link applicati layer ion layer layer on layer ISO 49 ISO 5765-3 N/A ISO 5765-3 N/A ISO 5765- FlexRay protocol Physical layer FlexRay bus The network layer of FlexRay network diagnostic protocol uses class ISO5765- protocol. Class ISO5765- protocol and ISO5765- protocol are the same. The format of class ISO5765 protocol network layer protocol data unit N_F_PDU and ISO5765- protocol N_PDU is the same. In order to ensure the correct transmission of diagnostic data, the communication control in FlexRay diagnostic protocol slightly modifies flow control mechanism based on CAN bus transmission control. 3.. Flow control mechanism FlexRay network diagnostics network layer diagnostic services data transmission can be divided into two types: single frame or multiple frames. For a single frame, due to the FlexRay bus, a data frame transmitted data is less than 54 bytes, so the requirements as a single frame transmission of diagnostic data length are less than 54 bytes. Single frame of data transfer can be completed in a static time period of the FlexRay communication cycle. Single frame need to transfer diagnostic data including control information and the transmitted data. Control information includes single-frame signs and the length of data. Single frame protocol data unit format is as shown in Table 7. Table 7. Single frame protocol data unit Data Unit Name The first byte The second byte 0-3 4-7 0-7 Single frame 0000 The length of the single frame of data For multi-frame, data length is greater than 5 bytes, so two or more than two frames can been completely transferred by FlexRay bus. Multi-frame transmission is used by flow control mechanism [4], and the flow control mechanism involves three concepts: the first frame, consecutive frames and flow control frame. The first frame protocol data unit format is as shown in Table 8. Table 8. First frame protocol data unit Data Unit Name The first byte The second byte 0-3 4-7 0-7 First frame 000 The length of the data Send the first frame, and then the sender will send the data of successive frames. Successive frames of the protocol data unit also include the control information and the transferred data as shown in Table 9. The length of the control information is a byte, the first four of which is the consecutive frame signs, the last four is the consecutive frame number. Table 9. Data unit of consecutive frame protocol Data Unit Name The first byte 0-3 4-7 Continuous frame 000 Continuous frame number FlexRay bus can transmit up to 54 bytes, which removes the control information, and a frame can transmit up to 53 bytes. There is no need to use ISO5765- protocol as shown in Table 0 consecutive frame number cycle mechanism. 55

First frame Table 0. ISO5765- multi-frame data number rules Consecu Consecu Consecu Consecu Consecu tive tive tive tive tive frames frames frames frames frames Consecu tive frames Consecu tive frames Number 0 E F 0 Flow control frame is mainly to control the data transmission. Flow control frame of the protocol data unit format is shown in Table, and the first four bytes are a flow control frame signs, and the last four bytes are flow control status: 0-re-send, -wait for transmission, -stop send, 3-0xF retention; the second byte is BS, the receiving end is used to indicate their ability to receive, allowing the sender sent continuously consecutive frames; the third byte is STmin, which is the shortest time interval between the sender sends two consecutive successive frames. FlexRay diagnostics class ISO5765- protocol has simplified and modified BS to require the receiver buffer size to a maximum transmission of data to the application layer. Table. Flow control frame protocol data unit Data Unit Name The first byte The second byte The third byte 0-3 4-7 0-7 0-7 Flow control frame 00 Flow control frame BS STmin The flow control mechanism mainly controls the transmission of diagnostic data, and the receiving end of the reception is the corresponding control. The flow control specific process is shown in Fig. Figure. FlexRay network diagnostic flow control mechanism The sender sends the first frame to the receiver, and the receiver sets the flow control frame parameters depending on the length of the sender sending diagnostic data: BS and STmin. FlexRay bus has the longer data, so the value of BS is relatively smaller than the value of CAN network BS. Therefore, the design of the FlexRay diagnostics flow control mechanism will be the value of BS set sender to send data frames to reduce the complexity of the flow control. FlexRay network diagnostic data transmission requires only one flow control. 3.3. Time parameters FlexRay network diagnostic protocol application layer and the ISO5765-3 protocol have the same time parameters requirements, but because of FlexRay network in the diagnosis of CAN and FlexRay bus systems in the diagnosis of the status of the CAN network with ISO5765-diagnosis of network 56

layer is slightly different timing requirements. For FlexRay network diagnostic protocol network layer, the time parameter is mainly reflected in the flow control process. FlexRay network diagnostic protocol application layer and network layer requirements of the specific time parameters are shown in Table. Table. FlexRay network diagnostic time parameters table OSI model Time parameters Description Application layer Pflexray_server The time from the server receiving the request information to issuing feedback Application layer P*flexray_serve r The time from the client successfully sending the feedback information of 78 to re-issuing feedback Network layer N_FlexRay_As The time of FlexRay node sending a frame Network layer N_FlexRay_Bs The time of FlexRay node receiving a flow control frame Network layer N_FlexRay_Cs The interval of continuous transmission of two consecutive frames Network layer N_FlexRay_Ar The time of FlexRay node sending a flow control frame. Network layer N_FlexRay_Br The time of FlexRay node issuing a flow control frame Network layer N_FlexRay_Cr The time of FlexRay node receiving a continuous frame Note: The gateway nodes and FlexRay networks are unified set. 3.4. Error-handling mechanism Duration the diagnosis of the communication process between the diagnostic apparatus and ECU nodes of the FlexRay network, there will be unpredictable errors, so the error handling module does the corresponding processing according to the type of error. If an error occurs, call the appropriate error handling function according to the type of error message and the different errors specific operation are shown in Table 3. Type of error P*flexray_server timeout Single frame of data error Consecutive frame number error Receive buffer overflow N_GATEWAY_As timeout N_GATEWAY_Ar timeout N_GATEWAY_Bs timeout N_GATEWAY_Cr timeout Table 3. Error handling table Operating Sent with 78 feedback Receive abort Give up the consecutive frames for waiting for the retransmission Send flow control frames to cease receiving Data retransmission Data retransmission Resend the data frame which has not been confirmed Give up the data frame for waiting for the sender resending 4. Gateway diagnostic design 4.. Gateway protocol stack CAN-FlexRay gateway protocol stack receives a bus device data and does protocol conversion, and the data is passed down, and then the data is sent to another network by the communication entity, and the receiving termination receives the data layer to rise until it reaches the corresponding peer layer [7]. The gateway between the layers of the protocol stack uses the interface for communication, and CAN driver and FlexRay driver are directly added to the protocol stack as a separate module. Gateway protocol stack is shown in Fig.3. 57

Diagnostic apparatus Diagnostic interface Application layer ISO5765-3 Gateway Protocol stack application layer module FlexRay node Diagnostic interface Application layer protocol Session layer ISO5765-3 Protocol stack session layer module Session layer protocol Network layer ISO5765- Protocol stack network layer module Network layer protocol CAN underlying driver module CAN underlying driver module FlexRay underlying driver module Figure 3. Gateway protocol stack FlexRay underlying driver module The protocol stack model can be seen that the gateway is an important bridge of the communication between FlexRay networks and CAN networks, and it needs to support these two network diagnostic mechanism. CAN-FlexRay gateway must also comply with the CAN network and the FlexRay network diagnostic protocol mechanisms. In the protocol data conversion process, the gateway first receives a network diagnostic data for the reorganization of the data frame to obtain users' data, and then the data is repackaged and split to convert the data packets for other networks for identifying and data packet and forwarding. Gateway protocol conversion model is shown in Fig.4. Figure 4. Gateway protocol conversion model As shown in Fig.4, the process of the CAN-FlexRay gateway diagnostic data protocol conversion is as follows: First of all, diagnostic equipment diagnostic submits service request protocol data unit A_SDU to the application layer, and then application layer and A_SDU control information according to the diagnostic protocol ISO5765-3 form application-layer protocol data unit A_PDU. Network layer re-packages the diagnostic data according to ISO5765- protocol, and N_PCI and A_PDU compose network layer protocol data unit N_PDU. N_PDU transmits to the CAN-FlexRay gateway through the communication entity and finally reaches the gateway network layer. After gateway network layer receives N_PDU, submit data to the upper by transport layer and session layer, and finally send to the gateway application layer and form A_PDU. The gateway extracts the key data of A_PDU and re-packages the data to conform to FlexRay network diagnostic requirements and forms FlexRay network diagnostics application layer protocol data unit A_F_PDU to meet data transfer requirements. A_F_PDU through session layer and transport layer is packaged for network layer protocol data unit N_F_PDU by the gateway protocol stack network layer, and then reach the network layer of FlexRay network nodes. N_F_PDU reaches the application layer by the transport layer and the session layer to 58

compose of the application layer protocol data unit A_F_PDU, and make the available diagnostic data interface, thus complete a data transfer process. FlexRay network diagnosed node feedback data process is similar to the above, and only have the reverse process. 4.. Data forwarding The diagnostic data of CAN-FlexRay gateway includes the gateway diagnosis and the data forwarding by the gateway for the FlexRay network diagnosis. CAN-FlexRay gateway analyzes the data, and judge that this data is sent to the gateway or FlexRay networks. If the diagnostic request is sent to the FlexRay network, the CAN-FlexRay gateway is as a diagnostic interface, and data is forwarded to the FlexRay network. Gateway forwarding of diagnostic data is divided into two.. CAN network -> FlexRay network CAN diagnostic data for single-frame, a frame of single-frame represents a diagnostic data, even if the length of this data is only 7 (another byte is the control information), but as a separate diagnostic request, the CAN-FlexRay gateway forwarding allows directly encapsulated into a FlexRay data frame. CAN diagnostic data for multiple-frame, the CAN-FlexRay gateway stores and forwards the diagnostic data. If the multi-frame data length is less than or equal to 5, the gateway has received all CAN multi-frame data, and then packaged FlexRay data frame is sent as a FlexRay network diagnosis. If the data length is greater than 5, FlexRay network data need multiple frames sent.. FlexRay network - CAN network FlexRay diagnostics data for single-frame, first judge according to its data length. If the length is less than 7, the CAN-FlexRay gateway is forwarded as the single frame of the CAN bus diagnostic data. If the length is greater than 7, it is forwarded as a CAN bus diagnostic data frame. FlexRay diagnostics for multi-frame data, the CAN-FlexRay gateway must be forwarded as multi-frame of the CAN bus diagnostic data. The gateway forwarding includes two ways: () Receive a frame for forwarding; () All have been received and then forwarded. 5. Simulation 5.. Simulation system CANoe is a set of common bus system development tool developed by German Vector company, and it has a very wide range of applications in the global auto companies, and it has become a vehicle bus standard design tools. It provides professional features for all stages of the production cycle including model creation, simulation, diagnosis and analysis. The steps of using the CANoe simulation model for simulation are as follows: () Start CANoe. () Create or load the configuration file, and then save the configuration file. (3) Create the nodes for interface inserting. (4) Enter CANdb++ interface, and create signal, message and environment variables according to the need, and they are associated with the network node to save the created database. (5) Start panel editor to create a panel control associated with the panel properties and environment variables. (6) Enter CAPL programming browser and the program generator for writing and compiling of the simulation program. (7) Compilation, set and simulation. The DaVinci Network Designer software creates the database between FlexRay network nodes, and design the mapping between the network nodes of the internal system and set up the internal message table. The FlexRay simulation systems creates three FlexRay network nodes, namely ABS, AMT and Gateway node are shown in Table 4. 59

Table 4. Message analysis table of slot allocation method Node Messages sent ABS Name Type Cycle(ms) Length(byte) Frame_ static state 5 Frame_ static state 5 Frame_3 static state 5 Frame_4 static state 5 Frame_5 static state 5 AMT Frame_6 static state 0 Gateway Frame_7 static state 0 Frame_8 static state 80 4 Frame_9 static state 80 Frame_0 static state 80 5.. Simulation results and analysis The test of the network management function of CAN network is divided into four parts: Initialize the state test, the normal state tests, sleep test and LimpHome state test. Specific test items and test results are shown in Table 5. Table 5. Network management test Test item Test results Initialize the state test First message format () (7) T[typ], T[max], T[error] test () (3) () rx_limit() (3) () Ring, Limp Home message format () (3) () (6) Normal state test The stability of the logical ring () (3) (4) (5) Skipping (3) (6) T[max] (3) (6) Sleep instructions (4) (5) T[active_min](4) Sleep recognition (8) Sleep state test Sleep apnea (9) (0) () T[WBS] (0) Wake-up conditions () Limphome state test Restart (5) Sleep indicator (6) T[max] (7) NMWaitBusSleep state (8) (9) Application message testing T-[typ], T [max] and T [error] test requirements are shown in Table 6, and the fluctuation range of the three timing parameters have been given in Table 6. Table 6. Timing parameters of network management Time parameters Min[ms] Typical[ms] Max[ms] T[typ] 70 00 0 T[max] 0 60 80 T[error] 950 000 050 The results of the calculation are shown in Table 7 by Trace window of CANoe. 60

Table 7. Test results of the timing parameters Time T[typ]/ms T[max]/ms T[error]/ms 00.985 57.50 004.99 0.00 57.46 00.048 3 00.987 57.459 009.775 Mean 00.99 57.465 008.50 It can be seen from the calculated results that T[typ] is about 0ms, T[max] is about 57ms and T [error] is about 008ms. They meet the test requirements and the test is passed. It is similar to the testing process of other tests, and they meet the testing requirements of network management and unanimously adopted. In this paper, the design of network management solutions is feasible for the basic network management functions for FlexRay and CAN networks. FlexRay network diagnostic test is similar to the network management test, and they are both functional test. The diagnostic services are provided for ISO49 protocol test. ISO49 protocol services and test results are shown in Table 8. Diagnosis can be drawn that other the services pass the test in addition to ECUReset services. So the diagnostic protocols of FlexRay network designed in the paper as well as the CAN-FlexRay gateway protocol conversion and data forwarding are feasible. Table 8. Diagnostic test results Testing services Result Testing services Result DiagnosticSessionControl ReadDataByPeriodicIdentifier ECUReset Unmeasured DynamicallyDefineDataIdentifier SecurityAccess WriteDataByIdentifier CommunicationControl WriteMemoryByAddress TesterPresent ClearDiagnosticInformation AccessTimingParameter ReadDTCInformation SecuredDataTransmission InputOutputControlByIdentifier ControlDTCSetting RoutineControl ResponseOnEvent RequestDownload LinkControl RequestUpload ReadDataByIdentifier TransferData ReadMemoryByAddress RequestTransferExit ReadScalingDataByIdentifier FlexRay network diagnostic protocol simulation test results show that the design of the FlexRay diagnostic protocol stack, CAN-FlexRay gateway diagnostic protocol stacks and data forwarding can achieve FlexRay network diagnostic capabilities and ensure the diagnostic data communication between the diagnostic equipment and ECU nodes, which achieves the FlexRay network diagnostic capabilities. 6. Conclusion The vehicle bus changes the traditional means of communication between ECU nodes, which makes automotive network security and reliability become the key, and the automotive fault detection techniques play an increasingly important role, so it is necessary to study the vehicle networks, network management and diagnostic functions. This paper studies the network management and diagnostic capabilities of the CAN and FlexRay bus systems, and the work is as follows: Put forward to the FlexRay network diagnostic methods background on the CAN network diagnosis. The flow control mechanism and the error handling mechanism are studied. Design the network diagnostic protocol conversion and data forwarding method of the FlexRay gateway about the CAN-FlexRay gateway. To solve the FlexRay network has certain significance. The simulation results show that the design of the network management program as well as the diagnostic method of the FlexRay network is feasible. 6

7. References [] Schmidt K. Schmidt E. G, "Message scheduling for the FlexRay protocol: The static segment", IEEE Transactions on Vehicular Technology, vol. 58, no.5, pp. 60 69, 009. [] Schmidt E. G., Schmidt K, "Message scheduling for the FlexRay protocol: The dynamic segment", IEEE Transactions on Vehicular Technology, vol. 58, no.5, pp.70 79, 009. [3] Seo S. H., Kim J.H., Hwang S, "An evaluation of the FlexRay-CAN gateway-embedded system in the HEV test bench", IEEE International Symposium on Industrial Electronics, pp. 664 669, 009. [4] Seo S. H., Moon T. Y., Kim J. H., "A fault-tolerant gateway for in-vehicle networks", IEEE Conference on Industrial Informatics, pp. 44 48, 008. [5] Moon T. Y., Seo S. H., Kim J. H., "Gateway system with diagnostic function for LIN, CAN and FlexRay", Conference on Control, Automation and Systems, pp. 844 849, 007. [6] Li H., Zhang H., Peng D, "Design and application of communication gateway based on FlexRay and CAN", in International Conference on Electronic Computer Technology, 009: 664 668. [7] Shaheen S., Heffernan D., Leen G, "A gateway for time-triggered control networks", Microprocessors and Microsystems, vol. 3, no., pp. 38 50, 007. [8] Marko H H, Dirk G, "FlexRay NM Hanser Atomotive", Sensing and Control, vol., no., pp. -7, 007. [9] Liu Biao, Wang Lide, Jin Zhenhua, Lu Qingchun, "Timing Analysis and Scheduling Optimization of the FlexRay Network", JDCTA: International Journal of Digital Content Technology and its Applications, vol. 6, no. 0, pp. -3, 0. [0] Jiangfeng Wang, Shuo Nie, Xuedong Yan, Xiaomeng Li, "Analysis of Information Dissemination in Different Road Networks Scenarios", AISS: Advances in Information Sciences and Service Sciences, vol. 4, no. 3, pp. 403-40, 0. 6