2
G. Fey and R. Drechsler
Also designers of digital systems can benefit from explanations. A typical design
task is debugging where a designer has to find the reason for certain actions executed
by a digital system. Depending on the current design task a designer may use the
same explanations that help users. Additionally, more detailed explanations, e.g.,
justifying data exchange between functional units may be useful. Thus, debugging
and development are supported by explanations giving simple access points for
a designer justifying the system’s execution paths. At design time a designer
can use explanations to understand the relation between the specification and the
implementation.
Correctness of the system is validated through explanations if these explanations
provide an alternative view that justifies the actual output. For in-field operation
explanations may even be exploited for monitoring as a side-check that validates the
actual execution of the system to detect failures and unexpected usage. In particular,
problems are detected earlier when explanations cannot be generated, are not wellformed, or are not consistent with respect to the actual behavior.
The notion of explanation used here are cause–effect chains as often used in the
philosophical domain. Moreover, granularity, addressee, and purpose are defined at
design time of a system that then explains all its observable actions at run time. We
consider such as system to be self-explaining.
Given a digital system the question is how to provide an explanation for
observable actions online. While on first sight this mainly concerns functional
aspects also non-functional aspects like actual power consumption or response time
of the system deserve explanations.
During online operation either the system itself or some dedicated additional
entity must provide the explanations. This incurs a cost, e.g., for storing historical
data that explains and, by this, also justifies current and future actions. This overhead
must be kept as low as possible.
A non-trivial challenge is to provide concise explanations in a cost-efficient way.
While some actions of a system may have very simple explanations, e.g., “the
power-on button has been pressed,” other actions may require a deep understanding
of the system, e.g., “when the distance to an energy source is large and the battery
level is low, we save energy by reducing speed as well as light and move towards
the energy source.” Such an explanation may in turn require knowledge about what
an energy source is, what thresholds are used, and how the system detects where the
next energy source may be found.
Our contributions are the following:
– We formalize explanations and define what a self-explaining system is. We
explain how to verify whether a system is self-explaining.
– We propose a conceptual framework that yields layered explanations providing
details where necessary, but keeping explanations understandable at the same
time.
– We provide a technical solution for explanations on the functional level and
discuss how to automatically infer them.
G. Fey and R. Drechsler
Also designers of digital systems can benefit from explanations. A typical design
task is debugging where a designer has to find the reason for certain actions executed
by a digital system. Depending on the current design task a designer may use the
same explanations that help users. Additionally, more detailed explanations, e.g.,
justifying data exchange between functional units may be useful. Thus, debugging
and development are supported by explanations giving simple access points for
a designer justifying the system’s execution paths. At design time a designer
can use explanations to understand the relation between the specification and the
implementation.
Correctness of the system is validated through explanations if these explanations
provide an alternative view that justifies the actual output. For in-field operation
explanations may even be exploited for monitoring as a side-check that validates the
actual execution of the system to detect failures and unexpected usage. In particular,
problems are detected earlier when explanations cannot be generated, are not wellformed, or are not consistent with respect to the actual behavior.
The notion of explanation used here are cause–effect chains as often used in the
philosophical domain. Moreover, granularity, addressee, and purpose are defined at
design time of a system that then explains all its observable actions at run time. We
consider such as system to be self-explaining.
Given a digital system the question is how to provide an explanation for
observable actions online. While on first sight this mainly concerns functional
aspects also non-functional aspects like actual power consumption or response time
of the system deserve explanations.
During online operation either the system itself or some dedicated additional
entity must provide the explanations. This incurs a cost, e.g., for storing historical
data that explains and, by this, also justifies current and future actions. This overhead
must be kept as low as possible.
A non-trivial challenge is to provide concise explanations in a cost-efficient way.
While some actions of a system may have very simple explanations, e.g., “the
power-on button has been pressed,” other actions may require a deep understanding
of the system, e.g., “when the distance to an energy source is large and the battery
level is low, we save energy by reducing speed as well as light and move towards
the energy source.” Such an explanation may in turn require knowledge about what
an energy source is, what thresholds are used, and how the system detects where the
next energy source may be found.
Our contributions are the following:
– We formalize explanations and define what a self-explaining system is. We
explain how to verify whether a system is self-explaining.
– We propose a conceptual framework that yields layered explanations providing
details where necessary, but keeping explanations understandable at the same
time.
– We provide a technical solution for explanations on the functional level and
discuss how to automatically infer them.