My name is Sushma B R, and I am working as Software Engineer at Luxoft India. In this article I will be providing the detailed information towards RTE and its Generation. Luxoft has provided me with multiple opportunity to work on various projects which inspired me to learn the RTE and its Generation.

The Run time Environment is on the coronary heart of AUTOSAR ECU shape. The RTE together with AUTOSAR COM, OS and tremendous BSW modules is the implementation of VFB Concept for a ECU.All the ports and interfaces are implemented in RTE which thereby understand the conversation among SWCs and furthermore act as a manner with the useful aid of which SWC can access BSW modules like OS and Communication offerings. As described above, RTE has interfaces using which the Runnable in SWC communicates with specific SWC or BSW module. RTE maps the Runnables to OS obligations as configured throughout RTE configuration and executes runnables both in equal undertaking or in every different way, RTE also handles the artwork of triggering runnables (if situations are met) the usage of RTE activities as configured in SWC configuration. RTE is strongly related with BSW scheduler because of same OS task may be used for each scheduling of SWCs and schedulable entities (additionally called most crucial processing abilities) of BSW module. Logically RTE is split in additives:

• communication between SWCs
• scheduling of SWCs

RTE and BSW scheduler is generated for each ECU to make certain most fulfilling operation and customization at ECU stage. In this text we are able to cognizance on RTE for SWC.

AUTOSAR is developed with a imaginative and prescient to create a architecture to have hardware independent application which is relocatable and reusable, without RTE this can't be done due to the fact RTE acts a glue layer to attach SWCs in application layer with BSW layers, to reap this RTE is separately generated for every ECU. RTE is not reusable, because it's far generated to healthy the utility requirements and if utility is changed the RTE also needs to be changed. All SWCs are portable and reusable besides the sensor/actuator kind of SWC that is rather dependent on ECU hardware. RTE is generated after integration of SWC, so RTE is responsible to make sure that device is operating as anticipated by way of making sure the communique of SWCs (between themselves as well as with BSW modules) is easy regardless of wherein the SWCs are deployed. RTE supports both SWCs with source code as well as SWCs with best object codes. RTE don’t aid any runtime reconfiguration, i.. Every verbal exchange among SWCs and BSW modules need to be configured earlier than RTE is generated.

Generation Of RTE:

Generation of RTE is the most essential and problematic step in any AUTOSAR based undertaking.
There are various file results of RTE generation, but here we are consideing only two files which are important:

1. Rte.c file
2. Rte.h file.

This is the most common RTE generation result but some integrator additionally opt to generate separate RTE files (.C and .H) for each SWC which is further included in most important RTE files only for ease of managing the RTE files of challenge, such era alternatives may additionally vary based on AUTOSAR GUI equipment. RTE generator may be a separate tool or a incorporated device which absolutely depends on the device seller you operate. For instance, in case of Vector DaVinci, the DaVinci developer is used for SWC,Runnables,IDT creation, and so on. While DaVinci configurator is used to configure the BSW and generate RTE. In any AUTOSAR based system, RTE is generated one by one for each ECU because SWCs of each ECU may additionally have their personal precise requirements and hence RTE is custom designed to cater such necessities.

Above figure gives RTE era steps with appreciate to SWC and RTE generator software.

Lets see each step in detail:

Collection of available SWC implementations:
This step consists of accumulating of SWC description files (if intend to reuse old SWCs) and their respective Composition SWCs and use them similarly. Or we can also create new SWC implementation and use it for similarly step.

Configure System:
This steps combines the SWCs from vintage step and System (entire car ECU community) is configured which has unique Composition SWCs of various ECUs and different gadget constraints. All SWCs are mapped to their respective ECUs in this step.

System Configuration Description:

This is arxml document which includes the info of ECUs of complete System (Vehicle) that's generated after System Configuration. For greater statistics on System Configuration description test out this link.

Extract ECU specific information:
This step extracts SWC description and different info of a single ECU in contrast to System configuration description report which contains information of all ECUs in a automobile. The output of this step is known as ECU Extract arxml which is subsequent step. For more facts on ECU Extract check out this link.

Generate ECU Configuration:
This step entails configuration of AUTOSAR lower layers (under RTE) of BSW modules like Com Services,and many others. The output of this step is once more a arxml file which incorporates the overall statistics of a ECU like BSW configuration, SWC configuration, and so on which takes place to be next step of RTE generation process.

Generate RTE:
This is important step in RTE era. In this step, all runnables are mapped to OS obligations, all delegation connectors are mapped to actual alerts, and many others. The output of this step is Rte.C and Rte.H files which can be roughly referred to as RTE layer of AUTOSAR. I am calling roughly due to the fact there are a few other documents related to RTE layer too.This step also generates BSWMD (Basic Software module description) document which incorporates statistics of various features of RTE.

Compile RTE:
As the call indicates, in this step the RTE documents are compiled (considering Runnable code is written) and item files are generated which can be then related with other compiled BSW and SWC files to generate a executable which may be flashed to MCU.

Above steps are repeated for each ECU of system. Along with RTE documents, SWC documents (.H and .C) also are generated for each SWC, a few software program additionally generates skeleton of runnable in the SWC .C record and a feature prototype in SWC .H document. SWC documents will have #protected with vital header documents (but this relies upon at the Configurator software you are using).

All RTE files are generated in adherence to MISRA-C popular, although some MISRA violations are allowed but such times are documented in feedback. RTE source document has RTE calls required by way of utility and other layers and RTE header files have prototypes for the ones calls.

To be continued...