AUTOSAR Run Time Environment (RTE)

Translate in your language

What Is Run Time Environment In General?

Run Time Environment (RTE) also called as run time system is a execution environment which helps a specific language or software to run and get accesses to hardware. For example, JAVA language uses JVM (JAVA Virtual Machine) or Python uses Python Interpreter. RTE helps the program to run correctly on hardware by abstracting different low level allocations like function, variables to memory mapping, etc. RTE also have software libraries, environment variables which are used by running processes. RTE is mostly used by high level languages. 

We being a Embedded system programmer, don’t work with RTE and C language don’t require any RTE for running on embedded systems hardware so we are not unaware of it, but AUTOSAR uses a RTE not in the sense of RTE for high level languages but in a different way, lets see it.   

Run Time Environment (RTE) in AUTOSAR

The Run time Environment is at the heart of AUTOSAR ECU architecture. The RTE along with AUTOSAR COM, OS and other BSW modules is the implementation of VFB Concept for a ECU. All the ports and interfaces are implemented in RTE which thereby realize the communication between SWCs and also act as a means by which SWC can access BSW modules like OS and Communication services. As described above, RTE has interfaces using which the Runnable in SWC communicates with other SWC or BSW module. RTE maps the Runnables to OS tasks as configured during RTE configuration and executes runnables either in same task or differently, RTE also handles the work of triggering runnables (if conditions are met) using RTE events as configured in SWC configuration. RTE is strongly linked with BSW scheduler due to same OS task may be used for both scheduling of SWCs and schedulable entities (also called main processing functions) of BSW module. Logically RTE is divided in two parts:

  • communication between SWCs
  • scheduling of SWCs

RTE and BSW scheduler is generated for each ECU to ensure optimal operation and customization at ECU level. In this article we will focus on RTE for SWC.

Simplified block diagram of AUTOSAR architecture
Fig. Simplified AUTOSAR layered architecture

AUTOSAR is developed with a vision to create a architecture to have hardware independent application which is relocatable and reusable, without RTE this cannot be achieved because RTE acts a glue layer to connect SWCs in application layer with BSW layers, to achieve this RTE is separately generated for each ECU. RTE is not reusable, because it is generated to match the application requirements and if application is changed the RTE also needs to be changed. All SWCs are portable and reusable except the sensor/actuator type of SWC which is highly dependent on ECU hardware. RTE is generated after integration of SWC, so RTE is responsible to make sure that system is working as expected by ensuring the communication of SWCs (between themselves as well as with BSW modules) is smooth irrespective of where the SWCs are deployed. RTE supports both SWCs with source code as well as SWCs with only object codes. RTE don’t support any runtime reconfiguration, i.e. every communication between SWCs and BSW modules must be configured before RTE is generated.

Uses or Application of RTE

RTE is one of the most important element of AUTOSAR because it performs vital operations useful for application. 

Some uses of RTE:

  • RTE Implements virtual function bus which helps in connection of SWCs within ECU and SWCs outside ECU (via physical network connection between ECUs)
  • RTE Implement communication paths using ports and interfaces which are used to connect between SWCs and BSW modules of lower layers as per configuration.
  • Invoke and support multiple Runnables of SWC based on different RTE events as per configuration.
  • Include any SWCs from any project during configuration and perform the operation as expected to accomplish the SWC reuse ability and portability feature of AUTOSAR. 
  • Enable instantiation of SWCs and support single as well as multiple instantiation of SWC
  • As RTE handles the execution of runnables in OS task, it implements a activation offset which is used to optimize CPU load,memory,etc in case of time triggered runnables mapped in same OS task. Because time triggered variables need to be executed on configured time and avoid conflicting of runnables by overlapping, RTE uses activation offset. RTE handles this by calculating the maximum period of task which is the Greatest Common Divisor(GCD) of all runnables and it assumes that any runnable maximum execution period would be lower than GCD.
  • RTE also notifies runnables of any interrupt (if configured) occurred at lower layers, but this doesn’t mean runnables will be executed in ISR! 😀 Runnables are subset of SWC and SWC is completely independent of lower layers.
  • RTE has to ensure data consistency when sharing variables among runnables of same SWC, or inter partition SWC or intra partition SWC or even in communication between SWC of different ECUs.
  • Communication between SWCs (in Sender-receiver communication) is not restricted to only peer to peer communication but also in 1:N (communication of a SWC with many SWCs) or N:1 (communication of many SWCs with one SWC) combination. RTE takes care to prevent any conflict if senders transmit at same time to one receiver or vice versa.
  • RTE notifies the sender of successful signal transmission if TransmissionAcknowledgementRequest is requested by sender. This notification doesn’t guarantee that receiver has received the signal successfully.

Generation of RTE

Generation of RTE is the most important and tricky step in any AUTOSAR based project. The result of generation of RTE is various files but we will consider 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 also prefer to generate separate RTE files (.c and .h) for each SWC which is further included in main RTE files just for ease of managing the RTE files of project, such generation options may vary based on AUTOSAR GUI tools. RTE generator can be a separate tool or a integrated tool which completely depends on the tool vendor you use. For example, in case of Vector DaVinci, the DaVinci developer is used for SWC,Runnables,IDT creation, etc. whereas DaVinci configurator is used to configure the BSW and generate RTE. In any AUTOSAR based system, RTE is generated separately for each ECU because SWCs of each ECU may have their own unique requirements and hence RTE is customized to cater such requirements.  

RTE generation process
Fig: RTE generation methodology

Above figure gives RTE generation steps with respect to SWC and RTE generator software. Lets see each step in detail:

  1. Collection of available SWC implementations: This step includes collecting of SWC description files (if intend to reuse old SWCs) and their respective Composition SWCs and use them further. Or we can also create new SWC implementation and use it for further step.
  2. Configure System: This steps combines the SWCs from old step and System (whole vehicle ECU network) is configured which has different Composition SWCs of different ECUs and other system constraints. In this step all SWCs are mapped to their respective ECUs. 
  3. System Configuration Description: This is arxml file which contains the details of ECUs of whole System (Vehicle) which is generated after System Configuration. For more information on System Configuration description check out this link. 
  4. Extract ECU specific information:This step extracts SWC description and other details of a single ECU unlike System configuration description file which contains information of all ECUs in a vehicle. The output of this step is called ECU Extract arxml which is next step. For more information on ECU Extract check out this link.
  5. Generate ECU Configuration: This step involves configuration of AUTOSAR lower layers (below RTE) of BSW modules like Com Services,etc. The output of this step is again a arxml file which contains the total information of a ECU like BSW configuration, SWC configuration, etc which happens to be next step of RTE generation process.
  6. Generate RTE: This is important step in RTE generation. In this step, all runnables are mapped to OS tasks, all delegation connectors are mapped to actual signals, etc. The output of this step is Rte.c and Rte.h files which can be roughly called RTE layer of AUTOSAR. I am calling roughly because there are some other files associated with RTE layer too.This step also generates BSWMD (Basic Software module description) file which contains information of different features of RTE. 
  7. Compile RTE: As the name suggests, in this step the RTE files are compiled (considering Runnable code is written) and object files are generated which are then linked with other compiled BSW and SWC files to generate a executable which can be flashed to MCU. 

Above steps are repeated for each ECU of system. Along with RTE files, SWC files (<swc_name>.h and <swc_name>.c) are also generated for each SWC, some software also generates skeleton of runnable in the SWC .c file and a function prototype in SWC .h file. SWC files will have #included with necessary header files (but this depends on the Configurator software you are using). All RTE files are generated in adherence to MISRA-C standard, although some MISRA violations are allowed 😀 but such instances are documented in comments. RTE source file has RTE calls required by application and other layers and RTE header files have prototypes for those calls.

As the main aim of AUTOSAR is the reuse ability of SWC, hence RTE supports compatibility of SWC for different AUTOSAR versions, provided that SWCs are available in their source file and not object code. The compatibility and reuse ability of SWC is not limited to only AUTOSAR version, but also tool vendor independence i.e. SWC from different tool vendors can be used provided their source code are available.

Some information on RTE API

RTE provides various APIs using which SWC can access data from other SWCs or lower layers.RTE APIs are easily distinguished in source by seeing the Rte_ prefix of any function call. RTE APIs are classified into two types:

  1. Direct API: It is a type of RTE API which is used when efficient (zero runtime overhead) invocation is needed. These APIs are generated for each port and application can directly use it by invoking the API name in runnable. Such APIs can be optimized for SWC while mapping APIs. Typically direct APIs are implemented as macros hence its not possible to get the address of the RTE API to use with function pointer in C, there are some hard ways however by which we can use function pointer if we want in our application.
  2. Indirect API: It is a type of RTE API where a API is invoked indirectly using a port handle. Such type of API is useful when there are multiple ports of single port interface so we can have an array of port handles of that interface and the same RTE API can be used for accessing multiple ports by just passing the respective port handle while invoking.

Both direct and indirect API calls will generate same result just the invocation way differs. Within SWC we can have both indirect or direct API implementation.

Relationship between files after RTE generation

After RTE generation, RTE generator tool generates many files of which the header files has relationship with other files i.e. those files are #included in different files. Lets see the files and their relationship with other files. Files generated :

  1. Rte.h: This file defines fixed elements that do not need to be generated for each ECU, because of this RTE generator software don’t generate this file again and again. However we can tailor this file to meet our application if needed. This file includes Std_Types.h file. 
  2. Std_Types.h: This file is the standard AUTOSAR file that defines basic data types like platform specific implementations of unsigned and signed integers and provides ways to access compiler abstraction.
  3. Rte_Main.h: This is Life cycle header file which has function prototypes of RTE life cycle API like Rte_Start and Rte_Stop . Some software also adds more life cycle APIs for initialization of RTE memory, etc. This file includes Rte.h file.
  4.  Rte_<swc_name>.h: This is application specific RTE header file, as the name explains the prefix of file name is always Rte_ and the suffix is the SWC name for which this RTE application file is associated. This file contains the function prototypes of RTE APIs, data structures and function prototypes of Runnable used in SWC associated with the SWC. This file includes Rte_Type.h and Rte_DataHandle.h file.
  5. Rte_Type.h: This file contains RTE specific type declarations derived from Implementation Data Type which is configured during SWC configuration. This file also contains AUTOSAR data types useful for RTE APIs. This file includes Rte.h file.
  6. Rte_DataHandle.h: This file contains Data Handle type declarations necessary for the SWC data structures. This file don’t contain any symbols which will use memory. 
  7.  Rte_<swc_name>_Type.h: This is also called Application types header file, it contains the application related constants like range values or enum values used in SWC. Again the file name will include the SWC name in spacer. This file includes Rte_Type.h file.

I hope I have explained RTE in simple language, although this is not enough but atleast it will give you a overview of RTE, its generation process and relationship between different files associated with RTE.

If you find any mistake I request you to please report me. If you have any doubt please ask it in comments section.

Thanks for reading 🙂

Like us on Facebook!

Subscribe for newsletters!

10 thoughts on “AUTOSAR RTE (Run Time Environment)”

  6. sudhir

    what is the diffrence between sender-reciver and client-server in rte w.r.t c-code generation(I am curious what type of c code will generate)

    Reply

Let me know your comments or doubts...

This site uses Akismet to reduce spam. Learn how your comment data is processed.