Overview of Events
What events to we have at our disposal in the RTE and the BSW modules, and how should we use them?
If you are very curious, by this point you may already know that the backbone of the Autosar OS is based on OSEK. So, some of the events in Autosar will look familiar to you, just like some very interesting concepts such as ISR category (CAT1 and CAT2, more on that in a future article). I highly encourage you to study the internals of the OSEK OS. It's easily available for Arduino and other popular platforms, and make a good exercise. You can check, for example TrampolineRTOS (opens in a new tab), for a very advanced experience, but there are more beginner-friendly platforms, so don't get scared.
So, what is an event? An event is a trigger to an action, which in Autosar, is usually a runnable, that defines (part of) the internal behavior of a component. This operation is controlled by the RTE, and requires a connection between your component and something else, which can be the OS, a SW-C, and BSW modules, as for most of them you have the option to generate a SW-C to communicate with components higher in the stack, instead of interfacing them with APIs, and in the case of most components other than CDD's (Complex Device Drivers), which is a special kind of SW-C, you are stuck with this option. For more info on what are CDDs, please check our article on Types of Software Components (opens in a new tab). Lastly, this connection between components is made invisible via the VFB (Virtual Function Bus), which is a vital part of the RTE.
Now, if you have seen our article on Types of Interfaces and Ports (opens in a new tab), the following names will sound very familiar to you. If they don't, please read the article, as it will provide you a good knowledge base to start. That said, let's dissect all the events.
The following events are triggered by the RTE:
| Abbrev. | Event | Description |
|---|---|---|
| T | TimingEvent | Event based on a timer period |
| BG | BackgroundEvent | Recurring event to perform background activities in a similar fashion to timer events but does not have a fixed time period and has a low priority |
| DR | DataReceivedEvent | Receive and process a signal received on a SR interface |
| DRE | DataReceiveErrorEvent | Triggered to collect the error status on reception |
| DSC | DataSendCompletedEvent | Receive and process acknowledge transmission notifications |
| DWC | DataWriteCompletedEvent | Receive and process acknowledge transmission |
| OI | OperationInvokedEvent | notifications for implicit communication |
| ASCR | AsynchronousServerCallReturnsEvent | Collect the result and status of an asynchronous CS operation |
| MS | SwcModeSwitchEvent | Trigger as a result of a mode switch operation |
| MSA | ModeSwitchedAckEvent | Receive and process mode switched acknowledgement notifications |
| MME | SwcModeManagerErrorEvent | Triggered to react on errors occurred during mode handling |
| ETO | ExternalTriggerOccurredEvent | Triggered at the occurrence of an external event |
| I | InitEvent | Activate runnables for initialization purposes in case of RTE start or restart of a partition |
| THE | TransformerHardErrorEvent | Raised when during the transformation of received data a hard transformer error occurred |
Aside from the former table, there are also BSW events. Contrary to the RTE events, the specification does not seem to abbreviate them, but we will, for easier reference. Most of them are similar to the ones found on the RTE, but there are some particularities, which will make more sense when we look at the table:
| Abbrev. | Event | Description |
|---|---|---|
| BswT | BswTimingEvent | Event based on a timer period |
| BswBG | BswBackgroundEvent | Recurring event to perform background activities in a similar fashion to timer events but does not have a fixed time period and has a low priority |
| BswETO | BswExternalTriggerOccurredEvent | Triggered at the occurrence of an external event |
| BswITO | BswInternalTriggerOccurredEvent | Triggered by explicit calls from within the module to the BSW scheduler. Its main purpose is to cause a context switch (e.g. from an ISR) |
| BswMS | BswModeSwitchEvent | Trigger as a result of a mode switch operation |
| BswMSA | BswModeSwitchedAckEvent | Receive and process mode switched acknowledgement notifications |
| BswMME | BswModeManagerErrorEvent | Triggered to react on errors occurred during mode handling |
| BswDR | BswDataReceivedEvent | Receive and process a signal received on a SR communication over the BSW scheduler |
| BswASCR | BswAsynchronousServerCallReturnsEvent | Collect the result and status of an asynchronous CS operation over the BSW over the BSW scheduler |
To finalize this article, we have seen some new concepts here, such as the BSW scheduler, transformers, and more. We will explore this in the future, so make sure to stay tuned for more articles.
Author: Micael Coutinho (opens in a new tab)
References:
© AutosarToday —@LinkedIn