Evaluation Environment for AUTOSAR-Autocode in Motor Control ...

More documents

Recommendations

Info

Chapter 3 MEDC17 3.2 Basic Software and Application Software Similar to the AUTOSAR architecture, MEDC17 is split into BSW and ASW. One part of the Basic Software, the operating system, was mentioned in the previous section. But some other parts like a communication stack and device drivers exist here, too. However, they do not fit to the interfaces specified by AUTOSAR. The BSW provides the infrastructure to run the ASW, whereas the Application Software is the functional part of the software. 3.3 Communication The current development of motor control software does not care about other ECUs, instead it just handles the one motor control unit. So MEDC17 does not share the inter–ECU approach from AUTOSAR. Every part that is developed and compiled with MEDC17 runs on the same ECU. Nevertheless, MEDC17 provides access to communication over CAN or other buses. The intra–ECU communication is here done with so called messages. These messages have to be configured for MEDC17 and than for each message one or more global variables are created during the auto build. The application software uses an API to access the global variable. This API is typically a #define directive, that maps the access to the correct variable. 3.4 Tasks and Processes The counterpart to a runnable in AUTOSAR is called a process in the terms of MEDC17. Here there are not so much mechanisms for a process than for a runnable in AUTOSAR. For MEDC17 some tasks are configured, which are time triggered. The periods of this tasks are from 1ms up to 1s. The source code of the tasks of MEDC17 is also auto generated from some configuration files, but it does not provide so much flexibility. The configuration of the tasks consist of a list of processes for each task, which is transformed into source code. The processes are called within a task in the same sequential order as they are defined in the configuration. There is no handling of events that triggers the one or the other process like it is shown in the AUTOSAR example in section 2.8, where two runnables with different timings are executed in the same task. So all processes are time triggered and for a process it has to be decided, in which interval it should be executed. Then the process is mapped to the task with the corresponding timing. Due to dependencies between processes, they have to be mapped in the correct order. Because e.g. one process can determine a value and another process uses this value, but the value have to be up to date for a special timing. So these processes have to be executed in the correct order and there is no mechanism to determine this order automatically. 26
3.5 Summary On the other hand the processes that run in a task do not necessarily have a dependency or fulfill the same job. They are just mapped to that task, so that they are executed in the correct interval. The term “task” does here not imply the meaning of achieving the same function. 3.5 Summary MEDC17 provides the current architecture of software development for one ECU for BOSCH. It has not to handle so much possibilities as AUTOSAR, since it has not to be supported by any other manufacture. It is very static configured and the application software has to deal with the existing architecture. So processes have to deal with the existing tasks and it is very unusual that a new task is created. AUTOSAR uses another way where the BSW and especially the operating system is configured to fit the application software and this configuration can change with every call of the RTE generator. 27
Page 1: Evaluation Environment for AUTOSAR-
Page 5: Danksagung An dieser Stelle möchte
Page 8 and 9: Contents 4 Goals 29 4.1 Background
Page 10 and 11: Contents Abbreviations 105 Bibliogr
Page 12 and 13: Chapter 1 Introduction not allow to
Page 14 and 15: Chapter 2 AUTOSAR 2.1 Architecture
Page 16 and 17: Chapter 2 AUTOSAR the hardware depe
Page 18 and 19: Chapter 2 AUTOSAR Basic task Basic
Page 20 and 21: Chapter 2 AUTOSAR communications. T
Page 22 and 23: Chapter 2 AUTOSAR DataReceivePoint
Page 24 and 25: Chapter 2 AUTOSAR mode A mode depen
Page 26 and 27: Chapter 2 AUTOSAR not absolutely tr
Page 28 and 29: Chapter 2 AUTOSAR 1 types Int
Page 30 and 31: Chapter 2 AUTOSAR 1 swc root
Page 32 and 33: Chapter 2 AUTOSAR 1 TASK(Task1) { R
Page 34 and 35: Chapter 2 AUTOSAR 24
Page 38 and 39: Chapter 3 MEDC17 28
Page 40 and 41: Chapter 4 Goals Communication The c
Page 42 and 43: Chapter 4 Goals 4.1.3 Development o
Page 44 and 45: Chapter 4 Goals files for special p
Page 46 and 47: Chapter 5 Analysis and Design test
Page 48 and 49: Chapter 5 Analysis and Design 38 na
Page 50 and 51: Chapter 5 Analysis and Design confi
Page 52 and 53: Chapter 5 Analysis and Design group
Page 54 and 55: Chapter 5 Analysis and Design direc
Page 56 and 57: Chapter 5 Analysis and Design The s
Page 58 and 59: Chapter 5 Analysis and Design 48
Page 60 and 61: Chapter 6 Implementation of the Tes
Page 86 and 87:
Chapter 7 Test Cases These examples
Page 88 and 89:
Chapter 7 Test Cases • The AUTOSA
Page 90 and 91:
Chapter 7 Test Cases SWC1 run11 SWC
Page 92 and 93:
Chapter 7 Test Cases 1 #include #i
Page 94 and 95:
Chapter 7 Test Cases 1 #ifndef TEST
Page 96 and 97:
Chapter 7 Test Cases 7.3.2 Implemen
Page 98 and 99:
Chapter 7 Test Cases 1 FUNC(void, R
Page 100 and 101:
Chapter 7 Test Cases 7.9. The sourc
Page 102 and 103:
Chapter 8 Conclusion Since a templa
Page 104 and 105:
Appendix A Example /interfaces/CS
Page 106 and 107:
Appendix A Example /interfaces/SR
Page 108 and 109:
Appendix A Example 98
Page 110 and 111:
Appendix B Requirements of the Func
Page 112 and 113:
Page 114 and 115:
Page 117 and 118:
Bibliography [1] FlexRay Protocol S
show all

Evaluation Environment for AUTOSAR-Autocode in Motor Control ...

Create successful ePaper yourself

Delete template?

Save as template?