Automated application of fault tolerance mechanisms in a component-based system

Abstract

Due to the reduction of structure sizes in modern embedded systems, tolerating soft errors presenting itself as bit flips becomes a mandatory task even for moderate critical applications. Accordingly, software-based fault tolerance mechanisms recently gained in popularity and a multitude of approaches that differ in the number and frequency of tolerated errors as well as their associated overhead have been proposed. As a consequence, an application-and environment-tailored selection of mechanisms is required to balance protection and costs.Accounting the diverse solution space, we propose to make software-based fault tolerance a matter of configuration that should be transparent to the applications. While this would be cumbersome when using an unsafe programming language, we show that in the context of KESO, a JVM for deeply embedded systems, this can be achieved by utilizing the Java type system and static code analysis. As an initial technique we decided to add redundant execution to KESO, which enables us to selectively and transparently replicate an application. This essentially builds a first step to a JVM, which offers reliable execution of components as demanded by the system configuration.

Fault-tolerant fault tolerance for component-based automation systems

“…If one entity fails, its redundant counterpart can take over its tasks. There are many publications and products that apply redundancy to achieve high availability by fault tolerance: triple-triple redundancy in the Boeing 777 [3], triple-modular redundancy (TMR) with voting [4,5], combining distributed voting with design diversity to avoid systematic errors [6], or providing standby redundancy based on master/slave replicas [7]. The TMR pattern, for instance, tolerates a single fault.…”

“…With standby redundancy, we focused on the hot standby variant; with N-modular redundancy, the focus was on triple-modular redundancy (TMR). As we focus on standby redundancy in this article, the TMR redundancy pattern is not further explained, but we refer the interested reader to [4,5]. A simple example for the redundant deployment of an application with hot standby redundancy is shown in Figure 2.…”

A JVM for soft-error-prone embedded systems

“…This has to be accomplished on a higher level by means of e.g. replication as presented in a previous paper [26].…”

“…through replication or control-flow monitoring). Assuming a redundancy and recovery approach as presented in [26], the recovery mechanism is able to restore both application data and respective valid references, as spatial isolation between replicas is maintained.…”

“…However, soft errors can break the soundness of the type system and thus an integral part of software-based replication. For this reason, a memory-protection unit (MPU), for example, is necessary to maintain spatial isolation and to avoid error spreading [19,26]. Hence, such software-based replication techniques usually cannot be applied at all to embedded systems where such an MPU does not exist.…”