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

More documents

Recommendations

Info

Chapter 4 Goals Communication The communication for MEDC17 is done with global variables. In case of AUTOSAR, ports are used to communicate between SWCs. The RTE generator often implements the intra-ECU sender–receiver communication with global variables, but it does not have to, especially not for components which are delivered in form of object code. Nevertheless, if the communication is implemented with global variables, the RTE generator creates some #define directives, which map the call to a direct access to global variables. But the identifiers of the directives differ from AUTOSAR to MEDC17 and the names of the global variables, too. Top–down Approach AUTOSAR uses a top–down approach in the way, that the BSW, especially the operating system, is configured for the needs of the ASW. In the case of MEDC17 the configuration is fixed and it is changed in very few cases. Instead, the ASW is adjusted to work with this premises. Ignorance From view of the RTE generator, it creates the RTE for all software, that runs on an ECU. The generated RTE provides data consistency for the communication and the specified behavior of e.g. the correct triggering of runnables by events. It does not know, that there is other software, which is not AUTOSAR compliant, but which runs additionally on the same ECU. This is not really a difference, but an important item for using not AUTOSAR compliant software. 4.1.2 Integration of AUTOSAR Software in MEDC17 For AUTOSAR compliant Software Components the RTE provides the connection to the BSW and between the components itself. So to integrate such components somewhere else it is necessary to integrate the RTE. Figure 4.1 shows the architecture of MEDC17 together with the integrated RTE. Of interest is especially the vertical part of the RTE layer, which adapts the old software to establish communications to the AUTOSAR software. However, adapters must exist to fit the old software. From the view of MEDC17 the RTE is just a new MEDC17 Application Software, which runs on it. But the RTE has some other requirements than a normal component and this requirements have to be provided from MEDC17. E.g. the RTE generator creates its own configuration for the operating system and the features and mechanisms specified in this configuration are needed to execute the generated RTE. So the operating system of MEDC17 have to be adjusted to provide this mechanisms. This could be e.g. a task or a special timing triggering a task. On the other hand not only MEDC17, but also the RTE can be changed, to get by the existing mechanisms. However the RTE is auto generated from the RTE generator, so this changes have to be done for every new configuration of a system. The other 30
AUTOSAR Application Software Runtime Environment (RTE) Adapter Adapter MEDC17 Basic Software MEDC17 Hardware 4.1 Background of the Topic MEDC17 Application Software Figure 4.1: Integration of AUTOSAR in MEDC17 way is to change the RTE generator itself, that it prefers mechanisms in the created source code, which are easier to handle for MEDC17. As described in chapter 2, the RTE does not only consist of generated code, but also of some fix source code which is called the RTE library. This RTE library can be customized once to fit into MEDC17. With this changes to the RTE library and the RTE generator and its output, it has to be assured, that the semantic of the configured system hasn’t changed. Because for delivered SWCs, the supplier has developed the components according to the AUTOSAR standard and this expected behavior has to be obtained. However, it is possible, to inform the supplier about AUTOSAR features, which can’t be integrated and therefore shouldn’t be used in delivered software. So there remain the following questions: • Which features can be integrated? • Which features can’t be integrated? • What should be changed on the RTE generator? • What should be changed on MEDC17? Since the RTE depends on the configuration of the system, to get answers for these questions, different configuration have to be checked. The result should be an interpretation, if the features can be integrated or what has to be changed to do it. If the feature cannot be integrated with adequate effort, this is also a result of the check. 31
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 36 and 37: Chapter 3 MEDC17 3.2 Basic Software
Page 38 and 39: Chapter 3 MEDC17 28
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?