Comparison of FlexRay and CAN-bus for Real-Time Communication

Transcription

1 Comparison of FlexRay and CAN-bus for Real-Time Communication Andreas Forsberg Mälardalen University Högskoleplan Västerås afg05001@student.mdh.se Johan Hedberg Mälardalen University Högskoleplan Västerås jhg05005@student.mdh.se ABSTRACT FlexRay is today being developed to match the future needs of invehicle communication that the automotive industry demands. Today the Controller Area Network (CAN) is widely used in the automotive industry. This paper presents an overview and comparison between the two communication protocols. Data efficiency, safety, system flexibility and complexity are some of the aspects compared in this paper. An overview on how the two different protocols work is included where the layered structure of the protocols is described. The paper also attempts to describe how media access is controlled and how the structure of the messages look like. In automotive industry dependable and predictable systems are preferred. therefore this paper also includes how the real-time demands such as response time analysis and schedulability is handled in the two protocols. General Terms Performance, Design, Reliability. Keywords CAN, FlexRay, Comparison, Overview 1. INTRODUCTION As the number of Electronic Control Units (ECUs) increase in vehicles the need for faster and more reliable communication is required. Today almost every car uses the CAN field bus in some way for the in-vehicle communication. As the demand for more applications like x-by-wire increase something has to be done to the communication system, this because the CAN bus cannot handle the increased need for more bandwidth and speed. The solution to this problem is what the industry refers to as the future communication bus, the FlexRay communication system. This article will describe both the CAN bus and the FlexRay protocol with regards to how they work and compare them against each other. Another aspect to the growing amount of ECU: s is that it gets harder to schedule and guarantee real-time constraints. The article will include comparison of some analyzing methods and scheduling algorithms for the different protocols. In section 2 the history and background will be described about the two protocols. Section 3 will present an overview of how the two protocols work. A number of different comparisons between the two protocols is made in section 4. Finally, section 5 holds the conclusions of the paper. 2. History and Background 2.1 CAN In 1983 Robert Bosch GmbH one of the world largest suppliers of automobile components began to develop a serial communication bus, its main design was to provide simple, efficient and robust communications for networks inside vehicles. CAN as the serial bus were called was first presented to a broader audience at a congress for automotive engineers in About a year later the first CAN controller chips were released, and in 1993 CAN got its first ISO standard publication. The number of ECUs used in cars increased quickly in the middle of the 1990s. Previously these ECUs were connected in a pointto-point manner, however when the amount of ECUs increased so did the cost of connecting them. Because of this the car industry started to use the CAN as a simple yet effective solution to reduce the cost of connecting the ECUs. The main principles of CAN is the following: Multi-master: Any node may send if the bus is idle. Guarantee of latency times: It should be possible to calculate the worst case time for a message to be sent and reach its receiver. Configuration flexibility: Nodes can be added to the network without the need to do any changes in hardware or software of any node and application layer. Prioritization of messages: A higher prioritized messages will get buss access before a lower prioritized message if they attempt to send at the same time. Broadcast communication: Every transmitted message is received in all nodes, the data should be consistent in the system.

2 Error detection and re-transmission of faulty messages. There should also be a distinction between temporary errors and permanent failures of nodes, defect nodes should autonomous be switched off. Bus arbitration: If more then one node wishes to send at the same time, the message with the highest priority should immediately get bus access. 2.2 FlexRay In 2000 BMW, Daimler-Chrysler, Philips and Motorola joined forces to create a new automotive network scheme which would better suit the increasing demand for advanced applications in automation. Since the start the FlexRay Consortium has been expanded and now consists of seven core, 28 premium associate and 64 associate members. There is a great consensus in the automotive industry that FlexRay will become the new standard within vehicles and thus replacing the old CAN-bus. The first vehicle built with the new FlexRay protocol was the 2006 BMW X5 but the first vehicle to fully utilize the FlexRay protocol was the BMW 7-series that had the FlexRay system introduced in As the new FlexRay protocol is supposed to be the future of automotive network communication the requirements of the protocol has to match with the modern requirements that are expected from a reliable real-time protocol. FlexRay should provide the following requirements according to [2]: Deterministic communication. Support for on-demand communication, and make sure that it does not interfere with the deterministic communication. Scalable fault-tolerance. Support for a discrete set of bit rates. Support for a bit rate of 10 Mbit/s. Support for host operations by providing a number of additional services: Network management service Message ID filtering service Macrotick timer service Temperature monitoring service Voltage monitoring service Support for composability of subsystems into larger systems. Predictable behavior at absence and at presence of error conditions. A network-wide consistent view of time with a known accuracy to all nodes. 3. Overview of the two protocols 3.1 CAN Figure 1: Layered structure of a CAN node. [4] Layers The different layers of the CAN system is shown in figure 1. The top layer in the CAN structure is the object layer which is responsible for the message handling, such as filtering. The next layer is the transfer layer in which arbitration, message validation, error handling and the handling of frames are covered. The final layer is the physical layer in which the different signals, how bits are represented and the actual transmission medium is covered Media Access Control CSMA/BA (Carrier Sense Multiple Access/Bitwise Arbitration) protocol is used when sending messages over the bus. CSMA/BA works so that when the bus is free any unit may start to transmit a message. If two or more units starts to transmit simultaneously the Bitwise Arbitration will determine which unit may continue sending. In the Bitwise Arbitration dominant and recessive bits are used on the bus, were dominant bits always overwrite recessive bits. Since each unit has a unique identifier included at the start of every message, that identifier is used for determining the priority of the unit by having more or less dominant bits in it. The units that are trying to transmit a message will do so by sending one bit at a time and monitoring the value on the bus, if the unit sends a recessive bit and reads a dominant bit the unit will stop transmitting and wait for the bus to be free and retransmit. This will result in that the unit with the most dominating bits will be able to transmit its message Frame types There are four types of frames for message transfer in the CAN protocol each with a different purpose. The data frame is used to carry data from a transmitter to one or more receivers. The data frame consists of the following bit fields:

3 start of frame, arbitration, control, data, Cyclic Redundancy Check (CRC), acknowledgment and end of frame. The data field can range between 0-8 bytes of data. The Remote Frame is used to request that a data frame is transmitted. The structure of the remote frame is almost identical to the data frame, the difference is that the remote frame does not have any data field. The error frame is used whenever any unit detects an error on the bus. The error frame consists of two bit fields, the error flag and the error delimiter. The error flag is used to indicate the occurrence of an error frame. The error flag can have two different appearances, one to symbolize the active error frame and the other to represent the error passive frame. The second bit field in the error frame is the error delimiter that is used to limit the number of error frames on the bus. The overload frame is used to delay any data or remote frame if the receiver is not yet able to receive due to some internal conditions. The overload frame consist of two bit fields where one is the overload flag that indicates that it is an overload frame, the second bit field is the overload delimiter that is used to limit the number of overload frames sent on to the bus. For further information see [1] Safety The CAN protocol is designed to detect five different errors with its error detection methods: Bit error Stuff error CRC error Form error Acknowledgment error Every transmitter that sends bits on the bus also monitors the value on the bus. This is done to detect bit errors, but there are exceptions like in the arbitration process were dominant bits overwrite recessive bits. Then if a transmitter sends a certain value on the bus but reads another value a bit error is detected and an error frame is generated. The monitoring is also used to detect an acknowledgement error which is detected if the acknowledgement slot does not contain a dominant bit. The method of bit stuffing is used to detect stuff errors in messages. The method works so that the transmitter checks the outgoing messages for consecutive streams of identical bits, if such a stream is detected that holds five bits a complementary bit is inserted. If the receiver upon receiving a message detects a sixth consecutive bit an error frame is generated. Each message that is sent holds a CRC field where the transmitter puts the calculated check sum of the message. If the receiver calculates a different check sum than the one in the CRC field a CRC error has occurred and the message has to be retransmitted. The message frames are checked for form errors which are bit errors in the specified bit fields in the frames. The method used whenever an error is detected is to send an error frame with an error flag. There are two kinds of error frames, an error active and error passive frame. Which type of error frame that is sent depends on what state the node detecting the error currently is in, further explained in the next section. To prevent the occurrence of a faulty node transmitting consecutive error frames the CAN protocol uses a fault confinement technique. The technique is based on that every unit can be in three different states, these different states are error active, error passive and bus off. To switch between these states each unit has two counters that count the number of transmitted and received errors. In the CAN protocol the time for which a message is valid differs between the transmitter and receiver. For a message to be valid for the transmitter no error can occur until the whole frame has been sent. The receiver considers a message to be valid if no error has occurred until the second last bit in the EOF field, this because an erroneous value on the last bit in the EOF does not lead to an form error. 3.2 FlexRay The design of Flexray is to use two channels for transmitting information. Each channel is able to work independently, but can also be used to communicate the same information. Each channel should be able to carry information with a rate of 10 Mbits/s. Nodes can be attached to either both channels or to a single channel, if it is just connected to a single channel it does not matter to which one it is connected. Different bus topologies can be used with Flexray, for example: point-to-point connection, star networks, dual channel topologies, and some hybrid topologies. Figure 2. Layered structure of a FlexRay node. [4] Layers The different layers of the FlexRay protocol is shown in figure 2. The top application layer is for user applications. The presentation layer contains the communication controller host interface, and is responsible for frame filtering and frame status handling. Next layer, the transfer layer is the main part of the protocol. It takes care of timing, synchronization, message framing, error detection, and send plus receive frames. The physical layer does the actual signal transmitting, and also has some error detection.

4 3.2.2 Media Access Control Flexray's media access control uses recurring communication cycles. Each cycle can be divided into four main parts, the two first parts are the static segment followed by the dynamic segment and is used for media access. After comes a symbol window which is used for sending control information between the nodes. Finally the cycle ends with a communication free period called network idle time, this time is mainly used for synchronizing clocks. The static segment use a technique called Time Division Multiple Access (TDMA) to distribute send access. TDMA breaks down the static segment in smaller parts called slots, all slots in the static segment have the same length and each slot is assigned to a node. It is possible that a slot is assigned to one node for example every even cycle and to another every odd cycle, one node may also have more then one assigned slot every cycle. If a node wants to send a message during the static segment it will send only that one message during one assigned slot, if the node wish to send another message it will have to be in another time slot, in the dynamic segment, or the next cycle. Commonly each static slot is reserved for one specific message, the type of messages that work very well with the static segment is hard real-time messages that needs to be sent frequently. There are some constraint for communication in the static segment according to [3]: Sync frames shall be transmitted on all connected channels, a sync frame is a FlexRay frame whose header contains an indicator that the frame is used for clock synchronization. Non-sync frames can be transmitted on either one channel or both. Only one node shall send a given frame ID on a given channel. If a cluster of nodes is configured to just use a single slot, then all non-sync nodes should decide a frame as the single slot frame. In the dynamic segment something called mini-slotting is used in order to arbitrate transmission. Just like the slots in the static segment each minislot got the same length, within the dynamic segment and on these minislots something called dynamic slots are used. The length of a dynamic slot depends on if communication is happening or not. If no communication is taking place the duration of the dynamic slot is the same as one minislot, the channel is idle through the minislot and no communication will happen until the next minislot. However if a message is sent the dynamic slot may consists of multiple (as many as the frame needs) minislots. The message transmission scheme in the dynamic section is based on message priority, so message with a higher priority will always get to send before a lower priority message Clocks and timing In a communication system like FlexRay every node in the network needs to have the same perspective of time in order to proper schedule the communication. However because of for example temperature and voltage changes the nodes clocks may begin to drift, and the nodes value of time may be different even if they where synchronized in the beginning. FlexRay nodes uses a hierarchy for time representation, much like we represent time in hours, minutes, and seconds the FlexRay nodes represent time as cycles, macroticks, and microticks. Each control unit calculate the microticks on their own, it is the smallest parts of the FlexRay timing hierarchy and the length of a microtick may vary from different nodes. The macroticks are synchronized by sending so called sync-frames among the connected nodes, based on these messages calculations are done within each node to determine the number of microticks for their next macrotick. Within a certain tolerance level the macroticks should be identical among the connected nodes. A slot consists of an integer number of macroticks, and this number should be the same for all nodes in the network, and it should also remain the same in every cycle. Figure 3. The FlexRay communication cycle, also showing the timing hierarchy. [3] The figure above shows how the whole communicaton cycle for FlexRay is laid out. For further information about FlexRay media access control, frames and clocks see [3] Frames FlexRay frames are divided into three segments, the header segment, payload segment, and the trailer segment. The header segment consist of 5 bytes and contains information such as: Some information about the purpose and the content of the frame, like if it should be used for clock synchronization, if the payload section contains any valid data, if the frame should be used as a startup message to some node, or if it contain network management information. The frame ID which determines in what slot the frame should be transmitted. The length of the payload segment. A cyclic redundancy check for the header, which is a type of hash function used to detect accidental data changes. The payload frame segment consist of 0 to 254 bytes of data depending of the size of the message a node wishes to send, the payload segment may contain a network management vector. The FlexRay frame trailer segment is a 24 bit cyclic redundancy check that is calculated over the two previous segments, the header and the payload parts of the frame in an attempt to find errors in these fields.

5 Figure 4. The FlexRay frame format. [3] Response time analysis and scheduling The messages sent in the static segment of the communication cycle is scheduled using static cyclic scheduling. Which node is to send in what slot is planned before runtime with static cyclic scheduling. Scheduling in the dynamic segment is done by fixed priority scheduling. Fixed priority scheduling is the same technique that is used for scheduling in CAN, each message got a fixed priority that is set before runtime, but the actual scheduling is done while the system runs. The worst case response time for the static segment assuming each cycle looks the same is: R m = D m + C m. Where D m is the longest possible time it takes for the message (m) slot to return (usually about the same time as the duration of one cycle). C m is the communication time and it can be calculated with the following formula: C m = Frame_Size(m)/Bus_Speed. Calculating the worst case response time for the dynamic messages is a bit harder, but the following formula can be used: R m(t)=σ m + w m(t) + C m. σ m is the longest possible delay during one bus cycle if the message is sent after its slot has passed. w m is the worst case delay caused by transmissions of the static segment and higher priority dynamic messages during the time t. How to exactly calculate the worst case response time for messages in the dynamic segment is out of the scope for this article, for further information on this subject see [8]. 4. Comparison 4.1 Complexity The CAN system is considered to be a low complexity system. Its low complexity is due to the single channel bus with arbitration method for bus access. The complexity of FlexRay is considered to be very high, the main reason for this is the use of two different protocols for accessing the communication bus. FlexRay uses both static and dynamic bus access which makes the whole system very complex. 4.2 Safety, composability and flexibility Safety The CAN protocol has many features to ensure safety such as bit monitoring, CRC and fault confinement. Safety was a key issue when the CAN protocol was developed and its broadcast bus with prioritization of messages ensures deadlines for high priority functions. The CAN has a great benefit for safety due to its low complexity which greatly reduces the risk of any manufacturing or programming errors. CAN buses use line topology which could be considered a safety risk, this due to the fact that the system could not handle if the main line would be broken. A break would result in that the nodes separated would be disconnected and their function lost. Since FlexRay is supposed to be the next communication system for automotive networks safety is of great importance. The FlexRay system uses two channels which is extremely useful for key safety features. The system may be configured in many different ways and the two channels may be used for example to be redundant channels, so if one of the channels would fail the system could keep its functionality. Each node in the FlexRay system is assigned a bus guardian which is a safety measure to ensure that the node does not get stuck in an erroneous mode and compromise the whole system Composability Is a system design principle that deals with the inter-relationships of components. A highly composable system provides recombinant components that can be selected and assembled in various combinations to satisfy specific user requirements. [2] Composability was not considered when the CAN system was developed instead other aspects were of greater importance. The lack of composability in CAN is because of the broadcast bus with prioritized messages. Nodes that are added or removed have an impact on the temporal behavior of the system and can therefore not be tested separately. For FlexRay on the other hand composability was a key issue from the beginning. FlexRay has the ability to make the system both static and dynamic with regards to the handling of messages. This makes it easy to add new nodes without having to change the scheduling of the system. Nodes can therefore be tested separately and then integrated into an existing system where it will be assigned time slots that can assure correct behavior of the node Flexibility The CAN system has some properties of a flexible system but is very restricted in other ways. The CAN system is flexible since new nodes may easily be added or removed from the system. The downside of the CAN system is that its single channel line topology does not allow any variations in system design. Like the name suggests FlexRay is intended to be a very flexible system. Due to its two channels the FlexRay system may be configured in many different ways. The most common topologies for FlexRay are normal bus line topologies like the one found in CAN, star topologies or combinations of star and bus line topologies. A standardization of the ECU interface is also a high priority in the development of FlexRay to ensure systems to be more flexible when it comes to node design. 4.3 Communication Principles FlexRay frames support a data field containing up to 254 bytes with a 40 bits header and a 24bits trailer, while CAN only supports a data field with up to 8 bytes with 44 bits of additional information. This means that FlexRay may send larger messages with less overhead then CAN, but for smaller messages the overhead is about the same. However since FlexRay's static segment use the same size for all slots shorter messages will be

6 ready before the slot is used up making the bus idle for the rest of the slot. There will also be some idle time in the dynamic segment because of the use of minislots, however that is not as big as in the static segment. CAN will not have that idle time as long as there are messages in the queue. The bandwidth of CAN goes up to 1Mbit/s while FlexRay can send data with a bitrates up to 10 Mbit/s on two channels. 4.4 Real-Time demands Knowing the worst case response time for each message is important for making schedulability analysis to see if the tasks will be ready in time or not. Making such analysis is possible with both CAN and FlexRay. However the way to calculate the response times for the different communication systems are a bit different. CAN use Fixed Priority scheduling, which means that each message got a set priority, and higher prioritized messages will get access to the bus before lower prioritized messages. The advantage with this system is that high prioritized messages will have a quick response time, however low prioritized messages may have to wait a long time before they get bus access if there are many high priority messages in the send queue. Another disadvantage with fixed priority scheduling is that it is not very predictable, however it is possible to calculate worst case response times for every message. FlexRay have different time slots for messages that is scheduled by static cyclic and fixed priority. Static cyclic scheduling got the advantages that it is easy to calculate response times and is very predictable. However since it needs to be scheduled before runtime it got some limitations, like how to schedule very important messages that rarely needs to be sent. In worst case that kind of message may have to wait for a whole cycle if its slot have passed, or multiple slots have to be assigned to that message but then these slots will pass empty most of the time. Making a static schedule may not be that easy for complex systems. Using one static section and one dynamic section like FlexRay may be an advantage since frequent real-time messages can be sent in the static segment, while uncommon high priority messages and lower prioritized messages can use the dynamic segment. Table 1. Comparison of a few properties of FlexRay and CAN CAN FlexRay 5. Conclusions In this paper we have compared the FlexRay communication system that is still in development, with the widely used CAN system. There are several advantages with using FlexRay instead of the older CAN protocol, such as higher bandwidth and more flexibility. However it will probably take time before FlexRay becomes widely used, because of how complex the system is compared to CAN. Since FlexRay is new and a lot more complex with less people that have knowledge about it CAN is today a much easier and cheaper solution for the industry. Even though the FlexRay protocol is supposed to take CAN:s place in automotive systems, there is still areas where a CAN system may be better suited. therefore systems where FlexRay and CAN can be combined would be an excellent solution. 6. REFERENCES [1] CAN Specification 2.0, Part A and Part B. [2] FlexRay Requirement Specification, version [3] FlexRay Protocol Specification, version 2.1, revision A [4] Seo, S-H., Lee, S-W., Hwang, S-H., Jeon, J. W Development of Network Gateway Between CAN and FlexRay Protocols For ECU Embedded Systems. Sungkyunkwan University, Suwon, Korea. [5] Shaw, R. Jackman, B An Introduction to FlexRay as an Industrial Network. Waterford Institute of Technology, Waterford, Ireland. [6] Kopetz, H A Comparison of TTP/C and FlexRay. Technische Universität Wien, Austria. [7] Jianxin, L., Xuefeng, G., Ping, T The Analysis and Test of Real-Time Performance for Time-Triggered CAN Bus. University of Xihua, Chengdu, China. [8] Pop, T., Pop, P., Eles, P., Peng, Z., Andrei, A Timing analysis of the FlexRay communication protocol. Published online. Bandwidth 1 Mbit/s 10 Mbit/s Number of channels 1 2 Frame data length Communication technique Dynamic arbitration TDMA with one static segment and one dynamic Complexity Low High Composability No Yes Flexibility Only possible to connect nodes to a Many different possible topologies