Introduction
This document describes the MICROSAR RTE generation process, the RTE configuration with DaVinci Configurator and the RTE API.
The MICROSAR RTE generator supports RTE and contract phase generation. Additionally, application template code can be generated for software components and for VFB trace hooks.
Chapter 2 gives an introduction to the MICROSAR RTE. This brief introduction to the AUTOSAR RTE can and will not replace an in-depth study of the overall AUTOSAR methodology and in particular the AUTOSAR RTE specification, which provides detailed information on the concepts of the RTE.
In addition, chapter 2 describes deviations, extensions and limitations of the MICROSAR RTE compared to the AUTOSAR standard.
The RTE generation process including the command line parameters of the MICROSAR RTE generator is described in chapter 3. This chapter also gives hints for the integration of the generated RTE code into an ECU project. In addition, it describes the memory mapping and compiler abstraction related to the RTE and finally, chapter 3.6 describes the memory protection support of the RTE including hints for the integration with the OS.
The RTE API description in chapter 4 covers the API functionality implemented in the MICROSAR RTE.
The description of the RTE configuration in chapter 4.17 covers the task mapping, memory mapping and the code generation settings in DaVinci Configurator. A more detailed description of the configuration tool including the configuration of AUTOSAR software components and compositions and their integration in an ECU project can be found in the online help of the DaVinci Configurator [22].
Architecture Overview
The RTE is the realization of the interfaces of the AUTOSAR Virtual Function Bus (VFB) for a particular ECU. The RTE provides both standardized communication interfaces for AUTOSAR software components realized by generated RTE APIs and it also provides a runtime environment for the component code – the runnable entities. The RTE triggers the execution of runnable entities and provides the infrastructure services that enable communication between AUTOSAR SWCs. It is acting as a broker for accessing basic software modules including the OS and communication services.
The following figure shows where the MICROSAR RTE is located in the AUTOSAR architecture.
RTE functionality overview:
- Execution of runnable entities of SWCs on different trigger conditions
- Communication mechanisms between SWCs (Sender/Receiver and Client/Server)
- Mode Management
- Inter-Runnable communication and exclusive area handling
- Per-Instance Memory and calibration parameter handling
- Multiple instantiation of SWCs
- OS task body and COM / LDCOM callback generation
- Automatic configuration of parts of the OS, NVM and COM / LDCOM dependent of the needs of the RTE
- Assignment of SWCs to different memory partitions/cores
SchM functionality overview:
- Execution of cyclic triggered schedulable entities (BSW main functions)
- Exclusive area handling for BSW modules
- OS task body generation
Functional Description
Features
The features listed in the following tables cover the complete functionality specified for the RTE.
The AUTOSAR standard functionality is specified in [1], the corresponding features are listed
in the tables
- Table 2-1 Supported AUTOSAR standard conform features
- Table 2-2 Not supported AUTOSAR standard conform features
Vector Informatik provides further RTE functionality beyond the AUTOSAR standard. The corresponding features are listed in the table
- Table 2-3 Features provided beyond the AUTOSAR standard
The following features specified in [1] are supported:
Deviations
The following features specified in [1] are not supported:
Additions/ Extensions
The following features are provided beyond the AUTOSAR standard:
Limitations
There are no known limitations.
Initialization
The RTE is initialized by calling Rte_Start (and Rte_StartTiming, if enabled). Initialization is done by the ECU State Manager (EcuM).
The Basis Software Scheduler (SchM) is initialized by calling SchM_Init (and SchM_Start and SchM_StartTiming, if enabled). Initialization is done by the ECU State Manager (EcuM).
AUTOSAR ECUs
Besides the basic software modules each AUTOSAR ECU has a single instance of the RTE to manage the application software of the ECU. The application software is modularized and assigned to one or more AUTOSAR software components (SWC).
AUTOSAR Software Components
AUTOSAR software components (SWC) are described by their ports for communication with other SWCs and their internal behavior in form of runnable entities realizing the smallest schedulable code fragments in an ECU.
The following communication paradigms are supported for port communication:
- Sender-Receiver (S/R): queued and last-is-best, implicit and explicit
- Client-Server (C/S): synchronous and asynchronous
- Mode communication
- Calibration parameter communication
S/R and C/S communication may occur Intra-ECU or Inter-ECU (between different ECUs). Mode communication and calibration parameters can only be accessed ECU internally.
In addition to Inter-SWC communication over ports, the description of the internal behavior of SWCs contains also means for Intra-SWC communication and synchronization of runnable entities.
- Inter-Runnable Variables
- Per-Instance Memory
- Exclusive Areas
- Calibration Parameters
The description of the internal behavior of SWCs finally contains all information needed for the handling of runnable entities, especially the events upon which they are triggered.
Runnable Entities
All application code is organized into runnable entities, which are triggered by the RTE depending on certain conditions. They are mapped to OS tasks and may access the communication and data consistency mechanisms provided by the SWC they belong to.
The trigger conditions for runnable entities are described below, together with the signature of the runnable entities that results from these trigger conditions. A detailed description of the signature of runnable entities may be found in section 4.3 Runnable Entities.
Triggering of Runnable Entities
AUTOSAR has introduced the concept of RTEEvents to trigger the execution of runnable entities. The following RTEEvents are supported by the MICROSAR RTE:
- TimingEvent
- DataReceivedEvent
- DataReceiveErrorEvent
- DataSendCompletedEvent
- OperationInvokedEvent
- AsynchronousServerCallReturnsEvent
- ModeSwitchEvent
- ModeSwitchedAckEvent
- InitEvent
- BackgroundEvent
- ExternalTriggerOccurredEvent
- InternalTriggerOccurredEvent
- DataWriteCompletedEvent
The RTEEvents can lead to two different kinds of triggering:
- Activation of runnable entity
- Wakeup of waitpoint
Activation of runnable entity starts a runnable entity at its entry point while wakeup of waitpoint resumes runnable processing at a waitpoint. A wakup of waitpoint is not applicable for all kind of RTEEvents and needs to be set up inside the runnable entity code using a dedicated RTE API.
Depending on the existence of a waitpoint, runnable entities are categorized into category 1 or category 2 runnables. A runnable becomes a category 2 runnable if at least one waitpoint exists.
Time Triggered Runnables
AUTOSAR defines the TimingEvent for periodic triggering of runnable entities. The TimingEvent can only trigger a runnable entity at its entry point. Consequently, there exists no API to set up a waitpoint for a TimingEvent. The signature of a time triggered runnable is:
void <RunnableName>([IN Rte_Instance instance] [,IN Rte_ActivatingEvent_<RunnableEntity> activation])Data Received Triggered Runnables
AUTOSAR defines the DataReceivedEvent to trigger a runnable entity on data reception (queued or last-is-best) or to continue to receive queued data in a blocking Rte_Receive call. Both intra ECU and inter ECU communication is supported. Data reception triggered runnables have the following signature:
void <RunnableName>([IN Rte_Instance instance] [,IN Rte_ActivatingEvent_<RunnableEntity> activation])Data Reception Error Triggered Runnables
AUTOSAR defines the DataReceiveErrorEvent to trigger a runnable entity on data reception error. A reception error could be a timeout (aliveTimeout) or an invalidated data element. The DataReceiveErrorEvent can only trigger a runnable entity at its entry point. Consequently, there exists no API to set up a waitpoint for a DataReceiveErrorEvent. The signature of a data reception error triggered runnable is:
void <RunnableName>([IN Rte_Instance instance] [,IN Rte_ActivatingEvent_<RunnableEntity> activation])Data Send Completed Triggered Runnables
AUTOSAR defines the DataSendCompletedEvent to signal a successful or an erroneous transmission of explicit S/R communication. The DataSendCompletedEvent can either trigger the execution of a runnable entity or continue a runnable, which is waiting at a waitpoint for the transmission status or the mode switch in a blocking Rte_Feedback call.
The DataSendCompletedEvent is raised in the communication callbacks. Beware that the communication callbacks are not triggered when the communication is already stopped at the time of the transmission. In this case the RTE APIs return RTE_E_COM_STOPPED immediately.
Both intra ECU and inter ECU communication is supported. Data send completed triggered runnables have the following signature:
void <RunnableName>([IN Rte_Instance instance] [,IN Rte_ActivatingEvent_<RunnableEntity> activation])Mode Switch Triggered Runnables
AUTOSAR defines the ModeSwitchEvent to trigger a runnable entity on either entering or exiting of a specific mode of a mode declaration group. The ModeSwitchEvent can only trigger a runnable entity at its entry point. Consequently, there exists no API to set up a waitpoint for a ModeSwitchEvent. The signature of a mode switch triggered runnable is:
void <RunnableName>([IN Rte_Instance instance] [,IN Rte_ActivatingEvent_<RunnableEntity> activation])Mode Switched Acknowledge Triggered Runnables
AUTOSAR defines the ModeSwitchedAckEvent to signal a successful mode transition. The ModeSwitchedAckEvent can either trigger the execution of a runnable entity or continue a runnable, which is waiting at a waitpoint for the mode transition status. Only intra ECU communication is supported. Runnables triggered by a mode switch acknowledge have the following signature:
void <RunnableName>([IN Rte_Instance instance] [,IN Rte_ActivatingEvent_<RunnableEntity> activation])Operation Invocation Triggered Runnables
The OperationInvokedEvent is defined by AUTOSAR to always trigger the execution of a runnable entity. The signature of server runnables depends on the parameters defined at the C/S port. Its general appearance is as follows:
{void|Std_ReturnType} <Runnable>([IN Rte_Instance inst] {,paramlist}*)The return value depends on application errors being assigned to the operation that the runnable represents. The parameter list contains input input/output and output parameters. Input parameters for primitive data type are passed by value. Input parameters for composite data types and all input/output and output parameters independent whether they are primitive or composite types are passed by reference. The string data type is handled like a composite type.
Asynchronous Server Call Return Triggered Runnables
The AsynchronousServerCallReturnsEvent signals the end of an asynchronous server execution and triggers either a runnable entity to collect the result by using Rte_Result or resumes the waitpoint of a blocking Rte_Result call.
The runnables have the following signature:
void <RunnableName>([IN Rte_Instance instance] [,IN Rte_ActivatingEvent_<RunnableEntity> activation])Init Triggered Runnables
Initialization runnables are called once during startup and have the following signature:
void <RunnableName>([IN Rte_Instance instance])Background Triggered Runnables
Background triggered runnables have to be mapped to tasks with the lowest priority. These tasks are repeatedly scheduled by the RTE in the background while no other task with higher priority is active. The signature of a background triggered runnable is:
void <RunnableName>([IN Rte_Instance instance] [,IN Rte_ActivatingEvent_<RunnableEntity> activation])ExternalTriggerOccurredEvent Triggered Runnables
AUTOSAR defines the ExternalTriggerOccuredEvent to trigger a runnable entity directly. The ExternalTriggerOccuredEvent can only trigger a runnable entity at its entry point. Consequently, there exists no API to set up a waitpoint for a ExternalTriggerOccuredEvent. The signature of an external triggered runnable is:
void <RunnableName>([IN Rte_Instance instance] [,IN Rte_ActivatingEvent_<RunnableEntity> activation])InternalTriggerOccurredEvent Triggered Runnables
The InternalTriggerOccuredEvent is raised when a runnable is triggered by an internal triggering point of the same software-component instance. The InternalTriggerOccurredEvent can only trigger a runnable entity at its entry point. The signature of an internal triggered runnable is:
void <RunnableName>([IN Rte_Instance instance] [,IN Rte_ActivatingEvent_<RunnableEntity> activation])Data Write Competed Event Triggered Runnables
AUTOSAR defines the DataWriteCompletedEvent to signal successful or an erroneous transmission of implicit S/R communication. The DataWriteCompletedEvent is raised in the communication callbacks and triggers the execution of a runnable. Beware that the communication callbacks are not triggered when the communication is already stopped at the time of the transmission. In this case the RTE APIs return RTE_E_COM_STOPPED immediately. Inside the runnable with DataWriteCompletedEvent, the transmission status is obtained with Rte_IFeedback API. Data write completed triggered runnables have the following signature:
void <RunnableName>([IN Rte_Instance instance] [,IN Rte_ActivatingEvent_<RunnableEntity> activation])Exclusive Areas
An exclusive area (EA) can be used to protect either only a part of runnable code (explicit EA access) or the complete runnable code (implicit EA access). AUTOSAR specifies four implementation methods which are configured during ECU configuration of the RTE. See also Chapter 5.10.
- OS Interrupt Blocking
- All Interrupt Blocking
- OS Resource
- Cooperative Runnable Placement
In addition, the BSW modules EAs have the implementation method
- OS Spinlock
All of them have to ensure that the current runnable is not preempted while executing the code inside the exclusive area.
The MICROSAR RTE analyzes the accesses to the different RTE exclusive areas and eliminates unneeded ones if that is possible e.g. runnable entities accessing the same EA cannot preempt each other.
OS Interrupt Blocking
When an exclusive area uses the implementation method OS_INTERRUPT_BLOCKING, it is protected by calling the OS APIs SuspendOSInterrupts() and ResumeOSInterrupts(). The OS does not allow the invocation of event and resource handling functions while interrupts are suspended. Hence, any call to a RTE API that is based upon an explicitly modeled waitpoint like: blocking Rte_Receive, Rte_Feedback, Rte_SwitchAck or Rte_Result API, as well as synchronous server calls (which sometimes use waitpoints that are not explicitly modeled or other rescheduling points) are not allowed. Additionally, all APIs that might trigger a runnable entity on the same ECU or cause a blocking queue access to be released are forbidden, as well as exclusive areas implemented as OS Resource.
All Interrupt Blocking
When an exclusive area uses the implementation method ALL_INTERRUPT_BLOCKING, it is protected by calling the OS APIs SuspendAllInterrupts() and ResumeAllInterrupts(). The OS does not allow the invocation of event and resource handling functions while interrupts are suspended. This precludes calls to any RTE API that is based upon an explicitly modeled waitpoint (blocking Rte_Receive, Rte_Feedback, Rte_SwitchAck or Rte_Result API) as well as synchronous server calls (which sometimes use waitpoints that are not explicitly modeled or other rescheduling points). Additionally, all APIs that might trigger a runnable entity on the same ECU or cause a blocking queue access to be released are forbidden, as well as exclusive areas implemented as OS Resource.
OS Resource
An exclusive area using implementation method OS_RESOURCE is protected by OS resources entered and released via GetResource() / ReleaseResource()calls, which raise the task priority so that no other task using the same resource may run. The OS does not allow the invocation of WaitEvent() while an OS resource is occupied. This again precludes calls to any RTE API that is based upon an explicitly modeled waitpoint and synchronous server calls.
Cooperative Runnable Placement
For exclusive areas with implementation method COOPERATIVE_RUNNABLE_PLACEMENT, the RTE generator only applies a check whether any of the tasks accessing the exclusive area are able to preempt any other task of that group. This again precludes calls to any RTE API that is based upon an explicitly modeled waitpoint and synchronous server calls.
OS Spinlock
The implementation method OS_SPINLOCK is available for BSW modules EAs. It allows the EA to be protected against race conditions in multicore systems. For this a Spinlock is created in the OS. Furthermore, this method ensures that the current runnable is not preempted while executing the code inside the exclusive area. For this SuspendAllInterrupts() and ResumeAllInterrupts() are called, if the Spinlock is not locking its area by default.
Error Handling
Development Error Reporting
By default, development errors are reported to the DET using the service Det_ReportError() as specified in [21], if development error reporting is enabled in the RteGeneration parameters (i.e. by setting the parameters DevErrorDetect and / or DevErrorDetectUninit).
If another module is used for development error reporting, the function prototype for reporting the error can be configured by the integrator, but must have the same signature as the service Det_ReportError(). The reported RTE ID is 2.
The reported service IDs identify the services which are described in chapter 4. The following table presents the service IDs and the related services:
The errors reported to DET are described in the following table:
The error RTE_E_DET_UNINIT will only be reported if the parameter DevErrorDetectUninit is enabled. The reporting of all other errors can be enabled by setting the parameter DevErrorDetect.
Dirty Flag Handling
The MICROSAR RTE supports NvBlock SWCs that can interact with the NVM to automatically persist the written values to NV memory when the dirty flag handling is configured. The following settings are possible:
In case an NVM job is still pending when the NvRunnable tries to write the block, the RTE retries the operation when the NVM notifies the RTE that the previous job is finished.
References
MICROSAR RTE Technical Reference (Version 4.25.0)
标签：RTE,Rte,AUTOSAR,runnable,Run,communication,Environment,OS From： https://blog.csdn.net/erroror/article/details/144022658