Collection: SafeNet Operating System

Introduction

This document deals with the SafeNet Micro-Kernel Operating System (O/S) functions. The OS handles all tasks in a single-threaded interrupt-driven fixed timeslot architecture that handles all I/O Operations. The O/S and runs the application programs (Blockware) and conducts vital self-testing and program safety assurance logic.

Characteristics of Classic Interrupt-Driven Real-Time Systems

Some commercial real time operating systems (Like Windows) are totally interrupt driven. This means that every data transfer from the serial ports or displays or keyboard entry generates an interrupt which is executed immediately if it is a top priority interrupt, or is deferred until its priority comes due. Any task can be interrupted by a higher priority interrupt, which then can be interrupted by yet another higher priority interrupt.

The characteristics of this type of real-time system (RTOS) is outlined below:

• I/O handlers can achieve fast response if operating at high priority levels.
• Background tasks at low priority levels operate with whatever throughput is leftover, so the response time varies dependent upon how much CPU is available.
• The execution time of any task except the highest priority task is uncertain.
• This method is very stack intensive, requiring up to 10k RAM for stack operations.
• A complete set of stack addressing instructions are needed.
• The interrupt handler prioritization requires dedicated interrupt control devices to manage interrupts. UP to 32 prioritized hardware interrupts are supported per device.
• Debugging real-world glitches is very difficult, due to the varied nature of the interrupt sequences.
• System crashes are frequent or loss of data results if several interrupts at same time and not enough CPU resources.
• The operating systems typically require over 1 Mbyte of RAM.
• Adding new devices changes the interrupt landscape which adds new complexities to the system.
• If two tasks use the same memory, then memory access control functions such as locks and semaphores are needed to control the memory. This can occur when a program is reading a buffer when another interrupt occurs, which then uses the same memory and may alter it. On return from interrupt, the original program has modified data.
• Memory is constantly being allocated and freed up by the O/S.
• The O/S makes extensive use of pointers and other techniques not vital-friendly.
• Most third party Operating Systems have no vital hazard analysis has been done and are not written to follow to safety standards. The source code is generally not available so a detailed analysis is not possible.
• Possibility of unknown bugs is high.
• Most O/S require a significant amount of CPU resources typically not found in embedded systems.

The disadvantages of this type of RTOS for safety critical applications is:

• The RTOS if included in a SIL4 design would also have to be certified as SIL4 compliant.
• The RTOS is a third party product not written to CENELEC safety requirements.
• Task execution time is variable so throughput changes (as higher priority tasks consume more CPU cycles)
• Debugging in real-time is difficult.
• Testing for all possible interrupt sequences is very difficult and tracing program flow through interrupts is virtually impossible
• As a debug technique Single stepping through multiple interrupts in real-time is impossible. Tracing memory in real-time collects megabytes of data every few seconds which is difficult to analyze for safety.
• The RTOS is designed to maximize throughput, not to maximize safety
• It is difficult to make predictable time studies on segments of code if they can be interrupted.
• Such a multiple interrupt environment is prone to errors and difficult to simulate and test all possible combinations of interrupts.
• After a system malfunction, it is not possible to determine the exact interrupts in play at the moment of the crash. Finding these types of malfunctions is very difficult.

The SafeNet Fixed Time-Slice Message Passing Networked O/S

It is clear that we do not wish to use an interrupt driven scheme as described above. However, there is another approach that is more suitable for the micro-controller in vital applications. This is the technique of a time-slice multi-programming O/S. In this scheme, a high-speed periodic interrupt (of say 10 micro=sec) is used to generate the single interrupt that is used to operate a state-machine based operating system. This creates a time slot which is of known fixed duration. The interrupt rate is faster than that required for the fastest I/O operation so that simple polling of all devices can determine quickly who needs servicing. The polling is done in the desired order as per fixed priority.

This fixed time slice O/S has the following advantages:

• The resultant O/S is simple to write, debug and test.
• A complex interrupt scheme is avoided.
• No stack is used.
• Memory semaphores and flags are avoided. A program segment operating in a given time slot can read/write memory as one atomic operation and need not fear that an interrupt will occur.
• Code does not have to be re-entrant since it is never interrupted. To do this, code would have to use stack resident variables (ie: local variables on the stack)
• More time slices can be given to foreground processes and fewer to background processes. This forms an elementary prioritization system. The exact frequency of service and the exact percentage of CPU time is always known and controlled. In this application, deterministic performance is desired.
• We are concerned with a predictable operation and not in maximizing throughput. Once the target throughput is achieved, nothing is gained by going faster.
• The order of execution of program segments never changes and the time required to do a program loop is always constant. This allows use to use special techniques to continually measure program control flow and continually measure execution time to a high enough precision to catch timing deviations as small as a few machine cycles. This forms the basis of many of the Defensive Programming techniques discussed in the Software Safety Concepts document.
• Program throughput remains constant in spite of instantaneous I/O loading. This allows applications programs to have a consistent scan cycle regardless of other system I/O operations.
• The application code must complete within its time slice, so careful attention is paid to the duration of each threaded segment.

 The SafeNet O/S is used in all Argenia Controller and monitoring Products. It has been in use for over 10 years and has millions of device hours in the filed.

The SafeNet O/S is designed for implementing Vital Applications in a micro-controller device.  Since we wrote this, we know every line of code and all the reasons for the decisions made along the development path.

The SafeNet O/S features an integrated Function Block Interpreter, which executes downloaded FB programs. The O/S has a library of pre-approved functions which the user references in a graphical flow diagram. The FB programs are executed in a safe, controlled and planned method where the user must obey the rules needed for safe program execution. Please read the Function Block paper on the Argenia Website. for more information.