IEC-61508 & EN26262 Platform introduction

When selecting a platform for IEC-61508 / EN26262 based development there are many issues to consider. Specially the final certification is a main factor to consider, one does not want to run into unexpected 'surprised' in that expensive phase. The Sciopta platform has been proven to be a very low-risk route to certification, and even unique in offering the internal checking required for SIL-2.
Next to that the Sciopta Message-based architecture is uniquely suited for safety-design.

 
Direct Message-Passing Real-Time Operating Systems
There are two main technologies of real-time operating systems. Shared Memory RTOS where the user is responsible for protecting memory from mutual access by using specific RTOS tools (e.g. semaphores) and Direct-Message Passing RTOS where data is encapsulated in messages used also for inter-process communication and synchronization.

SCIOPTA is a direct message passing real-time kernel. Its processes communicate and cooperate by exchanging messages. Messages can have a content and move data from one process to the other or can be empty and used for coordination. Often, process switches can occur as a result of such message transfer.

Besides data and some control structures messages also contain an identity. This can be used by a process for selecting specific messages to receive at a certain moment. All other messages are kept in the message queue of the receiving process.

Messages are allocated from a message pool. Each message is owned by a process in SCIOPTA. A process can only access a message that it owns. Therefore only one process at a time, the owner, may access a message. The ownership is assigned by SCIOPTA and is transferred from one process to another. This automatically excludes access conflicts by a simple and elegant method.
IEC61508 Safety Standard
IEC61508 is the international standard focusing on safety-related systems that incorporate electrical, electronic and/or programmable electronic (E/E/PE) instruments and devices.

Initially mainly used in the automation and process control industry,
IEC61508 is more and more accepted for applications in other industries including automotive and medical where safety and reliability are paramount.

IEC 61508 is divided into 7 parts:

    * IEC 61508-1, General requirements
    * IEC 61508-2, Requirements for (E/E/PE) safety-related systems
    * IEC 61508-3, Software requirements
    * IEC 61508-4, Definitions and abbreviations
    * IEC 61508-5, Examples of methods for the determination of safety integrity levels
    * IEC 61508-6, Guidelines on the application of IEC 61508-2 and IEC 61508-3
    * IEC 61508-7, Overview of measures and techniques

Certified RTOS in Safety-Related Systems
The major advantage of using a safety certified real-time operating system is the reduction of risk and cost. Time to market will also be reduced considerably. If you use an operating system component that is not certified, there is always a risk that this component cannot be certified without changes that may be outside of your control. It eliminates the cost
and time involved in certifying the real-time scheduling system portion of your design. It also eliminates the cost and time involved in creating additional measures in your application code to avoid potential faults in the not-certified operating system. Additionally, it rules out the need to gather proven-in-use data on the not-certified operating system.

Another advantage of using a certified RTOS is that it will provide a safety manual, which gives guidance on how to safely use the real-time operating system. This will include information about which features and functions can and can’t be used safely as well as any procedures that must be put in place to ensure safety. Also, such an RTOS will provide some of the features that will make it easier to design safety into your application (e.g. memory protection).
IEC61508 Part 3 Certification
IEC61508 safety RTOSes, such as SCIOPTA, are usually certified according to Part 3 (including Part 1 and Part 4) of the standard. Part 2, which covers the hardware requirements, is not covered by such software products. Parts 5, 6 and 7 include supporting information and do not contain direct requirements for compliance.

Therefore, adhering to part 2 is left entirely to the designer of the safety-related application. In a CPU-controlled safety embedded system the main task for covering part 2 will be designing memory check, memory protection, CPU check and other protection systems to get the required SIL for the safety functions.
 
 
Safe Interprocess Communication
In a safe system it is highly recommended to use direct message passing for interprocess communication. Other interprocess communication methods such as shared-memory, critical regions, semaphore or flags are not recommended.

SCIOPTA was developed with safety in mind from the ground up and therefore includes a safe and very sophisticated direct message passing technology.

Contrary to mailbox interprocess communication in traditional real-time operating systems, SCIOPTA is passing messages directly between processes. Only messages owned by the process can be transmitted. A process will become owner if the message is allocated from the message pool or if it was received by the process. When allocating a message by the message allocation system call, the user has to define the message ID and the size. The message allocation or the message return call returns a pointer to the allocated message. The pointer allows the user to access the message data to initialize or modify it.

The sending process transmits the message by calling the message transfer system call. SCIOPTA changes the owner of the message to the receiving process and puts the message in the queue of the receiver process.

If the receiving process is blocked at the message return system call and is waiting on the transmitted message the kernel performs a process swap and activates the receiving process. As owner of the message the receiving process can now get the message data by pointer access. The message return call in SCIOPTA supports selective receiving as every message includes a message ID and sender.

If the received message is not needed any longer or will not be forwarded to another process it can be returned to the system by a system call and the message will be available for reallocation.
 
 
The following rules apply for implementing safe message passing:

    * Use different kind (IDs or classes) of messages for different purposes.
    * Use a dedicated message for each specific situation.
    * Always check what type of message was received by checking the message ID before using the message data.
    * Use a checksum on the contents of SCIOPTA messages.

Do not:

    * Use large messages containing many fields for every purpose. Such multi-purpose messages will not contribute to good design and makes debugging difficult.
    * Use a copy of a pointer to a message.
    * Send pointers in messages. Pointers passing would constitute shared memory inter-process communication which is not recommended.

Memory Protection
Memory protection provides application and operating system data protection against illegal writes. SCIOPTA can isolate the address spaces of different processes. If a hardware MMU is available the RTOS will prevent processes from illegal writing and reading of data belonging to other processes. This is a very important feature to implement applications of different safety integrity levels to run on the same CPU.

SCIOPTA includes certified MMU support and this memory protection has tremendous advantages when going through a certification. It allows identifying non-safety related tasks that do not need to be developed with the same level of rigor in terms of process and on-line diagnostics. This will reduce the effort involved in the certification. In addition, third-party software can be used in the non-safety related part without the need to certify it, as this would create extra challenges to supply life cycle documentation in cooperation with the vendor.

Without MMU supported memory protection, you must either use other measures to assure this separation, or all software must be considered to be safety related and therefore subject to the requirements of the highest safety integrity level of the product.
 
 
Other Measures
Additional measures and techniques might be needed to achieve the planned safety integrity level. This can include CRC checking, duplicated and inverted data storage with comparisons every time it is accessed, message monitoring, logical program flow control, CPU instruction self-tests and safe data types.

The SCIOPTA safety kernels have implemented these features for different CPUs.