Fault Injection and Detection in Static Pattern-based Execution (SDR)

What is Static Detection and Recovery (SDR) ?

In an earlier blog post I explained how Static Reliable Execution (SRE) uses a pattern (predefined sequence of bits) to decide which version of the task to execute. To comply to an (m,k) requirement (m out of k tasks have to be correct to prevent mission failure) SRE executes an error-correction version if there is a "1" at the current bit position, and a basic version if there is a "0".

The problem with the SRE approach is that an error-correction version is executed m times to comply to (m,k). In general, error-correction consumes a lot of resources, more than for error detection. One way to correct errors in a calculation is to run the calculation three (or more) times, and then compare the result to use majority voting. This is the reason why we want to execute as less error-correction versions as possible.

Instead of executing an error-correction version every time there is a "1" in the pattern, we can fo…

Static Pattern-based Execution (SRE) in the Fault Tolerant Scheduler

In the FTS, using static patterns is a simple technique, which uses the concept of (m,k) requirements. We execute a pattern such as {1,1,0,1}. When there is a "1" in the pattern, the reliable version is executed, and when there is "0", the unreliable version is executed. In this pattern, three out of four correct instances are executed, which complies to the (m,k)-requirement (3,4). This means that there will always be three correct executions in every four instances.

There are two types of patterns available for the user, i.e. R-patterns and E-patterns [1]. An R-pattern contains all "0"s at the beginning and all "1"s at the end, such as in {0,0,0,1,1,1,1}. In E-patterns, the "1"s and "0"s are distributed evenly. The pattern's sufficient correctness proofs of complying to an (m,k) requirement can be read in [2] and [3]. The FTS executes this predefined pattern. The pattern is read by the FTS from left to right and top to …

Compile and test your modified RTEMS system

This blog post is about how to add code to the classical RTEMS API and compile the whole system, e.g. to test the newly implemented code in a test application. The requirement for this approach to work is that you already built the RTEMS tools and kernel, for example by following the Quick Start guide in the RTEMS user manual. I am using the erc32 board support package.

First we need to identify the RTEMS classical API's source code location. The folder location may differ depending on the configuration of the setup. Generally, the classical API implementation is located in the kernel folder, in  /rtems/cpukit/rtems/src. There, we find the implementation of several operating system services, e.g. for creating a new task in an RTEMS application, the function rtems_task_create(..) located in taskcreate.c needs to be called. In a similar way, semcreate.c allows the application developer to create and use semaphores for their resources.  

If you want to extend the classical API with …

Fault Tolerant Scheduler preliminary API

In this post I want to explain the Fault Tolerant Scheduler API and its implementation structure.

In RTEMS, the classical API implementation is located in /rtems/kernel/rtems/cpukit/rtems/src. For example, semrelease.c allows the user to release a semaphore by accessing the function rtems_semaphore_release( rtems_id id ). The header file semimpl.h and sem.h provide  the directives; they are located in /rtems/kernel/rtems/cpukit/rtems/include/rtems/rtems. In sem.h the definition rtems_status_code rtems_semaphore_release( rtems_id   id ) can be found, and it is implemented in semrelease.c. The low level directives used in semrelease.c are located in rtems/kernel/rtems/cpukit/score/src/.
The FTS API will be implemented following the same way as existing functions in the classical API.

FTS APIDescriptionvoid
fts_rtems_task_register(rtems_id id, TECHNIQUE)From the next activation on, the task with the given id will be protected.void
fts_init_versions(taskversions)Informs the fts about the …

Fault Tolerant Scheduler: Preparing to start SoC

Before the official start

 General notes:
 I will be working on an extension to the scheduler in the supercore, which has a readable interface for the user The fault tolerant scheduler will be embedded into the scheduling policy We assume that multiple execution versions of a control task are available, all with different levels of protection (three for now: error correcting version, error detecting version, basic version); the fault tolerant scheduler receives these execution versions from the rtems user applicationNot the whole task needs to be protected, the user can also choose to only protect a certain block of a task, this way some part of the code can be run without protectionBy giving the users the freedom to implement execution versions, they can decide about the level of protection themselves RTEMS fault tolerant scheduler provides tools to implement techniques which decide when to execute which version, since the versions with high level of protection use lots of system res…