Mapping multiple MATLAB Simulink applications to a Real-TimeOperating System using a Hierarchical Scheduling Framework

Mapping multiple MATLAB Simulink applications to a Real-TimeOperating System using a Hierarchical Scheduling Framework

Internship Report of J.G.S. van UdenFebruary 19, 2013, version 1.1

Automotive TechnologyInMotion

Contents

1 Introduction 3

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Report structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Requirements 6

2.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Quality requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Platform requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 Process requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Design 8

3.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Domain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4 Merge tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Implementation 12

4.1 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 Merge tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Conclusion 17

6 Future Work 18

Bibliography 19

Acronyms 20

Appendix A: Tool chain user manual 21

2


1 Introduction

1.1 Motivation

Automobiles have become very complex systems which contain many control systems. The controlstrategies for these systems are usually implemented by Matlab Simulink applications. In order toactually use these applications on an Electronic Control Unit (ECU), code needs to be generatedfrom these applications. A tool that provides this functionality is the Matlab Embedder Coder,however still much code needs to be added or altered by hand. This is usually done by softwareengineers, while the applications themselves are developed by control engineers. It would bedesirable if a tool chain was available in which most of the process of creating code from a MatlabSimulink application is automated in such a way that this process can be performed by the controlengineers that designed the applications. However this is hard to accomplish due to the variety ofECUs that exist and their differences.

Furthermore many resources get wasted in automotive systems because it is common that eachapplication that represents a certain function runs on its own ECU [2], some of which couldeasily share the resources of a single ECU. Because of the ever growing complexity of the entiresystem due to the increasing number of ECUs [3], it is desirable that different functions andthus applications will be integrated on just a few ECUs. The growth of the number of ECUs inpremium cars over the years is illustrated in Figure 1.1. According to an article by Robert N.Charette [1] from February 2009, the average number of ECUs in a premium car around thattime was already about 70 to 100. Furthermore it is stated that all these ECUs together needsomewhere around 100 million lines of code to be programmed and if this trend will continue, carswill need somewhere around 200 to 300 million lines of code in the near future.

Figure 1.1: The number of ECUs in several cars over the years [7]

3


The reliability of cars decreases when the number of ECUs, and therefore also the total lines ofcode, in a car increases. This has two major reasons. First, the number of errors in the softwareincreases with the total lines of code. Secondly, the more ECUs a car has, the more wires andconnectors are needed to connect them. Connectors and wires are common points of failure in acar. This calls for change.

AN

GS

LS LS LS...

T11 T21 Tx1... T1N T2N TxN...

T12 T22 Tx2...

A2A1

Figure 1.2: Hierarchical Scheduling Framework

A change from federated toward integrated architectures will reduce the overall complexity of thesystem [4] and therefore improve reliability. However, from an application viewpoint it would bedesirable if each application gets its own virtual ECU that can guarantee certain performanceaspects. These applications will need to be scheduled on this platform (on a global level). Sinceits very common that a single application consists of multiple tasks, these tasks also need to bescheduled (on a local level). A suitable solution is to use a Hierarchical Scheduling Framework(HSF) consisting of a global scheduler (GS) to schedule different applications on the platform andlocal schedulers (LS) to schedule the tasks within the applications. The basic structure of an HSFis shown in Figure 1.2.

The mapping of multiple applications on a single ECU, as described above, is not supportedby the Matlab Embedder Coder itself, however the Matlab Embedder Coder could be used as apart of a tool chain that does support the mapping of multiple applications.

1.2 Goal

The goal of this internship is to create a tool chain that can map multiple Matlab Simulinkapplications to a hardware platform, using a Real-Time Operating System (RTOS) combinedwith an HSF. In this way multiple applications can share a single hardware platform, while each

4


application runs on its own virtual platform. The target is to automate this process on sucha level that the tool chain can be used by control engineers with little knowledge of softwaredevelopment. This internship is conducted within the System Architecture and Networking (SAN)group. This is a research group within the Computer Science department at the EindhovenUniversity of Technology. The internship is conducted in collaboration with InMotion. InMotion isa spin-off company at the Eindhoven University of Technology that is building a high-performanceseries-hybrid race car.

1.3 Report structure

This report describes the implementation of a tool chain that enables the user to map MatlabSimulink applications to a hardware platform, that runs an RTOS combined with an HSF. Inthis chapter it is explained why such a tool chain is desirable and what its goal is. Chapter 2describes the requirements for the tool chain. The design and structure of the tool chain areillustrated in chapter 3. Implementation details of the merge tool that has been created withinthe tool chain can be found in chapter 4. The conclusion can be found in chapter 5. Finally therecommendations and points for future improvement are described in chapter 6.

5


2 Requirements

2.1 Functional requirements

• FR1. The system can map multiple applications to a single platform. This is thehighest level goal of the system.

• FR2. The system accepts multiple Matlab Simulink models as inputs. The specifictype of application that the system can process are Matlab Simulink models, the system iscurrently not be usable for any other types of applications.

• FR3. The system produces C code as an output. The output of the system is C codethat can be used to program the target platform.

• FR4. If the system for some reason encounters an error, the user must be notifiedstating the type of error and suggested action. If the user is not notified after a failure,or the user receives a general error, the user will have no clue to what went wrong and howto remedy the error. The error notifications supports usability.

• FR5. When the system has finished successfully, the user must be notified. If theuser is not notified after a successful execution, the user will have no clue if the system isalready finished, or when it’s finished. The notification supports usability.

2.2 Quality requirements

• QR1. The system uses only a single tool outside the Matlab environment. Thissupports efficiency, usability and maintainability. If more than one separate tool is be usedoutside the Matlab environment, the system will be harder to use by the user, since moreuser intervention will be required. In this way the user can efficiently convert the applicationto C code. If additional functionality or bug fixes are required it’s more convenient to dothis in one place than in multiple tools.

2.3 Platform requirements

• PlR1. The platform used is a Freescale EVB9512XF board. The Freescale EVB9512XFplatform is currently used by the SAN group for various educational and research purposes.There’s much technical knowledge and experience with this platform.

• PlR2. The RTOS used is µC-OS/II. The µC-OS/II RTOS has been ported to theFreescale EVB9512XF platform by the SAN group and is currently used for various educationaland research purposes. There’s much technical knowledge and experience with this RTOS.

6


• PlR3. The HSF used is based on the RELTEQ framework created by M. Holenderski[5]. The RELTEQ HSF has been developed within the SAN group and is currently usedfor various educational and research purposes. There’s much technical knowledge andexperience with this HSF.

2.4 Process requirements

• PrR1. The programming language used for development is Visual C++. It hasbeen chosen to develop the system in Visual C++. This allows to create a Graphical UserInterface (GUI) that can be used on Microsoft Windows computers, using the same visualobjects that Windows users are used to work with. Since the system is intended for usersthat have little knowledge about software, using a familiar graphical interface will supportthe effectiveness of the system.

• PrR2. The application specific code in the system will be generated by MatlabEmbedder Coder. In this way the built-in capabilities of Matlab to produce code directlyfrom a Simulink application can be used in the system. This supports reusability since theapplication-specific code can completely be reused.

• PrR3. The system and manual will be delivered before the 9th of February 2013.

7


3 Design

3.1 Related Work

3.1.1 µC-OS/II

As stated in requirement PlR2 in section 2.3, the system that has been designed uses the µC-OS/IIRTOS. Besides the fact that there is already much experience and knowledge within the SANgroup using µC-OS/II, this RTOS has another great advantage for use in automotive systems. Thesource of µC-OS/II follows 99% of the Motor Industry Software Reliability Association (MISRA) Ccoding standards. The MISRA standards have the goal to improve the reliability and predictabilityof C programs in critical automotive systems [6]. This makes the µC-OS/II RTOS a solid basefor automotive applications.

3.1.2 RELTEQ

As stated in requirement PlR3 in section 2.3, the system that has been designed uses the HSFbased on RELTEQ. In Multi-Resource Management in Embedded Real-Time Systems [5] it isstated that the goal of RELTEQ is to extend the RTOS µC-OS/II with an HSF. The HSF basedon RELTEQ enables µC-OS/II to use fixed-priority preemptive scheduling of the servers on aglobal level and also to use fixed-priority preemptive scheduling of the tasks within the servers.Therefore the RELTEQ framework offers all the desired possibilities in order to schedule differentapplications on a global level and the tasks within an application on a local level on a single ECU.The RELTEQ framework uses servers. Each server represents a virtual ECU and in this researcheach server hosts a single application. Multiple servers are scheduled on a single ECU. In this waythe applications virtually have their own ECU, while actually they’re all running on the same ECU.

3.1.3 Embedded Coder

In order to generate C code from the Matlab Simulink applications, the Matlab Embedded Coder isused. Custom code-generation templates are available within the SAN group in order to generateapplication-specific code embedded in the RELTEQ framework. These templates have been usedas a base for this system as well. The templates allow the user to create custom C code togetherwith application-specific code. For the final implementation of the system, the templates usedby the SAN group have been modified in order to pass the desired information from the MatlabSimulink Models to the other parts of the system that need it. More information about the useof these templates is described in section 4.1.

8


3.2 Domain Analysis

In order to create a suitable design for the system, a class diagram of the domain has been createdfirst, which is shown in Figure 3.1. This class diagram is used to determine which information,that is needed to merge the Simulink models, is available in which step of the process. In thisdiagram, only the relevant attributes in order to make design decisions about the system are takeninto account.

Generated from templates

-Name-Inputs-Outputs-Process description

Applications

-Name-Priority-Budget-Period-Type

Server

-ID-Priority-Sample Time-Offset

Task

-CPU-Memory-RTOS

Platform

-OSClock-Servers-Tasks

RTOS

-Name-Inputs-Outputs-Task Sample Times-Task Offsets-Process description

Simulink Model

1

0..*

1

0..*

1

1

Figure 3.1: Class diagram of domain

In the top left of Figure 3.1, the applications are defined as a generic class, a more specific classof applications, which is used in the system to be designed, are the Simulink models. TheseSimulink models contain additional information about the tasks that can be created from it. Foreach control loop with a certain sample time in the Simulink model, a separate task is createdby the Embedded Coder. If a Simulink model only uses a single sample time, the entire model iscreated as a single task. Also for each Simulink model a server will be created by the EmbeddedCoder. In this way a server can run a single task or multiple tasks, depending on the number ofsample times used in the Simulink model.

The tasks that are generated from the Simulink model and that are assigned to a certain serveralso need to have a unique priority in order to be able to run along each other on that server inthe RELTEQ framework. These priorities are not present in the Simulink models. However, theyare generated by the Embedded Coder templates based on the task ID.

9


The servers that are generated within the RELTEQ framework need to have a priority, budget,period and type. None of this information is present in the Simulink model. The server periodis indirectly derived from the Simulink model by the Embedded Coder templates, by taking theperiod of the fastest task. The other information needs to be given by the users. This means thatthe system needs to provide some kind of user interface (UI) so this information can be entered.

Furthermore, a restriction on the applications that are used as an input to the system is that theseapplications must be independent. Investigation of the complications that dependent applicationsintroduce are outside the scope of this research. When dependent applications are used, currentlyno performance guarantees can be given as applications may still influence each other.

3.3 Structure

Given the domain analysis in section 3.2, a suitable solution that meets the requirements describedin chapter 2 is to design a tool chain in which the information that is already available in MatlabSimulink is passed to a second tool. The information that has to be given by the user can beentered in the graphical user interface (GUI) of a this second tool. The first tool in the tool chainwill be the Embedded Coder, making use of modified templates in order to pass on the desiredinformation. The second tool will be a separate merge tool, which merges the individual piecesof code created by the Embedded Coder and allows the user to alter information and enter themissing information.

.c\.h .c\.h

main.c

Embedded Coder

<model2> \ert main.c<model1> \ert main.c

<model2>.mdl<model1>.mdl

Matlab Simulink

Matlab Embedded

Merge Tool

Legend

Model

Coder

Template

Figure 3.2: Graphical representation of tool chain

10


The basic structure of this tool chain is shown in Figure 3.2. Different applications that areimplemented in Matlab Simulink models are shown at the top. From these models, C code isgenerated by the Matlab Embedded Coder with the use of modified templates as described insection 3.1.

3.4 Merge tool

For each application, code is generated by Matlab Embedded Coder in several separate .c files.All the available information needed to combine the applications can be found in the ert_main.cfiles. The output of the tool is a new main.c containing the µC-OS/II framework and its servers.The information which is not available from the ert_main.c can be entered in the GUI of thetool by the user. The code for the applications themselves is stored in different .c files, whichcan be left unaltered and copied to the final project.

Information that can be altered by the user in the GUI is:

• Priority of each server; the default value increments with the server number

• Budget of each server; the default value is 100%n , where n is the total number of servers

• Period of each server; the default value is period of fastest task

• Type of each server

• Priority of each task; the default value increments with the task ID

• Period of each task; the default value is extracted from the model by the Embedded Coder

• Offset of each task; the default value is extracted from the model by the Embedded Coder

The priority of each task that is shown to the user in the GUI is the mutual priority between tasksthat are assigned to the same server. These priorities need to be unique only for tasks assignedto the same server, tasks running on different servers may have the same priority in the GUI. Thisis a design decision that emerged from consultations with a group of control engineers targetedto use the tool. In the µC-OS/II framework it is required that all tasks, even when they’re notassigned to the same server, have an unique priority. Therefore the priorities that are written tothe output file are a composition of the server priority followed by the task priority.

11


4 Implementation

As shown in Figure 3.2, the system that has been created consists of two main parts that havebeen implemented. The first part are the Matlab Embedded Coder templates and the second partis the merge tool. The implementation of both parts is described in this chapter.

4.1 Templates

The Matlab Embedded Coder allows the creation of a framework in which the application-specificC code is deployed. These templates contain TLC code, which the Embedded Coder executesprior to writing the generated source files to disk. The templates used for this tool chain are basedon templates that are already used by the SAN group to create a complete µC-OS/II frameworkwith a single application.

The given templates have been altered for this tool chain in two ways. First, specific tags arecreated and added to the generated c code that contain information that needs to be passed tothe merge tool. Secondly, a part is added in order to simplify and structure the alteration ofInput/Output (IO) actions in the code produced.

4.1.1 Tags

The created tags are implemented as comments in the c code, which has two main advantages.The tags created in the comments are easy triggers for the merge tool to search for the informationneeded ensuring the information is always at the same location in an expected format. The factthat the tags are created as comments in the output C code makes sure that the produced C codeis still executable when a single application needs to be programmed on an ECU.

Figure 4.1 shows the TLC code that is used to create three tags in the output c file. Thefirst tag is a generic tag that is the same for every model that is processed. This tag is usedby the merge tool to validate that the c code is actually generated with the correct templates.The second and last tags use TLC functions (indicated by the purple color) that produce datadepending on the model that is used. The //APPLICATION_NAME tag contains the name of theapplication, while the //NO_OF_TASKS tag contains an integer number indicating the number oftasks that the application contains.

Introduction – Requirements – Design – Implementation – Future work

• Templates – Generation of markers

18

//CODE_VALID_FOR_MERGE //APPLICATION_NAME = "%<LibGetMdlPubHdrBaseName()>" //NO_OF_TASKS = "%<LibGetNumSyncPeriodicTasks()>"

%assign sampleTime = LibGetSampleTimePeriodAndOffset(idx+tid01EQ,0) %assign offsetTime = LibGetSampleTimePeriodAndOffset(idx+tid01EQ,1) //create task%<idx>, and set the period and offset OSTaskCreate(%<LibGetMdlPubHdrBaseName()>_task%<tid>,(void*)0, &Task%<tid>Stk[TASK_%<tid>_STK_SIZE-1],TASK_%<tid>_PRIO); //assign task to relteqserver and set period RelteqServerAddTask(server_%<appName>,OSTCBPrioTbl[TASK_%<idx>_PRIO],&err); OSTaskSetPeriodEx (OSTCBPrioTbl[TASK_%<idx>_PRIO], %<sampleTime>*OS_TICKS_PER_SEC,%<offsetTime>); //TASK_SAMPLE_TIME_%<tid> = "%<sampleTime>" //TASK_OFFSET_%<tid> = "%<offsetTime>"

Figure 4.1: TLC code to generate information tags

12


Figure 4.2 shows the TLC code that is used to create a task in the RELTEQ framework, assignit to a server and set its period. The last two lines of the code show the creation of tags thatcontain all the valuable information for the merge tool. In this case the tasks sample time andoffset. In this example it is shown that the tags themselves can also contain parameters, in thiscase the current task number (%<tid>).


• Templates – Generation of markers

18

//CODE_VALID_FOR_MERGE //APPLICATION_NAME = "%<LibGetMdlPubHdrBaseName()>" //NO_OF_TASKS = "%<LibGetNumSyncPeriodicTasks()>"

%assign sampleTime = LibGetSampleTimePeriodAndOffset(idx+tid01EQ,0) %assign offsetTime = LibGetSampleTimePeriodAndOffset(idx+tid01EQ,1) //create task%<idx>, and set the period and offset OSTaskCreate(%<LibGetMdlPubHdrBaseName()>_task%<tid>,(void*)0, &Task%<tid>Stk[TASK_%<tid>_STK_SIZE-1],TASK_%<tid>_PRIO); //assign task to relteqserver and set period RelteqServerAddTask(server_%<appName>,OSTCBPrioTbl[TASK_%<idx>_PRIO],&err); OSTaskSetPeriodEx (OSTCBPrioTbl[TASK_%<idx>_PRIO], %<sampleTime>*OS_TICKS_PER_SEC,%<offsetTime>); //TASK_SAMPLE_TIME_%<tid> = "%<sampleTime>" //TASK_OFFSET_%<tid> = "%<offsetTime>"

Figure 4.2: Template code to create a task in the RELTEQ framework

4.1.2 IO operations

The part that has been added in order to simplify and structure the alteration of code to performIO operations is shown in Figure 4.3. In the base templates, IO actions are performed both rightbefore and right after execution of the task-specific code. For each task, the IO actions needed tobe added by hand in different places of the ert_main.c file. This has been changed by putting IOfunction calls on all the right places in the ert_main.c file in the template. These functions areput in different header files which are included in ert_main.c. This means that the ert_main.cfile does not need to be edited by hand any more and that all the IO code can be added in theright function in the right header file. For each model a separate header file is created, containingthe IO functions for all the tasks within that model. In this way the location of the IO code forall the tasks is clear and structured.


• Templates – Creation of I/O header files for each model – I/O editing in main.c not necessary – I/O operations structured in separate files

19

%openfile ioh = "IO_%<LibGetMdlPubHdrBaseName()>.h" %selectfile ioh %foreach idx = LibGetNumSyncPeriodicTasks() void %<LibGetMdlPubHdrBaseName()>_IO_before_step%<idx>(void){ //Put IO actions before step%<idx> here. } void %<LibGetMdlPubHdrBaseName()>_IO_after_step%<idx>(void){ //Put IO actions after step%<idx> here. } %endforeach %closefile ioh

Figure 4.3: Template code to generate IO header files

13


4.2 Merge tool

Once the code of the individual models is generated by making use of the templates as describedin section 4.1, the individual µC-OS/II frameworks contained in the ert_main.c files need to bemerged to a single framework containing all the models. The merge tool is implemented to servethis purpose.

4.2.1 Information flow

Figure 4.4 shows the information flow in the merge tool. The tool parses the input ert_main.cfiles and performs some checks. If the code in the parsed files is correct, the data is extracted andshown to the user in two tables. It is checked if code has already been generated for the inputmodels, if the code indeed exists it is checked if the code is generated with the correct template.If one of the checks fails, the tool generates an error.

Start

browseButton clicked

Yes

readInputFiles

checkTemplates

Templates OK

No

Display Error message

No

getFileData

Yes

Fill Tables with File Data

processButton clicked

Budgets ≤ 100%Display Error

messageNo

Yes

checkBudgets

Priorities UniqueDisplay Error

message

checkPriorities

Yes

No

Write Table Data to Output File

Yes

Display Notification

No

closeButton clicked

End

No

Yes

Figure 4.4: Flow chart of merge tool

14


As stated in section 3.2 the server’s priority, budget and type are not present in the Simulinkmodels, nor are they generated by the Embedded Coder templates. For that reason, this informationhas to be entered by the user. To increase the usability of the merge tool, the merge tool entersdefault values in the tables, which later can be altered by the user. The default priority isgenerated incrementing with the model number, as described in section 3.4. The default budgetof a server is calculated as 100%

n , where n is the total number of servers. The default servertype is a deferrable server, more information about the different server types can be found inMulti-Resource Management in Embedded Real-Time Systems [5].

The user can alter the values in the tables after which the integrated framework can be exportedand saved to a file called merged_main.c. When the user chooses to export the data, again somechecks are performed. If the data in the tables are correct, the merge tool generates the outputfile and the user is notified. The checks consist of a check if the server budgets do not exceed100% and if the priorities are unique. If a check fails, an error is generated and displayed.

4.2.2 Graphical User Interface (GUI)

In order to create a merge tool that is usable by people who don’t have a lot of experiencewith developing software, an easy-to-use almost self-explanatory GUI has been designed. This iscaptured by requirement PrR1 in Chapter 2. The GUI of the merge tool is shown in Figure 4.5.

Figure 4.5: GUI

15


At the top of the GUI, one can find all the files that are used as input files. Just below that, thereare three buttons to select input files, to close the tool and to process the data. The bottomof the screen contains two tables. The upper table contains all the data of the various servers,consisting of the application name, server priority, server budget, server period and server type.In the lower table, the data of the various tasks are shown. This data consists of the task’s ID,priority, period, offset and the application to which the task belongs. The values in these tablescan be altered by the user.

Figure 4.6: Code generated with incorrect template

In order to satisfy requirement FR4, clear error messages need to be displayed to the user, statingthe kind of error and, if available, information that can help the user remedy the cause of theerror. Figure 4.6 is an example of such an error message. It states clearly what is wrong andwhich of the selected models causes this error, giving the user a clue which model should be fixed.

Figure 4.7: Budgets exceed 100%

The warning displayed in Figure 4.7 also states what is wrong with the data entered in the table andgives the user enough information to take action and adjust the budgets to add up to 100% or less.

In order to satisfy requirement FR5 the user must be notified when the tool completes successfully.The implementation of this notification is shown in Figure 4.8.

Figure 4.8: Success notification

16


5 Conclusion

The main problem that this internship research targets to solve, as described in Chapter 1, fallsapart into two problems. The first problem is the fact that control engineers need to translatetheir designed control applications to code in order to execute them on an ECU and that they donot have any software development experience. This can already be done for a single applicationto a single ECU, but for mapping multiple applications on a single ECU there is currently notooling available. The second problem is the fact that the current trend in automotive design isto use a separate ECU for each implemented function or application. Because of this, a modernpremium car contains about 70 to 100 ECUs and around 100 million lines of code. This is a greatwaste of resources and can be greatly reduced if multiple functions are implemented on a singleECU.

After discussions with mechanical engineers who are the target group for using the system that hasbeen designed, requirements have been created, which are described in Chapter 2. Furthermorean domain analysis has been performed in order to gain insight in the information that is neededto generate the requested output and the parts of the system that can provide this information.Based on this domain analysis, a design has been created for a tool chain that can provide thefunctionality that satisfies the requirements.

The design of the tool chain that is described in Chapter 3 has been implemented and tested.Chapter 4 describes the implementation of the tool chain, together with an explanation how thisimplementation satisfies the functional requirements that are described in section 2.1.

It can be concluded that the tool chain created in this internship offers a solution to the problemthat has been defined and is a first step towards integration of functionality in the automotiveindustries, but the tool chain is currently too limited to be used in practice. However with someeffort and further investigation (which is described in Chapter 6) it is plausible that a tool chainbased on the one described in this report can be implemented and used in practice in the nearfuture. This would bring the domain of automotive engineering and software engineering closertogether and enable automotive control engineers to create their software from their controldesigns and integrate them as a complete system instead of separate parts that need to be linkedtogether afterwards. If such a tool were to be implemented and the software of an automobilewould be integrated as one system, this would greatly reduce the number of ECUs in a car andthe lines of code needed to program all functionalities. This requires a change of view of theautomotive designers as well as the tool chain to provide the functionality needed to do so.

17


6 Future Work

Chapter 5 describes that the tool chain produced in this internship is a good solution to theproblem described in Chapter 1, however it is only a first step to a final solution that is usablein practice because its functionality is currently too limited. In order to extend the tool withfunctionality that is outside the scope of this internship, it is needed to further investigate a fewother topics, which are described in this chapter.

The first point of improvement is the support for other operating systems and hardware platforms.The platform and RTOS used for this research has been chosen based on available knowledge andexperience within the SAN group, but a study can be performed to find a more suitable platformand RTOS to develop the tool chain for. In the case of InMotion the platform is not powerfulenough to run all the desired models for the car. Ideally the tooling will be developed togetherwith a more powerful and customizable ECU. If the hardware, RTOS and supporting tool chainare integrated and designed as a single system, the GUI of the tool chain can include SimulinkIO to hardware IO mapping options. This will greatly increase the usability of the tool chain inpractice, because it eliminates the need of code alteration by hand after the code is generated.

Another improvement to the tooling for generating C code form Simulink models is the supportfor validation of the generated code. When an architectural description of the applications thatneed to be mapped to the single ECU is available, the integrated c code which is generated bythe tool chain could be validated by this same tool. If this is possible, the confidence that thesoftware indeed does what is intended by the designer is increased, leading to greater acceptancein the automotive industry.

In Chapter 3 it is described that the applications used by the tool chain must be independent.When independent applications are used it can be guaranteed that each application can keeprunning on its own virtual platform, independent of the state of the other applications runningon the same platform. When dependent applications are used and communication between themis needed, it can not be guaranteed that a certain application can keep running if it expectsinformation from another application. A study can be conducted to what the influence of runningdependent applications on the same platform is on the guarantees that can be given. Furthermorea study can be performed in the field of communication between dependent applications and howthis can be optimized when the applications are running on the same platform.

In order to know if the set of applications that need to be merged is actually schedulable, thetool could be extended with an option to perform a schedulability analysis. If the user enters theexecution times of all the applications in the GUI, the tool could calculate the feasibility of themerged applications in terms of schedulability. This option increases the usability of the tool.

18


Bibliography

[1] Charette, R. N. This Car Runs on Code, IEEE spectrum, February 2009. Viewed online athttp://spectrum.ieee.org/green-tech/advanced-cars/this-car-runs-on-code; Viewed on 31thof January 2013.

[2] Peti, P.; Obermaisser, R.; Tagliabo, F.; Marino, A.; Cerchio, S. An Integrated Architecture forFuture Car Generations, Eighth IEEE International Symposium on Object-Oriented Real-TimeDistributed Computing, pp. 2-13, 2005.

[3] Keskin, U. In-Vehicle Communication Networks: A Literature Survey, TU/e CS-Report 09-10,2009.

[4] Natale, M. D.; Sangiovanni-Vincentelli, A. L. Moving From Federated to IntegratedArchitectures in Automotive: The Role of Standards, Methods and Tools, Proceedings ofthe IEEE, vol. 98, no. 4, pp. 603-620, 2010.

[5] Holenderski, M. Multi-Resource Management in Embedded Real-Time Systems, EindhovenUniversity Press, Eindhoven, 2012.

[6] Labrosse, J. J.; Downing, C. µC-OS/II: MISRA C Compliance Matrix, 2002. Viewed onlineat http://micrium.com/?wpdmdl=384; Viewed on 4th of February 2013.

[7] Nolte, T. Hierarchical Scheduling of Complex Embedded Real-Time Systems,Summer School on Real-Time Systems (ETRâĂŹ09), Paris, 2009. Viewed online athttp://www.telecom-paristech.fr/ETR09/presenta/Nolte.pdf; Viewed on 6th of February2013.

19


Acronyms

ECU Electronic Control Unit

GS Global Scheduler

GUI Graphical User Interface

HSF Hierarchical Scheduling Framework

IO Input/Output

LS Local Scheduler

MISRA Motor Industry Software Reliability Association

RTOS Real-Time Operating System

SAN System Architecture and Networking

UI User Interface

20


Appendix A: Tool chain user manual

This user manual explains the usage of the tool chain to create to integrated c code from Simulinkmodels. Before starting with Step 1, make sure that all the Simulink models that need to becombined are in the same folder.

Step 1 - Generating code from Simulink model

1. Open the model from which code needs to be generated in Matlab Simulink

2. Click on the Toolsmenu in the menu bar. From the Toolsmenu choose Code Generation > Options...

A Configuration Parameters window pops up (see Figure A.1).

Figure A.1: Configuration Parameters window

3. Select Templates in the left window pane.

4. Click on the Browse... button next to the File customization template: field and selectthe template included with the tool chain.

5. Select Code Generation in the left window pane. The resulting window will look like FigureA.2.

21


Figure A.2: Configuration Parameters window

6. In this window, make sure the box next to Generate code only is checked. After that clickthe Generate code button.

7. Repeat steps 1. to 6. for each Simulink model that needs to be programmed to the platform.

Step 2 - Merging the models

1. Open the Merge.exe tool, the GUI will now be displayed (see Figure A.3).

Figure A.3: Main GUI of the merge tool

2. Click on the Browse... button, a window like Picture A.4 will be displayed.

22


Figure A.4: Select files dialog

3. Navigate to the folder where all the Simulink models are stored. Select them all at once byfirst clicking the top one with the left mouse button. Now press the Shift-key and click on thebottom one with the left mouse button. After all the models have been selected click on theOpen button.

Figure A.5: GUI of the merge tool

23


4. The GUI of the merge tool will now look like picture A.5. Of course the information displayedin the two tables depends on the models that are selected. The models that are selected arenow shown in the top part of the GUI.

5. In the upper table, all the information about the various RELTEQ servers is displayed. Thisinformation can be adjusted to your own discretion.

6. In the lower table, all the information about the tasks within the server is displayed. Thisinformation can be adjusted to your own discretion.

7. In order to process the data and generate the output code, click the Process... button. Youshould now be notified if the process finished correctly, this is shown in Figure A.6

Figure A.6: Success notification

24

Documents

Mapping multiple MATLAB Simulink applications to a Real-TimeOperating System using a Hierarchical Scheduling Framework