10
G. Fey and R. Drechsler
Of course, a designer may choose to implement a system that is not fully selfexplaining, but only partially, e.g., by only providing explanations for the most
important output variables instead of all. In practice this can be used to reduce the
cost incurred by adding explanations to the system, but to still self-explain, e.g.,
control decisions or safety aspects.
1.3.4 Explanations of Different Granularity
Depending on the usage of explanations and the perspective on the system,
explanations may be used to answer different questions. We suggest several types
of explanations supporting users and designers in different ways and with different
levels of detail.
Consider the following conceptual framework for different types of explanations
together with the questions addressed:
– User-understandable explanation—which part of the input data and user-visible
conceptual state triggers the action?
– Environment-defined explanation—which part of the input triggers the action?
– Specification-defined explanation—which part of the specification requires a
certain action?
– Transaction-level explanation—which series of transactions initiated and then
implied the action?
– Architectural explanation—which functional units contribute to triggering the
action, which part of the internal state triggers the action?
– Unit-level explanation—which are the conceptual states and input events triggering an action in each functional unit?
– Program-level explanation—which statements trigger actions?
The implementation proposed in Sect. 1.3.2 yields program-level explanations.
We consider these as the most detailed level of explanations. Explanations on the
other levels are derived from these program-level explanations by removing details
and joining cause–effect chains.
1.4 Case Study
We apply our approach to a small robot controller that explains actions executed
with the controlled robot. Figure 1.3 shows an abstract view of the actual robot. The
robot has wheels on the left and on the right side, each equipped with a motor that
is commanded by the robot controller. The passive wheel on the back turns freely
such that by commanding the two motors the robot controller can steer and move
the robot. The main sensors of the robot are light sensors and microphones on the
four sides as well as eight push-buttons at its corners to detect collisions.
G. Fey and R. Drechsler
Of course, a designer may choose to implement a system that is not fully selfexplaining, but only partially, e.g., by only providing explanations for the most
important output variables instead of all. In practice this can be used to reduce the
cost incurred by adding explanations to the system, but to still self-explain, e.g.,
control decisions or safety aspects.
1.3.4 Explanations of Different Granularity
Depending on the usage of explanations and the perspective on the system,
explanations may be used to answer different questions. We suggest several types
of explanations supporting users and designers in different ways and with different
levels of detail.
Consider the following conceptual framework for different types of explanations
together with the questions addressed:
– User-understandable explanation—which part of the input data and user-visible
conceptual state triggers the action?
– Environment-defined explanation—which part of the input triggers the action?
– Specification-defined explanation—which part of the specification requires a
certain action?
– Transaction-level explanation—which series of transactions initiated and then
implied the action?
– Architectural explanation—which functional units contribute to triggering the
action, which part of the internal state triggers the action?
– Unit-level explanation—which are the conceptual states and input events triggering an action in each functional unit?
– Program-level explanation—which statements trigger actions?
The implementation proposed in Sect. 1.3.2 yields program-level explanations.
We consider these as the most detailed level of explanations. Explanations on the
other levels are derived from these program-level explanations by removing details
and joining cause–effect chains.
1.4 Case Study
We apply our approach to a small robot controller that explains actions executed
with the controlled robot. Figure 1.3 shows an abstract view of the actual robot. The
robot has wheels on the left and on the right side, each equipped with a motor that
is commanded by the robot controller. The passive wheel on the back turns freely
such that by commanding the two motors the robot controller can steer and move
the robot. The main sensors of the robot are light sensors and microphones on the
four sides as well as eight push-buttons at its corners to detect collisions.