PXROS-HR Architecture

Tasks are the basic elements of a PXROS-HR system. They represent concurrent processing units within an application and are prioritized among each other, yet never of higher priority than the handlers.

Tasks run in a quasi-parallel way. However, since typically several tasks share one physical processor, computing time is assigned to them by the operating system. In practice, this means that if a task is willing to run and has a higher priority than the current task, it will replace the current task.

A task can have any one of the following four states:

PXROS-HR uses a permission concept for tasks, i.e. tasks have to be authorized in order to access system resources. These types of permission are called privileges (hardware-based) or access rights (based on the operating system) (see Section Safety characteristics).

Handlers are functions that are called whenever a hardware or software interrupt occurs. They have a higher priority than any task.

In order to speed up processing of Handlers and to avoid blocking, they have restricted access to PXROS-HR system services.

There are three types of Handlers: Context Handlers and Fast Context Handlers, which are executed in the context of the associated tasks, and Fast Handlers, running in system context.

Task objects are used for modelling PXROS-HR processes, the so-called tasks, with their properties such as priority, stack size, protected memory assigned, etc. (see also Section Tasks).

A MemoryClass object represents a memory class: the available memory can be separated into several disjoint blocks, the so-called memory classes. Tasks can be either granted exclusive access to these memory classes, or several tasks can share a memory class.

When using several memory classes, tasks can have different types of memory assigned (slow memory / fast memory). Furthermore, by assigning a memory class exclusively to one task, memory shortage during runtime can be avoided in this task, which would otherwise occur if another task utilizes all the available memory.

Messages are objects, which are used by tasks to exchange data. They also serve for synchronizing tasks, since a sender task can wait for a recipient task to release a Message.

As illustrated in Access to the memory area of a Message, the content of a Message is not copied. A Message object is given a portion of memory belonging to the owner of the Message. After sending the Message, this memory portion changes into the possession of the recipient where it remains until the recipient releases, forwards or returns it.

Mailboxes are the communication terminals for Message exchange. A task sends a Message object to a mailbox, while a recipient can wait for arriving Messages at this mailbox.

Object pools are used for storing objects until they are needed. There is a standard system pool, where all objects can be found at the time of initialisation. Other object pools can be created and filled with objects. These pools can be assigned to individual tasks in order to avoid object shortage during runtime, as they would occur with shared object pools (see Object pools).

Interrupt objects are used for enqueing in the sysjob list, so that the according interrupt handlers are executed on OS level.

A Message object represents an element of communication that can transfer data.

A task wishing to send a Message has to provide a data buffer for this Message.

The data buffer for a Message can be obtained in two ways: The sending task can state a memory class (see Section MemoryClass Object), from which the memory is to be taken, i.e. it 'borrows' the memory from this memory class and can use it as if it were its own memory for as long as it owns the Message.

The other possibility is to provide the Message object with memory of the task’s own memory.

The data buffer can be filled with arbitrary data. As soon as the Message was sent to a mailbox, the corresponding buffer is no longer part of the memory area of the task, i.e. the task may no longer access this memory area.

If a recipient task reads the Message from the mailbox, the contained buffer is added to its address space. The task can access this area until it passes the Message on or releases it. Once the Message was released, the contained memory is reallocated to its original owner, i.e. the memory class or task.

An Event is used for signalling an occurrence to a task. In comparison to Messages, Events have the advantage of not using up any system resources. Up to 32 different Events can be signaled, the meaning of the events must only be agreed between sender and recipient.

A task can wait for several Events at the same time and is awakened as soon as one of the Events occurs.

The PXROS-HR safety concept is based on hardware-assisted memory supervision. This concept relies upon the Memory Protection Unit (MPU) of the processor. The MPU contains registers, in which the upper and lower bounds of the memory area of a task (or the system), as well as the corresponding rights (read and/or write) are stored.

A task is regarded as being enclosed in a capsule, which it cannot leave. Hardware memory protection has the purpose of preventing a task from reaching out of its capsule.

During initialisation, memory is allocated to a capsule, which it can access. The start and end addresses of this area, as well as read and write permissions, are stored in registers of the MPU, making it possible for the hardware to check memory access operations during runtime. This memory area contains the data as well as the stack memory of the task.

Apart from this, memory can be mapped onto the address area of the task if the task receives a Message object.

In addition, extended memory areas can be defined for a task. This method is, however, subject to a loss in performance since the memory areas are stored in virtual protection registers that have to be mapped to the hardware registers before they can be accessed.

If a task reaches out of its memory areas, the MPU detects this access violation and triggers a trap, thus avoiding error propagation. The cause of the error can be detected and the erroneous module can be selectively deactivated. Functional safety of the systems is thus guaranteed.

This type of memory protection makes it possible to realise the concept of encapsulation: A task and its Context Handlers are regarded as being located within a capsule, being thus separated from the rest of the system, which in itself also consists of capsules. Communication is achieved purely via Message objects and Events.

This leads to the separation of the individual functional units. The capsules can be considered as each running on a processor of its own. Complexity of the system is thus reduced, and the probability of error propagation. Should, nevertheless, an error occur, its effects are restricted to the corresponding capsule. Thanks to these characteristics, test procedures for applications can be modularised.

Tasks in general do not have any permission to access resources; such access has to be granted explicitly in individual cases. The permission concept knows two types of permissions, privileges and access rights.

Privileges are permission levels of the hardware. They can be subdivided into two categories: System privileges allow full access and are only available to the operating system and certain interrupt handlers; user privileges exist in several levels and can be assigned to parts of the application.

The following privilege levels exist:

Access rights are managed by the operating system. The following access rights can be granted:

In cases where a system service is called without having the required access rights, an error code is returned.

The safety characteristics of PXROS-HR include the ability to detect and react to runtime errors, such as memory access violations.

There are, essentially, two kinds of error treatment:

First, errors are detected during the regular control flow, i.e. during system calls PXROS-HR checks, whether a call is valid and returns the corresponding error code. Invalid system calls include calls with faulty parameters, such as invalid object IDs, missing permissions or invalid system function calls within a handler.

Second, exceptional treatment aborts the regular control flow: Invalid memory access operations cause the MPU to trigger a trap. The trap can be processed by an application-specific trap handler routine.