CRC are coded by bit stuffing. Whenever a transmitter detects five consecutive bits of identical value in the bit stream to be transmitted it automatically inserts.
Technische Universit¨ at Darmstadt Institut Integrierte Schaltungen und Systeme Fachgebiet Mikroelektronische Systeme Prof. Dr. -Ing. Sorin A. Huss
Diplomarbeit
Design of a Simulation Framework for Automotive Networks using SystemC
Bearbeiter
:
Hui Shao
Betreuer
:
Dipl.-Inform. Marc Zeller, Dipl.-Inform. Felix madlener
Beginn
:
1. January 2007
Ende
:
30. June 2007
Declaration
Herewith I declare, that I have made the presented paper myself and solely with the aid of the means permitted by the examination regulations of the Darmstadt University of Technology. The literature used is indicated in the bibliography. I have indicated literally or correspondingly assumed contents as such.
Darmstadt, 30. June 2007
Hui Shao
iii
Contents 1 Introduction
1
1.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Description of the Project . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2 Related Work
5
2.1
Modelling and Simulation with SystemC . . . . . . . . . . . . . . . .
5
2.2
Survey of Bus Networks . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.1
CAN (Controller Area Network) . . . . . . . . . . . . . . . . .
6
2.2.2
FlexRay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2.3
MOST (Media Oriented System Transport) . . . . . . . . . .
17
Pre-existing frameworks for generic communication . . . . . . . . . .
19
2.3.1
GreenBus . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.3.2
OSSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.3
3 Design and Implementation 3.1
3.2
23
Design Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.1.1
Transmission Routine . . . . . . . . . . . . . . . . . . . . . . .
24
3.1.2
Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.1.3
Control Flow . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.1.4
Design trade-off . . . . . . . . . . . . . . . . . . . . . . . . . .
30
System Architecture and Functionality . . . . . . . . . . . . . . . . .
31
3.2.1
Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.2.2
Arbiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.2.3
ECU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
v
Contents 3.2.4
Stimulus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.2.5
Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.2.6
Configuration parameters . . . . . . . . . . . . . . . . . . . .
41
4 Verification and Evaluation 4.1 Setup of Testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49 49
4.1.1
Test Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.1.2
Elaboration and Configuration . . . . . . . . . . . . . . . . . .
51
4.2 Simulation Performance and Results . . . . . . . . . . . . . . . . . .
52
4.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
5 Conclusion
63
5.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
Bibliography
65
A Used Abbreviations
67
vi
List of Tables 2.1
Vehicle Network Standards [5] . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Standard Format CAN Frame . . . . . . . . . . . . . . . . . . . . . .
10
2.3
Extended Format CAN Frame . . . . . . . . . . . . . . . . . . . . . .
10
2.4
Comparison between CAN and FlexRay . . . . . . . . . . . . . . . .
13
2.5
Overview of the FlexRay Frame Format
. . . . . . . . . . . . . . . .
16
2.6
MOST Frame Architecture . . . . . . . . . . . . . . . . . . . . . . . .
20
3.1
Length of CAN Frame without Bit-Stuffing . . . . . . . . . . . . . . .
43
3.2
Length of CAN Frame with Bit-Stuffing . . . . . . . . . . . . . . . .
44
3.3
Configuration parameters of FlexRay . . . . . . . . . . . . . . . . . .
48
4.1
BMW 7 Series Network Requirements [14] . . . . . . . . . . . . . . .
50
4.2
Expected System Behaviours of the Simulation Model . . . . . . . . .
51
4.3
Configuration Specifications for Test Case 1 . . . . . . . . . . . . . .
53
4.4
Worst case delays classified by message priority . . . . . . . . . . . .
54
4.5
Configuration Specifications for Test Case 2 . . . . . . . . . . . . . .
55
4.6
Comparison of worst case delays with diverse bus utilizations . . . . .
55
4.7
Configuration Specifications for Test Case 3 . . . . . . . . . . . . . .
57
4.8
Parison of worst case delays with diverse bandwidths . . . . . . . . .
58
4.9
Configuration Specifications for Test Case 4 . . . . . . . . . . . . . .
59
4.10 Worst case delays in the network CAN standard . . . . . . . . . . . .
60
4.11 Worst case delays in the network CAN extended . . . . . . . . . . . .
60
vii
List of Figures 2.1
CAN Network connecting multiple ECUs . . . . . . . . . . . . . . . .
7
2.2
CAN Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.3
FlexRay Network with dual Channels . . . . . . . . . . . . . . . . . .
11
2.4
Dual-channel FlexRay during a communication cycle . . . . . . . . .
12
2.5
FlexRay Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.6
MOST Network in Ring . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.7
MOST Communication . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.1
Simple Bus Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.2
Bus Protocol Classes . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.3
Data Flow in a Bus Use Case . . . . . . . . . . . . . . . . . . . . . .
27
3.4
Control Flow in a Bus Use Case
29
3.5
System Architecture without the Scheduler
. . . . . . . . . . . . . .
32
3.6
Class Diagram of Bus . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.7
Class Diagram of Arbiter . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.8
Class Diagram of ECU . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.9
Class Diagram of Stimulus . . . . . . . . . . . . . . . . . . . . . . . .
41
. . . . . . . . . . . . . . . . . . . .
3.10 System Architecture with the Scheduler
. . . . . . . . . . . . . . . .
42
3.11 CAN Data Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.12 Transmission Delay over CAN . . . . . . . . . . . . . . . . . . . . . .
46
4.1
Worst case delays classified by message priority . . . . . . . . . . . .
54
4.2
Comparison of worst case delays with diverse bus utilizations . . . . .
56
4.3
Comparison of worst case delays with diverse bandwidths . . . . . . .
58
ix
List of Figures 4.4 Comparison of worst case delays in networks CAN standard and CAN extended . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
x
61
1 Introduction 1.1 Motivation In the automotive sector, the number of electronic components in vehicles has increased rapidly and continuously during recent years. Thus a modern vehicle may have a complex distributed system consisting of various ECUs (Electronic Control Units), which is networked by several bus systems. Since automotive embedded systems have a great need for dependability, the impact of innovation introduction in hardware design and software functions lead to the expectation that the timing constraints due to the constrained resource consumption are regarded in an earlier design phase. To meet these design challenges, a simulation framework is designed and implemented in this project, in particular, with consideration of the time-constrained system performance characteristic. It aims to facilitate the system modelling and analysis for the early verification and validation. In this framework, generic functionalities and common basic components for simulating the in-car communication mechanisms are provided in such a way, that they could be selectively overridden or specialized by setting specific configuration parameters to make adaptations for diverse bus systems. The most obvious benefit of using such a simulation framework is that the overall system development time could be reduced by reusing the executable generic functionalities and the common basic components provided by the framework. The system designer and programmer may devote their time to meeting the specific sys-
1
1 Introduction tem requirements rather than to dealing with the more standard low-level details of providing working bus systems. On the other hand, using the functionalities and components provided by the framework, which have already been built and exploited, and thereby ensure certain system performance characteristics, may improve the predictability and reliability of the overall system.
1.2 Description of the Project The simulation framework in this project is specifically developed for in-car communication over the currently dominating bus systems in the industry, such as CAN, FlexRay and MOST. The design goal is to facilitate the modelling and analysis with emphasis on the cycle count accurate timing estimations for transmission delay and the variety of system configurations for architectural exploration. The approaches made in this project are summarised as follows:
Characterise and specify the in-car communication mechanisms over the bus networks: CAN, FlexRay and MOST Develop a concept including all necessary components for the simulation framework Develop interface functions to realize network communication to enable modelling interoperability among diverse bus systems Implement the design using SystemC Build Prototypes for the framework verification and analyse the obtained results with appropriate parameters.
2
1.3 Outline
1.3 Outline In this thesis, a review of related work is performed in Chapter 2. In this chapter, diverse in-vehicle networks and pre-existing frameworks for bus communication are studied and analyzed. Chapter 3 explains the design concepts and strategies employed in this framework. In addition, approaches for system implementation adhering to bus specification documents are presented in detail. Multiple simulations along with the configuration parameters are performed in Chapter 4. The achieved results including performance evaluation is given. The thesis is concluded with a summary in chapter 5.
3
2 Related Work In this chapter, a brief introduction to SystemC is given. Moreover, a review of the several currently dominant automotive networks and pre-existing frameworks in the area of generic communication are studied and analysed as preparation for the system design depicted in Chapter 3.
2.1 Modelling and Simulation with SystemC 2.1 Modelling and Simulation with SystemC In this project, automotive network systems are modelled and characterized on system level using the system description language SystemC. SystemC allows designing both the hardware and software components within a system together. Strictly speaking, SystemC is a set of library routines and macros implemented in C++, containing data types and structures for modelling hardware components along with the types supported by C++. Similar to the hardware description languages VHDL and Verilog, SystemC possesses a simulation kernel. Thus the instantiated objects based on SystemC may communicate in a simulated real-time environment and perform timing sequenced operations [1][2][3]. Generally, a SystemC model consists of several modules communicating with each other via ports. Module instances, as the basic building blocks, are used to describe the model hierarchy. Modules typically contain processes, ports, internal data, channels and possibly instances of other modules. Processes are used to model the functionality of modules, which could be operated concurrent conceptually at runtime, irrespective of the order in which they are called.
5
2 Related Work Communications among processes and modules are accomplished using ports, interfaces and channels. A process could access a channel interface via a port. The channel interface defines a set of access functions for a channel, while the channel itself provides the implementation of these functions. At elaboration time the ports of a module are connected to designated channels. The interface, port, channel structure provides for great flexibility in modelling communication and in model refinement [3].
2.2 Survey of Bus Networks Diverse bus standards are employed in dedicated application fields considering the required safety level, data rate and costs. Safety-relevant applications require reliable, real-time systems, infotainment applications require a high data transmission speed, and the networking of sensors and actuators in car body require a cost-efficient system with minimum wiring costs. Table 2.1 shows the application fields of the network standard CAN, FlexRay and MOST in terms of transmission speed. Besides transmission speed other technical features such as determinism, bandwidth and flexibility are taken into consideration for choosing the appropriate bus standard for certain applications.
2.2.1 CAN (Controller Area Network) CAN is a broadcast serial bus system for distributed embedded control. Transfer data are encoded in messages and transmitted at a baud rate of up to 1 Megabits per second. A message is transmitted in one or more frames, and the frame payload is limited up to 8 bytes. Figure 2.1 represents a simple CAN network, to which a number of ECUs is connected. In practice the total number of ECUS is limited by delay times an electrical loads on the bus line. The Model used by CAN for exchanging data is referred to as Producer-Consumer Model, that is, one ECU node sends another ECU node data without request in form of multicast or broadcast messages. As the message consumer does not know the
6
2.2 Survey of Bus Networks
Bus Transmission Standard Speed CAN 125Kbps to 1Mbps
FlexRay
1Mbps to 10Mbps
MOST
10Mbps or faster
Application Applications Field Status Electronic Indicators, Information driving information, automatic air conditioner, failure diagnosis, etc. Real-time Engine control, ABS, Control transmission control, break control, suspension control, etc. Multimedia Car navigation system, audio system, etc.
Table 2.1: Vehicle Network Standards [5]
ECU
ECU
ECU
...
ECU
CAN
Figure 2.1: CAN Network connecting multiple ECUs
7
2 Related Work receivers, the messages are not confirmed. The bus access process used by CAN is a multi-master access process, that is, the right of bus access is not assigned by a central instance, but each ECU node may start to transmit whenever the bus is free. If two or more nodes starts sending at the same time, this conflict is solved by means of an arbitration process which is conducted by the message identifier. For example, two ECU nodes start sending simultaneously and their identifiers are identical up to the fifth transmitted bit. None of them sense that other nodes are transmitting at the same time until the fifth bit is sent. By reading back the bus line it senses, the ECU node with a recessive bit at the fifth bit position finds out that a dominant bit is transferred over the bus. It realizes that an other node is sending a message with a higher priority and it will immediately stops transmitting its identifier. Thus, the node with the lower identifier wins. Due to this fact, that the arbitration procedure requires the transmitter to read back the bus line to detect whether it was overwritten, the maximum baud rate depends on the length of the bus line. The signal must be able to pass through the line twice during one bit time. The maximum baud rate of 1 Mbps can only be achieved up to a line length of 40 m. In CAN, each message is statically assigned a unique identifier (either 11-bit as standard or 29-bit as extended). This identifier is assigned to each frame within the message as transmission priority. Due to the recessive-dominant arbitration, the frame with the highest priority, namely the lowest identifier value, is eventually granted to obtain the access to bus. Once a frame is being sent, it is non-pre-emptive. The message identifier is also used by target node for filtering upon receipt. As mentioned above, data are transmitted broadcast over the bus CAN. The messageoriented protocol used by CAN does not have an address field with transmitter and receiver address, but with a unique message identifier. All nodes in the CAN network, having received the message correctly, perform an acceptance filtering to determine whether the data received is relevant or not. Concerned data will be processed, otherwise ignored. Figure 2.2 demonstrates the CAN frame format for data transmission without bit
8
2.2 Survey of Bus Networks Control Bits
Start Bit 11 or 29 bit Message Identifier
7 bit
Header 19 or 37 bit
Bus Idle Data 0 ... 8 Byte
Payload 0 ... 64 bit
15 bit CRC
Acknowledge & End of Frame
Trailer 25 bit
>= 3 bit
Figure 2.2: CAN Frame Format stuffing. The frame is composed of seven different bit fields, namely start of frame, arbitration filed, control field, data field, CRC field, acknowledgement field and end of frame. The standard and extended frame format of CAN are explained briefly in Table 2.2 and Table 2.3 respectively. Adhering to the specification document of CAN 2.0, a CAN network can be configured to work with two kinds of frame formats: the standard one with 11 bits message identifier and the extended one with 29 bits message identifier. The format to be chosen is denoted by the IDE control bit. Furthermore, these two formats can coexist within the same network. The frame segments start of frame, arbitration field, control field, data field and CRC are coded by bit stuffing. Whenever a transmitter detects five consecutive bits of identical value in the bit stream to be transmitted it automatically inserts a complementary bit in the actual transmitted bit stream. In other words, a bit of opposite polarity is stuffed after five consecutive bits of the same polarity. This extra stuffed bit is removed by the receiver node upon receipt. The remaining bit fields are of fixed form and not stuffed. It should be noted herein that each node in a CAN network has its own clock, and all clocks run at the same rate. There is no separate signal on CAN bus to synchronize the clocks. The CAN frame itself is used for the synchronization of clocks on all nodes. To achieve this effectively, bit stuffing mentioned above is employed [6] Due to the low cost of CAN controllers and processors, CAN bus is widely used in the automotive network. However, due to the event-triggered protocol and the priority based arbitration, the transmission time is predictable only for the message with the highest priority over the bus, whereas the transmission time for messages
9
2 Related Work
Field Start of frame Message identifier RTR bit IDE r0 DLC Payload CRC CRC delimiter ACK
Length 1 bit 11 bits 1 bit 1 bit 1 bits 4 bits 0-8 bytes 15 bits 1 bit 1 bit
ACK delimiter End of frame
1 bit 7 bits
Purpose Denote the start of frame transmission Unique identifier of the frame Remote transmission request bit Identifier extension bit Reserved bit for future expansion Data Length Code Data to be transferred Cyclic Redundancy Check One recessive bit Report a valid message receipt with a dominant bit One recessive bit Seven recessive bits
Table 2.2: Standard Format CAN Frame
Field Start of frame Message identifier A SRR IDE Message identifier B RTR bit r1/r0 DLC Payload CRC CRC delimite ACK
Length 1 bit 11 bits 1 bit 1 bit 18 bits 1 bit 2 bits 4 bits 0-8 bytes 15 bits 1 bit 1 bit
ACK delimiter End of frame Interframe space
1 bit 7 bits 3 bits
Purpose Denote the start of frame transmission First part of the frame identifier Substitute remote request Identifier extension bit Second part of the frame identifier Remote transmission request bit Reserved bit for future expansio Data Length Cod Data to be transferred Cyclic Redundancy Check One recessive bit Report a valid message receipt with a dominant bit One recessive bit Seven recessive bits Three recessive bits
Table 2.3: Extended Format CAN Frame
10
2.2 Survey of Bus Networks with lower priority could not be guaranteed.
2.2.2 FlexRay FlexRay is a deterministic and flexible high-speed communication protocol which enables static and dynamic message transmission at a data rate up to 10 Megabits per second. The basic technological features of FlexRay are outlined in Table 2.4 below and compared to CAN. One of FlexRay key features is the optional single/dual transmission channels, which is demonstrated in Figure 2.3 above. Using a dual channel configuration, these two channels could be implemented either redundant or stand-alone. If implemented stand-alone, the aggregate data rate of the FlexRay bus could reach up to 20 Mbps, that is, twenty times faster than maximum CAN bus data rate. As a result, it is suited to be employed as a vehicle-wide network backbone, working in conjunction with already well-established systems, such as CAN and MOST. It can drive down the overall system costs by reducing the number of parallel CAN networks used to solve bandwidth bottlenecks [9]. Safe-relevant messages are sent redundantly on both channels to ensure that the messages will be received even if one channel fails. A concrete use case of FlexRay bus with dual channels is demonstrated in Figure 2.4 during a communication cycle.
ECU
ECU
...
ECU
ECU
Bus Channel A Bus Channel B
FlexRay Figure 2.3: FlexRay Network with dual Channels
11
12
Channel 2
Channel 1
1
1
A1
A1
Channel 1 Channel 2
B1
2
2
A
C1
3
C1
3
C
4
D1
4
5 A2
A2
5
S tatic s egm ent
B
E
E1
6
E1
6
7
7 D3
C om m unic ation c y c le
D
8
C2
8 9
D2
10
C2
9
A3
E2
12
D y nam ic s egm ent
t
t
2 Related Work
Figure 2.4: Dual-channel FlexRay during a communication cycle
2.2 Survey of Bus Networks Feature Baud Rate (max.) Transmission Channel Network Topology Connected nodes (max.) Communication Message ID Data Length Code (DLC) Bus Access Data Throughput Cycle Time (max.)
CAN 1 Mbps single linear Depends on delay time of the bus (e.g. 16 nodes at 500 Kbps) event-triggered 11 bits (standard) 29 bits (extended) 8 bytes
FlexRay 10 Mbps single / dual linear / star or hybrid Linear bus topology: 22 nodes Star topology: 22/64 nodes Hybrid: 64 nodes time- and event-triggered 11 bits
CSMA Depends on CAN ID and bus load Depends on CAN ID and bus load
TDMA Depends on the number of reserved slots Predetermined offline
254 bytes
Table 2.4: Comparison between CAN and FlexRay
In this use case, five ECU nodes are connected over the bus, Node A, B, C, D and E. Among them Nodes A, C and E send data redundantly on both channels for messages A1, C1, A2, E1 and C2, and non-redundantly on only one channel for the messages B1, D1, D3, D2, A3 and E2. Nodes B and D are only designed for one-channel operation and thus transmit their data without redundancy. To attain a high transmission speed the use of active star topology is required. An active star consists of a node containing multiple bus drivers linked by a high speed back plane. Although FlexRay can also be configured in linear bus topology, its transmission speed would stay in the same region as CAN protocol. In the FlexRay protocol, media access control is based on a recurring communication cycle. Each cycle consists of a mandatory static segment for transmitting timecritical messages, an optional dynamic segment for transmitting less critical messages, and two protocol segments called symbol window (optional) and network idle time (mandatory). It provides determinism and flexibility by using a combination of timetriggered communication in the static segment and event-triggered communication in
13
2 Related Work the dynamic segment. Both the static and dynamic segments are composed of multiple time slots. In a static segment, the number of time slots is fixed, and each slot has a constant and equal length, regardless of whether or not static messages are sent over the bus in that cycle. In the dynamic segment, a time slot is further subdivided into smaller time quanta, namely, minislots. Thus, in a dynamic segment, the number of minislots is fixed, and each minislot has a constant and equal length. In contrast, the length of a time slot is variable and is determined at runtime. If no message is to be sent in a certain time slot, the slot length is equal to the length of one minislot, otherwise, the slot length is equal to the length of multiple minislots allocated for that message transmission on demand. Based on the static slots, a static segment utilizes TDMA, a time division multiplexing scheme, to access the bus. In combination with a static schedule, which is specified offline at system design phase, the FlexRay static data transmission is deterministic with bounded latency and small latency jitter. As opposed to the static segment, a dynamic segment utilized a prioritized-based scheme in a way similar to CAN bus, which allows each node to use the full bandwidth for event driven communication. The above mentioned characteristics of communication cycle, namely the communication cycle duration, the number of static slots for a static segment and their duration, the number of mini slots for a dynamic segment and their duration, should be specified as FlexRay configuration parameters offline during the system design phase and stored statically in each ECU. ECUs that require greater bandwidth and shorter update intervals for message transmission are assigned more slots than those that require less bandwidth and longer up-date intervals. For both the static and dynamic segment, only one ECU node is allowed to send over the bus, and that is the one which holds the message with the frame identifier equal to the current value of the slot counter. There are two slot counters corresponding to the static and dynamic segments respectively. The assignment of frame
14
2.2 Survey of Bus Networks identifiers to nodes is static and decided offline during the design phase. Each node that sends messages has one or moer static and dynamic slots associated to it. The bus conflicts are solved by allocating offline one slot to at most one node, thus making it impossible for two nodes to send during the same static or dynamic slot. At the beginning of each communication cycle, the communication controller of an ECU node resets the slot and minislot counter. At the beginning of each communication slot, the controller verifies if there are messages ready for transmission and packs them into frames. Two different approaches for static and dynamic messages to decide which messages are transmitted during the allocated slots. For static messages, a schedule table with transmission times are used. When the time comes for an static message to be transmitted, the microcontroller will place that message in its associated static buffer. For dynamic messages, messages selected and packed into dynamic frames will be transmitted during the dynamic segment of the bus cycle only if there is enough time until the end of the dynamic segment. It is achieved by comparing if, in the moment the dynamic counter reaches the value of the frame identifier for that message, the value of the minislot counter is smaller than the number of minislots required for completing that message transmission. Since an ECU node is allowed to send different messages using the same dynamic frame identifier, if two or more messages with the same frame identifier are ready to be sent in the same bus cycle, a priority scheme is used to decide which message will be sent first. Messages with the same frame identifier will be placed in a local output queue ordered based on their priorities. The message from the head of the priority queue is sent in the current bus cycle. A FlexRay frame format without bit-stuffing is represented in Figure 2.5 above. The frame consists of three segments, namely the header segment, the payload segment and the trailer segment. The frame format of FlexRay is explained briefly in Table 2.5 below. Noted that the frame payload of FlexRay could vary from 2 bytes to 254 bytes,
15
2 Related Work
5 Bytes Header
11 bit Message ID 5 bits
11 bits
Payload Length
0 ... 254 Bytes Payload
Header CRC Cycle Count
7 bits
11 bits
Data 0 to 254 Byte
6 bits
3 Bytes Trailer
CRC 24 bits
Reserved Bit Payload Preamble Indicator Bit Null Frame Indicator Bit Sync Frame Indicator Bit Startup Frame Indicator Bit
Figure 2.5: FlexRay Frame Format
Field Reserved bit Payload preamble indicator Null frame indicator Sync frame indicator Startup frame indicator Frame ID Payload length Header CRC Cycle count Payload Trailer CRC
Length 1 bit 1 bit 1 bit
Purpose Reserved for future protocol use Indicate an optional vector contained in the payload or not Indicate the frame is a null frame or not
1 bit
Indicate the frame is a sync frame or not
1 bit
Indicate the frame is a startup frame or not Defines the slot to transmit for the frame Indicate the size of the payload Cyclic Redundancy Check Code Time for frame transmission First two bytes for message ID Cyclic Redundancy Check Code
11 bits 7 bits 11 bits 6 bits 0-254 bytes 24 bits
Table 2.5: Overview of the FlexRay Frame Format
16
2.2 Survey of Bus Networks whereas the frame payload of CAN is limited to 8 bytes. The payload size is encoded in this field by setting it to the number of payload data bytes divided by two. It is fixed and identical for all frames set in the static segment of a communication cycle, however, it may be different for different frames in the dynamic segment. For frames transmitted in the dynamic segment, the message ID in given in the first two bytes of the payload data. FlexRay support fault-tolerance distributed clock synchronization for a global time base across all ECUs in the network. It is executed autonomously by the protocol state machine without interaction with the host processor in each ECU. Therefore it could continue to drive communication cycles even if an ECU fails in the network, and keep the schedule of all ECUs within a tight, predefined precision window. Compared to CAN, FlexRay has a higher synchronization overhead and slot allocation complexity. On the other hand, greater flexibility and collision free communication are offered in return, to meet the challenges of growing safety-relevant requirements in the automobile.
2.2.3 MOST (Media Oriented System Transport) MOST (Media Oriented System Transport) is a serial communication system intended for interconnecting multimedia and infotainment components in vehicles at bit rates far higher than other existing bus-based networking systems. Its transmission speed is up to 24.8 Mbps in synchronous and 14.4 Mbps in asynchronous transmission mode. As a high-speed function oriented network, MOST defines mechanisms for sending streaming data and packet-based data, and provides a complete application framework to control interaction between devices in a clearly structured way. As shown in Figure 2.6, a MOST network often employs a ring topology, but star configurations and double rings for critical applications are possible and may include up to 64 devices or nodes. The synchronization of the network is achieved by defining a Timing Master, which provides the system clock with a continuous data signal. All other devices or nodes, namely the Timing Slaves, synchronize their operation to
17
2 Related Work
ECU ECU
ECU
Ring ECU
ECU
Figure 2.6: MOST Network in Ring this base signal. Within the synchronous base data signal, the content of multiple streaming connections and control data are transported. MOST provides three types of data transport mechanisms, namely control channel, streaming data and packet data channel. On the control channel, data packets for control messages are transported to specific addresses. It is generally specified for event-oriented transmissions at low bandwidth and short packet length. In contrast to the control channel, the packet data channel is specified for transmissions requiring high bandwidth in a burst-like manner. It is mainly used for transmitting data with large block size. Both of the control channels are secured by a CRC and have an acknowledgement mechanism with automatic retry. Streaming data connections are employed for continuous data streams that demand high bandwidth and require time-synchronized transmission. The control channel is used to initiate the streaming data connection between sender and receiver. A connection manager is responsible for all requests for establishing connections, which administers the streaming resources in a central manner. The bandwidth allocated for the streaming data connections is always available and reserved for the dedicated stream so there are no interruptions, collisions, or delays in the transport of the data stream. It makes the MOST extremely suitable for high quality of service and efficient transport of audio and video.
18
2.3 Pre-existing frameworks for generic communication 1 Block = 16 Frames
1 Frame = 512 Bits
H eader 1 Byte
D ata F ield 60 Byte Synchronous Asynchronous
C ontrol D ata 2 Byte
T railer 1 Byte
Boundary Descriptor Synchronous: 24 ... 60 Byte Asynchronous: 36 ... 0 Byte
Figure 2.7: MOST Communication
For control data transport tasks and network management, the organization of data transfer in blocks of frames is required. 16 frames are combined in one block, each frame consists of 512 bits. The organization of a data transfer according to MOST specification Rev 3.0 is shown in Figure 2.7. An overview on the content of these 512 bits is outlined in Table 2.6. Since the transport mechanisms provided by the MOST network differ significantly from CAN and FlexRay, and MOST is such a complicated and comprehensive network, in this project, design and implementation efforts are given merely to the CAN and FlexRay, nevertheless, incorporating MOST into the framework is possible at anytime.
2.3 Pre-existing frameworks for generic communication Multiple frameworks in the area of generic communication over bus systems are present. The most interesting ones are done by GreenBus and OSSS.
19
2 Related Work Name Preamble
Bits 4
Boundary descriptor Synchronous or Asychronous data Control frame Frame control Parity
Discription Synchronize the MOST core and its internal functions of the bit stream 4 Marks the number of 4 byte blocks of data used for sync data in the data block 0...480 Sync data bytes limited to 60 bytes in one frame 16 Asynchronous data bytes limited to 48 bytes in one frame 7 Frame control and status bits 1 Error detection
Table 2.6: MOST Frame Architecture
2.3.1 GreenBus GreenBus is an open-source TLM fabric based on SystemC. It aims to build simulation models for various bus and communication architecture exploration by enabling interoperation between models of different levels of abstraction and models with different interfaces. These simulation models could be configured by simply making changes to a configuration file. GreenBus fabric is composed of three basic parts, that is, a generic protocol, an adaptation layer and a communication router. The generic protocol is used as a base for abstract channel and phase basic communication architecture simulation model development. This includes both the representation of the data that is transported across the channel and the modelling of protocol phases and their synchronization with the SystemC simulation time. The adaptation layer enables users to define their own bus independent API. This provides the possibility to connect heterogeneous IPs independent of their interfaces. The communication router is bus and user API independent. The router takes the application-specific protocol definition and provides a well implemented fast communication router which works at several abstraction levels. These three approaches take the advantage of IP reuse, as the user API is independent of the bus fabric. A layered approach is taken in GreenBus that decouples a higher level communi-
20
2.3 Pre-existing frameworks for generic communication cation interface, denoted as user interface, from the underlying low-level transport interface, namely the generic protocol interface. The user interface is developed to enable various IPs attachable to a GreenBus interconnect independent of its interface and protocol. The generic protocol interface is developed to make the bus protocol exchangeable while user code remains unchanged. GreenBus supports for both untimed performance and timed architecture simulation with one model. Separate blocking and nonblocking transport interfaces are provided for fast untimed simulation and for accurate timed simulation respectively. The transaction performed by GreenBus based on an RTL communication architecture model, which is simulated as a sequence of protocol phases in order to get a more abstract yet accurate enough communication architecture. Hereby a protocol phase data representation and transport mechanism based on SystemC is developed for modelling various protocols. Since GreenBus is specifically dedicated for system-on-chip buses, it deals with the message transmission based on a request-acknowledge scheme, in which a sender firstly submits a request to a receiver, the receiver processes the request and returns an acknowledgement in response. The sender starts to transmit the message only after receiving the acknowledgement from the receiver. This kind of message transmission is suitable for one-to-one mapping but not for multicast and broadcast. Moreover, to perform this request-acknowledge scheme the source and destination address for the message transmission is necessary. However, the communication performed in the common automotive networks, such as CAN and FlexRay, there is no addressing of source and destination nodes in the conventional sense, instead, prioritized messages are transmitted broadcast to all nodes over the bus. Based on the identifier of the received message, each node decides whether it should process the message or not. In addition, considering the difference in respect of the simulation environment and communication protocols adopted for the network, GreenBus is not an ideal framework for the in-vehicle network modelling.
21
2 Related Work
2.3.2 OSSS In addition to Green Bus, the framework OSSS also provides a suite of methodology supporting for embedded communication simulations. OSSS is a library for synthesisable system level model based on SystemC. It aims to enable HW/SW communication modelling with synthesizable channels. OSSS supports a two-layered channel model. Internally, a set of sc signals is used, which is equivalent to RTL wires and therefore synthesizable. An application layer provides more abstract convenience methods. For bus modelling a predefined read/write interface is proposed. A protocol library contains different implementation of these interface methods. Data transport and arbitration in OSSS is performed at the RTL level of abstraction. Thus, bus simulation is cycle accurate. One of the outstanding feature of the OSSS library is that it serves as a synthesisable extension to the SystemC hardware description language. To describe a complete HW/SW system, the behaviour of the software part of the system is modelled by using software tasks based on C/C++ code, the HW/SW communication is modelled by using method calls to shared objects. To enable the synthesis of HW/SW design, OSSS extends synthesisable subset for the description of certain architectural building blocks like processors, memories, buses, channels and object sockets. The key disadvantage of the OSSS library is the complexity of its APIs. One must spend a lot of time in learning to use this framework. Thus, the intended reduction in overall development time may not be achieved, for the simulation performance achieved with this approach is hardly better than with pure RTL models.
22
3 Design and Implementation The generic interconnect infrastructure, designed and built in particular for the invehicle network simulation in this project, is described in this chapter. The design concepts and strategies are presented based on the recherch¨ introduced in Chapter 2. The established model is explained in aspects of system structure and the incorporated functionality in detail. Study is given on how they could be in place to meet the bus specifications and fulfil the communication mechanisms.
3.1 Design Concepts Two basic concepts are applied throughout the system design. One is the modelling at system level, the other is the generic communication over bus system. Modelling at system level takes the advantage of reduced system complexity and increased system comprehensibility at a high abstraction level. The subsequent simulation performed to detect the design bottlenecks, ahead of the hardware implementation proceeds, allows for exploring and validating design alternatives at an early design phase, which improves the design productivity significantly [10]. For an effective system level modelling, SystemC is used in this project. Using the interface classes provided by SystemC, communication mechanisms among modules are modelled in channels and presented to modules via ports, while the transaction requests take place by calling interface functions of these channel models, which encapsulate low-level details of the information exchange. A generic communication over bus system could be achieved by model interoperation of the bus fabrics. It means that a port-to-port binding is configurable to
23
3 Design and Implementation represent any bus and accessible via the channel interface. Thus this modelling adaptability should be obtained with as little overhead as possible. And it focuses in this project mainly on the areas aimed to facilitate architectural exploration and timing schedulable evaluation performed in the subsequent simulation. As a result, it enables cycle count accurate timing estimations along with a variety of system configurations. The configurable parameters required for specifying the system architecture and communicating behaviours vary from protocol to protocol. The approach made in this project is to list all available configuration parameters out with given default value adhering to the bus specification documents: CAN Specification 2.0A and 2.0B provided by Bosch and FlexRay 2.1A by FlexRay Consortium. Flexibility is provided for system designer to set these parameters to the desired value at the system design phase. The intent is to maintain the implementation consistency and lower the simulation overhead by mapping the design requirements onto the generic bus fabrics. The timing estimation for transmission delay is performed by providing a communication mechanism to transmit timing information together with transfer data from message initiator to target. The variety of system configurations for architectural exploration is achieved by providing a list of configuration parameters and channel interfaces, which could be selectively overridden or modified to obtain the desired architectural specifications. To provide an efficient communication mechanism, several issues are confronted, which are listed as followings along with a brief explanation of the strategies adopted to solve them in this project.
3.1.1 Transmission Routine A communication system is composed of various message producers and consumers, which are interconnected via a bus fabric. In this project, ECU nodes are both message producers and consumers. Figure 3.1 below shows a simple use case that a message producer communicates with a message consumer via the bus. To improve model interoperation of the bus fabrics, the communication mechanisms
24
3.1 Design Concepts E C U N ode A
E C U N ode B
P roduc er
C ons um er EC U In te rfa ce
initiatorP ort
targetP ort
Bus C hannel In te rfa ce
B us
B u sP ro to co l C la ss
Figure 3.1: Simple Bus Use Case
among ECUs are modelled in channels inheriting from a unique virtual channel interface, namely the bus channel interface. This channel interface is an underlying low-level transport interface, which provides the access functions for the bus channel dealing with data transfer. As a super-class it is pure virtual and specifies the signature of each member function only. As in Figure 3.2 depicted, a set of bus protocol classes is derived as sub-classes from this channel interface. In every bus protocol class, the interface functions are implemented overridden adhering to the specifications of the desired protocol. The communication protocol is mapped onto the bus structure by choosing the appropriate protocol class for the bus instantiation. In other words, the bus component could be exchanged by simply changing the bus protocol class without impact on other system components. Similar to the bus channel interface, an ECU interface defines the access functions for the ECU. A message producer access the bus channel via a port using the bus channel interface, while the bus forward the message to the message consumer via a port using the ECU interface.
25
3 Design and Implementation sc_interface
BusInterface {virtual}
+ send() +receive()
CAN
FlexRay
MOST
+ send()
+ send()
+ send()
+receive()
+receive()
+receive()
Figure 3.2: Bus Protocol Classes
3.1.2 Data Flow Figure 3.3 below shows how the communication is handled considering a use case that only one ECU is trying to send while multiple ECUs are interconnected over the bus. Noted that router is not necessary for message transmission due to the broadcast feature of the automotive network. If any ECU microcontroller has data to be transferred, it passes them to the frame maker firstly, where these data are wrapped as payload together with other frame information into a message frame. Since no other competitor exists, the frame is sent broadcast over the bus so long as it is ready. All ECU nodes on the bus will receive this message frame. The incoming frame data are intercepted by an acceptance filter, where the message identifier and payload are stripped out and a filtering procedure is performed. Only the frame destined for this ECU will be handed over to the microcontroller by being informed of an interrupt. In this use case, for example, a message is to be sent from ECU node 2 to ECU
26
3.1 Design Concepts Node 1 (Consumer)
Node 2 (Producer)
Node 3 (Consumer)
Node 4 (Consumer)
M ic ro c ontroller
M ic roc ontroller
M ic roc ontroller
M ic roc ontroller
F ram e
F ilter
F ram e
F ilter
F ram e
F ilter
F ram e
F ilter
BusProtocol C lass
Figure 3.3: Data Flow in a Bus Use Case
node 1 and ECU node 4. In this communication mechanism, ECU node 2 is a message producer, in other words, it is an initiator node. ECU node 1, 2 and 4 are message consumers, among them only ECU 1 and 4 are target nodes. The frame data given by the microcontroller in ECU node 2 are received by all the four ECU nodes on the bus but could only arrive in the microcontroller in ECU node 1 and 4 eventually. If a message is ready to be transferred, the frame payload is present in the ECU memory somewhere. It could be imagined as a succession of memory cells, and the size of each cell is one byte (8 bits). These single-byte memory cells are numbered in a consecutive way, so as, within any block of memory, every cell has the same number as the previous one plus one. That is to say, the payload data could be specified by the base address plus the data length. Message identifier is another essential element of the frame data besides payload, for it is indispensable for the bus arbitration procedure and the acceptance filtering procedure. In addition, to obtain the timing of data transfer efficiently, the timing information stamped at message sending and receiving are taken as essential elements of the frame data. To simplify the transfer data manipulation, the data structure to be transferred
27
3 Design and Implementation is predefined fixed as a composite data type in this project, which includes the five items mentioned above at present, and it is extensible on demand. Reading and writing data from memory is one of the most basic procedures during data transfer. Since data copying is a time-intensive procedure, to speed up the simulation, the data to be transferred are passed by pointer instead of passed by value throughout the transmission routine. It means, instead of the frame data themselves, the pointer of the frame data are transferred to the target ECU, and the target ECU could refer to the received frame data using the pointer. This results in a situation as if the memory is shared between the initiator and the target ECUs.
3.1.3 Control Flow For a bus system that allows two or more ECU nodes start sending messages simultaneously, an arbitration procedure is extended in the bus fabric, which intents to fix how and when an ECU is granted to gain the access to bus. For event-triggered messages in both CAN and FlexRay, bus arbitration is based on the message priority. Since a message is identified by its unique priority, the arbitration procedure is implemented no other than sorting the messages to be transferred according to message identifiers plus granting the one with the highest priority, that is, the lowest message identifier to obtain the bus access. Figure 3.4 above demonstrates how the communication is handled considering a use case that multiple ECU nodes are connected over the bus and communicate with each other using event-triggered messages. Assuming that two nodes, ECU node 1 and ECU node 2, are trying to transmit messages at the same time, and the message sent by ECU 1 possesses a smaller message identifier, that is, a higher priority, than the message sent by ECU 2. Firstly, ECU 1 and ECU 2 send requests for access to the bus. The bus forwards the requests to the arbiter, in which these requests are sorted in a queue according to the message priority and waiting there for the arbitration procedure. The arbitration is performed once, every time the arbiter is activated. And it grants one ECU to access the bus, the ECU with the highest priority currently wins the arbitration. In
28
re ce ive M e ssa g e
n o tifyR e ce ive
n o tifyR e ce ive
re q u e stB u sA cce ss
se n d M e ssa g e
ECU 1
B us
g ra n tB u sA ccess
g ra n tB u sA ccess
in se rtQ u e u e
in se rtQ u e u e
A rb itra tio n
n o tifyR e ce ive
n o tifyR e ce ive
se n d M e ssa g e
ECU 2
n o tifyR e ce ive
n o tifyR e ce ive
re q u e stB u sA cce ss
A rb itra tio n
A rbiter
ECU n
n o tifyR e ce ive
...
re ce ive M e ssa g e
n o tifyR e ce ive
re ce ive M e ssa g e
ECU 3
3.1 Design Concepts
Figure 3.4: Control Flow in a Bus Use Case
29
3 Design and Implementation this use case, it is the ECU node 1. Thereafter ECU 1 transmits its message broadcast to all nodes over the bus. The acceptance filter in each ECU intercepts the received message and starts to check whether this message is concerned or not. During this filtering procedure, only the filter in the target node, in this use case the ECU node 3, would let the message pass and forwards it to the microcontroller, whereas all the other nodes reject and this message and simply discard it. For the message which is ready to be transferred in ECU node 2, the access to bus would be granted next time when the arbitrator is activated, so long as no other message with a higher priority is present in the arbitration queue. It should be noted herein that once an ECU starts to transmit a message, the transmission is uninterruptible, even if a message with a higher priority is trying to access the bus. This specification is also referred to as non-preemptive from perspective of schedule algorithm. This specification is achieved by employing a mutual-exclusion lock, namely sc mutex, during the performance of the send/receive mechanism caused by data transfer over the bus fabric. The bus is locked so long as the transmission begins and unlocked when it is completed.
3.1.4 Design trade-off Additional restrictions and assumptions are applied to the design to reduce the system complexity on the one hand and improve the simulation performance on the other hand. Developing a model with full specifications provided by a certain communication network could achieve an accurate simulation performance of this network, thus at the cost of high simulation overhead and lower reuse of model components. To achieve a higher operability and speed up the simulation, a compromise must be found. One of the restrictions made in this project is that no split transaction is performed during the transmission. For a message contains the payload data, whose length exceeds the maximal payload length defined by the applied protocol, this message should
30
3.2 System Architecture and Functionality be split into multiple frame sharing the same header and trailer and transmitted one after another. In this project, such a mechanism would not be handled by restrict the available payload length allocated to ECUs always under the maximal payload length. For example, the payload data allocated to a CAN node automatically is configured to be never bigger than eight bytes. The other is that no message validation is performed during the message acceptance procedure with the assumption that all transaction data would be accepted correctly, therefore no error checking, error signalling or fault confinement is necessary. Furthermore, the memory capacity is taken as infinite large, so that the transfer data would never be overwritten to ensure a safe read/write data mechanism. The last but not least is the problem of network synchronization, which involves the clock drift and many other physical constraints due to the characteristics of the electronic unit. Since this problem is more low-level hardware relevant, it would not be taken into consideration in this simulation model.
3.2 System Architecture and Functionality In order to validate the design concepts and strategies suggested for implementing the bus fabric, the entire system is constructed in this project, including the basic part of the bus fabric, the arbitrator, the ECU node connected on the bus, and a component called Stimulus, which is responsible for the system initialization. An overview of the system architecture is represented in Figure 3.5 below.
3.2.1 Bus The system component Bus is the basic part of the bus fabric, namely a bus trunk, which is specified as a hierarchical channel and allows for interconnecting an unlimited number of ECU nodes. It implements the bus if interface, which defines two access functions for the channel request() and release(). This is depicted in Figure 3.6. The function request() could be invoked by the system component ECU. The re-
31
3 Design and Implementation
S tim ulus
ECU 1
ECU 2
ECU 3
...
ECU n
B us
A rbiter
Figure 3.5: System Architecture without the Scheduler
sc_interface
bus_if {virtual}
sc_channel
sc_port
bus
+ arbiter + ecua
- ecuQuant : int + mutex + request() : void
+ request() : void
+ release() : void
+ release() : void
Figure 3.6: Class Diagram of Bus
32
sc_mutex
3.2 System Architecture and Functionality quest for access to the bus submitted by an ECU node would be handed over to the system component arbiter via this bus trunk. The function release() could be invoked by the system component arbiter, if a bus access is granted. The message to be transferred is transmitted via this bus trunk broadcast to all ECU nodes connected on the bus. The request for access to the bus submitted by an ECU node would be handed over to the system component arbiter via this bus trunk. Once the transmission starts, it is uninterruptable, even if another message with higher priority is ready to be transferred and submits the request for bus access. This specification is achieved by using a sc mutex channel provided by SystemC. A sc mutex channel is used for a mutual-exclusion lock for access to a shared resource. A process could lock and unlock the mutex. In the function release, the mutex is locked at the very beginning of the message transmission and it is unlocked until the transmission is completed. This bus trunk forwards the message broadcasting via a port named ecus. It is a multiport, which enables an arbitrary number of connections to the port and it is attached to the ecu if, which is the interface of the system component ECU.
3.2.2 Arbiter The system component Arbiter acts as an arbitrator for the bus contention. It fixes how and when an ECU node is granted to gain the access to bus and is modelled as a hierarchical channel. It implemented the arbiter if interface, which defines two access functions for the channel transInsert() and access(). This is depicted in Figure 3.7. The arbiter contains a group of buffers, which is reserved for depositing the messages that are ready to be transferred yet not get the permission to access the bus. This buffer block is implemented in the arbiter as a list of objects instantiated from a generic data type called transaction. The data type transaction is a composite data type, which contains all the frame information required to accomplish the communication mechanism. For the case of
33
3 Design and Implementation sc_interface
sc_channel
arbiter_if {virtual}
sc_port
sc_event
arbiter + bus - transID : int - transQueue : list
+ transInsert() : void - iter : list :: iterator + access () : void
- insert_event
+ transInsert() : void + access () : void
Figure 3.7: Class Diagram of Arbiter an event-triggered message, the fundamental frame information includes the payload data, the message identifier and the timing information. It could be handled as the message itself conceptually. For the case of an event-triggered message, the arbitration is priority based, which means that the message with the highest priority, namely the lowest message identifier, will win the arbitration. To accomplish this arbitration procedure efficiently, the list of message will be sorted according to their message identifier ascending. The one standing at the first position of the queue at last is the one with the lowest message identifier, and it is the one who can gain the grant to access the bus. For two messages with the same ID, it is desirable to show preference to the one who arrives earlier. This sorting algorithm is implemented in the function transInsert(). Sorting of the waiting queue should be performed every time once a new request arrives in, in order to ensure an in-time update for the next arbitration procedure. The function access() is registered with the SystemC kernel as a thread process. As a thread process, it is invoked only once, during the simulation initialization phase. It is repeatedly reactivated by implementing with an infinite loop and adopting dynamic sensitivity created by function wait() with a time argument. This thread process
34
3.2 System Architecture and Functionality executes until it meets the wait(), upon here the process is suspend. As the time defined by the time argument passes, the execution of the process resumes from the point of suspension. It makes this thread process behaves just like a clock sensitive process, namely a sc cthread process, more exactly, as if it is triggered by a clock in tact time as same as the time argument given to the function wait(). Every time the function access() is invoked, the first element of the waiting list is taken out and sent broadcast via the bus trunk, that is to say, the message with the highest priority is permitted to access the bus and starts to transmit, a bus arbitration is performed and accomplished. Once the message transmission is completed, this message should be removed from the waiting list. This arbiter hands over the message with the highest priority to the bus truck via a port named bus. This port is attached to the bus if, which is the interface of the system component bus. However, if the waiting list is empty, the function access() will be suspended and wait for an event called insert event. Once the insert event is notified, which indicates a new coming request is successfully inserted into the waiting list, the function access() is resumed and a bus arbitration is performed. The notification of the event insert event is implemented in function transInsert(). It would be notified every time when the sorted insertion of the new coming request is completed and it is performed using the function notify() provided by SystemC. A non-zero time argument is given to the function notify(), which indicates a timed notification, that is to say, this event will be triggered at the time specified by the given time argument. The time specified here is relative to the time of execution of the notify method. Note that in the thread process access(), the function release() provided by the system component Bus is called. And the thread could not return immediately from this function call, because it will be suspended by the function wait() defined in the function release(). According to the protocols CAN and FlexRay, the messages, which lose the bus contention, should be buffered somewhere in the ECU nodes and waiting for the next contention. However, in this simulation model, they are handed over to the arbiter directly and administrated there concentrative. Since the transfer data are passed by point throughout the transmission routine, such a memory management concept
35
3 Design and Implementation incurs no change in respect of the physical memory allocation in essence, whereas the simulation performance could be improved. On the one hand, it saves the mechanism of request submitting, which should be performed by the ECU nodes again and again, so long as the access is not granted. On the other hand, it speeds up the arbitration procedure performed in the arbiter. Instead of sorting all the messages currently ready to be transferred on the bus, only the new coming requests should be inserted into the waiting queue to the appropriate position based on the message priority.
3.2.3 ECU The system component ECU acts both as a message transmitter and a message receiver. It is composed of function blocks behaving as microcontroller, frame maker and acceptance filter. It is specified as a hierarchical channel. It implements the ecu if interface, which defines a set of access functions for the channel, such as transMaker(), notify rcv(),send(), receive(), setIDset() etc. It is depicted in Figure 3.8. The frame maker is responsible for generating the frame data, making them into a cluster as a frame conceptually, and sending them out via the bus trunk. A memory block is available for each ECU node, which is allocated automatically during the instantiation. This memory block is specified with the base address and its size. Data are saved in this memory in bytes, that is to say, each memory cell one byte (8 bits). This memory block is designed for depositing the payload data generated by microcontroller, which is ready to be transferred. Each ECU node possesses a set of message identifiers called idSET. This list outlines the identifier of the messages sent by other ECU nodes, which would contain data or information relevant to its own processing. This list is used as reference for the frame making and the acceptance filtering. The function transMaker() is registered with the SystemC kernel as a thread process. It is responsible for generating the payload data, making them into a frame along with the other frame information, submitting the request for the access to bus and sending them to the arbiter via the bus trunk.
36
3.2 System Architecture and Functionality
sc_interface
ecu_if {virtual}
sc_channel
sc_port
ecu - phyAddr : addrType + bus - mem : dataType* - addr_low : addrType
+ transMaker() : void - addr_high : addrType + notify_rcv() : void - idSET : set* + send() : void - length_max : int + receive() : void - util_threashold : int + setIDset() : void - msg : transaction* + getIDset() : set* + getThreshold() : int + getPHYaddr() : addrType
+ transMaker() : void + notify_rcv() : void + send() : void + receive() : void + setIDset() : void + getIDset() : set* + getThreshold() : int + getPHYaddr() : addrType
Figure 3.8: Class Diagram of ECU
37
3 Design and Implementation Since the payload data of the frame would be used in the simulation only for timing analyse, its content is not important actually whereas its length is relevant for estimating the communication delay. Both the content and the length of the payload data are generated randomly in the function transMaker() using the function rand() provided by C++. Every time the function rand() is called, it would return a random number back. This random number is a pseudo-random integral number in the range 0 to RAND MAX. A sequence of apparently non-related numbers is generated if this function is called for several times. Although the numbers containing in this sequence seem random, this sequence of numbers is always the same, for the generation algorithm adopted by the function rand() using the same seed to generate the series every time. If distinctive sequence of numbers should be generated, the function srand() provided by C++ should be used by specifying the generation seed with a distinct value every time. In the function transMaker(), the function rand() is employed with the intend to compare the simulation results with the same sequence of numbers. It should be noted here that the pseudo modulo operation adopted by the function rand() does not generate a truly uniformly distributed random number in the span, in most cases lower numbers are slightly more likely. This could impact the simulation result slightly. It is possible that the function transMaker() is invoked but no payload data are generated. In other word, it could happen that the microcontroller does not have the willing to send a message when it is triggered. The rate of payload generation is also determined randomly in this project, however in a predetermined range. If the ECU has something to send, it will wrap the payload data along with the other frame information into a data cluster, namely a frame conceptually, and the call the function send() to submit the request for the access to bus. In this project, a frame is defined as a data type called transaction. It is a composite data type which is composed of payload data, message identifier and the timing information. These are the information required for performing the transmission of an event-triggered message. The payload data is specified by its pointer and length and is passed by pointer. The message identifier is allocated by selecting an identifier randomly out
38
3.2 System Architecture and Functionality from the identifier list idSET, This data cluster is passed as argument to the function send(), when it is called. For the transmission of a time-triggered message, the information about the cycle count, in which time interval this message should be transmitted, is required additionally. Because when a time-triggered message should be transmitted is scheduled statically at the system design phase, which ensures a collision-free transmission. To adapt the frame content for such kind of transmission, a new data type should be defined and incorporated into the system using the C++ class Templates. This data type is not yet implemented into the current model, which should be done in future. In the function send(), the current simulation time denoted as the transmission start time, is obtained with the function sc time stamp() provided by the SystemC. This timing information is added to the frame data, and it will be used to calculate the communication delay for the purpose of timing estimation. At this point of time, the frame is ready to be transferred, and the request for the access to bus is submitted by invoking the function request() implemented in the system component Bus via a port named bus, which is attached to the bus if, the interface of the system component Bus. If a message is transmitted broadcast via the bus trunk, the system component Bus will notify the ECU node by calling the function notify rcv(). In the function notify rcv(), acceptance filtering is performed by checking whether the transfer data is relevant or not taking the list idSET as reference. If the identifier of the received message is one the identifier in the list idSET, the message will be delivered to the microcontroller by calling the function receive(). In the function receive(), the current simulation time denoted as the transmission ending time is obtained with the function sc time stamp().This timing information is written down to calculate the communication delay for the purpose of timing estimation. In addition, the payload data of the received frame is tripped out for the further proceeding. Furthermore, the ECU node contains an attribute named phyAddr, defined as a pseudo physical address of the ECU node, which is employed in the trace file for
39
3 Design and Implementation debugging. The other functions contained in the ECU node are implemented simply for the purpose of data encapsulation.
3.2.4 Stimulus The system component Stimulus is implemented specifically for the system initialization. It is implemented as a module and it possesses a multiport named ecus, which is attached to the ecu if and enables the access to all the ECU nodes connecting on the bus. This is depicted in Figure 3.9. The number of message identifiers which is used for message transmission over a certain network should be predetermined statically by the system designer. In practice, one ECU node is only interested in data with certain content. Furthermore, the number of ECU nodes connecting on the bus should be defined before the system simulation starts. These two variables are passed as parameters to the module constructor of the Stimulus. The Stimulus possesses an unique function named initMaker(), which is registered with the SystemC kernel as a thread process. It is executed during the simulation initialization. In the function initMaker(), a set of message identifier is generated randomly. The size of this identifier set is specified by the corresponding constructor parameter mentioned above. Since the message identifier is used to identify a message, it could be used to identify the content of the message in this sense. In other words, the list of message identifiers, which is utilized by the acceptance filtering performed by the ECU, should be defined statically by the system designer. This specification could be achieved by allocating the available identifiers to the ECU nodes randomly. As a communication mechanism is perform among two or more ECU nodes, each message identifier should be relevant at least to two ECU nodes. These sets of relevant message identifiers are distributed via the port ecus to the ECU nodes correspondingly by invoking the function setIDset() implemented in the system component ECU.
40
3.2 System Architecture and Functionality
sc_module
sc_port
stimulus
- idQuant : int - ecuQuant : int
+ ecus
- byPass : vector
+ initMaker() : void
Figure 3.9: Class Diagram of Stimulus
3.2.5 Scheduler A system model, which is composed of the system components Bus, Arbiter, ECU and Stimulus, is capable of handling the transmission of event-triggered messages, which is schedulable based on a prioritized arbitration. However, for the transmission of the time-triggered messages, which is scheduled statically by the system designer offline, an additional system component should be designed and incorporated into the system, namely the Scheduler. An overview of the system architecture with Scheduler is represented in Figure 3.10 below.
3.2.6 Configuration parameters The system model developed in this project is configurable using the parameters defined in a file named typeDef, in which the bus networks are specified as C++ Structs. On-going the bus networks CAN standard and CAN extended have been implemented named CAN BUS STD and CAN BUS XTD respectively. In the near future, the network FlexRay should be added as a strong complement and eventually
41
3 Design and Implementation
S tim ulus
ECU 1
ECU 2
ECU 3
...
ECU n
B us
A rbiter
Scheduler
Figure 3.10: System Architecture with the Scheduler
the network MOST as well. Within the network Structs, the communication relevant characteristics of the network system are specified in the form of data members and function members. New characteristics could be extended in an easy and simple way resulting in the loose internal structure of the Struct. In the Structs CAN BUS STD and CAN BUS XTD, the configuration parameters, which should be predefined statically for the model simulation, are declared and given a value, which could be modified later to adapt for diverse design requirements. Adhering to the specification documents of CAN 2.0 A and CAN 2.0 B, the main difference between these two frame formats is the length of the message identifier used for transmission. For CAN standard it is 11 bits and for CAN extended it is 29 bits. This is defined as the parameter named msgID bound. Furthermore, the different length of message identifier results in the variation of bit-stuffing. For this reason, the parameter called bit LUT should be given different valule in these two Structs as well.
42
3.2 System Architecture and Functionality
Arbitration field
Idle
S O F
0
Identifier
Control field R T R
I D E
R0
0
0
0
D LC
Data field
CRC field
D ata
CRC
A C K
EOF
1 01 1111111
IF S
Idle
111
Figure 3.11: CAN Data Frame In Figure 3.11 the CAN frame format is shown divided by constant parts and variable parts. The variable parts of a transmitted message include the arbitration field, control field, data field and CRC field. As the bit patterns “000000”and “111111”are used to signal errors in CAN protocol, it is essential that these bit patterns are avoided in the variable part of the message. Therefore a bit of the opposite polarity is required to insert by the transmitter whenever 5 bits of the same polarity are to be transferred. This bit-stuffing process should be performed reversed by the receiver. Since stuff bits increase the maximum transmission time of CAN messages, it should be taken into consideration for specifying the frame length. As the simulation model built in this project aiming at facilitating the schedulability analysis, the situation with the worst-case potential bit-stuffing should be chosen for the implementation. The length of a CAN frame without bit-stuffing and with worst-case bit-stuffing are outlined in Table 3.1 and Table 3.2 respectively. It is evident that the frame length in bits differs significantly with and without the bit-stuffing consideration. Nevertheless, Total length of message Payload with 0 bytes Payload with 1 bytes Payload with 2 bytes Payload with 3 bytes Payload with 4 bytes Payload with 5 bytes Payload with 6 bytes Payload with 7 bytes Payload with 8 bytes
11 bits Message ID 29 bits Message ID 47 bits 65 bits 55 bits 73 bits 63 bits 81 bits 71 bits 89 bits 79 bits 97 bits 87 bits 105 bits 95 bits 113 bits 103 bits 121 bits 111 bits 129 bits
Table 3.1: Length of CAN Frame without Bit-Stuffing
43
3 Design and Implementation Total length of message Payload with 0 bytes Payload with 1 bytes Payload with 2 bytes Payload with 3 bytes Payload with 4 bytes Payload with 5 bytes Payload with 6 bytes Payload with 7 bytes Payload with 8 bytes
11 bits Message ID 52 bits 61 bits 71 bits 81 bits 91 bits 101 bits 111 bits 121 bits 131 bits
29 bits Message ID 75 bits 84 bits 94 bits 104 bits 114 bits 124 bits 134 bits 144 bits 154 bits
Table 3.2: Length of CAN Frame with Bit-Stuffing the difference caused by diverse message ID length and payload length is also very immense. As a result, a parameter named bits LUT is declared in both the Structs CAN BUS STD and CAN BUS XTD, implemented as integer vector. The elements of this vector are the frame length with bit-stuffing in bits ordered ascending from payload length 0 bytes to payload length 8 bytes. This should be taken as reference to calculate the message transmission time. Noted that the value stored in the parameter bits LUT differ from each other in the two Structs CAN BUS STD and CAN BUS XTD. The other parameters defined in Structs CAN BUS STD and CAN BUS XTD are all with the same content, since no other vital difference exits between them concerning the message transmission mechanisms. The maximum number of data bytes in the message payload is bound to 8 using the parameter called burst length max. And the bit rate of the bus is defined in unit kbps using the parameter called baud rate. Noted that the bit rate, namely the bus speed, maybe modified to different value in diverse bus system, but in a given system it is uniform and fixed. The bus utilization rate of each ECU is specified using a parameter pair named bus util low and bus util high, which defined the lower bound and the upper bound of the bus utilization rate respectively. The exact utilization rate of the ECU is allocated during the ECU initialization randomly using the function rand() while taking these two parameter as bound limitation.
44
3.2 System Architecture and Functionality For CAN network, the frame data are sent in a sequence way, that is one bit after another, therefore the time for transmitting message over the bus is frame length proportional. The maximum transmission time of a message is equal to the maximum length of the frame in bits multiplied by the transmission time for a single bit. The maximum length of the frame is payload length and protocol dependent. It could be obtained using the parameter bits LUT mentioned above in the associated protocol Struct by specifying the payload length. The transmission time required for a single bit is the reciprocal of the bit rate. For example, if a message with payload length 8 bytes is transmitted over a CAN network with bit rate 500 kpbs using the standard protocol, it would take maximal 262 µs to complete the transmission. Because the maximum frame length for a message with payload length 8 bytes transmitted using the standard CAN protocol is 131 bits with the worst-case bit stuffing. If the CAN network bit rate is 500 kpbs, the time for transmitting a single bit would be 2 µs. Therefore, the total maximum transmission time for the frame would be 262 µs. This calculation procedure is defined in both of the CAN Structs as function member named transDelay(), which requires a mandatory argument, that is, the frame payload length. To calculate the worst-case transmission delay, additional time consuming factors should be taken into consideration. In Figure 3.12 the transmission flow of payload data from the message sender to the message receiver is demonstrated. If an ECU node has the willing to communicate with other ECU nodes over the bus, it will invoke the frame maker to wrap the payload data into a frame and submit the request for bus access. After it gets the grant for bus access from the arbiter, frame data will be sent broadcast to all the ECU nodes on the bus. After the message arrives in the receiver, the acceptance filtering is performed and the payload data are stripped out and forwarded for further proceeding. The latency from the time point request for bus access to the time point transmission over the bus is taken as the time elapses for the bus arbitration procedure. The requests for bus access will be queued in the arbiter and only the one with the highest priority could get the grant for access. This latency varies in a wide range dynamically at run time, for it depends on the number of senders on the network,
45
3 Design and Implementation SD\ORDGGDWD SUHVHQW
SD\ORDGGDWD SUHVHQW DFFHSWDQFH ILOWHULQJ
IUDPHPDNLQJ
UHTXHVWIRU EXVDFFHVV
WUDQVPLVVLRQ RYHUWKHEXV
6HQGHU
0HVVDJH7UDQVPLVVLRQ'HOD\LQWRWDO
Jitter
5HFHLYHU
Figure 3.12: Transmission Delay over CAN which have the willing to send messages at that point of time. Noted that even the message with the highest priority may comprise latency here due to the bus blocking, that is, a lower priority message is just in process of being transmitted and it is not interruptible because CAN is non preemptive scheduled. The latency from the time point payload data present to the time point request of bus access and the latency from the time point acceptance filtering to the time point payload data present are caused by the processes executing within the ECUs. Although the latency exists in practice, it will be taken as if it would be completed immediately without any time elapses, because the simulation model developed in this project focuses merely on the behaviours of the bus fabric. In this simulation model, the physical propagation time from the sender side to the receiver side is not taken into consideration as well, because the time consuming for network controller, transceiver and network route are all in the range of nano second, which are too smaller compared with the time amount needed for the transmission of one bit and could be neglected. Compared to network CAN, FlexRay possesses more complex timing behaviours. The configuration parameters required to be predefined statically and allowed to be modified for the FlexRay network in the design phase are outlined in Table 3.3 below. A brief description and the configurable range of the parameters are given adhering
46
3.2 System Architecture and Functionality to the specification document of FlexRay Version 2.1 Revision A.
47
3 Design and Implementation
Parameter Channel mode
Description Channel used to connect the nodes Sample clock period Sample clock period Macrotick Macrotick duration Microtick Microticks duration Samples per microtick Bit time
Number of samples per microtick Nominal bit time
Cycle time
Length of a communication cycle Idle phase duration within a dynamic slot Minislot duration Static slot duration Number of minislots in the dynamic segment Number of static slots in the static segment Payload length of a static frame Max. payload length for dynamic frames Network idle time
Dynamic slot idle phase Minislot Static slot Number of minslots Number of static slots Payload length static Payload length dynamic max. NIT
Range single/dual 0.0125/0.025/0.05 µs 1-6 µs Samples per microtick x sample clock period [µs] 1/2/4 samples per bit x sample clock period [µs] ≥ 10 µs 0-2 minislots 2-63 macroticks 4-661 macroticks 0-7986 ≥2 0 to max. payload length 0 to max. payload length 2-805 macroticks
Table 3.3: Configuration parameters of FlexRay
48
4 Verification and Evaluation In this chapter multiple approaches are taken to configure the simulation model aiming to validate the system adaptivity and its performance concerning the timing estimation of data transmission. Studies and analyses are given to appraise the results obtained from the set of test scenarios.
4.1 Setup of Testbench To verify the overall system performance, setting up appropriate testbench is the last but not the least step of the complete design process. To test the model developed in this project efficiently, efforts spent on checking and evaluating focus merely on two respects, namely the system interoperability and the timing estimation of communication delay. Test cases are formulated based on schedulability analysis developed for network communication, more exactly, for CAN, because the implementation of system components is still under development, only the part for CAN standard and extend is finished, the part for FlexRay is not yet on-going.
4.1.1 Test Scenario The verification procedure begins with the design of a test scenario covering the architectural and functional properties of the simulation model as comprehensive as possible. The basic concept of this test scenario comes up with the investigations performed in [13], which dedicates to system validation in respects of delay bounds and timeliness of information processing using deterministic performance evaluation
49
4 Verification and Evaluation methods. Based on sets of CAN data provided by Audi, the results obtained in [13] reveal that the delay bounds of message communication grows up with the priority levels proportionally. In other words, the lower the priority the larger is the maximum possible delay in CAN network. Since CAN media access is priority based and performed competitive and non-preemptive, this assumption is adopted into the test scenario to check the arbitration behaviour of the model. To validate the system interoperability, multiple approaches should be taken by varying the values of configuration parameters in the configuration file in the one hand, and modifying the construction of module/channel instances with associated interconnections on the other hand. Table 4.1 below is taken as reference to determine the variable range for the parameters, in which the requirements placed on in-vehicle networks for the BMW 7 Series are summarized. The number of ECUs connected on the individual CAN buses is typically between 2 and 32, and bandwidths vary in the range from 100 to 500 kbps. In the test scenario, for the sake of simplicity, the number of ECUs used in test cases would take the value 4 and 6, the value of the bandwidth would use 125 kbps for the timing behaviour research of low speed CAN bus, and 500 kbps for high speed CAN bus. The number of message IDs is fixed to 15 for all test cases except one as complement, which should be set to the value 10 for the extended timing analysis. Furthermore, the bus utilization rate may be as well of interest to judge simulation performance. The parameter pair (bus util low, bus util high) would take the value (15, 20) and (30, 40) as variant for each ECU node. It is assumed that different delay bounds would be obtained by varying the pa-
No. of ECUs Bandwidth No. of Message IDs Cycle Times
Body 14-30 100 kbps 300 50ms-2s
Chassis 6-10 500 kbps 180 10ms-1s
Powertrain 3-6 500 kbps 36 10ms-10s
Table 4.1: BMW 7 Series Network Requirements [14]
50
4.1 Setup of Testbench rameters mentioned above. Under the circumstance that all the other configurations unchanged but the number of ECU nodes, it is expected that the communication delay bounds should grow up with increased interconnecting nodes. With a lower bandwidth, which means a lower transmission speed, the communication delay bounds should increase correspondingly. Since the number of message IDs indicates the number of different content of messages and the number of priority classes within the communication system as well, it is supposed that increased number of message IDs would give negative impact on the delay bounds, in particular, of the messages with lower priority. Regarding the bus utilization rate for each ECU node, it implies the possibility that an ECU would have the will to transmit. It is logical that a heavy traffic load on the bus leads to an increase in transmission delay. The expected system behaviours in respects of the variations in system configuration and the delay bounds of message transmission within the simulation model are outlined in Table 4.2 below.
4.1.2 Elaboration and Configuration According to the specifications designed in the test scenario, parameters should be configured appropriately in the design phase, for SystemC does not support the dynamic creation of modules. The structure of the system is created during elaboration time and does not change during simulation. Elaboration is defined as the execution of the sc main() function from the start of sc main() to the first invocation of sc start(). During elaboration, the instances of the System Configuration ECU nodes on the bus Bus bandwidth Available message identifiers Bus utilization rate of each ECU
Transmission Delay Bounds Increase as the number grows Increase with lower bandwidth Increase as the number grows Increase with higher utilization rate
Table 4.2: Expected System Behaviours of the Simulation Model
51
4 Verification and Evaluation modules/channels are constructed and the port and channel binding occurs to build up the system hierarchy. To simulate a test case that four ECU nodes communicate with each other over a CAN bus using the CAN standard protocol, for example, four ECU instances should be created in the elaboration, and the generic type of the instances bus, arbiter, ecu and stimuls should be specified with the protocol class CAN BUS STD, namely the protocol CAN standard. If the protocol CAN extend is used for the network communication, then the protocol class CAN BUS XTD should be specified to the generic type correspondingly. Furthermore, the number of ECU nodes and the number of message identifiers are passed as parameter to the channel constructors stimulus and bus respectively. In the configuration file, the bus bandwidth should be specified via the parameter named baud rate and the bus utilization rate via the parameter pair us util low and bus util high. Noted that the exact value of the bus utilization rate is determined dynamic at the runtime using the function rand() provided by SystemC. A text file named trace file is used in this project to trace down the important simulation information for the purpose of debugging and reporting the timing information related for the delay calculation of message transmission. Other simulation information in this trace file could be the execution sequence of the send/receive mechanism with time stamp, the transfer data, the begin and ending time of message transmission, the message identifiers available within this communication system, the set of message IDs used by each ECU for frame making and acceptance filtering, etc. This trace file is implemented as a normal I/O file used the File I/O classes provided by C++.
4.2 Simulation Performance and Results Firstly, a test case implemented the basic concept of the test scenario described previously is elaborated and performed with the specifications outlined in Table 4.3. The message identifiers for the network communication are generated randomly during the simulation time and they are given the value 435, 737, 750, 905, 947, 1037,
52
4.2 Simulation Performance and Results Number of ECU nodes Bus bandwidth Number of message IDs Bus utilization rate per ECU
4 500 kbps 15 30-40
Table 4.3: Configuration Specifications for Test Case 1 1091, 1283, 1554, 1567, 1609, 1842, 1854, 1865, 2037. And the bus load utilization rate for the four ECU nodes are 38%, 39%, 39% and 31% respectively. The worst case delays of message transmission are outlined in Table 4.4 and depicted in Figure 4.1, classified by the message priority. The worst case delay for the message with the highest priority within this CAN network, namely the message with the identifier 415, is 441 µs, whereas the worst case delay for the message with the lowest priority, namely the message with the identifier 2037 is 6228 µs. The results reveal that in the simulation model the lower the priority, the higher the worst case delay. In particular, the situation would be extremely hard for the last several ones, where the upper bound of delay grows significantly. Hence, the basic concept of the test scenario is proved. The other expectation to the simulation model would be different worst case delays for the same message content in varying traffic loads. For this purpose, the next test case involves constructing two CAN networks by applying different bus utilization rate for the ECU nodes. The networks are configured using the specified value outlined in Table 4.5. The message identifiers for the network communication are the same in both CAN networks due to the intrinsic characteristic of the function rand() provided by C++, which is used here for the random generation during the simulation time. The available message identifiers are 50, 153, 443, 731, 832, 1014, 1197, 1232, 1238, 1283, 1463, 1480, 1567, 1605, 1710. The bus load utilization rate for the six ECU nodes in CAN network A are allocated with the value 16%, 18%, 17%, 15%, 16%, 15% respectively, whereas in CAN network B with the value 25%, 25%, 24%, 24%, 25%, 24%. The worst case delays of message transmission for the CAN network A and CAN network B are outlined in Table 4.6 and depicted in Figure 4.1, classified by the
53
4 Verification and Evaluation
Message ID max. Delay [µs] 435 441 737 514 750 687 905 1004 947 612 1037 807 1091 1019 1283 1365 1554 1637 1567 1751 1609 4094 1842 4569 1854 5697 1865 7426 2037 6228 Table 4.4: Worst case delays classified by message priority
8000
max. Delay [μs]
6000
4000
2000
0 435
737
750
905
947
1037 1091 1283 1554 1567 1609 1842 1854 1865 2073
Message ID
Figure 4.1: Worst case delays classified by message priority
54
4.2 Simulation Performance and Results
Configuration Parameter Number of ECU nodes Bus bandwidth Number of message IDs Bus utilization rate per ECU
CAN network A 6 500 kbps 15 15-20
CAN network B 6 500 kbps 15 20-25
Table 4.5: Configuration Specifications for Test Case 2
Message ID max. Delay [µs] max. Delay [µs] in CAN A in CAN B 50 395 607 153 402 387 443 412 851 731 545 851 832 446 605 1014 190 240 1197 297 733 1232 816 793 1238 723 1271 1283 449 1595 1463 1148 2264 1480 593 1993 1567 1399 2919 1605 954 7631 1710 2876 6590 Table 4.6: Comparison of worst case delays with diverse bus utilizations
55
4 Verification and Evaluation
10000
max. Delay [μs]
8000
6000
4000
2000
0 50
153
443
731 832 1014 1197 1232 1238 1283 1463 1480 1567 1605 1710
Message ID m a x. D e la y [μs] in CAN A m a x. D e la y [μs] in CAN B
Figure 4.2: Comparison of worst case delays with diverse bus utilizations
56
4.2 Simulation Performance and Results message priority. The worst case delay for the message with the highest priority in CAN network A is 395 µs, whereas the one in CAN network B is 607 µs. The worst case delay for the message with the lowest priority in CAN network A is 2876 µs, whereas the one in CAN network B is 6590 µs. Comparing the results obtained from the two networks throughout all the priority, it is evident that the network with higher bus utilization rate possesses a larger delay bounds for message transmission. Since the bus utilization rate indicates the possibility that ECU nodes would like to transmit messages, a heavy traffic load on the bus would lead to an increase in transmission delay. Hence, expected system behaviours are achieved. Furthermore, the results in Figure 4.2 reveals that the messages which have a high priority could complete their transmission most of the time even under a high busload, sometimes even far below 900 us. However, the messages with a low priority (high priority number) would almost always miss their deadlines under a high busload. In test case 3, the variation of the configuration bus bandwidth is taken into consideration. For this purpose, two CAN networks are constructed with bandwidth 125 kbps and 500 kbps respectively. The networks specifications are represented in Table 4.7. Noted that all the configuration parameters are the same in both CAN networks except for the bus bandwidth. The worst case delays of message transmission are outlined in Table 4.8 and depicted in Figure 4.3, classified by the message priority. It is no doubt that the bandwidth is the configuration parameter, which would give the greatest impact on the upper delay bounds of message transmission. The last test case is performed to validate the application of bus protocol CAN extended, and compared it with a network used the bus protocol CAN standard in Configuration Parameter Number of ECU nodes Bus bandwidth Number of message IDs Bus utilization rate per ECU
CAN network A 6 125 kbps 15 15-20
CAN network B 6 500 kbps 15 15-20
Table 4.7: Configuration Specifications for Test Case 3
57
4 Verification and Evaluation
Message ID max. Delay [µs] max. Delay [µs] in CAN A in CAN B 50 454 1972 153 576 3991 443 758 6351 731 1318 6820 832 2210 19008 Table 4.8: Parison of worst case delays with diverse bandwidths
20000
max. Delay [μs]
16000
12000
8000
4000
0
50
153
443
731
832
Message ID max . Delay [μs ] in CAN A max . Delay [μs ] in CAN B
Figure 4.3: Comparison of worst case delays with diverse bandwidths
58
4.2 Simulation Performance and Results respect of the message transmission delay bounds. The networks specifications are represented in Table 4.9. Noted that all the configuration parameters are the same in both networks except for the bus protocol class. Adhering to the specification documents CAN 2.0A and 2.0B the message identifier for CAN standard is in the length of 11 bits and the message identifier for CAN extended is in the length of 29 bits. Therefore the maximal range specified for the function rand(), which is responsible for the generation of message identifiers available within the system in the simulation time, are different for the two bus protocol. As a result, the message identifiers used for message transmission differ from each other in these two networks. The message identifiers available for the network CAN standard are 50, 153, 443, 731, 832, 1014, 1197, 1232, 1238, 1283, 1463, 1480, 1567, 1605, 1710. The message identifiers available for the network CAN extended are153, 4827, 7376, 7711, 11478, 15350, 16827, 19264, 19629, 19895, 19912, 20037, 22190, 23811, 24626. The bus load utilization rate for the six ECU nodes in both networks are the same, the value are given as 22%, 17%, 22%, 21%, 19%, 18% respectively. For these message identifiers are generated in the simulation time randomly and automatically, it is impossible to construct these two bus networks with the same message ID set. However, the comparison between the messages with the same priority class in the networks could be performed. The worst case delays of message transmission for the CAN network A and CAN network B are outlined in Table 4.10 and 4.11 respectively. These results are compared and depicted together based on the priority class in Figure 4.4. The results demonstrated in Figure 4.4 reveals that the upper delay bounds of message transmission is larger in the network using CAN extended than the one Configuration Parameter Number of ECU nodes Bus bandwidth Number of message IDs Bus utilization rate per ECU
CAN standard 6 500 kbps 15 15-20
CAN extended 6 500 kbps 15 15-20
Table 4.9: Configuration Specifications for Test Case 4
59
4 Verification and Evaluation
Message ID max. Delay [µs] in CAN standard 50 454 153 388 443 785 731 1050 832 789 1014 752 1197 489 1232 735 1538 856 1583 904 1463 1742 1480 1599 1567 1246 1605 1443 1710 2876 Table 4.10: Worst case delays in the network CAN standard
Message ID max. Delay [µs] in CAN extended 153 640 4827 545 7376 722 7711 1188 11478 908 15350 809 16827 2363 19264 1895 19629 1378 19895 1568 19912 2646 20037 5524 22190 4924 23811 4487 24626 19495 Table 4.11: Worst case delays in the network CAN extended
60
4.2 Simulation Performance and Results
10000
max. Delay [μs]
8000
6000
4000
2000
0 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Priority ma x. D e la y [μs] in CAN A ma x. D e la y [μs] in CAN B
Figure 4.4: Comparison of worst case delays in networks CAN standard and CAN extended
61
4 Verification and Evaluation using CAN standard. The frame overhead caused by the longer message ID could be disaster for the overall system, if the bus traffic is pretty heavy and can not bear for the extra overhead any more.
4.3 Evaluation Although the stimulus for the overall system is purely random and dynamic, the results obtained from the set of test cases demonstrate that the expectations drawn up in the test scenario are all fulfilled by given different setting to the simulation model. Noted that the simulation results could be improved further by running the simulation for a longer time and adopting the average value instead of the worst case value to eliminate the contingent factors out from the results. While performing the diverse test cases, the simulation model shows its advantage in meeting the system design requirements simply by alternating the value of the configuration parameters in the configuration file or modifying the system infrastructure during the elaboration time. As a result, it is applicable for designing and analysing worst-case response time of messages transmitted over CAN and hence determine system schedulability.
62
5 Conclusion This chapter concludes with a summary and indicates the future work with improvement suggestions.
5.1 Summary Based on the survey of the automotive networks CAN and FlexRay, design concepts and strategies are developed in this project for building and verifying in-car communication mechanisms over bus systems. A simple simulation model is implemented, which enables creation and reuse of system components for an effective design and modelling in the early verification and validation. Furthermore, it is extended to include timing properties, which makes it applicable for analysing the worst-case transmission time of messages with certain predefined system specifications. This simulation model is configurable with as little overhead as possible due to the interoperability of its system infrastructure. It facilitates the hierarchical exploration and allows for multiple design approaches to find out the design bottlenecks easily. Combined with its timing properties, it is especially suitable for performing schedulability analysis.
5.2 Future Work The simulation framework is still under development. The simulation model concentrates on-going merely the timing behaviours of protocols and presents the bus
63
5 Conclusion systems only in a unique bus topology. In the future more aspects of the protocol could be taken into consideration and more variations and flexibility should be provided by the bus fabric. In addition, it lacks the support for the failures and collision recovery procedures to handle disturbed messages, which should be improved in the future. Further improvements could be optimizing the component models in respect of timing accuracy and simulation speed.
64
Bibliography [1] System-Level Design and Synthesis of Embedded HW/SW Systems Homepage. http://system-synthesis.org. [2] CAN in Automation (CiA) Homepage. http://www.can-cia.org/. [3] Bit Synchronization on CAN Bus. http://www.dsrminc.com. [4] FlexRay Consortium Homepage. http://www.flexray.com. [5] Fujitsu Microelectronics Technology Homepage. http://www.fujitsu.com. [6] MOST Cooperation Homepage. http://www.mostcooperation.com. [7] SystemC language reference manual (LRM). http://www.systemc.org. [8] Freescale Semiconductor Homepage. www.freescale.com. [9] Synopsys’ Saber simulator. www.synopsys.com. [10] D. C. Black and J. Donovan. SystemC: From The Ground Up. Kluwer Academic Publisher, 2004. [11] K. Etschberger. Controller Area Network. Hanser Verlag, 2002. [12] R. I. Davis, A. Burns. Controller area network schedulability analysis: Refuted, revisited and revised. Real-Time Systems, 35(3):239–272, 2007. [13] S. Virtanen, D. Truscan, S. M¨aa¨tt¨a, T. Westerlund, J. Isoaho, J. Nurmi. Processor Design System-on-Chip Computing for ASICs and FPGAs. Springer Netherlands, 2007. [14] T. Gr¨otker, S. Liao, G. Martin, S. Swan. System Design with SystemC. Springer, 2002.
65
Bibliography [15] U. Klehmet, T.Herpel, K.S.Hielscher. Delay Bounds for CAN Communication in Automotive Applications. Reinhard German.
66
A Used Abbreviations ABS
Anti-lock Braking System
ACK slot
Acknowledgement slot
API
Application Program Interface
CAN
Control AArea Network
CRC
Cyclic Redundancy Check
CSMA
Carrier Sense Multiple Access
DLC
Data Length Code
EOF
End of Frame
IDE
Identifier Extension Bit
Kbps
Kilobits per second
Mbps
MMegabits per second
MOST
Media Oriented Systems Transport
OSI reference model
Open System Interconnection reference model
OSSS
Oldenburg System Synthesis Subset
RTR
Remote Transmission Request
SOF
Start of Frame
67
A Used Abbreviations
TDMA
68
Sime Division Multiple Access
