8
G. Fey and R. Drechsler
however, that in our case the execution of the system perfectly describes the order of
events. An explanation then captures this order without additional mechanisms for
synchronization. The only requirement is the association of an action with a unique
tag to form an event, i.e., any action occurs at most once with a particular tag.
Our formalism provides the basis for extending an actual digital system to
provide explanations for each observable action. The sets of variables, actions,
requirements, and explanations are freely defined. This leaves freedom to decide
on the granularity of explanations available during run time, e.g., whether an action
only captures the driving direction of a robot or the precise values of motor control
signals.
The set of observable actions must be derived at first. The methodology must
ensure that for each possible system output there is a related action. This is possible,
e.g., by mapping the variables and their assignments from the system model to
implementation level variables and their assignments. This mapping then produces
a mapping of actions onto system variables. A more precise definition depends on
the actual system under consideration. While in some system an action may only
occur when the output changes, in other systems a certain control signal may start a
new action in each time step where this signal is active. We delegate this refinement
for defining actions to the actual implementation.
Definition 1.4 A set of observable actions is complete with respect to a given
system iff for any observable output of the system there exists a related observable
action.
Definition 1.5 A set of explanations is complete iff it is well-formed and explains
all observable actions.
Definition 1.6 A digital system is self-explaining iff it has a complete set of
observable actions and creates a complete set of explanations.
1.3.2 Implementation
Practically, explanations are produced by adding appropriate statements to the
design description. To create the cause–effect chain, we think of functional units
that are connected to each other. A functional unit may be a hardware module or
a software function. To produce explanations for the actions, each unit records the
actions and their explanations from preceding units together with the input. By this,
data being processed can always be related to its causes, likewise actions triggered
by that data can be associated to their causes.
In the following we describe a concrete approach to implement a self-explaining
digital system. While the approach explained here is mainly manual, we discuss
how this can be automated in Sect. 1.5.2.
Functional units derive causes for their actions. We associate an explanation unit
for storage, reference, and usage of explanations to each functional unit. Whenever
a functional unit executes an action, the cause for that action is forwarded to the
G. Fey and R. Drechsler
however, that in our case the execution of the system perfectly describes the order of
events. An explanation then captures this order without additional mechanisms for
synchronization. The only requirement is the association of an action with a unique
tag to form an event, i.e., any action occurs at most once with a particular tag.
Our formalism provides the basis for extending an actual digital system to
provide explanations for each observable action. The sets of variables, actions,
requirements, and explanations are freely defined. This leaves freedom to decide
on the granularity of explanations available during run time, e.g., whether an action
only captures the driving direction of a robot or the precise values of motor control
signals.
The set of observable actions must be derived at first. The methodology must
ensure that for each possible system output there is a related action. This is possible,
e.g., by mapping the variables and their assignments from the system model to
implementation level variables and their assignments. This mapping then produces
a mapping of actions onto system variables. A more precise definition depends on
the actual system under consideration. While in some system an action may only
occur when the output changes, in other systems a certain control signal may start a
new action in each time step where this signal is active. We delegate this refinement
for defining actions to the actual implementation.
Definition 1.4 A set of observable actions is complete with respect to a given
system iff for any observable output of the system there exists a related observable
action.
Definition 1.5 A set of explanations is complete iff it is well-formed and explains
all observable actions.
Definition 1.6 A digital system is self-explaining iff it has a complete set of
observable actions and creates a complete set of explanations.
1.3.2 Implementation
Practically, explanations are produced by adding appropriate statements to the
design description. To create the cause–effect chain, we think of functional units
that are connected to each other. A functional unit may be a hardware module or
a software function. To produce explanations for the actions, each unit records the
actions and their explanations from preceding units together with the input. By this,
data being processed can always be related to its causes, likewise actions triggered
by that data can be associated to their causes.
In the following we describe a concrete approach to implement a self-explaining
digital system. While the approach explained here is mainly manual, we discuss
how this can be automated in Sect. 1.5.2.
Functional units derive causes for their actions. We associate an explanation unit
for storage, reference, and usage of explanations to each functional unit. Whenever
a functional unit executes an action, the cause for that action is forwarded to the