Issues with Existing Fault Injection Code

[JoGei]

This issue summarizes the functionality of the existing Fault Injection Code in ETISS and lists existing problems with it:

1.1 Functionality

The core concept is that a VirtualStruct, aka an Injector, checks whether one of its assigned Triggers is satisfied and then applies the corresponding Actions through the static Stressor that manages all Fault s registered through ETISS' configuration.
A Fault has a set of Triggers and a set of Actions.

Existing Trigger types are:

• META_COUNTER: The Trigger has a sub trigger which has to fire a certain number (count) of times until the Trigger fires
• VARIABLEVALUE: The trigger condition is satisfied if the associated variable Field is equal to a constant value
• TIME: The trigger condition is satisfied, if ETISS simulation time has reached the given constant time value of the trigger
• TIMERELATIVE: On the first check of the Triggercondition the given time value is added to the current simulation time to make a TIME type trigger
• NOP: No trigger operation - invalid

Existing Action types are:

• BITFLIP: Flips the target bit of the target Field equal to exclusive or of Field word with newval = newval ^ (1<<bit);
• Command: Calls the Injectors applyCustomAction with the given string as an argument.
• INJECTION: Injects a new Fault into the simulation, e.g., see TIMERELATIVE Trigger
• NOP: No Action operation - invalid

1.2 Existing Problems / Todos

• To allow Action being applied by the Stressor all VirtualStructs, e.g., the CPUCore, have to be mounted to the static VirtualStruct::root(). This is needed to allow the Stressor to resolve all Injectors when a faults schedule, e.g., faults.xml, is configured.
• Field has constant access flags denying fault injection to itself. A Field must be constructed as injectable otherwise it is not.
• NOP type Triggers and Actions lead to simulation errors instead of "don't care"s.
• Stressor::firedTrigger calling Stressor::addFault in INJECTION type Actions result in deadlock because both take same mutex.
• Limited Field fault capability with only supporting BITFLIPS
• No "memory faults"
• No "instruction faults". Requires re-translation of affected translation block if transiently faulted instruction data.
• No "permanent" faults, because once a (non-sub) trigger fires, it is removed from the trigger list of an Injector
• No example/how-to use fault injection
  • general example and how-to
  • example for architectural faults and scheduling
  • example for memory faults (requires etiss processor system)
• better enums to allow nicer string->enum|enum->string conversion for xml

[JoGei]

Open PR: #100 addressing "1.2 Existing Problems / Todos".