Reconfigurable Communication Middlewarefor FlexRay-based Distributed Embedded

Systems

Diptesh Majumdar

Department of Computer Science & Engineering

IIT Guwahati

A Report Submitted in Partial Fulfillment of the Requirements for the Degree of

Master of Technology

Under the guidance of Prof. Purandar Bhaduri and Prof. Samarjit Chakraborty

April 2015

DECLARATION

This is to certify that the thesis entitled “Reconfigurable Communication Middleware for FlexRay-based Distributed Embedded Systems”, submitted by me to the Indian Institute of Technology

Guwahati, for the award of the degree of Master of Technology, is a bona fide work carried outby me under the supervision of Prof. Purandar Bhaduri and Prof. Samarjit Chakraborty. The contentof this thesis, in full or in parts, have not been submitted to any other University or Institute for theaward of any degree or diploma.

Signed:

Diptesh MajumdarDepartment of Computer Science & Engineering,Indian Institute of Technology Guwahati,Guwahati-781039, Assam, India.

Date: 10.06.2015

Acknowledgements

Immeasurable appreciation for the help and support are extended to the following indi-viduals without whom this thesis might not have been written, and to whom I am greatlyindebted. First and foremost I would like to thank Prof. Purandar Bhaduri, my super-visor at IIT Guwahati, for his constant support, advices, guidance, valuable comments,suggestions and provisions that helped me immensely in the completion of this project. Iowe him a huge debt of gratitude for giving me an opportunity to work at the prestigiousInstitute for Real-Time Computer Systems, Technische Universitat Munchen which pro-vided me with an enriching wealth of experience that will surely benefit me in my futureendeavors. I would like to express the deepest appreciation to my supervisor at TUM,Prof. Samarjit Chakraborty for continually and convincingly conveying a spirit of ad-venture in regard to research and higher-studies. Without his guidance and persistent helpthis thesis would not have been possible.A special gratitude goes out to my advisor at TUM, Dipl. -Ing. Licong Zhang, whointroduced this exciting area of research to me. His dedication, keen interest and hisoverwhelming support has been a constant source of encouragement through the entireduration of the project. It was a privilege to work with him and to be able to gain fromhis inestimable knowledge and expertise in this area. His excellent supervision in han-dling the usage of the tool-chain used in our experiments along with endless assistance inpreparing this report has been instrumental in successful completion of this project.Last but not the least, I would like to dedicate this endeavor to my loving parents whohave always been by my side when I needed them most.

Sincerely,Diptesh Majumdar

Abstract

In this report we consider the case of a network of Electronic Control Units (ECUs) con-nected through a FlexRay bus in the automotive domain. Multiple distributed applicationscan run on this underlying architecture, each partitioned into tasks that are mapped on dif-ferent ECUs. These applications can often be executed in different functional modes withdifferent requirements on the communication resources in terms of data size and sam-pling period. Moreover, new applications can be deployed on to the ECUs at run-time.To efficiently utilize the communication resources and accommodate new applications, acertain flexibility in reallocation of the resource is necessary. However, the FlexRay busrequires static configuration of schedules and data mapping in order to guarantee a moredeterministic system behavior, allowing little room for flexibility. In order to addressthis problem, we propose a reconfigurable communication middleware that lies betweenthe application layer and the communication controller layer, which maps messages ontoFlexRay schedules, and can be reconfigured at runtime. The configuration is synthesizedand deployed online, allowing a certain reallocation of communication resource to appli-cations. In this report, we describe the design of such a reconfigurable communicationmiddleware and demonstrate its function with an implementation using industry-strengthFlexRay design tools.

List of Figures

1.1 The proposed communication middleware . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 FlexRay communication cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 An Example of FlexRay schedules: Θ1 = (2, 0, 2), Θ2 = (4, 1, 4), Θ3 = (9, 1, 2) . . 8

3.1 Interface between the software components . . . . . . . . . . . . . . . . . . . . . . 123.2 Data mapping component and the message to frame mapping . . . . . . . . . . . . . 133.3 State transition diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.4 Timing diagram for state transition . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1 Normalized performance of the applications for all modes . . . . . . . . . . . . . . . 294.2 Application Tasks designed during modeling of the ECUs . . . . . . . . . . . . . . . 304.3 Data rate requirements for different modes of applications. This requirement is de-

noted as average number of bytes per communication cycle . . . . . . . . . . . . . . 324.4 Application modes in all reconfiguration steps . . . . . . . . . . . . . . . . . . . . . 334.5 Performance value of each application and the overall performance in all reconfigu-

ration steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

iii

Contents

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Our Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Structure of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Problem Formulation 52.1 Architectural Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 FlexRay Communication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Constrained Communication Resources . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Proposed Communication Middleware 93.1 Motivational Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.2 Brief Overview of Components . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 Data Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3.1 Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3.2 Packing Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3.3 Unpacking Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4 Configuration Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.5 State Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.6 Reconfiguration Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.7 Configuration Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.7.1 ILP Formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.7.2 Linear Search Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

iv

3.7.3 Two-Layer Linear-ILP Formulation . . . . . . . . . . . . . . . . . . . . . . 24

4 Experimental Results 274.1 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.1 Evaluation of Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.1.2 Example of a Reconfiguration Request Series . . . . . . . . . . . . . . . . . 28

4.2 Hardware Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3 Results and Discussions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 Concluding Remarks 34

References 35

v

Chapter 1

Introduction

1.1 Motivation

In modern vehicles, increasingly more complicated software applications are developed to help con-trol the vehicle, assist the driver and offer more comfortable driving experience. This developmenthas led to an increase in the scale and complexity of the E/E architecture, and also imposes more loadon the existing communication buses. As the communication resources have become more scarceand valuable, an efficient utilization of the bandwidth has become a problem of great interest. Fur-thermore an application can sometimes run in different operation modes, offering different levels ofperformance. Each mode may be characterized by a different algorithm or sampling period of tasks,data size, period of the messages sent over communication bus, etc.. An example of this is a controlapplication (e.g., engine control), where different environment conditions or driving patterns mightrequire different modes. If a vehicle runs in a difficult terrain like paths on a mountain, it requiresa better performance compared to driving on a city street with moderate speed, thus requiring bettercontrol and more data sent on the in-vehicle network. Another example can be an object detection andcollision warning driver assistance system. If the vehicle is driving at lower speed, the safe distancecould be shorter, in which case less data needs to be processed and communicated. A safe designparadigm for this case is over-provisioning of resources for the applications so that they always haveenough resources to run in the most demanding mode. However, there can be a waste of valuablecomputation and communication resources whenever the applications are not required to run in thebest possible mode. Moreover, it is difficult in this case to accommodate Plug-and-Play applications,i.e., new applications deployed onto the vehicle while it is in use, which is an emerging trend in theautomotive domain. In addition, in the automotive context, the case of inadequate communication

1

Ap

plic

atio

n

Ap

plic

atio

n

Ap

plic

atio

n

Ap

plic

atio

n

communication middleware

Data Mapping

Operating System and FlexRay Controller

DeploymentManagement

ConfigurationCalculation

ReconfigurationRequest

State Management

Figure 1.1: The proposed communication middleware

resources is more likely to happen, due to the constantly increasing number of applications and sizeof data. In this case, a likely scenario is that not all applications can run simultaneously in their bestmode. Thus the ability of the system to allow resource sharing so that the applications can switchbetween different operation modes at run time is quite important. However, to enable this, a certainflexibility of the system is necessary. Furthermore, the support for future Plug-and-Play ability of thevehicles also requires some flexibility and scalability of the underlying embedded system. But thedesign and implementation of current automotive bus systems does not allow much flexibility. Let usconsider FlexRay for example, which is a typical automotive communication bus system usually usedfor the safety critical applications. The FlexRay clusters are often designed and configured offlineand there is little room for an online reconfiguration of the system on the protocol level.

Towards addressing this problem, in this report we propose a communication middleware forFlexRay-based distributed embedded systems, enabling a certain reallocation of the communicationresources within an ECU. In this middleware, we introduce a data mapping component that castsmessages of applications into FlexRay frames with a specific schedule based on a configuration. Weuse additional software components to synthesize the configuration of both the application mode andthe data mapping in order to deploy the new configuration and to safely reconfigure the system. Thiscommunication middleware will enable a reconfiguration of the communication on a FlexRay busand facilitate the online change of application modes and activation of newly deployed applications.The experimental results have shown that the proposed middleware can be implemented in a FlexRaybased ECU system using a commercial off-the-shelf tool-chain.

2

1.2 Related Work

Mundhenk et al. [1] have introduced a virtual event-triggered communication layer on top of atime-triggered communication infrastructure to flexibly schedule policy-based messages, i.e., event-triggered messages that have been assigned different priorities allowing integration of multi-modeapplications for different situations experienced by a vehicle. At run-time, event-triggered messagesare sorted in the virtual layer to produce wrapper Protocol Data Units (PDUs) that fill the entire staticslot. However, the message mapping is based on a pre-defined policy and the change in the period ofmessages according to change in mode of applications has not been considered.

For the multi-mode applications, Phan et al. [2] presented a model, referred to as Mode ChangeProtocol (MCP), to express the system behavior during mode transitions in multi-mode real time sys-tems. Each MCP model is a finite state automaton, represented as a DAG where each node capturesthe system-tasks during a mode transition and each edge specifies a buffer update and a timing/buffercondition between two intermediate transitional stages. Sha et al. [3] proposed a basic mode changeprotocol which can support mode changes in the context of common preemptive scheduling algo-rithms for periodic tasks such as rate monotonic scheduling. Mode change operation is classified intotwo categories depending on increase and decrease of task set’s processor utilization. Subsequently,the authors argue that a new task can be added to the system if sufficient processor capacity is avail-able, i.e. if the resulting task set meet all their deadlines using the rate-monotonic algorithm and thepriority ceiling protocol. A comprehensive survey of mode change protocols for real-time systemscan be found in [4]. Also, the construction of multi-mode schedules by extension of a single modescheduler has been demonstrated in [5]. The single mode scheduler traverses precedence graph, con-structed from the precedence constraints of the task set, and tries to select ready tasks i.e. those withfulfilled precedence constraints. In case of multiple modes precedence graphs, one for each mode,are traversed simultaneously in an effort to construct individual schedule for each mode thus enablingswitching between schedules at run-time without rephasing. Buttazzo et al. [6] presented a periodictask model in which tasks have a minimum and a maximum period along with an elastic coefficient.In this framework, an intentional change in execution rate of one task leads to automatic adaptationof periods of other tasks in order to keep the system underloaded, thus essentially solving the prob-lem of multimode scheduler. A performance analysis method focusing on testing feasiblility of taskscheduling in systems supporting multiple modes has been detailed in [7]. However, these works donot address the problem of FlexRay communication, while in this work, we focus on the schedulingat the communication level instead.

A method to reconfigure a FlexRay network in order to increase fault tolerance has been proposed

3

in [8]. This approach is mainly targeted at the event of a node failure since it uses redundant slots inthe schedule which again under-utilizes the bandwidth of communication in normal circumstances, acondition we aim to improve in the present work.

1.3 Our Contribution

In this report we demonstrate a method that allows reconfiguration of applications and allocationof communication resources within an ECU. In order to perform this reconfiguration, we propose acommunication middleware layer between the application layer and the operating system and com-munication controller layer. This middleware layer allows an online calculation of configuration anddeployment of the new configuration on a reconfiguration request. The calculation involves genera-tion of a feasible mode combination of the currently running applications along with new schedulesfor periodic messages while maximizing the overall system performance level. Based on the newlygenerated configuration, the middleware allows re-mapping of messages onto underlying static com-munication resources.

1.4 Structure of the Thesis

The rest of this report is organized as follows. In Chapter 2 we present the problem formulationincluding the architectural setting we are considering including the FlexRay communication protocol.The proposed communication middleware layer, its components and their function are explained inChapter 3. Chapter 4 shows the experimental results, where a case study is used to demonstrate theonline reconfiguration of applications of the proposed middleware using industry-strength FlexRaydesgin tools, before we conclude in Chapter 5.

4

Chapter 2

Problem Formulation

2.1 Architectural Setting

In this report we consider a distributed embedded system consisting of multiple Electronic ControlUnits (ECUs) connected by a common FlexRay bus. We denote the set of ECUs as E = {E1, ..., ENe},where Ne is the number of ECUs in the system. We assume that a set of applications are running inthe system, denoted by A = {a1, ..., aNa}. An application ai is a collection of certain tasks and mes-

sages that performs an independent function. The tasks in an application can be mapped on differentECUs and the data between the tasks are sent on the FlexRay bus as messages.

We denote a task as τj and the set of tasks belonging to an application ai as Ti. A message containsthe actual data that needs to be sent on the communication medium. It can be characterized by a tuplemj = (wj, pj,Θj), where wj and pj denote respectively the data size per message and the period atwhich the message needs to be sent. Θj represent the FlexRay schedule for the message. The conceptof a FlexRay schedule will be explained in the following subsection. Here we differentiate betweena message and a frame. A message is a certain amount of raw data that needs to be packed into aFlexRay frame to be transmitted on the bus.

An application can have different pre-programmed operation modes. Each mode is a customiza-tion of the application, offering a different level of functional performance. Depending on the per-formance to provide, it could require different amount of data to be sent on the bus. This variationcould lie in the data size or the period of the message. Furthermore, the tasks of the applicationmight also have a different period or algorithm implementation for a different mode. An applicationmode is also associated with a specific performance value, where usually a higher performance valuerequires more resources i.e. more data size per message and (or) greater frequency of message to

5

Modes(α) data size (w) period (p) Performance (J)1 4 bytes 10 ms 1002 4 bytes 5 ms 803 2 bytes 5 ms 50Off 0

Table 2.1: Example of an application manifest in terms of communication

be sent. This performance value is usually specified by the application designer and can possibly bederived from the characteristics of the tasks and messages. Here we characterize an application asai(αi) = (Ti(αi),Mi(αi), Ji(αi)), where αi ∈ Gi denotes the mode and Gi is the set of pre-definedoperation modes of the application ai. Ti and Mi denote respectively the set of all the tasks andmessages in the application. Ji ∈ Ji is the corresponding performance value of mode αi. We canreasonably assume that all characteristics of Ti and Mi as well as Ji for all modes are known before-hand, which is provided by the application designer and stored in the manifest of the application inthe ECUs that the application is mapped on. In terms of Mi, the corresponding requirements of datasize w and period p should be specified. An example of such a manifest in terms of communicationis shown in Table 2.1.

2.2 FlexRay Communication Protocol

FlexRay [9] is a communication protocol commonly found in the automotive domain and is suitablefor safety critical application clusters. As a hybrid protocol, it offers both time-triggered and event-

triggered communication services. FlexRay is organized as a series of periodic communication cycles,which we denote here as Tbus, as shown in Fig. 2.1. Each cycle has two major components, thestatic segment (ST) and the dynamic segment (DYN), where the time-triggered and event-triggeredmechanisms are respectively applied. Every 64 communication cycles constitute a periodic sequenceof bus cycles, as shown in Fig. 2.2.

The static segment of a communication cycle follows the TDMA approach, where the wholesegment is partitioned into a number of static slots of equal length ∆. We denote the static slots in acommunication cycle as SST = {1, ..., SLs}. A frame can be assigned to one static slot. It does notmatter whether there is data to be sent or not in a communication cycle, the static slot will alwaysbe occupied. The dynamic segment employs the Flexible-TDMA (FTDMA) approach. The wholesegment is partitioned into a number of mini-slots of equal length δ. On the DYN segment, a dynamic

slot is a logical entity, which represents something similar to a priority. The dynamic slot is defined

6

Static Segment Dynamic Segment

Communication Cycle

Figure 2.1: FlexRay communication cycle

as SDYN = {SFd , ..., SLd}. Here, if a frame is sent on a dynamic slot, it will consume a number ofmini-slots necessary for the transmission. If a frame is not sent, it will consume only one mini-slot.In the context of this report, we only consider the case where data are sent on the static segment.

Here we can divide the concept of a communication schedule for FlexRay into two different layers.Schedule on the communication layer, or protocol layer represents the actual timing when the FlexRayframe is sent on the bus, i.e., the slot where the frame is assigned to. Schedule on the application layerrepresents the mapping of messages onto frames. The schedule on the two layers together constitutethe schedule of a message. Here we first define the FlexRay schedule on the communication layer.As explained above, FlexRay is organized as a periodic sequence of 64 communication cycles, witheach communication cycle indexed by a cycle counter. The cycle counter increments from 0 to 63

and is then reset to 0. Therefore to fully characterize a FlexRay schedule on the communication layer,we can define a schedule as Θi = (Si, Bi, Ri), where Si represents the slot number, Ri represents therepetition rate and Bi represents the base cycle. The repetition rate is the number of communicationcycles that has to elapse between two consecutive transmission of the frame and can take the valueRi ∈ {2n|n ∈ {0, ..., 6}}. The base cycle indicates the cycle offset in the the 64 cycles. Fig. 2.2 showsan example of FlexRay schedules. Multiple slots can be assigned to a specific ECU and additionallya slot can have multiple FlexRay schedules through slot multiplexing. On the application layer, amessage needs to be packed into FlexRay frames, which is essentially a mapping of messages onFlexRay schedules.

2.3 Constrained Communication Resources

In an automotive setting, we often face a case of constrained communication resources, where acommon bus is shared by many ECUs. This is especially true in the case of a FlexRay-based system,

7

cycle

slot0

1

2

3

4

5

62

63

. . .

1 2 3 4 5 6 7 8 9

Figure 2.2: An Example of FlexRay schedules: Θ1 = (2, 0, 2), Θ2 = (4, 1, 4), Θ3 = (9, 1, 2)

where during the incremental design a FlexRay cluster configuration is often inherited from previousdesigns while more ECUs and applications are mapped onto the system. Therefore, over-provisioningcommunication resources for applications is not an efficient design paradigm. In this report, weconsider the case that for a specific ECU Ei, a set of static slots Sj ∈ S(Ei) are already assigned.We try to reallocate the underlying static communication resources available to the applications at runtime.

Note that for an application having multiple application modes, computation resource along withcommunication resource requirement varies with different modes. For example, if an applicationswitches to a mode of higher performance, the task period, the execution time of the tasks as well asthe schedules of the tasks can also change. This problem of task scheduling in the case of multi-modeapplications is fortunately well studied, as mentioned in the related work [2, 3, 4, 5]. In this report,we assume the scheduling problem at the task-level can be solved by existing methods and focus onthe scheduling at the communication level instead.

8

Chapter 3

Proposed Communication Middleware

3.1 Motivational Example

Let us illustrate the problem with a concrete example. Consider the case of a subsystem consistingof two ECUs, E1 and E2, which is a part of a whole ECU network. There are currently applicationsa1, a2 and a3 partitioned and mapped on both ECUs. Each application has one task mapped on E1

and a following task mapped on E2. Periodic messages m1, m2 and m3 are sent from E1 to E2.The application manifest for messages is shown in Table 3.1. Let us assume that the duration of onecommunication cycle of the FlexRay bus is Tbus and a static slot can accommodate a maximal payloadof 8 bytes. Two static slots S1 and S2 are assigned to E1.

We have a case of a constrained communication resources here, since the available static slots as-signed can not accommodate all three applications to operate in their best mode, i.e., mode 1, whichrequires an average payload of 18 bytes per communication cycle while only 16 bytes are available.Therefore, some of the applications can only run in modes with lower performance. If we assume theoverall performance value of the system is a weighted sum of the performance values of all applica-tions with equal weights, Table 3.2 shows some combination of modes with better overall performancevalues. In the conventional design, one of these combinations is statically configured and the systemcan only run as such. For example, if we choose combination 1 here, then it is not possible for appli-cation a3 to switch to mode 1 at run time. Even when the ECU allows the tasks of the applications toswitch at runtime, no sufficient communication resources can be allocated. The only way to do thisis to over-provision the communication resources so that it can accommodate all the applications intheir best mode. But if it is not necessary for applications to run in the best mode, this will be a wasteof valuable communication resources. Now we consider a second case, where three applications are

9

a1 a2 a3 a4α1 w1 p1 J1 α2 w2 p2 J2 α3 w3 p3 J3 α4 w4 p4 J41 8 Tbus 100 1 4 2Tbus 100 1 8 Tbus 100 1 4 2Tbus 1002 4 Tbus 80 2 4 4Tbus 80 2 4 Tbus 80 Off 03 4 2Tbus 50 3 4 8Tbus 50 3 4 2Tbus 50Off 0 Off 0 Off 0

Table 3.1: Communication manifest of the applications in the motivational example

running in the system and a fourth application a4 is deployed on E1 and E2. The application can notbe activated since there is no communication resources assigned to it and the application will not beable to transmit any data on the bus, even though it is theoretically possible to map the message ofa1 on top of combination 1. In this case, even over-provisioning of the communication resources willnot help since it may not be possible to know at design time the manifest of the new application andthe system will not be able to transmit the data due to lack of necessary configuration of the extramessage even though there are communication resources available.

To enable the mode switch of the applications and accommodation of messages of new applica-tions on the FlexRay bus at runtime, we need more flexibility in the FlexRay communication to allowa certain degree of reallocation of communication resources at runtime. A clear interface to the appli-cations is also important so that a newly developed application just needs a manifest for the FlexRaycommunication to reconfigure to accommodate the new messages.

3.2 Software Architecture

In this report, we propose a communication middleware architecture that enables online reconfigu-ration of FlexRay communication. As shown in Fig. 1.1, the proposed middleware consists mainlyof five software components: (i) data mapping, (ii) state management, (iii) deployment management,(iv) reconfiguration request and (v) configuration calculation. Before describing the functions of eachsoftware component of the middleware, we first explain the concept of configuration considered inthis report.

3.2.1 Configuration

We divide the configuration of the system into two parts. The first part is the configuration of ap-plications, which is essentially a list of which applications are active and in which mode the active

10

index a1 a2 a3 Joverall1 1 1 2 2802 2 1 1 2803 1 2 2 2604 2 2 1 2605 1 1 3 2506 3 1 1 250

Table 3.2: Combination of application modes with better performance levels

applications are operating. This can be characterized by a set Ca = {αi|ai ∈ A}, where A is the setof applications considered. Based on αi, application ai can adjust, for example, the algorithms andthe schedules of the tasks and the amount of data that needs to be transmitted. The second part is theconfiguration for data mapping, i.e., it decides which message is packed into a frame with a specificFlexRay schedule. We denote this configuration as Cc = {Mi|ai ∈ A}. For each message mj ∈ Mi

involved, a mapping mj → Θj is obtained. The data size wj and period pj are obtained from themanifest and the mode of the applications. The configuration Cc can also be seen as a lookup tablefor data mapping.

3.2.2 Brief Overview of Components

The data mapping component is responsible for mapping messages of different applications to theavailable FlexRay slots. The state management takes care of the safe state transition of the wholesystem in the re-configuration process. The deployment management component deploys the newconfiguration to the relevant software components and manages the reconfiguration of the applica-tions and the mapping component. The reconfiguration request component negotiates the reconfigu-ration request and sends it to the configuration calculation component, which calculates the suitablenew configuration and passes it onto the deployment management module. The interfaces and inter-action between the components are shown in Fig. 3.1. When there is no reconfiguration request, theapplications and data mapping component work normally based on an available configuration. Thereconfiguration process is initialized by the reconfiguration request component in response to a cer-tain event. Such an event can be a request to switch an application to a mode of higher performance,a request for deactivation of a running application or activation of an application. A reconfigurationrequest is sent to the configuration calculation component, which synthesizes the new configurationif possible based on the application manifests and the information about availability of underlyingcommunication resources. Once a new configuration is calculated, it is passed onto the deployment

11

Applications

Data Mapping

DeploymentManagement

StateManagement

ConfigurationCalculator

ReconfigurationRequest

reconfigurable part

FlexRay Communication Controller

enableconfigure

newconfiguration

new configurationready

requestreconfiguration

configure

configure

send receive configuration

cycle counter

Figure 3.1: Interface between the software components

management component where the new configuration will be distributed and stored. A new con-figuration ready signal is also sent to the state manager which will then control the whole process ofreconfiguration. It will first make sure that the new configuration has been known to all relevant ECUsand will safely control a synchronized reconfiguration of both the applications and the data mappingcomponent.

3.3 Data Mapping

The function of the data mapping component is to map application data into the correspondingFlexRay slot according to the configuration Cc. Depending on whether the ECU is sending or re-ceiving the data, the data mapping component has two different functions. On the sender side, itpacks the messages into the slots and on the receiver side it retrieves the messages and passes themonto the corresponding application tasks. We consider a set of static slots Si assigned to ECU Ei.For each Sj ∈ Si, there could be multiple FlexRay schedules for the slot depending on the repetitionrate and base cycle of the schedule. In the conventional design paradigm, the messages are staticallymapped to frames, which has a FlexRay schedule. Therefore, it is not possible to reconfigure thesystem when new data or different data are sent. Towards tackling this problem, in the middlewareproposed, we assign a base schedule Θj,base = (Sj, 0, 1) to each slot and assign a frame with max-

12

Header Trailer

Payload

Index field(optional)

Data field

Sender ECU

Receiver ECU

App1 App3 App4

1

m1

Data Mapping

App2

m3 m4

0 1 1 0

Data Mapping

Config

Config

m1 m3 m4

m1 m3 m4

App1 App3 App4App2

Frame

Figure 3.2: Data mapping component and the message to frame mapping

imum payload allowed for the slot, i.e., a longest possible frame is sent every communication cycleon the slot. The data mapping component is then responsible to cast the messages into the payloadof the frames according to a mapping table, which can be reconfigured online. For the data mappingcomponent to be able to map the messages into different schedules, the FlexRay communication cyclecounter needs to be known to the middleware. In this report, we consider the case where every ECUis synchronized to the FlexRay controller.

3.3.1 Framing

As shown in Fig. 3.2, the application data are packed into and unpacked out of the frame by thedata mapping component. The payload of a frame can be divided into two fields, the index field -which identifies the applications whose data are packed into the current frame - and the data field -which holds the actual messages. If the index field is used, the length of the index field depends onthe maximal number of applications that can be considered. One bit is assigned to each application.In this case, no configuration Cc needs to be deployed for a receiver ECU since it can determine

13

which message is packed into the frame based on the index field and manifest of the application.Alternatively, the configuration Cc can be deployed and stored on the receiver ECU, in which case anindex field is not necessary.

3.3.2 Packing Message

The mapping component on the sending side packs the messages of applications into the frame ac-cording to the configuration it holds. It sets the index field (if applied) according to configurationCc to indicate the application whose message is contained in this frame. Then it casts the messagesmapped on this frame into the data field of the payload. The messages in a frame is ordered accordingto the index of the applications. To keep the problem simple, if multiple messages are sent by anapplication, we put the messages together as a large single message.

3.3.3 Unpacking Message

The mapping component on the receiving side receives the frame and reads first the index field toknow the messages of which applications have been sent on the frame. Then it cast the data fieldinto the corresponding messages based on the application manifest and forward the messages to thecorresponding applications. Casting of the data field requires the knowledge of configuration Ca,which along with the manifest lets the receiver know of the expected width and type of the incomingdata. Note that if the index field is applied, configuration Cc does not need to be deployed on thereceiving side. Rather this configuration is indicated in the frame through the index field. An alternateimplementation could be that the configuration Cc is first deployed on the receiving side and the datamapping component can then cast the payload into messages according to Cc. In that case, an indexfield is not necessary.

Here we only described the sending and receiving side behavior of the data mapping component.If an ECU is simultaneously a sender and a receiver, the data mapping component will contain thefunction of both sides.

3.4 Configuration Deployment

The configuration deployment management component is responsible for the deployment of the con-figuration. The function of this component can be divided into two phases: (i) sending the configura-tion to all relevant ECUs and (ii) actual reconfiguration of the application tasks and the data mapping

14

component of the middleware. For phase (i), we introduce an additional configuration deploymentapplication acd, which is associated with a message mcd, which will be broadcast from the ECU host-ing the configuration calculator to all the relevant ECUs. This message contains Ca and Cc, whichcan be cast into a specific data type, possibly a bit stream. If the message is longer than the maximalpayload allowed, it can be segmented and transmitted on multiple frames and a signal is introducedto specify the start and end of the configuration transmission. This message can be mapped on areserved static slot with any valid repetition rate and can also share a slot with other messages usingslot multiplexing. Once the ECUs receive the configuration Ca and Cc (if Cc is necessary), it is storedand the ECUs wait for the synchronized reconfiguration time point. Until then, the ECUs continuethe communication according to the previous configuration. Once they reach the reconfiguration timepoint, i.e., in phase (ii), applications are switched to the new Ca, the current configuration at the datamapping component is overwritten with newCc and the ECUs resume their communication accordingto the new configuration.

Implementation issues: Let us consider the case of a particular ECU hosting I number of sender-applications, each having J possible modes. Also, we assume that S slots, each having maximumpayload capacity of W , have been allocated to the ECU. Hence, content of mcd are as follows:

• Ca: Modes of each application encoded in a binary string. If an application is currently switchedoff, the corresponding mode of the application is set to zero (invalid mode). Hence, number ofbits consumed by Ca is I × log2J .

• Cc: Slot number and base-cycle of messages generated by each application. Repetition-rateand width of the messages can be obtained from the modes and manifest of the applications.Hence, number of bits consumed by Cc is I × (log2S + log2H) where H is the number ofcommunication cycles in one FlexRay Cycle i.e. 64.

BothCa andCc are sent to the Data-Mapping components of the sender-ECU and relevant receiver-ECUs except in case of usage of index field, when Cc need not be sent to the receivers. Thus lengthof mcd can be represented as:

length(mcd) =

I × (log2J + log2S + 6) ,if index field not used

I × log2J ,otherwise(3.1)

15

If length(mcd) > W , then atleast⌈length(mcd)

W

⌉frames are required to complete the deployment to

the receiver.

3.5 State Transition

In order to ensure safe functioning of the applications, especially during reconfiguration, we proposea state management component to monitor and control the states of the whole system. The wholesystem can be described by one of the following states:

• Normal Operation (NO): The whole system runs normally with current configuration de-ployed both for the applications and the middleware layer. No reconfiguration request has beenmade.

• Configuration Calculation (CC): A reconfiguration request has been triggered by a certainevent and sent to the configuration calculator. The calculator is currently synthesizing the newconfiguration. The applications and the data mapping component run normally with currentconfiguration.

• Configuration Deployment: (CD): A valid new configuration has been calculated and passedon to the deployment management components of the relevant ECUs. During configurationdeployment, the applications and mapping component function according to the old configura-tion.

• Wait for Reconfiguration (WR): The deployment manager of all relevant ECUs now holdthe new valid configuration. All ECUs waits for the time point to perform a synchronizedreconfiguration.

The actions that trigger the state transition are as follows:

• (1) Reconfiguration request: This action is a signal sent by the reconfiguration request man-ager to the configuration calculator for the calculation of a valid new configuration.

• (2) Request denial: This action is triggered when either the configuration calculator is not ableto synthesize a feasible new configuration or the synthesized new configuration is identical tothe current one and no reconfiguration is necessary.

16

Normal Operation

ConfigurationCalculation

ConfigurationDeployment

Wait forReconfiguration

reconfiguration requestre

con

fig

ura

tio

n

fin

ish

ed

configuration deploymentfinished

new

co

nfi

gu

rati

on

rea

dy

request denial

Figure 3.3: State transition diagram

• (3) New configuration ready: The action is triggered once a valid new configuration is gener-ated by the configuration calculator and passed on to the deployment manager for configurationdeployment.

• (4) Configuration deployment finished: Once the new configuration is sent to all relevantECUs, this action is triggered and all ECUs waits for a synchronized time point to simultane-ously switch to the new configuration.

• (5) Reconfiguration finished: All ECUs have switched to the new configuration, the wholesystem then carries on functioning in the normal operation state.

Fig. 3.3 demonstrates the state transition diagram where the transitions are labeled by actions trig-gering a change of state. Fig. 3.4 shows the state transition during a reconfiguration process alignedwith the FlexRay communication cycles. As already mentioned, we consider the case where eachECU is synchronized to the FlexRay controller and the middleware can thus obtain the FlexRay cyclecounter. Once a reconfiguration request is triggered (Action 1), the configuration calculator takesthe request and starts to calculate a valid new configuration. The process of synthesizing this new

17

… … … … … … …

K - 1 K K + m K + m + 1

reconfiguration request

new configuration ready

configuration deployment

ready

reconfiguration finished

NO CC CD WR NO

old config new config

systemstate

configapplied

actions

Figure 3.4: Timing diagram for state transition

configuration may take a considerable amount of time, much larger compared to the FlexRay com-munication cycles. Let us assume that a new configuration is synthesized and available sometimein the (K − 1)th 64-cycle sequence (Action 3). Then the ECU where the calculator is mapped willstart transmitting the new configuration as a message to all relevant ECUs from the Kth sequence.We consider the case where m sequences are necessary for the transmission of the full configuration.Once this transmission is finished, the system waits for the (K + m)th sequence to finish (Action 4).At the beginning of the (K + m + 1)th sequence of 64-cycle, all relevant ECUs will simultaneouslyuse the new configuration and the whole system goes into the (NO) state (Action 5).

Implementation issues: We can prevent the arrival of a new configuration from the calculator duringconfiguration deployment triggered by the previous request by restricting an ECU from generating areconfiguration request when it is not in (NO) state. Also, number of sequences required for the trans-mission of full configuration depends on the repetition-rate of mcd. As we discussed in Section 3.4,multiple frames may be required to deploy the configuration. Hence the FlexRay cycle in which thelast such frame is received is labeled as the (k +m)th cycle and the reconfiguration is triggered fromthe next cycle.

3.6 Reconfiguration Request

There could be multiple reasons for a reconfiguration request. One example is that a newly installedapplication or an application that was not previously active needs to be activated online and thereforethe system needs to allocate the necessary communication resources for this application online. Con-

18

versely, a currently active application can be switched off and the resources can be utilized by otheractive applications to achieve better performance. Another example is that a currently active applica-tion needs to be switched to a mode offering higher performance. In all such cases, an event wouldtrigger the reconfiguration request manager to send a reconfiguration request to the configuration cal-culator and the calculator will then start synthesizing the new configuration based on the request andthe manifest of the applications. Such a request contains information about which applications shouldbe active, and the requested mode, if an application is requested to switch to a specific mode.

Implementation issues: Current on-off-configuration of the applications can be coded as a binary-string, hereafter referred to as active, whose length is same as the number of applications. If the nth

bit of active is 1 (or 0), the corresponding nth application at the sender-ECU is switched on (or off).At some point, if a change in configuration of application is desired i.e. some application may be re-quired to be switched on/off, the value of active is modified and sent to the configuration-calculator.Request for a change in mode of an application can be executed by setting the performance-level ofthe corresponding application in the manifest to infinity and resending active to the calculator.

3.7 Configuration Calculation

The configuration calculator is a software component that computes the configurationCa andCc usinga mathematical model of the mapping problem, which will be discussed in this subsection. Once thecalculator receives the request for a reconfiguration, it will start computing the configuration accord-ing to the request and the manifest of the applications. If a new valid configuration is obtained, it willpass this to the deployment management component and deploy the new configuration. If the newconfiguration is identical to the old one or no valid configuration can be obtained, no reconfigurationprocess will take place. This component can be implemented as a task which can be mapped on anyECU, provided the ECU can accommodate the transmission of the configuration. But this task usuallytakes much longer than application tasks and can last for a number of FlexRay communication cyclesor application periods. Depending on the operating system used (e.g., an non-preemptive operatingsystem), complications may arise when this task interferes with other application tasks. In that case,the configuration calculator can be mapped on a separate ECU.

Mathematical modeling of the configuration synthesis: Since the mapping of messages to commu-nication resources is independent for each ECU, the whole problem can be divided into subproblems

19

for each single sending ECU. Without loss of generality, we describe only the modeling of the prob-lem for a specific ECU. We consider that a set of applications ai ∈ A are sending messages. ThenCa can be defined as Ca = {αi|ai ∈ A}. As discussed in the subsection of data mapping, weput all messages of one application together into a large message, Cc = {mi(αi)|ai ∈ A}, wheremi(αi) = (wi, pi, (Si, Bi, Ri)). Since pi can be reasonably assumed to be a multiple of the communi-cation cycle, so pi = RiTbus. Therefore we can simplify the Cc into Cc = {(wi, Si, Bi, Ri)|ai ∈ A}.Additionally, wi and pi (thus Ri) will be obtained from manifest once αi is known. The input ofthe problem include (i) underlying communication resources, i.e., Sj ∈ S, where S denotes the setof static slots assigned to the ECU, (ii) the active applications and the requested mode if any, (iii)the application manifest. This problem of optimizing schedules of messages on static segment ofFlexRay has been extensively researched upon in recent years. Most common approaches includeBin Packing [10], Genetic Algorithm [11, 12], Linear Integer Programming [13], Non-Linear IntegerProgramming [14], Mixed-linear Integer Programming [15] and Constraint Programming Algorithms[16]. The problem is NP-complete [13, 15] and cannot be solved by optimization tools within a shortruntime. Although, all these solutions are based on application-tasks that run in only one mode. Inthis report, we present three possible solutions to the problem of message scheduling in a multi-modesystem: i. Integer Linear Programming (ILP) formulation, ii. a simple linear search method and iii.Two-Layer Linear-ILP formulation

3.7.1 ILP Formulation

The problem of an ILP formulation to pack messages into FlexRay slots is a well-studied subject. [10]has transformed this problem into a two-dimensional bin packing problem and provided an efficientILP formulation for it. We will use the majority of the constraints formulated in [10]. The differenceis that it does not consider a multi-mode application with different communication requirement andthe objective is to minimize the number of slots used, whereas we want to maximize the overall per-formance.The size of a bin is same as the size of one static slot, which is W × H , where W is the width ofeach slot and H is the number of communication cycles which is 64 in the case of FlexRay. Thetransformation converts message generated by each application ai running in mode αi = j into a rect-angular element of size hi,j × wi,j , where the height of each message is related to the repetition-rateas: hi,j = H

ri,j. If yi,j is the offset of this message on the y-axis of the bin, the level of the message is

given by li,j =yi,jhi,j

. In contrast to a common two-dimensional bin packing, the above transformation

20

has some additional constraints: height of all elements are a power of two, height of the bin is at leastthe maximal height of all elements and each element can be placed only on a multiple of its height onthe y-axis i.e. yi,j = li,j × hi,j with the level l ∈ {0, ..., H

hi,j− 1}.

To tackle the multi-mode problem, which essentially imposes a look-up table and difficult for linearformulation, we introduce a binary variable set {γi,j,k,l}, where i and j represent respectively the ap-plication index and the mode the application is running in. k and l represent the bin (i.e. slot) andlevel where mi is mapped. γi,j,k,l = 1 if application ai is running in mode j and mi is mapped in slotSi = k on a level l. A reverse-transformation function demonstrated in [10] can be used to obtainthe base-cycle of the message Bi from level l. Here, only active applications are considered and ifan application is requested to be operated on a specific mode, only the variables for that mode areintroduced. Sets of constants {ωi,j}, {φi,j}, {ψi,j} can be obtained from the manifest, which denoterespectively the data size, repetition rate (period divided by Tbus) and the performance of ai in modej. Thus the data size wi, repetition rate Ri and the performance Ji can be represented respectivelyas wi =

∑j ωi,j

∑k,l γi,j,k,l, Ri =

∑j φi,j

∑k,l γi,j,k,l, Ji =

∑j ψi,j

∑k,l γi,j,k,l. Now the ILP can be

formulated as follows:

max∑ai∈A

λiJi (3.2)

∀ai ∈ A,∑

j∈Gi,k∈S,l∈L

γi,j,k,l = 1 (3.3)

∀k ∈ S,∀l ∈ L∑

ai∈A,j∈Gi

ωi,jγi,j,k,l ≤ W (3.4)

Here Eq. 3.2 is the objective function to maximize the overall performance value of the system, whichis represented as a weighted sum of the performance value of each individual application, where theweight of ai is denoted as λi. Constraint (3.3) enforces the condition that each application can runin only one mode and that the message can only be mapped into one specific bin and at one specificlevel. Constraint (3.4) ensures that the packed data does not exceed the payload of the frame, whereW denotes the maximal available payload of a static slot. Here, instead of minimizing the slots used,we only need a feasible schedule that maximizes the performance level of the system. If a feasiblesolution exists, the ILP solver will return values of slot si and level li for all applications runningaccording to one mode combination. Base cycles Bi can be obtained from the levels using a transfor-mation function as demonstrated in [10].

21

Transformation Function: This section describes a one-to-one transformation between the slot pack-ing problem that arises from the FlexRay cycle multiplexing and a special form of a two-dimensionalbin packing problem. Since each slot corresponds to one bin, the transformation is presented for asingle slot to a single bin and vice versa. In our work we have assumed that each ECU has beenprovided with a fixed number of FlexRay Static Slots, which remains constant for the entire durationof its life-cycle. This assumption is in compliance with the current automotive industry, where theslot-allocation to ECU is altered very rarely since it requires shutting down the entire system andresetting the FlexRay configuration.

Each static slot is defined by the payload size W (without the reserved load for the AUTOSARspecific update bits) and the number of cycles H which is 64 for the FlexRay bus. In our problem, theknown parameters of a message component of an application i are:

• si: The assigned FlexRay Static Slot ID

• ri: Repetition rate of the message

• wi: Width of the message in bytes

For a feasible slot packing, other two parameters of message have to be determined:

• xi: The offset in bytes on the x-axis

• bi: The base cycle that defines offset on the y-axis

The task of the transformation of the slot packing into a bin packing is to convert each messageinto a rectangle element and determine its position such that each feasible slot packing results ina feasible bin packing and vice versa. The bin size is the same as the slot size with the width Wand height H . Also the position on the x-axis xi and the width wi for each message generated byapplication i correspond to the position and width of the message in the slot packing. Therefore, themain task is to find a transformation that obtains the following two values for each message:

• yi ∈ N : The offset on the y-axis in the bin

• hi ∈ N : The height of a message in the bin

22

The transformation for the height hi is related to the repetition ri as follows:

hi =H

ri(3.5)

Thus, the height of an element in the bin equals the number of appearances of the correspondingmessage in the H cycles.

In the bin-packing problem, the yi position is restricted to ri individual levels, depending on theheight of the message. Level of a message is denoted by li and is defined by the following equation.

li =yihi

(3.6)

The following transformation function t : N0 × N → N0 , has been considered for transformingthe slot packing problem to bin packing problem.

t(x, y) =

0 if x = 0

t(x2, y2) if x is even

t(x−12, y2) + y

2if x is odd

(3.7)

with

y ∈ {2n|n ∈ N0} (3.8)

0 ≤ x < y (3.9)

x ∈ N0 (3.10)

The transformation function t directly transforms the level of a message li to the base bi and viceversa, such that the following two equations hold:

li = t(bi, ri) (3.11)

bi = t(li, ri) (3.12)

23

Proof of correctness of this transformation function is given in [10].

3.7.2 Linear Search Method

In the linear search method, all possible combinations of modes Ca = {αi} are traversed and acombination is feasible if a valid Cc = {wi, Si, Bi, Ri} can be obtained. The mode combination Ca

with highest performance and its corresponding Cc is returned as the output of this component. Theexhaustive search on the entire solution space can be more efficient compared to the ILP method ifthe number of variables is very small. Let us consider that an ECU has been allocated S slot andis hosting I application each running in J modes. Then the maximum number of data points on thesolution space in case of linear search is 64 × I × J × S = T , whereas in case of ILP method thenumber of data points is 2T .

3.7.3 Two-Layer Linear-ILP Formulation

This method divides the problem into two layers. In the upper layer, we traverse possible modecombinations, which are determined by the active applications and mode request. Here we considera set of mode combinations, where the kth mode combination can be represented as Ca,k = {αi}k ∈Ca. The corresponding data width {wi}k, repetition rate {Ri}k and performance value {Ji}k canbe obtained from the manifest. We consider the total performance of a mode combination to beJtotal,k =

∑λiJi, where λi is the weight of ai. In the lower layer, for each mode combination, we

will use the bin-packing problem according to [10] to solve for feasible schedules. The lower layerILP problem can be formulated as follows.

Similar to the first method, the size of a bin is the same as the size of one static slot: W × H ,where W is the payload length of a slot and H = 64 is the number of communication cycles in asequence. The transformation from slot-packing to a bin-packing problem [10] converts a messagemi into a rectangular element of size hiwi. The height of each message is related to the repetition rateas: hi = H/Ri. If yi is the offset of this message on the y-axis of the bin, the level of the message isgiven by li = yi/hi. In contrast to a common two-dimensional bin packing, the above transformationhas some additional constraints: height of all elements are a power of two, height of the bin is at leastthe maximal height of all elements and each element can be placed only on a multiple of its heighton the y-axis, i.e., yi = lihi. A set of binary variables {γi,s,l} denoting mi is mapped on slot s and at

24

level l are introduced. The constraints of the problem can be formulated as

∀ai ∈ A,∑

s∈S,l∈{0,...,Ri−1}

γi,s,l = 1 (3.13)

∀s ∈ S, y ∈ {0, ..., H − 1}∑ai∈A

wiγi,s,⌊

yhi

⌋ ≤ W (3.14)

where constraint (3.13) forces each message to occur exactly once among all bins (static slots) andconstraint (3.14) ensures that each bin is not overloaded. Here, instead of minimizing the slots used,we only need a feasible schedule. If a feasible schedule for the kth mode combination exists, thesolver will return values of slot Si and level li for each message and Bi can be obtained from li. If thekth mode combination does not allow a feasible schedule, the corresponding performance value is setto zero, i.e., Jtotal,k = 0. The mode combination Ca with highest performance and its correspondingCc is returned as the output of this component.

This method requires the first level to generate all possible combinations of modes and store thecorresponding schedule and performance level for each mode, i.e., if there are I applications eachhaving J possible modes then the space complexity of the first level is exponential w.r.t to the numberof applications (J I). Although, the number of data points on the solution space of ILP is reduced bya factor of J .

Implementation issues: Output of this component can be encoded into a binary string, referred to asNewSchedule, before being sent to the relevant ECU. The new configuration consists of the followingparameters:

1. Optimized mode of the currently active applications. If there are J modes possible for eachapplication, number of bits required to express the desired mode of an application is log2J .

2. Static Slot number in which the applications can send the messages. This is required whenmore than one static slot has been assigned to the sender-ECU. If S slots are available fortransmission, number of bits required to express the slot number of a message is log2S.

3. Base or communication-cycle-offset of the application message. We know that a Flexray Cycleis divided into 64 communication cycles. Hence, the number of bits required to represent thebase of an application message is log264 = 6.

25

If the number of applications at the sender-ECU is I , length of NewSchedule can be computed asfollows:

length(NewSchedule) = I × (log2J + log2S + 64) (3.15)

In the next chapter we are going to discuss the hardware implementation of a simple case study,where we require the configuration-calculator component to be coded as an embedded-matlab func-tion or a matlab S-function. If we choose to implement a method based on ILP formulation, we needto have an ILP-solver which has been written according to the format of an S-function. Till now, wedo not have any such solver available as an open-source distribution. Moreover, linear search methodproduces the optimum schedules faster compared to an ILP method in software simulation when weconsider 3-4 applications. An inherent limitation of the current tool-chain and the requirement of asimple case study implied the usage of linear seach method during design of this component. Al-though, a correct mathematical formulation along with a successful software simulation using theILP method suggests that a tool-chain supporting a function-call to an extrinsic matlab function froman S-function can allow a simple hardware implementation of an ILP-based calculator. An alterna-tive solution can be allowing the ILP-based calculator to run on a computer with matlab-compilerinstalled in it. This computer can interface with all relevant ECUs, collecting reconfiguration requestsand generating optimized schedules.

It should be mentioned that in all three cases as the size of the problem increases, the computationtime will increase greatly. However, as mentioned above, this packing problem is well-studied andmore efficient algorithm to solve this problem and the optimization of the computation time is not thefocus of this work.

26

Chapter 4

Experimental Results

4.1 Case Study

In this section, we use a case study to demonstrate the function of the communication middlewareproposed in this report. We first explain the system setup, how the performance values can be ob-tained and then a series of steps of reconfiguration requests to be triggered. In the case study, weconsider a synthetic system consisting of four applications a1 to a4 mapped on two ECUs, E1 and E2.Each application has three different modes. Table 4.1 shows the communication manifest of the appli-cations, containing the data size per message in bytes, message period and the performance value foreach mode. All messages are sent from E1 to E2. We consider the weights of performance values forall applications to be equal. If multiple mode combinations have the best performance, the calculatorchooses any one of them. FlexRay is configured to have a communication cycle of Tbus = 10ms.Each static slot allows a maximal payload length of 16 bytes and two static slots are assigned to E1

statically. Here we represent the two slots as s1 and s2.

4.1.1 Evaluation of Performance

The performance value of each mode should be specified by the application designer. Here we il-lustrate how a set of performance values can be obtained. We consider in this case application a2and a4 as control applications and application a1 and a3 as realtime applications. The performancefor control applications is measured by the control performance and we assume that the performanceof the realtime applications are directly proportional to the average amount of data transmitted perFlexRay communication cycle. Then we normalize the performance according to a scale of 100. Forthe control applications we consider a feedback control system with one sampling period delay. The

27

a1 a2 a3 a4α1 w1 p1 J1 α2 w2 p2 J2 α4 w3 p3 J3 α4 w4 p4 J41 16 Tbus 100 1 8 Tbus 100 1 16 Tbus 100 1 8 Tbus 1002 16 2Tbus 50 2 8 2Tbus 56 2 8 Tbus 50 2 8 2Tbus 563 8 2Tbus 25 3 8 4Tbus 34 3 4 Tbus 25 3 8 4Tbus 34Off 0 Off 0 Off 0 Off 0

Table 4.1: Communication manifest of the applications in the case study

discrete control system with one sample delay can be represented as

x[k + 1] = Ax[k] +Bu[k], (4.1)

where x[k] is the feedback states of the control plant and u[k] = Kx[k − 1] + Fr is the control inputfor one sample delay. Here r is the reference value, K and F are respectively the feedback and feedforward gain. Let y[k] = Cx[k] represents the output. The performance of the control application canbe defined as [17]

J =∑||y[k]− r||2. (4.2)

We then take the reciprocal of this performance to represent the performance of the control appli-cations. Here we use a DC motor speed control plant model in the case of step response to referencer. The feedback and feed forward gains are designed using the method discussed in [18]. We assumethat the sensor task is mapped on one ECU while the controller and actuator tasks are mapped on theother. The sensor data are transmitted on the FlexRay bus. For each sampling period, we find a set ofgains that optimizes the performance. The performance of each application with respect to the modeobtained through simulation is shown in Fig. 4.1. In the experiment we will use these performancevalues.

4.1.2 Example of a Reconfiguration Request Series

Here we demonstrate the function of the proposed middleware by injecting a series of pre-programmedreconfiguration requests and show the results of the reconfiguration. The reconfiguration requests areshown as follows:

• Init Step: All applications are switched off

• Step 1: Request to switch on a1

28

Modes1 2 3 0ff

No

rmal

ized

per

form

ance

0

20

40

60

80

100Perf of a

2, a

4

Perf of a1, a

3

Figure 4.1: Normalized performance of the applications for all modes

• Step 2: Request to switch on a2

• Step 3: Request to switch on a3

• Step 4: Request a3 to run in mode α3 = 1

• Step 5: Request to switch on a4

• Step 6: Request a4 to run in mode α4 = 1

• Step 7: Request to switch off a3

• Step 8: Request to switch on a3

4.2 Hardware Implementation

The case study is implemented in a hardware system using three EB6120 ECUs [19]. Here we usetwo EB6120 ECUs to serve as E1 and E2. Since we use a non-preemptive operating system, in order

29

Figure 4.2: Application Tasks designed during modeling of the ECUs

to prevent interference on the schedules of application tasks on E1 and E2, we map the configurationcalculator on an extra ECU E3. The software including a prototype of the proposed communica-tion middleware, is developed using a commercial off-the-shelf tool chain - Matlab/Simulink andSIMTOOLS/SIMTARGET toolbox [20]. In this tool chain, software for application tasks are devel-oped using Simulink blocks as shown in Fig. 4.2 and the SIMTOOLS/SIMTARGET toolbox is usedto provide interfaces between the application software and the underlying operating system and theFlexRay communication. These interfaces include the schedules of tasks, the mapping of signals ontoFlexRay frames, etc.. The FlexRay communication is configured using the SIMTOOLS blocks. ThenSIMTARGET is used to generate binary files for the ECUs from the Simulink models. The middle-ware for the case study is implemented with Simulink blocks including Matlab embedded functionblocks. The configuration calculator is implemented according to the linear search method and forthe framing in the data mapping component, we adopted the alternative without the index field.

30

Steps a1 a2 a3 a4 Systemα {S,B,R}J α {S,B,R}J α {S,B,R}J α {S,B,R}J Jtotal Javg.

0 off 0 off 0 off 0 off 0 0 01 1 {s1, 0, 1} 100 off 0 off 0 off 0 100 1002 1 {s2, 0, 1} 100 1 {s1, 0, 1} 100 off 0 off 0 200 1003 1 {s2, 0, 1} 100 1 {s1, 0, 1} 100 2 {s1, 0, 1} 50 off 0 250 834 3 {s2, 0, 2} 25 1 {s2, 0, 1} 100 1 {s1, 0, 1} 100 off 0 225 755 3 {s1, 1, 2} 25 1 {s1, 0, 1} 100 1 {s2, 0, 1} 100 2 {s1, 0, 2} 56 281 706 3 {s1, 1, 2} 25 2 {s1, 0, 2} 56 1 {s2, 0, 1} 100 1 {s1, 0, 1} 100 281 707 1 {s2, 0, 1} 100 1 {s1, 0, 1} 100 off 0 1 {s1, 0, 1} 100 300 1008 3 {s1, 1, 2} 25 1 {s1, 0, 1} 100 1 {s2, 0, 1} 100 2 {s1, 0, 2} 56 281 70

Table 4.2: Communication request of the applications in the case study

4.3 Results and Discussions

In this case study, the communication resources available for the four applications are not sufficientfor all applications to run in their best mode. The relationship between the application modes andthe required communication resources is shown in Fig. 4.3. If all the applications run in the bestmode, an average of 48 bytes of data per communication cycle are required to accommodate all themessages. However, only 32 bytes per communication cycle are available. Furthermore, even if theaverage of 32 bytes are required, the messages might still not be schedulable using slot multiplexing.An alternative is to over-provision communication resources for the applications, although not allapplications always need to run in the best mode, in which case it would lead to inefficient utilizationof communication resources.

Table 4.2 shows the reconfiguration of the system according to the series of request steps. Themodes of and performance values of applications for each step are shown respectively in Fig. 4.4and Fig. 4.5. From this table and the two figures, we can observe the application mode switch in thewhole series of reconfiguration steps. From step 1 to step 3, a1 to a3 are incrementally switched on.In step 1 and step 2, the assigned slots can accommodate the applications in their best mode and theoverall performance value rises. In step 3, when a3 is switched on, not all applications can run intheir best mode due to inadequate resources. Therefore the configuration calculator has synthesized aconfiguration placing a1, a2 and a3 respectively in modes 1, 1 and 2. In step 4, a3 is forced to run inmode 1, and taking this into account, a1 is switched down to mode 3 to release resources for a3. Notethat in this case, the overall performance value drops from 250 in step 3 to 225. This is because theconfiguration synthesized here is not the one with the best overall performance, since it is constrainedthat a3 has to run in mode 1. Then when additionally a4 is activated and the condition for a3 is

31

Applications

a1

a2

a3

a4

Ave

rag

e d

ata

rate

[b

yte

per

Tb

us]

0

5

10

15

20Mode 1Mode 2Mode 3Off

Figure 4.3: Data rate requirements for different modes of applications. This requirement is denotedas average number of bytes per communication cycle

removed, the whole system switched to a case where the four applications run respectively in mode3, 1, 1, 2, which offers the best overall performance value when all 4 applications are active. Similarto step 4, in step 6, a4 is forced to run in mode 1, and to reallocate the communication resources forthis, a2 is switched down to a mode with lower performance. Step 7 demonstrates the behavior ofthe system when an application is deactivated. When a3 is switched off, the rest of the applicationswould be able to switch to their best mode. Note that here the overall performance is better than instep 5 and step 6. This is because such a mode combination is not available for step 5 and 6, sincethere all 4 applications need to be active. In the final step, when a3 is switched on again, the wholesystem returns to the configuration in step 5, where the requirement is identical.

From the experimental results, we can see that the proposed communication middleware can bereconfigured to reallocate the communication resources within an ECU to enable resource sharingbetween multi-mode aplications in a FlexRay-based distributed system at runtime. The configurationcan be synthesized and deployed according to a request and optimize the overall performance whilecomplying to the constraints specified in the request.

32

Reconfiguration stepsInit 1 2 3 4 5 6 7 8

Mo

des

Off

3

2

1

Mode a1

Mode a2

Mode a3

Mode a4

Figure 4.4: Application modes in all reconfiguration steps

Reconfiguration stepsInit 1 2 3 4 5 6 7 8

Per

form

ance

0

50

100

150

200

250

300

350

400Perf a

1

Perf a2

Perf a3

Perf a4

Perf totalPerf avg.

Figure 4.5: Performance value of each application and the overall performance in all reconfigurationsteps

33

Chapter 5

Concluding Remarks

This report demonstrates a middleware layer and its implementation using commercial tools, that al-low a dynamic reconfiguration of applications whose messages are scheduled on the static segment ofFlexRay. Future work may generalize this idea by extending the middleware layer to accommodatescheduling of application data on the underlying bus following any communication protocol. Thiswill allow selection of the type of communication medium used by an application at run-time, whichwill increase the fault-tolerance of the medium along with better optimization of the performance ofapplications.Current design of the middleware layer for the time-triggered messages can also be improved byinstalling a more efficient configuration calculator component on the hardware. Most solutions forthe slot-packing problem works fine on software simulation but they are very hard, if not impossibleto implement on the available tool-chain. Another drawback of the current model is a possibilityof involuntary switching-off of comfort-applications due to mode switch of a safety-critical applica-tion during reconfiguration. This can be avoided by shifting the periodic messages of the comfort-applications onto the dynamic segment of FlexRay at run-time, which will require a more advanceddata-mapping component.

34

References

[1] Philipp Mundhenk, Florian Sagstetter, Sebastian Steinhorst, Martin Lukasiewycz, and SamarjitChakraborty. Policy-based message scheduling using flexray. In 2014 International Conference

on Hardware/Software Codesign and System Synthesis, CODES+ISSS 2014, Uttar Pradesh,

India, October 12-17, 2014, pages 1–10, 2014. doi: 10.1145/2656075.2656094. URL http:

//dx.doi.org/10.1145/2656075.2656094. 3

[2] Linh T.X. Phan, Insup Lee, and Oleg Sokolsky. A semantic framework for mode change pro-tocols. In 2011 17th IEEE Real-Time and Embedded Technology and Applications Symposium.IEEE, 2011. 3, 8

[3] Lui Sha, Ragunathan Rajkumar, John Lehoczky, and Krithi Ramamritham. Mode change pro-tocols for priority-driven preemptive scheduling. Real-Time Systems, 1(3):243–264, 1989. 3,8

[4] Jorge Real and Alfons Crespo. Mode change protocols for real-time systems: A survey and anew proposal. Real-time systems, 26(2):161–197, 2004. 3, 8

[5] Gerhard Fohler. Changing operational modes in the context of pre run-time scheduling. IEICE

Transactions on Information and Systems, 76(11):1333–1340, 1993. 3, 8

[6] Giorgio C Buttazzo, Giuseppe Lipari, and Luca Abeni. Elastic task model for adaptive ratecontrol. In Real-Time Systems Symposium, 1998. Proceedings., The 19th IEEE, pages 286–295.IEEE, 1998. 3

[7] Youngsoo Shin, Daehong Kim, and Kiyoung Choi. Schedulability-driven performance analy-sis of multiple mode embedded real-time systems. In Design Automation Conference, 2000.

Proceedings 2000, pages 495–500, 2000. doi: 10.1109/DAC.2000.855361. 3

35

[8] Kay Klobedanz, Andreas Koenig, and Wolfgang Mueller. A reconfiguration approach for fault-tolerant flexray networks. In Design, Automation & Test in Europe Conference & Exhibition

(DATE), 2011, pages 1–6. IEEE, 2011. 4

[9] FlexRay Consortium et al. Flexray communications system protocol specification version 2.1.Request online: http://-www. flexray. com/specification request. php, 2005. 6

[10] Martin Lukasiewycz, Michael Glaß, Jurgen Teich, and Paul Milbredt. Flexray schedule opti-mization of the static segment. In Proceedings of the 7th IEEE/ACM international conference

on Hardware/software codesign and system synthesis, pages 363–372. ACM, 2009. 20, 21, 24

[11] Shan Ding, Naohiko Murakami, Hiroyuki Tomiyama, and Hiroaki Takada. A ga-based schedul-ing method for flexray systems. In Proceedings of the 5th ACM international conference on

Embedded software, pages 110–113. ACM, 2005. 20

[12] Shan Ding, Xiaona Yin, Hongming Xu, and Shi Zhang. A hybrid ga-based scheduling methodfor static segment in flexray systems. In Control and Decision Conference (CCDC), 2010 Chi-

nese, pages 1548–1552. IEEE, 2010. 20

[13] K. Schmidt and E.G. Schmidt. Optimal message scheduling for the static segment of flexray.In Vehicular Technology Conference Fall (VTC 2010-Fall), 2010 IEEE 72nd, pages 1–5, Sept2010. doi: 10.1109/VETECF.2010.5594407. 20

[14] Klaus Schmidt and Ece Guran Schmidt. Message scheduling for the flexray protocol: The staticsegment. Vehicular Technology, IEEE Transactions on, 58(5):2170–2179, 2009. 20

[15] Haibo Zeng, M. Di Natale, A. Ghosal, and A. Sangiovanni-Vincentelli. Schedule optimization oftime-triggered systems communicating over the flexray static segment. Industrial Informatics,

IEEE Transactions on, 7(1):1–17, Feb 2011. ISSN 1551-3203. doi: 10.1109/TII.2010.2089465.20

[16] Zheng Sun, Hong Li, Min Yao, and Nan Li. Scheduling optimization techniques for flexrayusing constraint-programming. In Green Computing and Communications (GreenCom), 2010

IEEE/ACM Int’l Conference on Int’l Conference on Cyber, Physical and Social Computing (CP-

SCom), pages 931–936, Dec 2010. doi: 10.1109/GreenCom-CPSCom.2010.111. 20

[17] Reinhard Schneider, Dip Goswami, S. Zafar, Martin Lukasiewycz, and Samarjit Chakraborty.Constraint-driven synthesis and tool-support for flexray-based automotive control systems.pages 139–148, 2011. 28

36

[18] Dip Goswami, Reinhard Schneider, and Samarjit Chakraborty. Relaxing signal delay constraintsin distributed embedded controllers. IEEE Trans. Contr. Sys. Techn., 22(6):2337–2345, 2014.doi: 10.1109/TCST.2014.2301795. URL http://dx.doi.org/10.1109/TCST.2014.

2301795. 28

[19] Elektrobit. www.elektrobit.com. 29

[20] SIMTOOLS/SIMTARGET. www.simtools.at. 30

37