Scope
The current page contains all useful information about Operating System (OS) Basic Software in System Service Layer.
The main scope, is to learn of RTA-OS is built and to configure/generate it for the interaction between RTA-SUMs (like SOH) as OS in AUTOSAR stack.
AUTOSAR OS Specification
AUTOSAR OS shall be strongly based on OSEK OS (event-trigger based OS) for its flexibility and maintainability. OSEK provides the following features for supporting AUTOSAR OS:
- Fixed Priority Scheduling;
- Facilities for Interrupt Handling;
- Priority management between Interrupts and Tasks;
- Protection aganist inappropriate usage of OS Services;
- Startup and Shutdown Interfaces for OS and Hooks;
According to these, the main features for identifying a compliant AUTOSAR OS are the following:
- It is configured and statically scaled;
- It is aimed to be used for Real-Time applications;
- It provides a Priority-based scheduler;
- It implements protection functions aganist wrong usage and accessing to Memory and Timing resources;
- It can be hosted on a target device without the necessity of external resources;
RTA-OS Specification and Configuration
General
RTA-OS is ETAS's Real-Time Operating System (RTOS), it allows preemption, totally compliant with AUTOSAR OS. It can be configured and built on a PC and then, it can be used on a target platform.
The configuration can be done by a graphical tool: RTA-OS OS Configuration Tool, while building, that generates the Kernel libraries can be done by tcommand line using rtaosgen command;
The Port plug-ins allows the customization of RTA-OS for a specific target MCU and specific compiler. As Default, At installation time, RTA-OS includes the port VRTA to run the OS on General Purpose PC with a Virtual Target Environment.
The definition of task priority, interrupts and critical sections shall be done at configuration time.
Configuration
The configuration can be done with "RTA-OS OS Configuration Tool". Its usage foreseen:
- As Input : .arxml files, .rtaos (project for this tool) and OIL files. These last can be imported how it is explained in the User Guide.
- As Output : .arxml file with all configuration parameters;
Generation
For Kernel libraries generation, it requires as input the XML files from Configuration step. The generation will optimize the configuration of the RTA-OS in order to have a smaller and more efficient work product. The Generation is done by Command Line, batch/bash script or graphical panel in graphical tool.
For this phase it is necessary to specify the target environment and the code compiler. For our scope, at the moment, we are having:
- Target Environment: VRTA;
- Compiler: MinGW;
If a different target shall be defined, then it is necessary to allow the access to its tool-chain (look Getting Start documentation for RTA-OS).
Structure
Assuming the configuration of the RTA-OS as Object-Oriented, its architecture with related hierarchy and dependencies, can be represented with the following class diagram:
Error Handling (SOH interaction)
OS Basic Software module is different from other basic software ones because it does not report its error codes to Dem (production errors) or Det (Development error) but it can directly handle them. OS Errors are defined by codes in AUTOSAR specification (AUTOSAR_SWS_OS, Section 7.13) as it is reported in the next table:
| Type of error | Related error code | Value |
|---|---|---|
| Service can not be called. | E_OS_SERVICEID | Assigned by implementation |
An invalid address is given as a parameter to a service. | E_OS_ILLEGAL_ADDRESS | Assigned by implementation |
Tasks terminates without a TerminateTask() or ChainTask() call. | E_OS_MISSINGEND | Assigned by implementation |
A service of the OS is called inside an interrupt disable/enable pair. | E_OS_DISABLEDINT | Assigned by implementation |
A stack fault detected via stack monitoring by the OS. | E_OS_STACKFAULT | Assigned by implementation |
A memory access violation occurred. | E_OS_PROTECTION_MEMORY | Assigned by implementation |
A Task exceeds its execution time budget. | E_OS_PROTECTION_TIME | Assigned by implementation |
A Category 2 ISR exceeds its execution time budget. | E_OS_PROTECTION_TIME | Assigned by implementation |
A Task/Category 2 ISR arrives before its timeframe has expired. | E_OS_PROTECTION_ARRIVAL | Assigned by implementation |
A Task/Category 2 ISR blocks for too long. | E_OS_PROTECTION_LOCKED | Assigned by implementation |
| A trap occurred. | E_OS_PROTECTION_EXCEPTION | Assigned by implementation |
| Core is not available. | E_OS_CORE | Assigned by implementation |
De-scheduling with occupied spinlock. | E_OS_SPINLOCK | Assigned by implementation |
Deadlock situation due to interference. | E_OS_INTERFERENCE_DEADLOCK | Assigned by implementation |
Potential deadlock due to wrong nesting. | E_OS_NESTING_DEADLOCK | Assigned by implementation |
A null pointer was given as argument | E_OS_PARAM_POINTER | Assigned by implementation |
Error codes are returned by RTA-OS API calling and they can be handled by Error Hooks. Actually, RTA-OS can be configured in order to handle the entire AUTOSAR error codes set or a sub-set. If the entire error set shall be handled then:
- Configuration of RTA-OS build status must be equal to EXTENDED ;
- User-specifc Error Hooks shall be generated;
In RTA-OS OS Configuration Tool, it is possible to require the generation of ErrorHook skeleton in section: Builder > Setup > Samples checking the boxes as in the following:
The result will be generated in folder Samples/ErrorHook, once that button "Build Now" will be pressed and building process will terminate. At the end, it will appear like the following:
In this case, the ErrorHook it is never been called by an application, it is just a skeleton with library inclusion.
If you want to generate an ErrorHook skeleton that is intended to be called by OS-Application, It is necessary to set RTA-OS configuration parameter OsErrorHook as TRUE (look the following picture about RTA-OS Configuration Tool)
The ErrorHook is an user-specific function and it is invoked by OS when one of its API returns an Error Code (E_OS_<xxx>). When OS defines a single and general ErrorHook for each occurrence, it is just named ErrorHook().
In the specific case of SUM SOH, ErrorHook can be used to handle OS error and then report it to SOH by RTE.
ErrorHook skeleton generation can be also done by text command:
rtaosgen --samples:[ErrorHook]overwrite <MyConfig.xml>
RTA-OS Project Sample
The following Files contain a sample of RTA-OS configuration that is intended for communication of the SOH. The actual OS settings are aligned to SOH release 6.0.0.
Generally, RTA-OS Configuration Tool create the project file with extension .rtaos, while the configuration (i.e. the description) is contained in an .arxml file.
The RTA-OS generated files are all the Kernel libraries and the samples that are selected (for example ErrorHook or ProtectionHook). These files are generate in order to be used for:
- Unit Testing in Cantata: it is possible to include the generated files, as OS.h, in Cantata Stub folder. Let's note that this solution might require the manual development of pieces of code for completing the stubs source codes;
- RTE Generation: ErrorHook skeleton is generated from building of sample project. It shall be filled in order to communicate the OS error occurrence to SOH by RTE;
- Integration Testing with VRTA: Modifying the sample project makes possible to modify the OS generated code. This last can be compiled and then it can be run as an Host process on Windows/Linux PC. The application shall be then synchronized with VRTA testing by sendig/receiving signal to/from it.
According to the last topic, the artifact (arxml) of the RTA-OS shall replace or update that one in RTA-SK for VRTA in path: VRTA_GCC_x.y.z/Implementation/RTA-SK/ecu_config/os. The same folder can directly contains rtaos file. General guidelines, where it is important to pay attention are:
- According to AUTOSAR specification, not all Scalability Classes allows the generation of ErrorHook: for this reason it has been chosen to configure the RTA-OS with Scalability Classes 4 that allows the entire set of OS feature. Note that not everyone of them shall be configured as mandatory;
- RTA-OS define the entire set or OS errors, as specified by AUTOSAR. However, there are two possibility for implementing error classes: one for more experts and another for the beginners. Considering the necessity of the SOH that shall monitor all errors in OS, it has been necessary to set the OS Status in order to produce them. This is possible setting Configuration Parameter OsStatus as EXTENDED.
- In OS Configuration/General/Target (look on left panel of Configuration tool window when it is opened) make sure that in "Target Selection" there are these values:
- Name: VRTA (This is necessary for testing with VRTA)
- Variant: MinGW
