PXROS-HR Architecture

In this chapter the components and mechanisms used for building up a PXROS-HR system are explained.

Overview - Architecture

The architecture of PXROS-HR is object-based, i.e. all the elements of a PXROS-HR system are regarded as objects. Objects can contain other objects or be assigned to other objects (see Object relations).

object relations thin
Fig. 1. Object relations

The architecture design of PXROS-HR allows to define a base system providing the core functionality of an operating system, i.e. resource management and hardware abstraction. In order to extend this system with the actual application-specific functionality, application tasks can be loaded in the initialization phase or later at runtime.

system en
Fig. 2. PXROS-HR System

Functional Units

Functional units are elements of the system that contain executable code and represent each one control flow path. In this context, a differentiation is made between tasks and handlers, as described below.

Tasks

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.

Equal priority tasks do not supplant each other.
Exception: If time slicing is activated, a task can be supplanted by one of equal priority as soon as its time slice has expired.

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

waiting

The task waits for an event to 'wake' it, e.g. the arrival of a message.

ready

The task has been woken up and is now willing to run, but it does not have the highest priority of all ready tasks.

active

When a task is ready and in possession of the highest priority (e.g. because a task of higher priority has changed into the waiting state), it becomes active and is then in possession of the processor.

suspended

A task was suspended by another task, meaning it will not become active, even if it is ready and has the highest priority.

task state en neu
Fig. 3. Task 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).

Under PXROS-HR it is possible to reload tasks into the system during runtime.

Handlers

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.

Fast Handlers

Fast Handlers, work on interrupt level, meaning these are the fastest and have the highest priority within the system. They have to be processed as quickly as possible since otherwise interrupt processing can be delayed. They are prioritized among each other; a Handler of higher priority can interrupt one of lower priority.

Fast Handlers have all-encompassing permissions, since they run in supervisor mode.

To install a Fast Handler, a task has to have the appropriate permission.

Fast Handlers can be used, for instance, to realize equidistant sampling.

Fast Context Handlers

Similar to a Fast Handler, a Fast Context Handler also works on interrupt level and has the same priority range. In contrast to Fast Handlers, however, a Fast Context Handler is assigned to the task it was installed by. Thus, the context has to be switched at Handler entry which adds a certain delay to the actual processing time.

A Fast Context Handler is executed in the context of the creating task and has access to the address space of this task.

To install a Fast Context Handler, a task has to have the appropriate permission. The installed Handler will then have the same address space as the creating task.

Context Handlers

A Context Handler is assigned to the task by which it was installed. Context Handlers have lower priority than Fast (Context) Handlers, and higher priority than tasks.

A Context Handler is executed in the context of the creating task and has access to the address space of this task.

To install a Context Handler, a task has to have the appropriate permission. The installed Handler will not run on interrupt level but on OS level.

priority en
Fig. 4. Distribution of Priorities

Objects

All the elements of PXROS-HR are regarded as objects. There are two basic types of objects: generic objects, which belong to an 'abstract base class' and do not implement any functionality, and specific objects, which are 'derived'.

objects en
Fig. 5. Object hierarchy

Tasks

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).

task components en
Fig. 6. Components of a task object

MemoryClass Object

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

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.

msg access en
Fig. 7. Access to the memory area of a Message

Mailboxes

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.

Mailboxes can contain an arbitrary number of Message objects.

Private Mailboxes

Private mailboxes are a special feature. In general, mailboxes can be made available for any task, yet each task has its own private mailbox, which is unreadable for other tasks. The usual case of inter-task-communication is an exchange of Messages between private mailboxes.

Messagepools

Messagepools are another special feature. They are 'storehouses' for Message objects created beforehand. This means, Messages are created during initialization and stored in a Messagepool. This procedure has several advantages:

  • Creating Messages during runtime can be avoided; the necessary Messages can be extracted from the Messagepool.

  • There is no shortage during runtime, e.g. because at a certain time there are no more objects available.

  • This shows the usefulness of the feature that several tasks can have access to the same mailbox.

Mailboxhandler

Handlers can be defined for mailboxes. If a handler was installed at a mailbox, then this handler is called whenever a Message is sent to this mailbox.

This feature is of particular usefulness if a task wishes to receive Messages from several mailboxes.

Objectpools

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).

Objects that were released after utilization, are returned to the object pool they were taken from.

Interrupt Objects

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

Objects for realising timer functionality

Delay objects

Delay objects are the most common objects for modelling timers: A Delay object makes sure that a handler function is called after a specified period.

Periodic event objects

A periodic event object (Pe) is a specialised version of a Delay object. A task creating a Pe object receives events in regular intervals.

Timeout objects

A timeout object (To) is a specialised version of a Delay object. A task creating a To object receives a single event after a defined period.

Interprocess communication

Interprocess communication, meaning communication among different tasks, is achieved by two different mechanisms: Messages and Events.

The two types of communication are different in that Messages can contain data, which can be processed by the recipient, whereas Events can only signal that an event has occurred.

Messages

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.

msgsend en
Fig. 8. Sending a Message

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.

msgreceive en neu
Fig. 9. Receiving a Message

Events

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.

Safety characteristics

The safety characteristics of PXROS-HR have the purpose of minimising the effects of runtime errors. Runtime errors should be detected so that, firstly, they can be reacted to properly via exception handling, and secondly, so that error propagation throughout the system is avoided.

Hardware memory protection

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.

protection register en neu
Fig. 10. Memory protection register

Memory protection and encapsulation

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.

The MPU can even detect stack overflow if the memory is appropriately apportioned, i.e. if the stack is located at the end of the individual memory.

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

memory en neu
Fig. 11. Memory areas of a task

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.

Permissions

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:

Usermode0

allows access to the internal memory area exclusively

Usermode1

allows access to the internal memory area and to the periphery

Systemmode

allows full access (only available to the operating system and certain interrupt handlers)

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

PXACCESS_HANDLERS

for installing handlers that own system rights

PXACCESS_INSTALL_HANDLERS

for installing handlers that own the rights of the task

PXACCESS_INSTALL_SERVICES

for installing certain PXROS-HR services as handlers

PXACCESS_REGISTER

for executing system functions that have access to special registers of the processor

PXACCESS_SYSTEMDEFAULT

give access to the system memory class and system object pool

PXACCESS_RESOURCES

allows a task to access, in addition to its own resources (those that were assigned to it during creation or that it created itself), but also to resources that it does not own

PXACCESS_NEW_RESOURCES

allows a task to create object pools or memory classes

PXACCESS_SYSTEM_CONTROL

allows a task to suspend or continue other tasks

PXACCESS_MODEBITS

allows a task to set its modebits

PXACCESS_OVERRIDE_ABORT_EVENTS

allows a task to override its aborting events

PXACCESS_TASK_CREATE

allows a task to create another task

PXACCESS_TASK_CREATE_HIGHER_PRIO

allows a task to create another task with a higher priority than its own priority

PXACCESS_TASK_SET_HIGHER_PRIO

allows a task to increase its priority

PXACCESS_CHANGE_PRIO

allows a task to lower its priority

PXACCESS_TASK_RESTORE_ACCESS_RIGHTS

allows a task to restore its access rights to the initial value

PXACCESS_TASK_CREATE_HIGHER_ACCESS

allows a task to create an other task without respecting the memory inheritance rule

PXACCESS_TRACECTRL

allows a task to setup the trace mechanism by PxTraceCtrl

PXACCESS_GLOBAL_OBJECTS

allows a task to allocate objects from the PXOpoolGlobalSystemdefault for the communication between tasks on different cores

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

Error handling

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.