RTEMS SOCIS 2017: Fault Tolerance

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

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 AP

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

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 application Not 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 protection By 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