As we outlined in the previous Section, traditionally, SFL has been deployed in a static context where we consider a test suite's execution for an a-posteriori identification of faulty components. Our aim is quite different in that we focus on a live setting where we continuously collect new execution data. Constantly analyzing these data via diagnostic reasoning, we establish a reliability measure for each of a system's actions (they act as our "components"), recognize failed action sequences, and when re-planning (and when deriving future plans) we aim to select the most reliable actions (technically it is their rules) for achieving our goals. That is, those rules (and their sequences) that are least likely to fail.
The three-phase cycle implemented in RBL's run-time engine as discussed in the preliminaries perfectly fits the demands for our control-concept, so that we did not have to implement it ourselves but focused on adapting the engine for our reasoning. Also, other dynamic planning environments feature similar control concepts so that our approach could be easily adopted there needing only some adaptions to accommodate our reasoning. RBL's engine, for instance, used a quite different cost function (a specific weight model) and related plan optimization concept, so that we needed to adapt the planning algorithm to support our own SFL-related reasoning.
But in general, once we translate the static SFL idea to a dynamic context, deploying it does not require massive changes in a corresponding run-time engine like that of RBL. That is, in principle, we need to continuously