OCEOS/oceos introduction

Introduction

OCEOS is a pre-emptive real time operating system (RTOS) with a small memory footprint intended for hard real time systems that use the GR716 micro-controller, SPARC LEON2/3/4 processors and ARM Cortex-M micro-processors.

It was developed by O.C.E. Technology with support from the European Space Agency (ESA) under project 4000127901/19/NL/AS and 4000135473/21/NL/GLC/js.

This document describes the features and use of OCEOS, and details its behavior and system calls.

• Real time software is often written as a set of trap/interrupt handlers and tasks managed by a RTOS.
• The trap/interrupt handlers start due to anomalous conditions or external happenings. They carry out the immediately necessary processing, and may ask the RTOS start a task to complete the processing.
• The RTOS starts tasks and schedules them for execution based on priority. In hard real time systems scheduling must ensure that each task completes no later than its deadline. Being early can also be a problem.
• OCEOS provides a timed output service (software timers) that allows an output be set for a precise system time independently of scheduling.
• OCEOS supports up to 255 tasks, and up to 15 current start requests for each task.
  • Each task has a fixed priority.
  • There are 254 task priorities, 1 (highest task priority) to 254 (lowest task priority).
  • More than one task may have the same priority.
  • Tasks of the same priority are FIFO scheduled.
  • Time slicing between tasks does not occur in OCEOS.
• In OCEOS each task has a pre-emption threshold. A task can only be pre-empted by a task with a higher priority than this threshold. Pre-emptions and any traps/interrupts that occur will delay a task’s completion and potentially cause it to miss its deadline. Careful analysis is needed to ensure that task deadlines are always met.
• OCEOS supports this analysis and allows relatively simple determination of worst case behaviour.
• Problems such as unbounded priority inversion, chained blocking, and deadlocks cannot occur in OCEOS.
• OCEOS provides mutual exclusion semaphores (mutexes) to protect critical shared code or data, and inter-task communication using counting semaphores and data queues.
• A system state variable provides a summary of the current state of the system.
• Error conditions such as missed deadlines are logged and the system state variable updated. If the system state is not normal a user defined error handling function may be called and actions taken such as disabling a task or resetting the system.
• OCEOS does not allow dynamic creation of tasks at run time.
• Virtual memory is not supported.
• OCEOS is based on the Stack Resource Policy extension of the Priority Ceiling Protocol Baker 1991.
• OCEOS is provided as a library and is statically linked with an application.
• Services not needed by an application are omitted by the linker.

Purpose of the Software

OCEOS is an object library for target architecture which provides directives to schedule fixed priority tasks, and supporting mutexes, semaphores, data queues, timed outputs, and interrupt handling.

There are also directives for logging, error handling, GR716 memory protection and GR716 watchdog control.

OCEOS Main Features

• Fixed priority preemptive scheduling
• Based on Stack Resource Policy – unbounded priority inversion, chained blocking, and deadlocks cannot occur
• Deterministic processing
• Fast real-time performance
• Single stack rather than separate stack for each task
• Small code footprint ( <10 kBytes for scheduling and mutex)
• Inter-task communication (Counting Semaphores and Data Queues)
• Synchronisation (Mutexes)
• Task preemption level
• Interrupt support (most of the directives can be called from IRQ handlers)
• Very short time for disabling interrupts
• Very low interrupt latency
• Nested interrupts support
• High precision timed actions (Software Timers) for data output and task start at pricise time
• Supports SPARC V8 LEON2/3/4 and ARM Cortex-M single core targets
• Fault Detection, Isolation and Recovety
• GR716 Memory protection functionality
• Enhancements for Cobham-Gaisler GR716 applications
• Sample Applications for Quick start
• Online Documentation
• Tutorial applications to demonstrate main features of OCEOS
• DMON debug tool support (execution timeline, CPU usage and profiling, commands to display information for OCEOS modules)
• Support & ISVV services available from OCE Technology Ltd.
• MISRA C Compliant
• Developed to ECSS Category B and ISO 26262 standards
• Developed in cooperation with European Space Agency (ESA)

OCEOS Main Concepts

An application that uses OCEOS typically starts at main(), performs device initialization and other activities including setting up interrupt handlers,
then starts OCEOS in two phases, an initialization phase and a scheduling phase. Tasks, mutexes etc. are only created in the initialization phase,
resulting in a fixed data structure that is passed to the scheduling phase. OCEOS normally does not return to the application but will do so if it detects a fatal error.

The specific application determines the tasks, mutexes and other OCEOS components used.

The interrupt/trap handlers respond to events, do the immediately necessary processing, and typically ask OCEOS to start a task to complete the processing.

OCEOS then creates an execution instance of the task, a ‘job’, and either puts it into immediate execution or on the ready queue or
the timed jobs queue waiting to be scheduled for execution.

OCEOS schedules jobs based on their priority and may pre-empt the processor from a job with a lower pre-emption threshold before that job
completes in order to start a higher priority job.

OCEOS maintains a system priority ceiling based on currently locked resources and the pre-emption threshold of the currently executing job.
Only jobs with higher priority than this ceiling can pre-empt.

Jobs with the same priority are scheduled according to time of arrival on the ready queue. Time slicing or pre-emption between jobs of the same priority does not take place.

A job may have a deadline by which it must complete. It is the responsibility of the software developer to assign task priorities so that all jobs are guaranteed to meet their deadlines.

In OCEOS mutual exclusion of tasks is supported by mutexes. Counting semaphores and data queues support task synchronization and the exchange of data between jobs.

Task start requests and data outputs (software timers) can be set to occur independently of scheduling at a given system time in microseconds.

OCEOS maintains a system state variable and system log. If the state variable is not normal OCEOS may call a user defined function to deal with
whatever condition has occurred.

Tasks

In OCEOS all tasks are defined before scheduling begins and each task assigned a fixed priority, a pre-emption threshold, a current jobs limit,
a maximum start to completion time, and an expected minimum inter start request time.

A task’s pre-emption threshold limits the tasks that can pre-empt it to those with higher priority than this threshold. Tasks with short run times
can use this to avoid context switch overheads.

Each task has two main states, enabled or disabled. OCEOS provides system calls to change task state. The state is usually enabled when the task is
created, but can be initially disabled.

A disabled task will not be executed, and any attempt to start it will be logged and the system state variable updated.

A request to start an enabled task creates an execution instance of the task, a ‘job’. A count is kept for each task of the number of times it has been started,
i.e. total number of jobs created.

Multiple jobs of the same task can be in existence simultaneously. A limit for the maximum number of these current jobs is set when a task is created, the ‘current jobs limit’.

Each task has a current jobs count. This increments each time a task is started and decrements on job completion unless completion creates a further job from this task.

A further execution instance of a task is not created if the current jobs count has reached the current jobs limit. Such job creation failures are logged and the system state updated.

For each task a record is kept of the shortest time between attempts to create a new job, and a record of the maximum time between these attempts.

For each task a record is kept also of the maximum time a job was waiting before starting, the minimum execution time, the maximum execution time,
the maximum time from job creation to completion, and the maximum number of job pre-emptions. The system state variable is updated if necessary.

Task chaining is supported. A job can create a new job and pass this to the scheduler or place it on the timed actions queue.

Tasks provide a start address for a termination routine for use if task execution must be abandoned.