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 API Description
void
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 available task versions
MODE
fts_get_mode(rtems_id id)		 Returns the execution mode the protected task has to execute next.
void
fts_off(rtems_id id)		 Signs off a task from protection.
int
fts_task_status(rtems_id id)		 Gives information about whether the task with the given id is registered for protection.
TECHNIQUE
fts_change_tech(rtems_id id, TECHNIQUE)		 Changes the fault tolerance technique of a specific task to the one specified in the parameter.
Tasklist
fts_tasklist()		 Returns the list of all registered tasks.


Data structures, macros, and detailed description will follow once the basic implementation is finished.

The data structures and low level functions will be implemented separately in score/src. Using the FTS, other fault tolerance techniques could be implemented here too. The fault tolerance techniques I will implement first are from this source by Chen et al., but other techniques can be used as well. The only requirement is that different task versions with different levels of protection are used, and the FTS makes sure that the proper version is scheduled at all times.

Some notes on the protection technique:

The function staticc(rtems_id id, tec) will ensure that Static Reliable Execution (S-RE) is used to protect the control task. It uses the concept of (m,k) robustness requirements. The other techniques will follow later.

We need a data structure for every task, containing:
- m,k
- nr of executions
- nr of detects
- nr of corrects
- replenishment counters

Can possibly be difficult:
How we can detect errors and send a signal to the FTS, which will trigger a response. Create interrupt, trigger protection version ?

A quick look at the file structure:

For classical API header files:
rtems/kernel/rtems/cpukit/rtems/include/rtems/rtems

Classical API:
rtems/kernel/rtems/cpukit/rtems/src

Kernel implementation:
rtems/kernel/rtems/cpukit/score/src

-------

The video of today is about the LISA pathfinder which detects gravitational waves, launched in December 2015:


Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

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

Bild
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
Mehr anzeigen

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

Bild
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, w
Mehr anzeigen