Mapping multiple MATLAB Simulink applications to a Real-Time Operating System using a Hierarchical Scheduling Framework Internship Report of J.G.S.

van Uden
February 19, 2013, version 1.1

Automotive Technology InMotion

Contents
1 Introduction 1.1 1.2 1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Report structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 4 5 6 6 6 6 7 8 8 9 10 11 12 12 14 17 18 19 20 21

2 Requirements 2.1 2.2 2.3 2.4 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quality requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Platform requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Design 3.1 3.2 3.3 3.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Merge tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Implementation 4.1 4.2 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Merge tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Conclusion 6 Future Work Bibliography Acronyms Appendix A: Tool chain user manual

Automotive Technology InMotion

1
1.1

Introduction
Motivation

Automobiles have become very complex systems which contain many control systems. The control strategies for these systems are usually implemented by Matlab Simulink applications. In order to actually use these applications on an Electronic Control Unit (ECU), code needs to be generated from 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 software engineers, while the applications themselves are developed by control engineers. It would be desirable if a tool chain was available in which most of the process of creating code from a Matlab Simulink application is automated in such a way that this process can be performed by the control engineers that designed the applications. However this is hard to accomplish due to the variety of ECUs that exist and their dierences. Furthermore many resources get wasted in automotive systems because it is common that each application that represents a certain function runs on its own ECU [2], some of which could easily share the resources of a single ECU. Because of the ever growing complexity of the entire system due to the increasing number of ECUs [3], it is desirable that dierent functions and thus applications will be integrated on just a few ECUs. The growth of the number of ECUs in premium 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 that time was already about 70 to 100. Furthermore it is stated that all these ECUs together need somewhere around 100 million lines of code to be programmed and if this trend will continue, cars will 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]

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

GS

A1 LS

A2 ... AN LS LS T 12 T 22 ... T x2

T 11 T 21 ... T x1

T 1N T 2N ... T xN

Figure 1.2: Hierarchical Scheduling Framework

A change from federated toward integrated architectures will reduce the overall complexity of the system [4] and therefore improve reliability. However, from an application viewpoint it would be desirable if each application gets its own virtual ECU that can guarantee certain performance aspects. These applications will need to be scheduled on this platform (on a global level). Since its very common that a single application consists of multiple tasks, these tasks also need to be scheduled (on a local level). A suitable solution is to use a Hierarchical Scheduling Framework (HSF) consisting of a global scheduler (GS) to schedule dierent applications on the platform and local schedulers (LS) to schedule the tasks within the applications. The basic structure of an HSF is shown in Figure 1.2. The mapping of multiple applications on a single ECU, as described above, is not supported by the Matlab Embedder Coder itself, however the Matlab Embedder Coder could be used as a part 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 Simulink applications to a hardware platform, using a Real-Time Operating System (RTOS) combined with an HSF. In this way multiple applications can share a single hardware platform, while each

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

1.3

Report structure

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

Automotive Technology InMotion

2
2.1

Requirements
Functional requirements

FR1. The system can map multiple applications to a single platform. This is the highest level goal of the system. FR2. The system accepts multiple Matlab Simulink models as inputs. The specic currently 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 code that can be used to program the target platform. FR4. If the system for some reason encounters an error, the user must be notied or the user receives a general error, the user will have no clue to what went wrong and how to remedy the error. The error notications supports usability. FR5. When the system has nished successfully, the user must be notied. If the user is not notied after a successful execution, the user will have no clue if the system is already nished, or when its nished. The notication supports usability.

type of application that the system can process are Matlab Simulink models, the system is

stating the type of error and suggested action. If the user is not notied after a failure,

2.2

Quality requirements

QR1. The system uses only a single tool outside the Matlab environment. This outside the Matlab environment, the system will be harder to use by the user, since more user intervention will be required. In this way the user can eciently convert the application to C code. If additional functionality or bug xes are required its more convenient to do this in one place than in multiple tools.

supports eciency, usability and maintainability. If more than one separate tool is be used

2.3

Platform requirements

PlR1. The platform used is a Freescale EVB9512XF board. The Freescale EVB9512XF platform is currently used by the SAN group for various educational and research purposes. Theres 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 the and research purposes. Theres much technical knowledge and experience with this RTOS.

Freescale EVB9512XF platform by the SAN group and is currently used for various educational

Automotive Technology InMotion 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 used experience with this HSF. for various educational and research purposes. Theres much technical knowledge and

2.4

Process requirements

PrR1. The programming language used for development is Visual C++. It has been chosen to develop the system in Visual C++. This allows to create a Graphical User objects that Windows users are used to work with. Since the system is intended for users that have little knowledge about software, using a familiar graphical interface will support the eectiveness of the system. PrR2. The application specic code in the system will be generated by Matlab from a Simulink application can be used in the system. This supports reusability since the application-specic code can completely be reused. PrR3. The system and manual will be delivered before the 9th of February 2013. Interface (GUI) that can be used on Microsoft Windows computers, using the same visual

Embedder Coder. In this way the built-in capabilities of Matlab to produce code directly

Automotive Technology InMotion

3
3.1

Design
Related Work
C-OS/II

3.1.1

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

As stated in requirement PlR3 in section 2.3, the system that has been designed uses the HSF based on RELTEQ. In Multi-Resource Management in Embedded Real-Time Systems [5] it is stated that the goal of RELTEQ is to extend the RTOS C-OS/II with an HSF. The HSF based on RELTEQ enables C-OS/II to use xed-priority preemptive scheduling of the servers on a global level and also to use xed-priority preemptive scheduling of the tasks within the servers. Therefore the RELTEQ framework oers all the desired possibilities in order to schedule dierent applications 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 research each server hosts a single application. Multiple servers are scheduled on a single ECU. In this way the applications virtually have their own ECU, while actually theyre 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 is used. Custom code-generation templates are available within the SAN group in order to generate application-specic code embedded in the RELTEQ framework. These templates have been used as a base for this system as well. The templates allow the user to create custom C code together with application-specic code. For the nal implementation of the system, the templates used by the SAN group have been modied in order to pass the desired information from the Matlab Simulink Models to the other parts of the system that need it. More information about the use of these templates is described in section 4.1.

Automotive Technology InMotion

3.2

Domain Analysis

In order to create a suitable design for the system, a class diagram of the domain has been created rst, 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 this diagram, only the relevant attributes in order to make design decisions about the system are taken into account.
Applications -Name -Inputs -Outputs -Process description Platform -CPU -Memory -RTOS

1 1 RTOS -OSClock -Servers -Tasks

Simulink Model -Name -Inputs -Outputs -Task Sample Times -Task Offsets -Process description 0..* Task

1 0..* Server -Name -Priority -Budget -Period -Type

-ID -Priority -Sample Time -Offset

Generated from templates

Figure 3.1: Class diagram of domain

In the top left of Figure 3.1, the applications are dened as a generic class, a more specic class of applications, which is used in the system to be designed, are the Simulink models. These Simulink models contain additional information about the tasks that can be created from it. For each control loop with a certain sample time in the Simulink model, a separate task is created by the Embedded Coder. If a Simulink model only uses a single sample time, the entire model is created as a single task. Also for each Simulink model a server will be created by the Embedded Coder. In this way a server can run a single task or multiple tasks, depending on the number of sample times used in the Simulink model. The tasks that are generated from the Simulink model and that are assigned to a certain server also need to have a unique priority in order to be able to run along each other on that server in the RELTEQ framework. These priorities are not present in the Simulink models. However, they are generated by the Embedded Coder templates based on the task ID.

Automotive Technology InMotion 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 period is indirectly derived from the Simulink model by the Embedded Coder templates, by taking the period of the fastest task. The other information needs to be given by the users. This means that the 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 these applications must be independent. Investigation of the complications that dependent applications introduce are outside the scope of this research. When dependent applications are used, currently no performance guarantees can be given as applications may still inuence each other.

3.3

Structure

Given the domain analysis in section 3.2, a suitable solution that meets the requirements described in chapter 2 is to design a tool chain in which the information that is already available in Matlab Simulink is passed to a second tool. The information that has to be given by the user can be entered in the graphical user interface (GUI) of a this second tool. The rst tool in the tool chain will be the Embedded Coder, making use of modied templates in order to pass on the desired information. The second tool will be a separate merge tool, which merges the individual pieces of code created by the Embedded Coder and allows the user to alter information and enter the missing information.
<model1>.mdl <model2>.mdl

Legend
Matlab Simulink Model Matlab Embedded Coder Embedded Coder Template Merge Tool

.c\.h

.c\.h

<model1> \ert main.c

<model2> \ert main.c

main.c

Figure 3.2: Graphical representation of tool chain

10

Automotive Technology InMotion The basic structure of this tool chain is shown in Figure 3.2. Dierent applications that are implemented in Matlab Simulink models are shown at the top. From these models, C code is generated by the Matlab Embedded Coder with the use of modied templates as described in section 3.1.

3.4

Merge tool

For each application, code is generated by Matlab Embedded Coder in several separate .c les. All the available information needed to combine the applications can be found in the ert_main.c les. 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 the tool by the user. The code for the applications themselves is stored in dierent .c les, which can be left unaltered and copied to the nal 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 Oset 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 tasks that are assigned to the same server. These priorities need to be unique only for tasks assigned to the same server, tasks running on dierent servers may have the same priority in the GUI. This is a design decision that emerged from consultations with a group of control engineers targeted to use the tool. In the C-OS/II framework it is required that all tasks, even when theyre not assigned to the same server, have an unique priority. Therefore the priorities that are written to the output le are a composition of the server priority followed by the task priority.

11

Automotive Technology InMotion

Implementation

As shown in Figure 3.2, the system that has been created consists of two main parts that have been implemented. The rst part are the Matlab Embedded Coder templates and the second part is 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-specic C code is deployed. These templates contain TLC code, which the Embedded Coder executes prior to writing the generated source les to disk. The templates used for this tool chain are based on templates that are already used by the SAN group to create a complete C-OS/II framework with a single application. The given templates have been altered for this tool chain in two ways. First, specic tags are created and added to the generated c code that contain information that needs to be passed to the merge tool. Secondly, a part is added in order to simplify and structure the alteration of Input/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 information needed ensuring the information is always at the same location in an expected format. The fact that the tags are created as comments in the output C code makes sure that the produced C code is 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 le. The rst tag is a generic tag that is the same for every model that is processed. This tag is used by 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 data depending on the model that is used. The //APPLICATION_NAME tag contains the name of the

emplatesapplication, while the //NO_OF_TASKS tag contains an integer number indicating the number of
tasks that the application contains.
//CODE_VALID_FOR_MERGE //APPLICATION_NAME = "%<LibGetMdlPubHdrBaseName()>" //NO_OF_TASKS = "%<LibGetNumSyncPeriodicTasks()>"

Generation of markers

ampleTime = LibGetSampleTimePeriodAndOffset(idx+tid01EQ,0) Figure 4.1: TLC code to generate information tags ffsetTime = LibGetSampleTimePeriodAndOffset(idx+tid01EQ,1) task%<idx>, and set the period and offset ate(%<LibGetMdlPubHdrBaseName()>_task%<tid>,(void*)0, &Task%<tid>Stk[TASK_%<tid>_STK_SIZE-1],TASK_%<tid>_PRIO);

12

task to relteqserver and set period verAddTask(server_%<appName>,OSTCBPrioTbl[TASK_%<idx>_PRIO],&err);

Automotive Technology InMotion Figure 4.2 shows the TLC code that is used to create a task in the RELTEQ framework, assign it to a server and set its period. The last two lines of the code show the creation of tags that contain all the valuable information for the merge tool. In this case the tasks sample time and oset. In this example it is shown that the tags//CODE_VALID_FOR_MERGE themselves can also contain parameters, in this case the current task number (%<tid>).
//APPLICATION_NAME = "%<LibGetMdlPubHdrBaseName()>" //NO_OF_TASKS = "%<LibGetNumSyncPeriodicTasks()>"

Templates

Generation of markers

%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>"

Introduction Requirements Implementation Figure 4.2: Template code to create a Design task in the RELTEQ framework
4.1.2 IO operations

Future work
18

The part that has been added in order to simplify and structure the alteration of code to perform IO operations is shown in Figure 4.3. In the base templates, IO actions are performed both right be added by hand in dierent places of the ert_main.c le. This has been changed by putting IO Templates function calls on all the right places in the ert_main.c le in the template. These functions are put in dierent header lesfiles which for are included ert_main.c. This means that the ert_main.c Creation of I/O header eachin model le does not need to be edited by hand any more and that all the IO code can be added in the I/O editing in main.c not necessary right function in the right header le. For each model a separate header le is created, containing the IO functions for all the tasks that model. In this way the location of the IO code for I/O operations structured inwithin separate files all the tasks is clear and structured.
%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

before and right after execution of the task-specic code. For each task, the IO actions needed to

Figure 4.3: Template code to generate IO header les Introduction Requirements Design Implementation Future work
19

13

Automotive Technology InMotion

4.2

Merge tool

Once the code of the individual models is generated by making use of the templates as described in section 4.1, the individual C-OS/II frameworks contained in the ert_main.c les need to be merged to a single framework containing all the models. The merge tool is implemented to serve this purpose. 4.2.1 Information ow

Figure 4.4 shows the information ow in the merge tool. The tool parses the input ert_main.c les and performs some checks. If the code in the parsed les is correct, the data is extracted and shown to the user in two tables. It is checked if code has already been generated for the input models, 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

No

browseButton clicked Yes readInputFiles

processButton clicked Yes checkBudgets

No

checkTemplates

Budgets 100%

No

Display Error message

Yes Display Error message No Templates OK checkPriorities

Yes getFileData Priorities Unique Yes Fill Tables with File Data Write Table Data to Output File No Display Error message

Display Notification

closeButton clicked Yes End

No

Figure 4.4: Flow chart of merge tool

14

Automotive Technology InMotion As stated in section 3.2 the servers priority, budget and type are not present in the Simulink models, nor are they generated by the Embedded Coder templates. For that reason, this information has to be entered by the user. To increase the usability of the merge tool, the merge tool enters default values in the tables, which later can be altered by the user. The default priority is generated incrementing with the model number, as described in section 3.4. The default budget of a server is calculated as
100% n ,

where n is the total number of servers. The default server

type is a deferrable server, more information about the dierent server types can be found in Multi-Resource Management in Embedded Real-Time Systems [5]. The user can alter the values in the tables after which the integrated framework can be exported and saved to a le called merged_main.c. When the user chooses to export the data, again some checks are performed. If the data in the tables are correct, the merge tool generates the output le and the user is notied. The checks consist of a check if the server budgets do not exceed 100% 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 dont have a lot of experience with developing software, an easy-to-use almost self-explanatory GUI has been designed. This is captured by requirement PrR1 in Chapter 2. The GUI of the merge tool is shown in Figure 4.5.

Figure 4.5: GUI

15

Automotive Technology InMotion At the top of the GUI, one can nd all the les that are used as input les. Just below that, there are three buttons to select input les, to close the tool and to process the data. The bottom of 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 tasks ID, priority, period, oset and the application to which the task belongs. The values in these tables can 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, stating the kind of error and, if available, information that can help the user remedy the cause of the error. Figure 4.6 is an example of such an error message. It states clearly what is wrong and which of the selected models causes this error, giving the user a clue which model should be xed.

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 and gives 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 notied when the tool completes successfully. The implementation of this notication is shown in Figure 4.8.

Figure 4.8: Success notication

16

Automotive Technology InMotion

Conclusion

The main problem that this internship research targets to solve, as described in Chapter 1, falls apart into two problems. The rst problem is the fact that control engineers need to translate their designed control applications to code in order to execute them on an ECU and that they do not have any software development experience. This can already be done for a single application to a single ECU, but for mapping multiple applications on a single ECU there is currently no tooling available. The second problem is the fact that the current trend in automotive design is to use a separate ECU for each implemented function or application. Because of this, a modern premium car contains about 70 to 100 ECUs and around 100 million lines of code. This is a great waste of resources and can be greatly reduced if multiple functions are implemented on a single ECU. After discussions with mechanical engineers who are the target group for using the system that has been designed, requirements have been created, which are described in Chapter 2. Furthermore an domain analysis has been performed in order to gain insight in the information that is needed to 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 the functionality that satises 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 this implementation satises the functional requirements that are described in section 2.1. It can be concluded that the tool chain created in this internship oers a solution to the problem that has been dened and is a rst step towards integration of functionality in the automotive industries, but the tool chain is currently too limited to be used in practice. However with some eort and further investigation (which is described in Chapter 6) it is plausible that a tool chain based on the one described in this report can be implemented and used in practice in the near future. This would bring the domain of automotive engineering and software engineering closer together and enable automotive control engineers to create their software from their control designs and integrate them as a complete system instead of separate parts that need to be linked together afterwards. If such a tool were to be implemented and the software of an automobile would be integrated as one system, this would greatly reduce the number of ECUs in a car and the lines of code needed to program all functionalities. This requires a change of view of the automotive designers as well as the tool chain to provide the functionality needed to do so.

17

Automotive Technology InMotion

Future Work

Chapter 5 describes that the tool chain produced in this internship is a good solution to the problem described in Chapter 1, however it is only a rst step to a nal solution that is usable in practice because its functionality is currently too limited. In order to extend the tool with functionality that is outside the scope of this internship, it is needed to further investigate a few other topics, which are described in this chapter. The rst 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 and experience within the SAN group, but a study can be performed to nd a more suitable platform and RTOS to develop the tool chain for. In the case of InMotion the platform is not powerful enough to run all the desired models for the car. Ideally the tooling will be developed together with a more powerful and customizable ECU. If the hardware, RTOS and supporting tool chain are integrated and designed as a single system, the GUI of the tool chain can include Simulink IO to hardware IO mapping options. This will greatly increase the usability of the tool chain in practice, 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 support for validation of the generated code. When an architectural description of the applications that need to be mapped to the single ECU is available, the integrated c code which is generated by the tool chain could be validated by this same tool. If this is possible, the condence that the software indeed does what is intended by the designer is increased, leading to greater acceptance in 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 keep running on its own virtual platform, independent of the state of the other applications running on the same platform. When dependent applications are used and communication between them is needed, it can not be guaranteed that a certain application can keep running if it expects information from another application. A study can be conducted to what the inuence of running dependent applications on the same platform is on the guarantees that can be given. Furthermore a study can be performed in the eld of communication between dependent applications and how this 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, the tool could be extended with an option to perform a schedulability analysis. If the user enters the execution times of all the applications in the GUI, the tool could calculate the feasibility of the merged applications in terms of schedulability. This option increases the usability of the tool.

18

Automotive Technology InMotion

Bibliography
[1] Charette, R. N. This Car Runs on Code, IEEE spectrum, February 2009. Viewed online at http://spectrum.ieee.org/green-tech/advanced-cars/this-car-runs-on-code; Viewed on 31th of January 2013. [2] Peti, P.; Obermaisser, R.; Tagliabo, F.; Marino, A.; Cerchio, S. An Integrated Architecture for Future Car Generations, Eighth IEEE International Symposium on Object-Oriented Real-Time Distributed 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 Integrated Architectures in Automotive: The Role of Standards, Methods and Tools, Proceedings of the IEEE, vol. 98, no. 4, pp. 603-620, 2010. [5] Holenderski, M. Multi-Resource Management in Embedded Real-Time Systems, Eindhoven University Press, Eindhoven, 2012. [6] Labrosse, J. J.; Downing, C. C-OS/II: MISRA C Compliance Matrix, 2002. Viewed online at 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 (ETR09), Paris, 2009. Viewed online at http://www.telecom-paristech.fr/ETR09/presenta/Nolte.pdf; Viewed on 6th of February 2013.

19

Automotive Technology InMotion

Acronyms
ECU GS GUI HSF IO LS MISRA RTOS SAN UI Electronic Control Unit Global Scheduler Graphical User Interface Hierarchical Scheduling Framework Input/Output Local Scheduler Motor Industry Software Reliability Association Real-Time Operating System System Architecture and Networking User Interface

20

Automotive Technology InMotion

Appendix A: Tool chain user manual

This user manual explains the usage of the tool chain to create to integrated c code from Simulink models. Before starting with Step 1, make sure that all the Simulink models that need to be combined 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 Tools menu in the menu bar. From the Tools menu choose Code Generation > Options... A Conguration Parameters window pops up (see Figure A.1).

Figure A.1: Conguration Parameters window

3. Select Templates in the left window pane. 4. Click on the Browse... button next to the File customization template: eld and select the template included with the tool chain. 5. Select Code Generation in the left window pane. The resulting window will look like Figure A.2.

21

Automotive Technology InMotion

Figure A.2: Conguration Parameters window

6. In this window, make sure the box next to Generate code only is checked. After that click the 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

Automotive Technology InMotion

Figure A.4: Select les dialog

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

Figure A.5: GUI of the merge tool

23

Automotive Technology InMotion 4. The GUI of the merge tool will now look like picture A.5. Of course the information displayed in the two tables depends on the models that are selected. The models that are selected are now shown in the top part of the GUI. 5. In the upper table, all the information about the various RELTEQ servers is displayed. This information can be adjusted to your own discretion. 6. In the lower table, all the information about the tasks within the server is displayed. This information can be adjusted to your own discretion. 7. In order to process the data and generate the output code, click the Process... button. You should now be notied if the process nished correctly, this is shown in Figure A.6

Figure A.6: Success notication

24