Design Optimization of Soft Real-Time Applications on FlexRay Platforms

Transcription

1 Institutionen för Datavetenskap Department of Computer and Information Science Master s thesis Design Optimization of Soft Real-Time Applications on FlexRay Platforms by Mahnaz Malekzadeh LIU-IDA/LITH-EX-A 13/034 SE Linköpings universitet SE Linköping, Sweden Linköpings universitet Linköping

2

3 Institutionen för Datavetenskap Department of Computer and Information Science Master s thesis Design Optimization of Soft Real-Time Applications on FlexRay Platforms by Mahnaz Malekzadeh LIU-IDA/LITH-EX-A 13/034 SE Supervisor: Examiner: Dr. SOHEIL SAMII Department of Computer Science and Information Technology at Linköping University Prof. PETRU ELES Department of Computer Science and Information Technology at Linköping University

4 Linköping University Electronic Press Upphovsrätt Detta dokument hålls tillgängligt på Internet eller dess framtida ersättare från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida Copyright The publishers will keep this document online on the Internet or its possible replacement from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: Mahnaz Malekzadeh.

5 Abstract FlexRay is a deterministic communication bus in the automotive context that supports fault-tolerant and high-speed bus system. It operates based on the time-division-multiple-access scheme and allows transmission of eventdriven and time-driven messages between nodes in a system. A FlexRay bus has two periodic segments which form a bus cycle: static segment and dynamic segment. Such a bus system could be used in a wide area of realtime automotive applications with soft and hard timing constraints. Recent research has been focused on the FlexRay static segment. As opposed to the static segment, however, the dynamic one is based on an event-triggered scheme. This scheme is more difficult to be temporally predicted. Nevertheless, the event-triggered paradigm provides more flexibility for further incremental design. The dynamic segment is also suitable for applications with erratic data size. Such advantages motivate for more research on the dynamic segment. In a real-time system, results of the computations have to be ready by a specific instant of time called deadline. However, in a soft real-time application, the result can be used with a degraded Quality of Service even after the deadline has passed while in a hard real-time system, missing a deadline leads to a catastrophe. This thesis aims at optimizing some of the parameters of the FlexRay bus for soft real-time applications. The cost function which helps to assess the solution to the optimization problem is the deadline miss ratio and a solution to our problem consists of two parts: (1) Frame identifiers to messages which are produced at each node. (2) The size of each individual minislot which is one of the FlexRay bus parameters. The optimization is done based on genetic algorithms. To evaluate the proposed approach, several experiments have been conducted based on the FlexRay bus simulator implemented in this thesis. The achieved results show that suitable choice of the parameters which are generated by our optimization engine improves the timing behavior of simulated communicating nodes. iii

6 iv

7 To Mehdi, Oranous and Nasser v

8 Acknowledgements I would like to express my sincerest gratitude to my examiner Prof. Petru Eles for being such a great mentor during my master studies and giving me the opportunity to carry out my thesis on such an interesting topic. I would also like to thank my supervisor Soheil Samii for his constructive comments and advices on this work. Without his support this thesis would not have been possible. I was also fortunate in having great friends at Linköping University. My sincere thanks to them for their companionship through the years of my master studies. My last but not the least gratefulness goes to my family for their endless love, support and encouragement all the way in my life. vi

9 Contents 1 Introduction Real-Time Systems The FlexRay Communication Protocol Motivation Problem Statement Overview of The Approach Thesis Outline Preliminaries Embedded Systems Real-Time Systems Soft Real-Time Systems Hard Real-Time Systems Performance Metrics Deadline Miss Ratio The FlexRay Communication Protocol Heuristic Algorithms Combinatorial Problems Heuristics Genetic Algorithm Related Prior Work Timing analysis and optimization of the dynamic segment in FlexRay Bus access optimization for FlexRay-based Distributed Embedded Systems Genetic-Based Optimizations of the FlexRay Dynamic Segment Summary System Model Platform Model Application Model The Protocol Model vii

10 viii CONTENTS 5 Problem Formulation Motivational Example Constraints and Optimization Objective Simulation Implementation SystemC The FlexRay bus simulator The msggenerator module The CommunicationController module The CommunicationBus module Optimization Approach 41 8 Experiments Experimental Setup Experimental Results Conclusion and Future Work Conclusion Future Work

11 List of Figures 1.1 Distributed Real-Time System A schematic block diagram of a real-time system [7] Platform and application instance FlexRay Bus Cycle Overview of the simulation environment Critical Hard Deadline Essential Hard Deadline Soft Deadline Firm Deadline Comparison of systems A and B Execution time probability density FlexRay communication example FlexRay bus cycle Flowchart of the optimization approach Response time distribution of different assignments of FrameIDs and minislot length Optimization of the DYN segment The logical architecture of FlexRay bus simulator The process flow of the msggenerator module The process flow of the CommunicationController module The process flow of the CommunicationBus module Flowchart of the optimization approach A roulette wheel representing the population members Tunning δ co Optimization progress Achieved improvments Optimization time ix

12 x LIST OF FIGURES

13 List of Tables 5.1 Message properties Bus configuration Timing behavior xi

14 xii LIST OF TABLES

15 Chapter 1 Introduction Embedded systems [12] are information processing systems which are integrated into products ranging from home appliances to automotive, avionics and telecommunication equipment. Many embedded systems must meet real-time constraints due to their coalescent and continual interaction with the environment, operating such as real-time systems [7]. The correctness of a real-time system depends not only on the produced results, but also on the time when the results are available. Consequently, real-time systems are categorized into soft and hard real-time systems [10] in terms of the timing constraints. In a hard real-time system, each task in the system has to finish its execution within a specific time which is called deadline, otherwise a catastrophe will happen. In a soft real-time system, it is preferred that all the tasks meet their deadline. However, the system may survive even if a missed deadline occurs. Automobiles are embedded systems with real-time behavior. Nowadays, they are becoming complex distributed real-time systems. A distributed real-time system [8] consists of hardware and software components (called nodes) which are connected through a real-time communication network. (See Figure 1.1) The communication between nodes could be carried out either statically at predefined instances of time (called time-driven) or dynamically in response to an event (called event-driven). In some protocols such as Time-Triggered Protocol (TTP) [7], [10] message scheduling is performed statically and messages are sent at predetermined moments of time. This approach has no flexibility while it guarantees deterministic timing behavior. On the other hand protocols such as Control Area Network (CAN) [7], [10] are based on dynamic scheduling of the tasks and messages within the system. In this work, the FlexRay [5] communication protocol is targeted. FlexRay is a hybrid communication protocol based on a digital serial bus system designed for advanced automotive applications. It has been proposed by a large consortium of automotive manufacturers and suppliers. FlexRay allows sharing of the bus between both time-triggered and event- 1

16 2 CHAPTER 1. INTRODUCTION Node A Node B Node C Real-Time Communication System Node D Node E Node F Figure 1.1: Distributed Real-Time System triggered messages. The time-triggered component is known as the static segment (ST) and the event-triggered component is called the dynamic segment (DYN). This work deals with timing analysis and optimization of the FlexRay protocol for soft real-time applications. This chapter starts with an introduction to real-time systems and their categories. A description of the FlexRay protocol follows. Then we will discuss the motivation of this work, followed by describing the problem which is addressed in our work. Finally, the chapter ends with an overview of the rest of the thesis. 1.1 Real-Time Systems In a real-time system the correctness of the system operation depends on both the computational results and the instance of time these results are produced. Figure 1.2 shows a schematic block diagram of a real-time system. Sensors in such a system are responsible for acquiring environmental parameters such as temperature, speed and pressure. They also sense the state of the process that is supposed to be controlled. There is also a preloaded software for the task list in Figure 1.2. The role of the trigger generator is to support the mechanism needed for triggering execution of each task. The schedule of the tasks execution can be set either offline as a lookup table or online during execution. The output of the execution is fed to the actuators and display to control the system. In a real-time system, the result of the computations must be ready by a specific instant of time which is called deadline. If these results can be used even after a deadline has passed, it is called a soft deadline. However, the system operates with a degraded Quality of Service (QoS). If missing a deadline may lead to a catastrophe, the deadline will be called a hard deadline and a system with at least one such a deadline is called a hard

17 1.2. THE FLEXRAY COMMUNICATION PROTOCOL 3 environment Controlled process Sensors Job list Clock Trigger generator Actuators Execution Display Operator Figure 1.2: A schematic block diagram of a real-time system [7] real-time system or a safety-critical real-time system. If missing a deadline does not lead to a catastrophe, but the result is useless, the deadline is firm [10]. 1.2 The FlexRay Communication Protocol FlexRay [5] is a deterministic communication bus in the automotive context that supports fault-tolerance and high-speed communication. It was preliminary developed in 1999 by the FlexRay consortium consisting of automotive manufacturers and big suppliers e.g. BMW, DaimlerChrysler, Motorola, Philips. Since then, many other large companies e.g. Bosch, GM, VW, Mazda have joined the consortium [5]. Increasing safety, performance and reliability of data communication between Electronic Control Units (ECU) in a car have become beyond what a Controller Area Network (CAN) bus can provide. Increasing bandwidth requirements demands a next generation of embedded networks. The FlexRay standard is the result of effort to meet these new challenges for future automotive industry products. FlexRay operates based on the Time Division Multiple Access (TDMA) scheme. All nodes within a FlexRay bus are synchronized to the same clock. Each node is assigned to a particular time slot to write data on the bus. The bus in FlexRay consists of two periodic segments which form a bus cycle: static segment (ST) and dynamic segment (DYN). The FlexRay protocol allows transmission of event-driven and time-driven messages between nodes.

18 4 CHAPTER 1. INTRODUCTION N1 N2 τ 11 γ 112 τ 12 γ 212 τ 22 γ 213 τ 21 τ 23 γ 234 τ 24 CC Bus CC Figure 1.3: Platform and application instance The FlexRay protocol with such a bus system could be used in a wide area of real-time automotive applications with soft and hard real-time constraints. Such applications consist of nodes which are connected to the bus by the communication controllers. Each node N is composed of a processing unit (CPU) and the communication controller (CC). There are tasks on each node which are scheduled by a scheduling policy. Communication on the FlexRay bus occurs in periodic cycles. Figure 1.3 shows a system with two nodes which are connected by the communication controller (denoted by CC in the figure) to the bus. A set of tasks shown by circles are executed on each node. This causes messages being generated on each node. The communication between tasks indicated by arrows is performed by transmitting these messages on the bus. This architecture will be explained in detail in Chapter 2, in the FlexRay Section. Each bus cycle has the length of gdcycle and it is composed of a static segment (ST) and a dynamic (DYN) segment.(see Figure 1.4) The length of the ST and DYN segment may differ, but they are fixed over the cycles. The ST segment has a number of slots with the same size gdstaticslot regardless of weather ST messages are sent or not sent in that cycle. The DYN segment length is specified by the number of minislots (gnumberofminislots) which have the same length (gdminislot). Each DYN segment has also a number of DYN slots with possibly different sizes. During a DYN segment if there is no message available to be sent in its allocated DYN slot, the DYN slot length will be equal to the length of one minislot (minimum possible length), otherwise it will be equal to the length of the message frame that stores the

19 1.3. MOTIVATION 5 gdcycle gdcycle Static Segment Dynamic Segment Static Segment Dynamic Segment MS MS MS MS MS MS MS MS MS MS Figure 1.4: FlexRay Bus Cycle message during its transmission in the current DYN slot. Each node is assigned one or more ST and DYN slots and it could send messages during corresponding slots. Allocating slots to each node is decided offline. Only one node is allowed to send in each associated slot in order to avoid bus conflicts. 1.3 Motivation As we mentioned earlier, the FlexRay protocol consists of static and dynamic segments. Recent research has focused more on the static segment which employs a time-division multiple-access (TMDA) scheme with highly predictable timing behavior. The dynamic segment is based on an eventtriggered scheme which is more difficult to be temporally predicted. However, the event-triggered paradigm in the DYN segment leads to more flexibility for any further incremental design, i.e, adding unexpected communicating tasks on the nodes which causes more messages on the FlexRay bus. The characteristics of the DYN segment also make it suitable for applications demanding various data types of erratic sizes. The contribution of this work is timing analysis and optimization of the FlexRay bus system based on two parameters of the dynamic segment, frame identifiers and minislot length. Target applications are soft real-time systems. 1.4 Problem Statement The aim of our work is to set some parameters of the FlexRay DYN segment with the goal of optimizing FlexRay communication bus. The targeted applications are the soft real-time ones. So, the deadline miss ratio (DMR) is chosen as our cost function [8]. This function aids to assess our proposed solution for the problem. A solution to our optimization problem consists of two parts which are: (1) Frame identifiers to messages which are produced at each node. (2) The size of each individual minislot.

20 6 CHAPTER 1. INTRODUCTION Parameters Simulator kernel Application model System architecture DMR Stopping condition Outputs Optimization engine Heuristic algorithms Figure 1.5: Overview of the simulation environment 1.5 Overview of The Approach In this work, the performance metric (DMR) will be calculated by simulation. As it is shown in Figure 1.5, the application model and the system architecture, the problem parameters such as messages period and release time and the stopping condition of the simulator are fed to the simulator kernel. The simulator generates the DMR based on resulted response times of the messages. At the next step, the optimization engine is implemented using heuristic algorithms [16] such as Genetic algorithm [13], [6]. It takes the DMR as the input and outputs the problem parameters provided that the DMR is optimized. A near optimal solution to the parameters such as message frame identifiers, the number of minislots and their size is proposed by the optimization engine. The stopping condition determines after how many iterations, the simulator has to stop. 1.6 Thesis Outline The rest of this thesis is organized as follows: In Chapter 2, we are focused on real-time systems, heuristic algorithms and cost functions in more detail. In this chapter, we also illustrate the operation of the FlexRay protocol and we go through several examples. Chapter 3 is about the related prior work. The problem is formulated in Chapter 4. Then we describe the proposed optimization solution in Chapter 5. Chapter 6 includes the experimental results. The thesis ends with Chapter 7 presenting conclusions and future work in the area of this thesis.

21 Chapter 2 Preliminaries In this chapter, we explain the fundamentals on which this work is built on. Embedded systems, real-time systems, the FlexRay protocol and heuristic algorithms are the main concepts of focus in this chapter. 2.1 Embedded Systems An embedded system [12], [7], [23] is a combination of the programmable components which continuously interacts with its surrounding environment through the sensors and actuators. Although the constitutive components are computer-based systems, they are not perceived as general-purpose computers. Common characteristics of embedded systems are as follows: They must be dependable. Many of such systems are safety-critical [8] which means they are directly connected to the physical environment, therefore their operation has an instantaneous effect on the environment. They must be efficient [12] in terms of energy, run-time, code size, weight and cost. They are connected to the physical environment by the sensors which are responsible for collecting information about the environment and actuators for controlling the environment. Many embedded systems have to perform in real-time and if the data is not available by a specific deadline, the system is said to fail its correct operation. They are reactive systems which means they continuously interact with the environment and operate at a rate imposed by the environment. They are hybrid systems consisting of digital and analog parts. 7

22 8 CHAPTER 2. PRELIMINARIES An embedded system has a dedicated user interface such as pushbuttons and pedal instead of keyboards and mice which are typically used in a general-purpose computer. They are usually dedicated to a specific application. For instance, a processor which runs a control program in a plane will not run a computer game. 2.2 Real-Time Systems The correct operation of a real-time system [8], [7] depends not only on the computational results, but also on the instance of time when these results will be available. This instance of time is called deadline. If missing a deadline causes a catastrophe, the deadline is called hard critical [4]. The Quality of Service (QoS) function goes immediately to minus infinity after missing the deadline (See Figure 2.1). An essential hard deadline causes QoS drops to a negative constant after deadline is missed that indicates a constant penalty (See Figure 2.2). A job with a soft deadline should be completed by its deadline to achieve its best performance. However, in case of missing the deadline the system still performs but at a decreased QoS level as it is shown in Figure 2.3. QoS may reach to zero at some point that shows the result is of no use. However, the situation does not cause any damage. Consequently, a system with firm deadline may have a limited number of missed deadlines, but the result is useless if produced after the deadline. If a job with a firm deadline misses its deadline, it is aborted and its produced result is of no use for the system. The remaining jobs of the firm system have to be completed by their deadlines. QoS drops to zero after the deadline is missed but there is no damage (See Figure 2.4) Soft Real-Time Systems In a soft real-time system [10], it is not necessary that all deadlines are met. A desirable soft real-time system is based on high throughput and small response time. As an example, multimedia systems have to provide the users with services of a guaranteed quality. It is expected that the movie frames are received within a reasonable time. In other words, a timing constraint is imposed for such systems. The users accept occasional violation in timing requirements if they occur rarely and for a short period of time. So the timing constraints for these systems are based on statistics such as average number of lost/delayed frames per unit of time Hard Real-Time Systems Many embedded systems are hard real-time systems [10] with hard deadlines. Let us consider an automatically controlled train. Before getting to a stop

23 2.2. REAL-TIME SYSTEMS 9 QoS 1 0 Deadline Catastrophe Completion time Figure 2.1: Critical Hard Deadline QoS 1 0 Deadline Penalty Completion time Figure 2.2: Essential Hard Deadline

24 10 CHAPTER 2. PRELIMINARIES QoS 1 0 Deadline Completion time Figure 2.3: Soft Deadline QoS 1 0 Deadline No use Completion time Figure 2.4: Firm Deadline

25 2.2. REAL-TIME SYSTEMS 11 Probability Density System A System B Response Time Figure 2.5: Comparison of systems A and B station within its route, the train s sensors have to sense the stop signal and the braking action has to be taken in a specific distance away from the station. The controller of the system computes the time for the train to travel this braking distance. The calculated time is imposed to the tasks which are responsible to activate the brake. This imposed time is called a hard deadline Performance Metrics The performance [8] of a real-time system measures how much the produced result is good relative to the best possible outcome of the system. Let us consider a user typing on a terminal. If the delay between typing a character and seeing it on the screen is negligible, the system performs reasonably as far as the user is concerned. From the user s point of view, in such a case 5 µs or 10 µs delay have no noticeable difference. So both response times ended the same performance from his point of view. The performance perceived by the user degrades as the response time gets longer. Before using a real-time system in the field, it must be carefully designed and validated due to the critical application in which it is used. The validation process consists of methods to evaluate system correctness and characterize its performance. To be more detailed with this concept, let us consider the response time of a task running on systems A and B (See Figure 2.5). System A is more predictable than B due to the shorter interval of response times. However, system B has a better performance in term of the average response time. A good performance metric presents efficient encapsulated information. It also gives a basis to rank candidate controllers for a specific application. It gives an objective optimization criteria in the design phase as well as facts which can be verified. In order to have a correct characterization of performance, it is important which performance measure (also called performance metric) is used. For this reason, a performance metric must briefly be encoded in very few numbers and preferably a single number. It should

26 12 CHAPTER 2. PRELIMINARIES Probability Probability 15% (a) t WCET Time (b) t WCET Time Figure 2.6: Execution time probability density simply indicate what is important in terms of the system performance. As we already said in 2.2.2, hard deadlines are imposed for the safetycritical applications. There are also numerous applications with soft timing constraints. In the case of a hard real-time system, breaking a deadline is not tolerated whereas for a soft system this is allowed to happen depends on the deadline miss ratio and the quality of service [4]. The quality of service (QoS) is related to the system quality that is perceived by the user Deadline Miss Ratio Figure 2.6 a. shows the probability density function of task execution time (ETPDF) [8] running on a cheap processor. Time t is the the deadline imposed to the system. The cheap processor cannot guarantee that the execution of all task instances meet the deadline. So, as it can be seen the deadline is missed every now and then and the Worst Case Execution Time (WCET) exceeds time t. If no missed deadline can be accepted, a faster processor is needed (See Figure 2.6 b.) The performance metric suitable for the soft real-time applications is called Deadline Miss Ratio (DMR) [11] which indicates the long-term percentage of the missed deadlines. While designing such systems a threshold can be imposed to the deadline miss ratio. So the critical tasks within the system are not allowed to exceed this threshold. The deviation from the threshold (denoted by dev τ ) is defined as follows:, DMR > 0, τ hard real time task DMR threshold, DMR > threshold, τ soft real time task 0, DMR 0, τ hard real time task. The arrival time of task τ (denoted by A τ ) is when the task is invoked by the system. However, due to the task offset, its execution may be prolonged.

27 2.3. THE FLEXRAY COMMUNICATION PROTOCOL 13 Host (CPU) Priority queues N 1 low m e N 2 N 3 m a 1 m f m g high m b 2 m c 3 Priority queues m h low m d high Controller-Host Interface (CHI) Communication Controller (CC) Figure 2.7: FlexRay communication example The ready time of task τ is the the earliest time the task might be effectively executed. The finishing time is the moment in which the execution of the task is completed. Let us denote these variables with R τ and F τ respectively. The deadline miss ratio is the probability that the task finishing time exceeds the task deadline. We formally express it as follow: DMR τ = 1 P (F τ deadline τ ) The ready time τ is defined as the maximum of the finishing times of tasks (such as σ) in its predecessor set (Pred(τ)): Finally the finishing time of task τ is R τ = max σ P red(τ) F σ F τ = R τ + E τ + B τ + I τ where E τ is the execution time τ, B τ is the interference due to the lower priority tasks and I τ is the interference due to the higher priority tasks blocking time. 2.3 The FlexRay Communication Protocol In this section, FlexRay [5], [21] operation is described. For this reason, we go through an example which is depicted in Figure 2.7. In this example three nodes are considered, N 1 to N 3 which send messages m a, m b,..., m h through the FlexRay bus. Each node N is composed of a processing unit (CPU) and a communication controller (CC). Here, it is shown how the messages which are generated by the CPU communicate over the FlexRay bus system. The communication in the bus system is performed in periodic cycles (Figure 2.8 shows two cycles of length

28 14 CHAPTER 2. PRELIMINARIES gdcycle gdcycle Static Segment Dynamic Segment Static Segment Dynamic Segment MS MS MSMSMS MSMS m a m g m d m b m c m e m h m f Static slot counter Dynamic slot counter Minislot counter Figure 2.8: FlexRay bus cycle gdcycle). Each bus cycle has the length of gdcycle and it includes two segments called static (ST) and dynamic (DYN) segment. The first one has a time-division-multiple-access (TDMA) [9] policy for message transmission and the second one is based on a flexible TDMA (FTDMA) bus access scheme. The length of these two segments may differ from each other but they are fixed over the bus cycles. The static (ST) and dynamic (DYN) segments consist of slots. The ST segment has a number of static slots gnumberofstaticslots with the same size gdstaticslot regardless of whether ST messages are sent or not sent in that cycle. The DYN segment length is specified by the number of minislots (gnumberofminislots) which have the same length (gdminislot). Each DYN segment has also a number of DYN slots with possibly different sizes. During a DYN segment if there is no message available to be sent in its allocated DYN slot, the DYN slot length will be equal to the length of one minislot (minimum possible length), otherwise it will be equal to the length of the message frame that stores the message during its transmission in the current DYN slot. This can be seen in Figure 2.8, where DYN slot 1 has 6 minislots 1, 2,..., 6 in the first bus cycle at the time when message m g is transmitted. The second DYN slot has the length of one minislot (denoted by MS) since there is no message at node N 2 to be sent on the bus. In each slot, only one node is permitted to send messages on the bus. It is the node with the same frame identifier (FrameID) as the current slot counter value. So it is impossible that two nodes send messages during the same ST or DYN slot. For ST and DYN segments, there are two different counters. Frame identifiers are staticly assigned to nodes at design phase. Each node has one or more ST and/or DYN slots. In Figure 2.7, node N 1 has ST slot 1, DYN slots 1 and 5, N 2 sends

29 2.3. THE FLEXRAY COMMUNICATION PROTOCOL 15 during ST slot 2, DYN slots 2 and 3, and finally N 3 transmits through ST slot 3, DYN slot 4. The controller-host interface (CHI) in each node keeps a buffer. The CPU can write to this buffer and the communication controller (CC) reads from it at the beginning of each slot. These buffers are shown in Figure 2.7. The number of assigned DYN slots to each node N i is denoted by DY NSlots Ni. For instance N 1 in Figure 2.7 has DY NSlots Ni equal to value 2. There are different policies which can be used in order to transmit ST and DYN messages on the bus. For ST messages, it is assumed that the CPU maintains a schedule table with transmission times. The CPU writes each ST message into the CHI buffer when it has to be transmitted. As it can be seen in Figure 2.7, ST message m a from node N 1 has the value 1 in the schedule table which means it could be sent in the first static slot of each bus cycle. On the other hand, for DYN messages, frame identifiers are assigned to them offline. It can be seen that the DYN message m f is assigned to the frame identifier 5. A node can send different messages within the same FrameID based on message priorities denoted by priority mi. This policy helps nodes to decide over each message transmission turn. For example, in Figure 2.7, messages m g and m e have the same FrameID equal to 1 at node N 1. These are placed in a local output queue while ordered by their priority. The message with the highest priority will be sent first to the bus. For instance, message m g will be sent first since it has a higher priority. The same applies to messages m d and m h with the same FrameID 4 on on node N 3. At the beginning of each cycle, all the counters (ST, DYN and minislot counters) are reset by the communication controller. As a specific slot begins, the communication controller checks if there are messages available to be transmitted. In our example, we assume that all messages are generated by the first cycle. ST frames which contain ST messages for transmission will be transmitted during the bus cycle in their associated ST slots based on the schedule table. It is shown in Figure 2.7 that message m a is sent in ST slot 1 in the first bus cycle and messages m b and m c are sent in ST slot 2, 3 in the second bus cycle respectively. This scenario changes in case of a DYN frame. In such a case, the frame will be sent if there is enough time until the end of the dynamic segment. It is done by comparing the current value of the minislot counter with a given value platesttx. The DYN frame is sent if the counter value is smaller than the platesttx value. In other word, platesttx defines the last possible allowed time to transmit a DYN frame on the bus. It is set to be fixed for each node by the designer. It depends on the size of the largest DYN frame that the node will send during run-time. For example in Figure 2.7, message m f is ready before the first bus cycle starts. But there is not enough space left in the DYN segment for its transmission at the time when DYN slot 5 starts. This delays sending m f until the next bus cycle.

30 16 CHAPTER 2. PRELIMINARIES 2.4 Heuristic Algorithms In this section we deal with heuristic algorithms [16] which are used intensively in order to find a near optimal solution for many interesting problems. Most of these problems are optimization problems which are faced in various applications Combinatorial Problems A noticeable research effort has been interested to find optimal solutions to problems which are based on a function of some decision variables. There are also some constraints for the variables. Such problems are formulated as below in which x is a vector of decision variables. f(x), g i (x), h j (x) are general functions: Minimize f(x) subject to g i (x) b i ; i = 1,..., m; h j (x) = c j ; j = 1,..., n. Many types of such problems can be delivered by imposing restrictions on the type of the functions as well as the decision variables. The most wellknown types are obtained by considering the functions of linear type which result in linear programming. There is also another class of such problems which is called combinatorial problem which is based on discrete decision variables. The solution to such a problem is a set or sequence of integers or other discrete objects. Finding optimal solutions to this sort of problems is called combinatorial optimization. Here we exemplify the concept with the 0-1 knapsack problem. We have n items that are supposed to be packed into a knapsack with C capacity units. Each item has the value v i and takes up to c i capacity units. A solution to this problem is a subset I 1,..., n of the items. They have to be packed in the knapsack in order to maximize i I v i such that Heuristics i I c i C The term heuristic derives from the Greek heuriskein which means to find or discover. In the concept of the combinatorial optimization, the word heuristic means seeking good (could be called near optimal) solutions at a reasonable computational cost. It cannot guarantee optimality. It is not able to indicate how close to optimality a found solution is. A simple way for solving a combinatorial problem is to list all possible solutions, evaluate

31 2.4. HEURISTIC ALGORITHMS 17 their objective functions and then choose the best one. But this is not a feasible approach since there are a huge number of solutions to such problems of reasonable sizes. So this complete enumeration method would be quite inefficient to find the solution. To illustrate this problem, let us consider the famous traveling salesman problem (TSP) as follow: A salesman is supposed to find a route that passes N cities just once while minimizing the whole distance he travels. If we consider the distance of all the cities equal regardless of the direction of travel, there are (N - 1)!/2 possible solutions. A computer capable of finding all feasible solutions of a 20-city problem per hour, spends 20 hours to solve a 21-city and 17.5 days for a 22-city problem. A 25-city problem would last nearly 6 centuries. This exponential growth in computation time relative to the size of the problem shows the inefficiency of the complete enumeration approach. Various algorithms have been proposed to find the optimal solution in a more efficient way rather than the complete enumeration methods [16], [6] and [13] Genetic Algorithm Genetic algorithms [6], [13] are heuristics with a stochastic algorithm based on some natural evolution: Genetic inheritance and Darwinian competion for survival. In a genetic algorithm we have individuals (also called genotypes) in a population. They are called strings or chromosomes. Chromosomes consist of units called genes. Every gene controls the inheritance of some characteristics. Genes of a certain character are located in specific places of the individual which are called loci. The gene can be in different states called alleles (gene value). Each chromosome presents a potential solution to a problem and an evolution process searches for an optimal solution through the potential solutions of a certain problem. The evolution program (EP) keeps a population of chromosomes, P(t) = {x t 1, x t 2,..., x t n} for iteration t. Every individual is a potential solution and it is represented by data structure S in the evolution program. Each solution x t i is evaluated in term of its fitness. Further, a new population is generated based on the better fitness values of the old individuals within the next iteration t + 1. During the generation of the new population, some chromosomes are altered by some genetic operators. The mutation operator m i makes small changes in an individual (m i : S S) while the crossover operator c i creates new chromosomes by combining parts of two or more individuals (c i : S... S S). Finally, after a number of iterations the program converges with a high probability that the found solution is a near optimal solution for the problem. You can see the typical structure of such an evolution program in

32 18 CHAPTER 2. PRELIMINARIES Algorithm 1: Procedure evolution program 1 t 0; 2 initialize P(t); 3 evaluate P(t); 4 while!= (termination condition) do 5 t t + 1; 6 select P(t) from P(t - 1); 7 alter P(t); 8 evaluate P(t); 9 end Algorithm 1: To sum up, the genetic algorithm must have the following properties: a genetic representation for potential solutions, an approach to generate an initial population of the potential solutions, an evaluation function which also called a fitness function to rank the solutions based on their fitness value, the genetic operators for chromosomes transformation, determined values for parameters such as population size, probabilities of applying genetic operators which are used by the genetic algorithm, termination condition to stop the optimization or proceed with it.

33 Chapter 3 Related Prior Work In this chapter, we look into a few prior related work. Our focus is mainly on design, scheduling and optimization of the new high bandwidth communication standard for automotive systems called FlexRay. 3.1 Timing analysis and optimization of the dynamic segment in FlexRay As it was mentioned in 2.3, the FlexRay protocol provides periodic frames and messages with time-triggered transmission in the static segment and a priority-based scheduling scheme in the dynamic segment. Zeng et al. in [22] make a timing analysis for frame identifiers (frame IDs) in the FlexRay dynamic segment. They also define a safe upper bound for Worst Case Response Time (WCRT) by heuristics. The calculated WCRT is useful in time-critical applications. Furthermore, they propose an algorithm based on sifting algorithm by Rudell [17] to assign identifiers to frames in the dynamic segment to optimize the design objective. They also make a comparison between their suggested approach and simulated annealing [16]. The authors assume a set of given unique frame IDs. Their algorithm operates by swapping two neighboring frame IDs while keeping other frame IDs unchanged. An initial possible schedule is produced by Audsley s algorithm [1]. The algorithm works iteratively afterwards. At the beginning of each iteration, frames are sorted in a list called SortedList based on a criteria such as the ID order in predecessor iteration or the difference between deadline and response time. From the SortedList, they pick each frame and locate it to its optimum position while keeping the order of the other frames fixed. They do ID assignment for frame m i by first swapping its priority with successors until it gets the lowest priority in the system and then doing the same with its predecessors until it achieves the highest 19

34 20 CHAPTER 3. RELATED PRIOR WORK Algorithm 2: Basic bus configuration 1 gdnumberofstaticslots = max(2, nodes st); 2 gdstaticslot = gdnumberofstaticslots *gdstaticslot; 3 assign one ST slot to each node (round robin); 4 foreach (n = 1,..., 64) do 5 gdcycle = T ss/n; 6 if (gdcycle < µs) then 7 DY N bus = gdcycle - ST bus ; 8 Assign FrameIDs to DYN messages; 9 GlobalSchedulingAlgorithm(); 10 Compute cost function Cost; 11 if (Cost < BestCost) then 12 Save current solution; 13 end 14 end 15 end priority. A position that leads to the best suitable objective function of the system is kept and assigned to the frame. Each iteration causes a single move for each frame. The algorithm stops after two consequent iterations when the objective function value has no improvement. This approach can suffer from trapping in a local optimal solution. So, the authors run the algorithm several times with different initial scheduling. 3.2 Bus access optimization for FlexRay-based Distributed Embedded Systems Pop et al. in [15] do timing analysis for both the static and dynamic segment of FlexRay. For event-triggered messages in the dynamic segment, a worst case response time analysis is performed which enhances predictability of the messages which are transmitted in the dynamic segment. They also present a static cyclic scheduling for time-triggered messages of the static segment. In another work [14] by Pop et al. the FlexRay bus system is optimized for the static and dynamic segment. The parameters which are considered for optimization are: (1) length of a static slot (ST slot), (2) the number of ST slots within the static segment, (3) assignment of ST slots to nodes, (4) lenght of the dynamic segment, (5) assignment of DYN slots to nodes, and (6) assignment of Frame IDs to the DYN messages. For this reason, first they propose a basic bus configuration which is presented in Algorithm 2. The algorithm uses message criticality rating as a basis for assigning frame IDs to DYN messages. Each DYN message takes a unique ID. Message m criticality (denoted by CP m ) is calculated by the difference between its deadline D m and the longest path LP m in the task graph from root to the node that performs transmission of the message. A

35 3.3. GENETIC-BASED OPTIMIZATIONS OF THE FLEXRAY DYNAMIC SEGMENT 21 message with higher criticality receives a lower frame ID. The cost function for evaluating the proposed configuration by the basic algorithm is as follows: f 1 = τ ij max(r ij D ij, 0), if f 1 > 0 Cost = f 2 = τ ij max(r ij D ij ), if f 1 = 0 where R ij and D ij are worst case response times and deadlines of all system s tasks respectively. In case of a missed deadline, the function is positive and it is negative if all the tasks are completed by their deadlines. The GlobalSchedulingAlgorithm() in line 9 of the algorithm is based on the listscheduling scheme that iteratively constructs the static schedule table with start times for static messages and tasks [15]. Then the authors propose an optimized heuristic based on a curve-fitting approach for determining the length of the dynamic segment. This approach explores a reduced number of solutions for the DYN segment length with a smaller convergence time rather than the basic approach that considers all the possible DYN lengths from minimum to maximum values. The main target of this paper is time-critical applications with hard timing constraints. 3.3 Genetic-Based Optimizations of the FlexRay Dynamic Segment In the approach proposed by Samii et. al in [20], the FlexRay bus system optimization is based on the immune genetic algorithm which consists of the traditional genetic algorithm and a vaccination operator [6]. The algorithm objective is determining a fixed priority for each task in the system, frame IDs and priority for each message. A single Frame ID can be granted to several messages. This assigns priority to each message to determine its transmission turn on the bus. The traditional genetic algorithm performs mutation and crossover operators while the immune algorithm applies vaccination operator as well. The latter operator enforces a specific improvement into a solution in terms of the final solution quality and convergence time. Figure 3.1 illustrates the optimization approach that is proposed in this work. The cost function which is desired to be optimized is defined as follows: C = (i,j) γ tasks w ij Rij, where R ij is the average response times of the task. The weights w ij are given by the designer. In [19], a similar genetic based approach is proposed for design optimization and synthesis of FlexRay parameters for embedded control applications [18].

36 22 CHAPTER 3. RELATED PRIOR WORK System Specification Generate Population Population Evaluate Costs Poplulation Costs Stop? Yes Done No Crossover Mutation Vaccination New Population Figure 3.1: Flowchart of the optimization approach

37 3.4. SUMMARY Summary In this chapter, we discussed some prior work in the area of the FlexRay bus system. Their main focus was timing analysis and optimization of the FlexRay bus system. Similar to them, this thesis deals with the FlexRay bus system optimization. However, their work mainly target time-critical applications. Furthermore, the work in sections 3.1 and 3.2 performs worst-case response time analysis based on different optimization objectives. There is no similar analysis in the area of soft real-time applications on which we mainly focus. So, we determine deadline miss ratios as the optimization objective which allows some tasks to miss their deadlines every now and then. In [22] a sifting-based algorithm for frame ID assignment in the dynamic segment is proposed while in [20] and [19], the authors perform frame ID assignment based on the genetic algorithm. Similar to [20] and [19], we perform optimization based on the genetic algorithm while ignoring the vaccination operator which is used in [20]. The mentioned prior work optimizes bus parameters for the dynamic segment except [15] and [14] that optimize parameters for both the static and dynamic segment. This thesis is also targeting the optimization of the dynamic segment parameters.

38 24 CHAPTER 3. RELATED PRIOR WORK

39 Chapter 4 System Model The main focus within this chapter is describing the target platform, application model which is run on this platform, the model of the FlexRay protocol and finally the objectives of the optimization. 4.1 Platform Model The target platform has a set of nodes N (indexed by ζ N ) which are connected by a communication controller to a bus. The communication bus performs based on the FlexRay protocol. In each node, a set of application tasks exists. We will describe this in more details in section 4.2. Let us consider a system similar to Figure 2.7. It shows a system with three nodes (N 1, N 2 and N 3 ). The communication controller connects the nodes to the bus. The bus cycle is periodic and it has two phases of fixed length: the static phase and the dynamic phase (See Figure 2.8). In the static segment, there are equal-length static slots. Each of these slots is assigned to one node. The number of assigned static slots to each node may vary between 0 to the maximum number of static slots in the static segment. The dynamic segment consists of a number of minislots. The minislots are of equal length.the dynamic segment also consists of a number of dynamic slots of varying size. Similar to a static slot, a dynamic slot is also assigned to a particular node. The size of each dynamic slot depends on whether a message is sent on that dynamic segment and it would be equal to the number of minislots which are needed to send that particular message on the bus. If there is no message to be sent in a dynamic slot, this slot s size would be equal to the size of one minislot. The maximum number of dynamic slots n DY N is given as a part of the FlexRay configuration. Consequently, we introduce the function Γ : {1, 2,..., n DY N } N that assigns each dynamic slot to a node. 25

40 26 CHAPTER 4. SYSTEM MODEL 4.2 Application Model On the execution platform, a set of applications Θ is run which is indexed by ζ Θ. An application Θ i Θ (i ζ Θ ) is modeled as a directed acyclic graph (A i, B i ), where the nodes A i, indexed by ζ i, show the tasks and the graph edges B i A i A i represent data dependencies between tasks. The set A Θ = i ζ Θ A i represents all the tasks in the system. As it is depicted in figure 1.3, the system has two applications Θ 1 and Θ 2. Application Θ 1 has two tasks A 1 = {τ 11, τ 12 } which are shown by gray circles. Application Θ 2 consists of four tasks depicted by black circles. The arrows in the figure, represent data dependencies between tasks. For instance, tasks τ 12 depends on a message γ 112 = (τ 11, τ 12 ) from tasks τ 11. Each application Θ i Θ has the arrival period h i and release time R i at which each application s task starts execution. A job q of each task is invoked at time (q 1)h i. The tasks are executed according to Rate Monotonic Scheduling Theory (RMST) [3] which means the shorter the task deadline, the higher priority is assigned to the associated jobs to that task. The executing job can be preempted at any time by a higher priority job. Job q of task τ ij is denoted by τ q ij which has the execution time Eq ij. The task execution time is a stochastic viable bounded by its best-case and worstcase execution times. For a message γ ijk = (τ ij, τ jk ) B i, the message instance produced by job τ q ij is denoted by γq ijk. The time difference between completion and release time of a job is called its response time. If job τ q ij finishes at time t, then its response time is r q ij = t - R i. 4.3 The Protocol Model Let us consider a system similar to the one depicted in figure 2.7. The communication bus is configured based on the FlexRay protocol with the static phase and the dynamic phase. Since the focus of the current work is on the dynamic segment, the static segment is ignored. Based on the message transmission behavior on the communication bus that is described in 2.3, it can be said that frame identifiers and minislot length affect the temporal behavior of the system. Two simulations of a system consisting 40 tasks are run while considering the response time of one task. For each simulation, a particular assignment of frame identifiers to the messages is considered and a specific length for minislot is chosen. Figure 4.1 shows the resulted histograms of response times. It corresponds to two different assignments of frame identifiers and minislot length. On the horizontal axis, the response time and on the vertical axis the number of times a certain response time occurs are shown. The histograms show the response time distribution of several tasks. The average response time for the top and bottom graphs are 1880 and 1235 respectively. It shows that frame identifier assignment and minislot length which are considered for the bottom graph lead to a better timing behavior in term of average response

41 4.3. THE PROTOCOL MODEL Frequency 20 Frequency More Response Time Frequency 20 Frequency More Response Time Figure 4.1: Response time distribution of different assignments of FrameIDs and minislot length

42 28 CHAPTER 4. SYSTEM MODEL time compared to the top graph.

43 Chapter 5 Problem Formulation 5.1 Motivational Example This thesis contribution is proposing an optimization of the following parameters: length of minislot and frame ID assignment to messages in the dynamic segment. The solution will lead to a reduced Deadline Miss Ratio (DMR). Here, we show how the choice of bus parameters leads to different timing behaviors of the sample application. For instance, we consider a system of two nodesn 1 and N 2. N 1 sends out messages m 1, m 2 and N 2 sends m 3 on the bus. Figures 5.1 shows how the structure of the dynamic segment influences each message response time and deadline miss ratio through three different bus configurations (a, b and c). To be concise, the static segment of the bus cycles is ignored. Table 5.1 presents deadline and communication time of each message. Table 5.2 presents the three (a, b and c) bus configurations. Table 5.3 presents the timing behavior of the three configurations. Although DMR has the same value in a and b, each message gets different response times. Scenario c achieves lower DMR rather than a and b because m 1 and m 2 get first and second priorities for transmission. This causes them to get finished before their deadline in the first cycle. After these two transmissions, there is not enough time left in the first cycle for m 3. So, m 3 transmission is delayed until the second cycle. m 3 misses its deadline and consequently DMR gets 33.3% in this scenario. In a and b, although m 3 is transmitted in the first cycle, it is not finished by its deadline. Table 5.1: Message properties Message Deadline Communication Time m m m

44 30 CHAPTER 5. PROBLEM FORMULATION (a) Table 5.2: Bus configuration Message FrameID Minislot length m 1 3 m m 3 2 (c) Message FrameID Minislot length m 1 1 m m 3 3 (b) Message FrameID Minislot length m 1 1 m m 3 2 (a) Message Response time DMR m m m (c) Message Response time DMR m 1 98 m m Table 5.3: Timing behavior (b) Message Response time DMR m 1 98 m m Constraints and Optimization Objective In our design-optimization problem, the inputs are a set of computation nodes N which are connected to a bus by communication controllers. A set of applications Θ indexed by ζ Θ with arrival period h i for each application Θ i (i ζ Θ ) and a mapping function to map all the applications tasks to the nodes, map : A Θ N. Given is also the deadline D i and the execution time of each task E i as well as the parameter platesttx for each node. The length of the FlexRay bus cycle, the length of the dynamic segment in form of minislots and the number of dynamic slots in each dynamic phase are also provided. The outputs are the frame identifier assignment to the messages and the length of minislot in the dynamic segment. Thus, a solution to the problem consists of two parts which is shown as ϕ =(f,m). The first part f assigns frame identifiers to each message. Let us consider the set of messages communicated on the bus as Γ bus. We consider ρ Γ : {1,..., Γ bus } Γ bus

45 5.2. CONSTRAINTS AND OPTIMIZATION OBJECTIVE 31 (a) gdcycle = 200 gdcycle = 200 Dynamic Segment Dynamic Segment MS MS MS m 2 m 3 m Dynamic slot counter Dynamic slot counter Minislot counter (b) gdcycle = 200 gdcycle = 200 Dynamic Segment Dynamic Segment MS MS MS m 1 m 3 m Dynamic slot counter Dynamic slot counter Minislot counter (c) gdcycle = 200 gdcycle = 200 Dynamic Segment Dynamic Segment MS MS MS m 1 m 2 m Dynamic slot counter Dynamic slot counter Minislot counter Figure 5.1: Optimization of the DYN segment

46 32 CHAPTER 5. PROBLEM FORMULATION as any bijection. Then f = (f 1,..., f Γbus : f m f n, m n) where f k is the frame identifier of message ρ Γ (k). The frame identifiers are assigned to the messages based on the dynamic slot available to each sending computation node. In other words: f F = {(f 1,..., f Γbus : f m f n, m n) N Γ bus : f k dyn*(map(τ ij )), (τ ij,τ)) = ρ Γ (k) }. where dyn*(map(τ ij ) assigns dynamic slots to each node. The second part of the solution consists of minislot length in the dynamic segment. Considering the tuple M = (m MIN,..., m k,..., m MAX ) where m k indicates the length of minislot and m MIN, m MAX represent minimum and maximum allowed values for the length of minislot according to the FlexRay specification [5]. At the end, our optimization objective is to find a solution ϕ =(f,m) F M that optimizes a cost function like C. The cost function C in our problem is the average deadline miss ratio of all the application s tasks: C = (i,j) γ tasks DMR ij

47 Chapter 6 Simulation Implementation This chapter describes the implementation the FlexRay bus simulator. 6.1 SystemC The FlexRay bus simulator is implemented in SystemC [2]. SystemC is a language that allows system designers developing the system hardware and software components. It also has a simulation kernel for simulating and evaluating the system behavior. Modules in SystemC are the main constructing blocks. They mainly consist of processes, ports and channels. Processes provide system functionality in SystemC. They are divided into two categories: 1. SC THREAD which runs only once when the simulation starts and could be suspended by the wait statement. 2. SC METHOD that could not be delayed. Once it starts, it will run till the end. Such a process could be sensitive to an event. When the event occurs, the corresponding SC METHOD is ready for execution. The communication between modules are handled by channels and ports in SystemC. Processes write and read values on channels while they are supported by ports. Ports are considered as the module s input and output. They are connected to channels and make reading and writing from/to channels possible. For simplicity, in the following sections, SC THREAD and SC METHOD are referred by thread and method respectively. Channels are also used as the communicating infrastructure between modules and we avoid defining their corresponding ports. 33

48 34 CHAPTER 6. SIMULATION IMPLEMENTATION msggenerator Module msgframe generatedmsgproperty CommunicationController Module transmittedmsgproperty minislot dynslot CommunicationBus Module Figure 6.1: The logical architecture of FlexRay bus simulator 6.2 The FlexRay bus simulator The logical architecture of the simulator is shown in figure 6.1 which consists of the main following modules: The msggenerator module This module periodically produces messages of each task in the system. It directly communicates with CommunicationController module over two input and output channels that are called msgframe and generatedmsgproperty respectively. Messages of each application task have particular properties which are produced by our self-developed tool. It produces message properties that form the inputs to the msggenerator module. These properties are as follows: Message Deadline that shows the maximum allowed time in which the message has to reach from the source node to destination. Later this property will be used to calculate deadline miss ratio of communicating messages in the system. Message Period that indicates time intervals when a new instance of a

49 6.2. THE FLEXRAY BUS SIMULATOR 35 receiveframe Thread initialevent msginstance Thread newinstanceevent msgsave Method sendcc Method msgframe Channel generatedmsgproperty Channel Figure 6.2: The process flow of the msggenerator module message is produced. Message Communication Time shows how long it takes for a message to be transmitted on the bus from source to destination. Message Identifier is a property that we define to distinguish among different tasks in the system and their belonging messages. Messages of each particular task in the system take the task s identifier. Message Priority which is not used in the current implementation. However, it eases future extension of the optimization problem when we will have messages with the same frame identifiers. This property prioritizes each message to be transmitted on the bus. Node platesttx is not a message trait but a node property specified by the FlexRay bus configuration. Here, it is used to model the different nodes of the system. Each node takes an exclusive platesttx. Messages reside on the same node will take the same platesttx value. As it is shown in Figure 6.2, the process graph of msggenerator module consists of the following major methods and threads: receiveframethread is a thread which starts involuntary as soon as the module runs. It takes frame identifiers for each message and saves them in a structure which contains message properties. Afterwards, it triggers an event called initialevent. msginstancethread is a thread triggered by the initialevent event. It periodically notifies the msgsavemethod method of the presence of every new instance of a message. This is done by triggering the event newin-

50 36 CHAPTER 6. SIMULATION IMPLEMENTATION stanceevent. Different instances of a particular message have different release times. The latter affects message response time which is calculated later in our implementation. msgsavemethod is a method sensitive to the newinstanceevent event. It keeps all message properties along with each message instance release time. sendccmethod is sensitive to the msgframe input channel. Based on the received frame identifier, it loads the generatedmsgproperty output channel with the corresponding message s properties The CommunicationController module This module simulates the communication controller operation located on each system node. As it is shown in figure 6.1, the module communicates with the msggenerator and communicationbus modules by means of several input and output channels. It operates based on two main methods being as follows: sendframemethod is a method sensitive to input channel dynslot. As depicted in figure 6.3, this channel connects the CommunicationController to the communicationbus module. The value on the dynslot channel indicates the current dynamic slot number of the communication bus. The message with the same frame identifier will be transmitted by the communication controller (CC) on the bus. In order to fetch the corresponding message, sendframemethod initially checks if there is any message in the message queue waiting for transmission or not. In such a case, the message with the same frame identifier as the current dynamic slot is fetched and the properties such as communication time, deadline and release time will be transferred on the transmittedmsgproperty output channel to the communicationbus module. In the other case, when there is no message with similar frame identifier in the queue, the method sends out the dynamic slot value to msggenerator on the msgframe channel. This is a value that triggers sendccmethod in msggenerator. receivemsgpropertymethod is sensitive to received values from the generatedmsgproperty channel. Based on the msggenerator operation, a message with the same frame identifier as the current dynamic slot is received by the receivemsgpropertymethod. This method compares the current minislot value of the bus with the received platesttx value along with the other properties of the message. If (current minislot) < (platesttxmsg) then it writes the received values on an output channel transmittedmsgproperty which is connected to the communicationbus. Otherwise according to the FlexRay bus specification the message could not be transferred at the current cycle and it is buffered in the message queue to be transmitted in the next bus cycles.

51 6.2. THE FLEXRAY BUS SIMULATOR 37 sendframe Method receivemsg PropertyMethod minislot Channel dynslot Channel msgframe Channel transmittedmsgproperty Channel generatedmsgproperty Channel Figure 6.3: The process flow of the CommunicationController module The CommunicationBus module T his module implements The FlexRay bus cycle. The process flow of this module is shown is 6.4. It has the following processes: initializebusthread is presented in Algorithm 3. It starts the bus cycle based on the received minislot length as input. In order to notify nodes of the current dynamic slot of the bus cycle, it triggers an event called current- DynslotEvent. Then, the thread suspends until an event called receivedmsgevent occurs. This shows whether a new message with the same frame ID as the current dynamic slot is ready for transmission at one of the nodes Communication Controller (CC). Message response times and deadline miss ratio are the method s outputs. They are used by the optimization engine which will be described in Chapter 7. If there is no message ready in CC, the thread only suspends one minislot and resumes execution afterwards. Values of the current dynamic slot and the number of passed minislots are calculated here as well. This thread is set to run for the number of bus cycles which is initially defined. senddynslotmethod is triggered by event currentdynslotevent. It initially calculates timing value of minislot by multiplying its length to the number of passed minislot in the bus cycle. Then it sends the dynamic slot and minislot values to the CommunicationController module on dynslot and minislot channels respectively as it is shown is figure 6.4.

52 38 CHAPTER 6. SIMULATION IMPLEMENTATION Algorithm 3: The initializebusthread Algorithm Input: MinislotLength Output: MessageResponseT ime, DeadlineMissRatio 1 foreach BusCycleIteration do 2 MinislotCounter 0; 3 foreach DynSlotCounter {1,..., dynmessages} do 4 while CurrentBusT ime < BusCycleLength do 5 notifies all nodes of DynSlotCounter; 6 wait for message with the same framid as DynSlotCounter; 7 if no message is available then 8 wait(minislotlength); 9 MinislotCounter MinislotCounter + 1; 10 end 11 else 12 wait(messagecommunicationtime); 13 MessageResponseT ime CurrentBusT ime MessageRealseT ime; 14 if (MessageResponseT ime > MessageDeadline) then 15 MissedMessages MissedMessages + 1; 16 end 17 MessageF ramelength MessageCommunicationT ime/minislotlength; 18 MinislotCounter MinislotCounter + MessageF ramelength; 19 T otalmessages T otalmessages + 1; 20 end 21 end 22 wait(buscyclelength); 23 end 24 DeadlineMissRatio MissedMessages/T otalmessages; 25 end The receivemsgpropertymethod becomes ready for execution when values are sensed from transmittedmsgproperty channel. It means a new message is ready to be transmitted on the current bus cycle. It notifies this incident to the suspended initializebusthread by receivedmsgevent. By the simulation presented in this chapter, a deadline miss ratio can be calculated. In the next chapter, we present the optimization engine based on the genetic algorithm to assign frame identifiers to messages and decide for the length of minislot in the dynamic segment. The solution to this problem has to optimize the cost function.

53 6.2. THE FLEXRAY BUS SIMULATOR 39 initializebus Thread currentdynslotevent senddynslot Method receivemsgevent receiveproperty Method transmittedmsgproperty Channel minislotslot Channel dynslot Channel Figure 6.4: The process flow of the CommunicationBus module

54 40 CHAPTER 6. SIMULATION IMPLEMENTATION

55 Chapter 7 Optimization Approach This chapter is about implementation of the optimization engine. The proposed optimization approach is based on the genetic algorithm which functions according to Figure 7.1. This approach is implemented by defining the following processes: initialpopulation: It randomly generates a given number of solutions called members (Φ). As it was mentioned in 5.2, a solution to our optimization problem consists of two parts: First, frame identifiers to messages (f ) and second minislot length (m). So, the initial population looks like: Φ 1 F M. calculatedmr: It is the process being used to evaluate the current population cost. The process is called for each member within the generated population to calculate its deadline miss ratio by running the FlexRay bus simulator. Feeding inputs that was mentioned earlier in 6.2 takes place here in this process. Passing this step, we check for a convergence criterion to examine if the optimization has to be stopped or continued. Let us denote the average deadline miss ratio in each iteration k of the optimization with DMR k. Then, we define the convergence criterion (called stopping condition) for all tasks τ ij as follows: (i,j) γ tasks DMR k ij (i,j) γ tasks DMR k 1 ij < δ sim where δ sim is an input parameter which we have experimentally tuned to δ sim = It means the optimization stops when the average deadline miss ratio of all the tasks has changed with less than 0.5 percent. After checking the convergence criterion, if it turns up to proceed the optimization, we generate a new population and go back to the evaluation phase. twobestmembers: This process is used to generate new populations. To generate the new population in every iteration k of the optimization loop, we take care of two solutions from the current population Φ k with the small- 41

56 42 CHAPTER 7. OPTIMIZATION APPROACH System Specification Generate Population Population Evaluate Costs Simulation Population Costs No Stop? Yes Done Crossover Mutation New Population Figure 7.1: Flowchart of the optimization approach est and the second-smallest deadline miss ratio (denoted by DMR) values. These two survived to the next population Φ k+1. Furthermore, the remaining Φ k - 2 members are generated while Φ k is even. Two genetic algorithm operations called crossover and mutation are applied to these members. Prior to this phase, we would like members from the current population with better cost values be selected as parents to undergo crossover and mutation. RouletteWheelSelection [6]: It performs based on the idea that the better the members are, the larger chance they have to be selected to generate the next population. Lets imagine a roulette wheel on which all members are placed based on their cost function value. In other words, the smaller the cost is, the bigger portion the individual occupies on the roulette wheel (See Figure 7.2). Then a marble is thrown to select a member. A member with bigger place has a better chance to be selected in every try. The basic steps toward RouletteWheelSelection are depicted in Algorithm 4 which shows how our RouletteWheelSelection process functions in the optimization approach. It provides crossover and mutation operations with parents which are selected by the roulette wheel selection scheme. crossoveroperation: Till now, best and second-best solutions survived to the next generation. Parent members which are used to generate the remaining Φ k - 2 members of the next generation are also selected. Crossover is done by selecting two parent members depicted as ϑ (1) and ϑ (2) from the

57 43 Member 1 Memebr 2 Member 3 Member 4 Figure 7.2: A roulette wheel representing the population members Algorithm 4: RouletteWheelSelection 1 T otalcostsum calculate sum of all member costs in the current population; 2 Generate a random number r (0, T otalcostsum); 3 foreach (n (0,..., NumberOfMembers)) do 4 Calculate PartialCostSum; 5 if (P artialcostsum > r) then 6 Stop and return the member where we are in the for loop; 7 end 8 else 9 Continue; 10 end 11 end current population Φ k. We generate two offsprings ϑ (1) and ϑ (2) from ϑ (1) and ϑ (2) using probability δ co. In our implementation, δ co performs as it is shown in Algorithm 5: Crossover is individually performed on each part of the solution. For this reason, we randomly generate crossover points for every part. For frame identifiers and minislot length, this point should be a value like α f {1,..., Γ bus } and α m {1,..., 63} respectively. According to the FlexRay specification the maximum allowed value for minislot length is 63 MT while MT {1,..., 6}µs and it refers to the nominal bit time. In our simulations we consider its value equal to 1µs. According to the minislot length range, six bits are considered to store the corresponding binary value of the minislot length and crossover performs on the bits. Crossover for frame identifier performs on decimal values. We show the