My name is Sharana Basava, and I work at Luxoft India as a junior software engineer. I have had multiple opportunities to work on different projects at Luxoft, which has motivated me to talk about the crucial steps in creating a Automotive standard.
->Introduction about Runtime Environment
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
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
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 Sender/Reciever and Client/Server 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.
Triggering of Runnable Entities
AUTOSAR has introduced the concept of RTE Events to trigger the execution of runnable entities· The following RTE Events are supported by the MICROSAR Classic RTE:
->TimingEvent
->Data Received Event
->Data Receive Error Event
->Data Send Completed Event
->Operation Invoked Event
->Asynchronous Server Call Returns Event
->Mode Switch Event
->Mode Switched Ack Event
->Init Event
->Background Event
-> External Trigger Occurred Event
->Internal Trigger Occurred Event
->Data Write Completed Event
The RTE Events can lead to two different kinds of triggering:
->Activation of runnable entity
->Wakeup of wait point
Activation of runnable entity starts a runnable entity at its entry point while wakeup of wait point resumes runnable processing at a wait point· A wakup of wait point is not applicable for all kind of RTE Events and needs to be set up inside the runnable entity code using a dedicated RTE API·
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 wait point for a Timing Event·
Data Received Triggered Runnables
AUTOSAR defines the Data Received Event 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:
Data Reception Error Triggered Runnables
AUTOSAR defines the Data Receive Error Event to trigger a runnable entity on data reception error. A reception error could be a timeout (alive Timeout) or an invalidated data element. The Data Receive Error Event can only trigger a runnable entity at its entry point. Consequently, there exists no API to set up a wait point for a Data Receive Error Event.
Data Send Completed Triggered Runnables
AUTOSAR defines the Data Send Completed Event to signal a successful or an erroneous transmission of explicit S/R communication· The Data Send Completed Event can either
trigger the execution of a runnable entity or continue a runnable, which is waiting at a wait point for the transmission status or the mode switch in a blocking Rte Feedback call·The Data Send Completed Event 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
Top comments (0)