PXROS - Real-time OS for TriCore and AURIX™

The PXROS-HR operating-system for TriCore has been officially safety approved. HighTec received the certificate confirming the fitness of PXROS-HR for safety-related applications up to SIL 3 (IEC61508) and ASIL D (ISO 26262).

The certification includes an assessment report containing the assessment results of the certification authority, TÜV-Nord Systems GmbH & Co. KG. 

PXROS-HR is developed with the HighTec C/C++ compiler for TriCore/AURIX and best suited for industrial applications, as well as automotive applications where safety is key. The RTOS integrates with Infineon's MCAL and SafeTlib software frameworks, while being non-AUTOSAR based and highly optimized for the TriCore architecture, providing multi-core support for the AURIX family

PXROS-HR (High Reliability) is the successor of the original real-time micro-kernel PXROS, that was first developed in 1983, which is in successful use since 1985 on thousands of different applications/devices in the field. There were three very important design goals set for the original PXROS, which were fully achieved:

• Excellent interrupt behavior (no interrupt locking!)
• Philosophy of OS leads to a good structure and architectural clearness
• Extreme robust behavior under heavy load

One of the most important principles underlying PXROS is encapsulation of information and activity.

Both help to improve the reliability and protection against unintended or malicious interference. Activities (tasks in the sense of processes) live in capsules and can only communicate by exchanging message objects and signals. Processes of this kind only know the objects needed to fulfill their task and behave in a such way that the rest of the system is affected to the least possible extend. For example, they should never use hard interrupts locks, because this might destroy assumptions regarding timing behavior in other places. Resources should only be used in such a way, that a local bottleneck has no global effects.

The PXROS-API offers the complete set of services required to achieve the above mentioned goals. This API also allows to emulate the APIs of many other OSs. In PXROS-HR the principles of encapsulation are ensured in the form of automatic run-time checks performed by the AURIX MPU. The AURIX MPU behaves like an address comparator for checking address boundaries. PXROS-HR manages the AURIX MPU and ensures that an illegal data access by a task will be immediately detected at run-time by the MPU, and any error propagation will be prevented. If a task is scheduled, PXROS-HR will switch the MPU configuration of the corresponding task.

In addition, PXROS-HR allows reloading and debugging tasks at run-time without stopping a running application. This encapsulation enables customers to perform a save function integration and to mix safety and non safety related software on a single AURIX without risk, since there is no error propagation. 

Tasks and Handlers

Because fast reactions to certain events are required in many technical applications, which should be executed with as little overhead as possible, PXROS implements the concept of complete interrupt transparency, i.e. PXROS never changes the state of the interrupt system of the microcontroller. This feature makes it possible to achieve warm start capability with PXROS. Thus, there are no interrupt locks caused by PXROS and interrupt services can always interrupt PXROS. The RTOS solely manages the remaining time resources of a main-loop. Due to the interrupt transparency, existing applications without OS can easily be ported to PXROS-HR as well as OS, which are partially or totally implemented on interrupt level. As the interrupt handling is not “predefined” or interfered by the microkernel, the application might implement any needed or reasonable check for the activity related to interrupts.

In the PXROS terminology the interrupt service routines are so called handlers, which, in principle, are completely under control of the application, but can still use a subset of PXROS services. These services are handled in a special way, in order to minimize the PXROS related overhead on interrupt level.
A handler can, for example, send signals (Events) to a task. This service is not executed on interrupt level, but is inserted into a list instead. Then this service is executed before returning from the interrupt levels to task level. This is in time, because the next task to be executed has to be determined before leaving the interrupt level.
The use of handlers guarantees optimal time response (just like without OS), but except for the highest interrupt level, has affects on other interrupts. Actions within a task have no effect on the interrupt system, but task scheduling and communication generate some overhead, and thus it is vital for the overall performance of an application to find a good balance between handler and task based execution of application parts.

In PXROS philosophy, a handler always belongs to a task and its address space. This means that in PXROS-HR, handlers will be controlled by the MPU. Handlers and the related task have a relation like interrupts to main-loop.
In dynamically configured PXROS - systems (static configuration is also possible), tasks are responsible for installing and uninstalling related handlers. This concept allows dynamic configuration and reconfiguration of a running system.
The PXROS-HR micro-kernel is executed in supervisor mode and handles the Memory Protection Unit of the controller. Tasks and handlers are executed in UserMode-0 or UserMode-1. In UserMode-1 the access to peripherals and the interrupt system is enabled. In the restricted UserMode-0 code can be executed, but the interrupt and peripherals cannot be accessed. Special PXROS-HR services allow selective access to peripherals in UserMode-0.

The supervisor mode and the User-Modes use separate sets of protection registers, which are switched automatically by the TriCore hardware without overhead. If the PXROS-HR kernel is active, the kernel restricts its access to the object that has to be modified.

Control of Resources

With respect to safety and robustness it is very important to avoid bottlenecks or at least to limit their global effects. For this reason resources are subject to quota. Thus, every task has accounts, from which consumed resources are deducted or to which released resources are reassigned. This also means, that objects are either free (unused) or assigned to a task. All special objects (mailboxes, memory classes, object pools, message objects) are created from free “universal” objects taken from object pools and become “universal” objects again when released.

This means in particular, that as long as free objects are available, objects of any kind can be created and deleted during run-time. Every task gets memory and objects from its creator. With suitable quotas memory- and object-bottlenecks can be limited to the affected task or subsystem, and systems can be built, which are partially dynamic without bottlenecks having compromising effects to vital functions of the overall system.

Signaling and Communication

PXROS allows interaction between handlers and tasks and among tasks via events and message-objects. Events are short messages implemented as bit fields, for which tasks can wait selectively with the help of a bit mask, telling which of the bits should terminate the waiting state. Message objects consist of an object description only accessible for the OS and the related data area. The object description also contains the information, which task currently uses the object. Moreover, there are link elements allowing to link the object into a mailbox (list), so that a mailbox can receive an arbitrary number of messages. If the object is sent, it leaves the address space of the sender and becomes part of a mailbox. Receiving an object from a mailbox removes the object from the mailbox and assigns it to the address space of the receiving task. An additional PXROS service is then required by the receiving task to get a pointer to the data area. If the micro-controller (e.g. AURIX) has suitable memory protection, PXROS-HR can protect itself and all managed objects from faulty and illegal access.

Sending of a message or event is asynchronous and the sending instance must not assume, that the effect of these operations would be immediate. Sychronisation has to be done explicitly!.

In PXROS-HR the content of messages is protected by the MPU, which leads to the highest level of data encapsulation and is relevant for achieving a high level of security.
For clean implementation of this protection concept for objects, the micro-controller should have a suitable memory protection unit (MPU) with fine granularity such as the AURIX . Without a suitable MPU there is either a compromise in safety and security, or an excessive use of resources. In contrast to semaphore based communication, message object passing like in PXROS means atomic transfer of reference and access rights. It can be ensured, that at any given point of time an object can only (!) be used or modified by a single instance. Common objects can still be handled safely if they are stored (deposited) in a mailbox currently not used by other instances. Just like other objects, mailboxes can be created and deleted dynamically.
PXROS allows simultaneous waiting for message objects and events

General Abort Mechanism

All services eventually leading to a waiting state can be terminated via Events. Moreover, an arbitrary function can be called in such a way that it is subject to termination via selected Events. This might be helpful in cases where computation has to be limited in time (convergence issues) or for other important reasons such as power fail situations.

Time Management

PXROS is completely event driven and thus does not need a tick for internal operation. Since software timers are often required or helpful, PXROS offers so called delay-jobs as basic timing mechanisms. A delay-job allows the execution of user defined functions (with parameters) after a given number of ticks. The tick period and thus time granularity is defined by the application. Delay-jobs are executed as handlers on the interrupt level of the tick source. The time base of these soft timers can of course be subject to jitter if higher interrupts exist.
As outlined, PXROS as an event controlled micro-kernel does not need timing events, yet it supports time slicing if ticks are available.

Improved Computing Power Consequences

Safety and security measures often increase time and space requirements. In the past, this resulted in security or performance compromises. With modern high performance microcontrollers such as the TriCore, clean approaches and strict encapsulation become possible with minimal overhead. In PXROS-HR, the relevant overhead for encapsulation of tasks and message object transfer consists of the time that is needed for a Send and Receive operation with task scheduling.

Redundancy, voting, diversity and other advantages are now possible even for fast processes. Moreover, control instances can be inserted transparently into the data and control flow.

• All Infineon AURIX, TC2x, TC3x and TC4x

Please contact us for further information and quotation.