Towards Self-Explainable Cyber-Physical Systems

Andreas Vogelsang; Andreas Wortmann; Christoph Sommer; Francisco Javier Chiyah Garcia; Joel Greenyer; Maike Schwammberger; Mathias Blumreiter; Verena Kl\"os

REVIEW 3 major objections 4 minor 18 references

Towards Self-Explainable Cyber-Physical Systems

T0 review · 3 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Cyber-physical systems can be made to explain their own behavior at run-time by wrapping them in a Monitor-Analyze-Build-Explain loop that reuses requirements and behavior models as the source of explanations.

desk verdict A clearly-written vision paper proposing MAB-EX, a MAPE-inspired loop for self-explaining CPS; the architecture is sensible and the V2X example helps, but it is a design sketch with no implementation, and the explanation-fidelity assumption is real. read the letter →

arxiv 1908.04698 v1 pith:ROF7UT5H submitted 2019-08-13 cs.AI

Mathias Blumreiter , Joel Greenyer , Francisco Javier Chiyah Garcia , Verena Klös , Maike Schwammberger , Christoph Sommer , Andreas Vogelsang , Andreas Wortmann This is my paper · ORCID

classification cs.AI

keywords self-explainablesystemscyber-physicalexplainabilityrequirementsmodelsatruntimeMAB-EXMAPEloopscenario-basedmodeling

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper tries to establish a workable reference architecture for self-explainable cyber-physical systems: systems that can, while running, answer questions about their past, current, and future behavior. It proposes the Monitor, Analyze, Build, Explain (MAB-EX) framework, in which a system monitors its own data, detects or receives a request for explanation, builds the explanation from an explicit explanation model, and delivers it in a form suited to the recipient. The motivation is that as vehicles, factories, and infrastructure make consequential decisions, users, engineers, and auditors need truthful accounts of those decisions, and no such design methodology currently exists. The paper claims the framework is general: it can be layered on any computing system, it can reuse requirements and behavior models as explanation sources, and Model Learning lets it cover new behavior after the fact.

What carries the argument

The load-bearing concept is the explanation model: a behavioral model that captures causal relationships between events and system reactions, from which the Build phase extracts possible causes or runs look-ahead simulations. The paper gives it two concrete forms. The first is a model of causality, typically a tree whose nodes carry natural-language explanations plus conditions over system variables that can be checked to see whether a branch is plausible. The second is an executable scenario-based model written in the Scenario Modeling Language (SML), a textual version of Live Sequence Charts—executable message-sequence charts that say which events may, must, or must not happen—in which requested, alternative, or committed events carry @EX annotations providing explanation text. That second form can serve both as the system's implementation and as its explanation source, so the artifact answering 'why' is the same artifact that decides. Around these models, the MAB-EX loop itself (Monitor, Analyze, Build, Explain, plus Model Learning) is the organizing machinery, and the recipient model decides how the explanation is rendered.

What would settle it

Build a MAB-EX-style V2X system, then deliberately change the controller to deny entry for a reason not present in the explanation model (for instance, a time-of-day rule). Ask the system 'Why am I being told to stop?' If the answer cites the old priority-vehicle scenario, or no answer is produced, the claim that the framework yields truthful run-time explanations fails in that case.

Watch

Extended reading notes

Core claim

The central claim is that self-explainability can be engineered as a run-time feedback loop rather than designed in as a list of canned messages. The MAB-EX loop has four phases: Monitor captures sensor data, the history of controller commands, and user interactions; Analyze detects the need for an explanation, either because a recipient asks or because monitored behavior deviates from what is expected; Build evaluates an explanation model to identify possible causes of the behavior or to simulate future behavior; and Explain renders the result in a recipient-appropriate form using a recipient model. A Model Learning component updates the explanation and recipient models when the system encounters behavior it cannot yet explain, so explanations can be given later or on recurrence. The paper demonstrates the architecture on a Vehicle-to-X (V2X) obstacle-passing assistant, generating the answer to 'Why do I have to stop?' from a causality tree or from SML scenarios annotated with @EX text, and shows that follow-up questions such as 'Why is a priority vehicle registered?' can be answered by traversing past scenario states.

Load-bearing premise

The framework works only if the explanation model faithfully captures the causal relationships that actually drive the system's behavior; if that model is missing, outdated, or different from the real decision logic, the delivered explanation is a plausible story rather than the truth about why the system acted.

Editorial extensions

If this is right

Systems following MAB-EX can answer future-oriented questions ('What happens if...?', 'When will I be allowed to pass?') because the explanation model can be executed for look-ahead simulation, not just retrospection.
Explanations are not limited to pre-scripted situations: Model Learning detects behavior absent from the explanation model and updates the model so the system can explain that behavior later or if it recurs.
The same annotation that explains an event can be part of the implementation itself (as in the SML variant), preventing the explanation source from drifting from the behavior source.
Explanations can be personalized: reciprocal models range from coarse group profiles (engineer versus end-user) to individual preferences, so the same fact is presented at different abstraction levels.
MAB-EX can be added to systems that are not self-adaptive, and on self-adaptive systems it can be merged into the existing MAPE control loop, meaning it does not require a particular control architecture.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

If MAB-EX is taken seriously, explanation models become audit artifacts: a regulator asking 'why did this car stop?' can follow the same monitored trace and model traversal the system used, which makes explainability and accountability the same mechanism. The paper does not make this point, but it follows directly from placing requirements models at run-time.
A quantitative test of the framework would compare the causes cited in an explanation with the actual state conditions and history used by the controller. For the executable-scenario variant this fidelity should be near-perfect, while the manually built causality trees should lose fidelity when a cause is omitted or the system is changed; the paper does not report such a comparison.
The Model Learning component is the least specified part of the loop; if it learns from observed correlations rather than causal knowledge, it can produce a rationalization that reads as an explanation but is not the cause. A companion requirement would be to validate learned models against the system's actual decision procedure.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Read this one before your next explainability meeting: it's a short, clearly argued vision paper that adapts the MAPE loop to run-time explainability for CPS. The new thing is MAB-EX — Monitor, Analyze, Build, Explain — with an explicit separation between detecting an explanation need, constructing an explanation from an internal explanation model, and delivering it via a recipient model, plus a model-learning component. That is a genuine, reusable orientation, and the paper is honest that it is an adaptation of MAPE. The V2X narrow-passage example is concrete, and the SML scenario-based realization is worked out in enough detail to show how explanations could be composed from design-time models with annotations.

What it does well: it positions explainability as a run-time concern with feedback, it distinguishes explanations from rationalizations, and it lays out a sensible research roadmap. The two realization sketches — causality trees and executable SML scenarios — are complementary and connect to prior work the authors know well.

Soft spots, in proportion. The central claim that 'no reference framework exists' is overstated given the related work it cites, especially [8] and [9], both of which already sketch layers, feedback loops, and user-group granularity. The paper tempers this later, but the abstract and intro overreach. More importantly, the paper is a design hypothesis: no implementation, no user study, no evaluation of explanation quality. For a framework whose whole point is to produce explanations that are truthful and useful, that is a real gap. The stress-test concern about explanation fidelity lands: the explanation model is allowed to be separate from the control logic, and nothing in the loop verifies that the model still matches the actual decision-making after the controller changes. In the SML variant the mismatch is avoidable if the scenarios are the implementation, but the paper explicitly leaves open the weaker option. The model-learning component can update the explanation model from observations, but observations alone do not give causes; you need something like interventions or a consistency check. So the framework could produce plausible but false explanations, and the paper does not address that. Minor point: the example retrieves mostly engineer-written annotation text; that is fine as a starting point but does not demonstrate explanation generation from independent evidence.

Who it is for: researchers in software engineering and explainable AI who want a common vocabulary and a starting architecture for self-explaining CPS. It deserves serious peer review — there is enough substance and the roadmap is useful — but it should be revised as a vision/position paper with explicit limitations, and the novelty claim should be tempered.

Referee Report

3 major / 4 minor

Summary. The paper proposes MAB-EX, a reference framework for building self-explainable cyber-physical systems. MAB-EX adapts the MAPE loop into Monitor, Analyze, Build, Explain phases, augmented by a Model Learning component that updates explanation and recipient models when un-explainable behavior is detected. The framework is illustrated on a V2X narrow-passage assistance system with two concrete Build-phase realizations: design-time models of causality, and runtime executable scenario models in SML annotated with natural-language explanations. The authors position the contribution as the first general design methodology and reference framework for self-explainable systems, and close with a research roadmap of open challenges.

Significance. If the framework is accepted as a reference architecture, it provides a useful structuring vocabulary for a young research area and a concrete, testable instantiation path via scenario-based behavior models. The V2X example is pedagogically clear, and the SML realization has the merit of being executable, which makes the proposal more concrete than a purely abstract loop. The paper honestly labels itself as a vision and roadmap contribution; it offers no implementation, user study, or evaluation of explanation quality, so the central claim is a design hypothesis rather than an empirically established result. The main risk is that the framework, as currently specified, does not guarantee that the explanations it produces are truthful accounts of the system's actual decision logic.

major comments (3)

[Section III, Build phase; Section IV-C2] The framework's central promise is to provide truthful explanations of why the system acted, but nothing in the Build phase verifies that the explanation model reflects the actual control logic. Section III explicitly permits the explanation model to be 'constructed from requirements or from a behavior model, constructed manually, or learned from observations,' and Section IV-C2 states that executable scenarios 'could live solely within the system's explanation layer (as EX models).' If the explanation model is separate from the implementation, controller modifications can make the model diverge from real causes, and the system will produce plausible but false explanations. The SML realization avoids this problem when the scenarios are also the implementation, but the framework does not require that choice. Please either add an explicit consistency-validation mechanism between the explanation model and the controller, or clearly scope the claim to settings where this consistency is guaranteed by construction.
[Section III, Model Learning; Section V] The Model Learning component is described as machine learning, an expert system, or a combination, but no mechanism is specified for checking that an updated explanation model still captures true causal relationships. Learning from observational data alone cannot establish causality without interventions or additional assumptions, so the learned explanations may be no more than correlations. This is load-bearing because the paper distinguishes itself from rationalization approaches precisely by promising explanations that reflect the system's real decision process. Please describe how Model Learning validates causal fidelity, for example by replaying learned explanations against recorded controller traces or by requiring expert confirmation before model updates become active.
[Section II, related work] The introduction claims that 'no design methodology or reference framework exists' for self-explainable systems, but Section II cites [8], which already proposes a conceptual framework for self-explaining digital systems with an abstract model layer and user-specific explanation granularity. The manuscript does not provide a detailed comparison explaining what MAB-EX adds beyond [8] beyond the feedback-loop structure and the SML instantiation. Since the novelty claim is a core part of the paper's positioning, please either qualify the claim or add a systematic comparison table/discussion of the differences.

minor comments (4)

[Section IV-C1, Figure 3] The root node of the causality tree in Figure 3 is labeled 'Vehicle Stops,' while the running example's observable event is the controller's 'enteringDisallowed' response. Please align the terminology between the figure and the scenario descriptions.
[Section IV-C2, Listing 1] The listing's @EX annotations are said to be combined into the final explanation, but the composition rule is not defined: it is not clear how the fragments from multiple active scenarios are selected, ordered, and merged into the quoted sentence in Section IV-D. A short description of the composition procedure would make the example reproducible.
[Section IV-C2] The sentence 'It will be interesting to elaborate how also explanations for not executing certain events can be provided' is a fragment in the printed text; please rephrase it as a complete sentence.
[Section V, research roadmap] The roadmap lists seven challenges, but several items, such as 'Explanation prediction' and 'Cooperative explanations,' are already partially addressed elsewhere in the paper (e.g., look-ahead simulation in Section III and the collaborative learning cloud in Model Learning). Please add cross-references or clarify how these items go beyond what is already sketched.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: MAB-EX is a self-contained reference architecture, and its illustrative explanations are transparently assembled from explicit annotations.

full rationale

The paper is a vision/position paper proposing the MAB-EX reference framework, adapted from the MAPE loop. It contains no fitted parameters, empirical predictions, or first-principles derivations whose outputs could reduce to their inputs. Section III defines an explanation model as 'a behavioral model of the system that captures causal relationships between events and system reactions,' but this is a design assumption about what an explanation model should be, not a theorem derived from the framework. The framework explicitly allows such models to be constructed manually, derived from requirements, or learned, and it nowhere claims that any particular explanation is verified to be true. The two Section IV realizations are illustrative. The causality-tree realization cites prior work by the same authors ([13,14]) only as an example technique; it is not used as a uniqueness argument or as load-bearing evidence for the central claim. The SML realization produces explanations by combining @EX annotations that the developer explicitly attaches to scenarios; this is transparent by design, and the paper does not claim the annotations are inferred from behavior or validated by the framework. The remaining self-citations ([17,18]) concern the SML language and tooling and similarly do not carry the paper's argument. The concern that an explanation model may drift from the actual control logic is a correctness and fidelity risk, not a circularity, and the paper itself distinguishes rationalizations from accurate explanations in Section II. Hence no step reduces to its own input, and the circularity score is 0.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central claim rests on assumptions about model availability and fidelity rather than on measured data or formal proofs. No free parameters are fitted and no new physical or conceptual entities are postulated beyond the framework's own modeling artifacts.

assumptions (4)

domain assumption An explanation model can be constructed that captures causal relationships between events and system reactions, and it can be evaluated at run time.
Section III, Build phase; this is the core premise under which explanations can be generated.
domain assumption Monitoring and analysis of sensor data, command histories, and user interactions can reliably detect when an explanation is needed.
Section III, Monitor and Analyze phases; the framework assumes deviations and queries indicate explanation needs.
domain assumption A recipient model can represent a stakeholder's explanation preferences and mental model well enough to tailor the output.
Section III, Explain phase; personalization is claimed but no evidence is given that such models can be acquired.
domain assumption Executable scenario models (SML) can serve simultaneously as the system implementation and as the explanation model, so the annotations refer to actual behavior.
Section IV-B2 and citation [17]; this is a strong assumption for the illustrative realization.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Towards Self-Explainable Cyber-Physical Systems." pith.science (2026). https://pith.science/paper/ROF7UT5H

@misc{pith2026190804698,
  author       = {Pith},
  title        = {Pith review of: Towards Self-Explainable Cyber-Physical Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ROF7UT5H}},
  note         = {Machine review of arXiv:1908.04698}
}

read the original abstract

With the increasing complexity of CPSs, their behavior and decisions become increasingly difficult to understand and comprehend for users and other stakeholders. Our vision is to build self-explainable systems that can, at run-time, answer questions about the system's past, current, and future behavior. As hitherto no design methodology or reference framework exists for building such systems, we propose the MAB-EX framework for building self-explainable systems that leverage requirements- and explainability models at run-time. The basic idea of MAB-EX is to first Monitor and Analyze a certain behavior of a system, then Build an explanation from explanation models and convey this EXplanation in a suitable way to a stakeholder. We also take into account that new explanations can be learned, by updating the explanation models, should new and yet un-explainable behavior be detected by the system.

Figures

Figures reproduced from arXiv: 1908.04698 by the authors.

**Figure 1.** The Monitor, Analyze, Build, Explain (MAB-EX) framework. understanding of what the autonomous vehicles were doing and why, as well as how they work [13]. III. THE MAB-EX LOOP FOR EXPLAINABILITY Our framework for self-explaining systems is inspired by the MAPE loop for self-adaptive systems, as we need similar self-reflection capabilities to detect the possible need for an explanation and to provide context-specific … view at source ↗

**Figure 2.** Vehicle-to-X (V2X) narrow passage coordination assistance system observed situation, or as combination of both. This cooperative updating process could, e.g., be realized by connecting Model Learning components of different systems and experts via a cloud service. To update the recipient model, preferences of the recipient can be inferred from the interaction with the recipient (e.g., based on follow-up questions th… view at source ↗

**Figure 3.** Model of causality for the car example. Each node has a condition [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Figures from the paper (1 more)

**Figure 4.** Figure 4: Scenario run-time states for the V2X example [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

18 extracted references · 18 canonical work pages

[8]

Towards self-explaining digital systems: A design methodology for the next generation,

R. Drechsler, C. Lüth, G. Fey, and T. Güneysu, “Towards self-explaining digital systems: A design methodology for the next generation,” in 2018 IEEE 3rd International Veriﬁcation and Security Workshop (IVSW) . IEEE, 2018, pp. 1–6

work page 2018
[9]

Combining monitoring and autonomous feedback requests to elicit actionable knowledge of system use,

D. Wüest, F. Fotrousi, and S. Fricker, “Combining monitoring and autonomous feedback requests to elicit actionable knowledge of system use,” in Requirements Engineering: Foundation for Software Quality , E. Knauss and M. Goedicke, Eds. Cham: Springer International Publishing, 2019, pp. 209–225

work page 2019
[1]

Why and why not explanations improve the intelligibility of context-aware intelligent systems,

B. Y . Lim, A. K. Dey, and D. Avrahami, “Why and why not explanations improve the intelligibility of context-aware intelligent systems,” in SIGCHI Conference on Human Factors in Computing Systems (CHI) , 2009, pp. 2119–2129

work page 2009
[2]

Improving user conﬁdence in concept maps: Exploring data driven explanations,

P. Le Bras, D. A. Robb, T. S. Methven, S. Padilla, and M. J. Chantler, “Improving user conﬁdence in concept maps: Exploring data driven explanations,” in CHI Conference on Human Factors in Computing Systems. ACM, 2018, pp. 1–13

work page 2018
[3]

An architectural blueprint for autonomic computing,

“An architectural blueprint for autonomic computing,” IBM, White Paper, Jun. 2005

work page 2005
[4]

Sommer and F

C. Sommer and F. Dressler, Vehicular Networking. Cambridge University Press, 2014

work page 2014
[5]

On generating explainable plans with assumption-based argumentation,

X. Fan, “On generating explainable plans with assumption-based argumentation,” in International Conference on Principles and Practice of Multi-Agent Systems . Springer, 2018, pp. 344–361

work page 2018
[6]

Interactive explanation for planning-based systems,

E. Zhao and R. Sukkerd, “Interactive explanation for planning-based systems,” in 10th ACM/IEEE International Conference on Cyber-Physical Systems (ICCPS 2019) , 2019

work page 2019

Show all 18 references

[7]

Towards explainable multi- objective probabilistic planning,

R. Sukkerd, R. Simmons, and D. Garlan, “Towards explainable multi- objective probabilistic planning,” in 4th International Workshop on Software Engineering for Smart Cyber-Physical Systems . ACM, 2018, pp. 19–25

2018
[10]

Rationalization: A neural machine translation approach to generating natural language explanations,

B. Harrison, U. Ehsan, and M. O. Riedl, “Rationalization: A neural machine translation approach to generating natural language explanations,” 2017

2017
[11]

Dynamic gener- ation and reﬁnement of robot verbalization,

V . Perera, S. P. Selveraj, S. Rosenthal, and M. Veloso, “Dynamic gener- ation and reﬁnement of robot verbalization,” in 25th IEEE International Symposium on Robot and Human Interactive Communication (RO-MAN) . New York, NY , USA: IEEE, Aug. 2016, pp. 212–218

2016
[12]

Keep me in the loop: Increasing operator situation awareness through a conversational multimodal interface,

D. A. Robb, F. J. Chiyah Garcia, A. Laskov, X. Liu, P. Patron, and H. Hastie, “Keep me in the loop: Increasing operator situation awareness through a conversational multimodal interface,” in 20th ACM International Conference on Multimodal Interaction (ICMI) . ACM, 2018, pp. 384–392

2018
[13]

Explainable autonomy: A study of explanation styles for building clear mental models,

F. J. Chiyah Garcia, D. A. Robb, A. Laskov, X. Liu, P. Patron, and H. Hastie, “Explainable autonomy: A study of explanation styles for building clear mental models,” in 11th International Natural Language Generation Conference (INLG) . ACM, 2018, pp. 99–108

2018
[14]

Explain yourself: A natural language interface for scrutable autonomous robots,

F. J. Chiyah Garcia, D. A. Robb, X. Liu, A. Laskov, P. Patron, and H. Hastie, “Explain yourself: A natural language interface for scrutable autonomous robots,” in Explainable Robotic Systems Workshop (HRI) , 2018

2018
[15]

Emotion recognition in human-computer interaction,

R. Cowie, E. Douglas-Cowie, N. Tsapatsoulis, G. V otsis, S. Kollias, W. Fellenz, and J. G. Taylor, “Emotion recognition in human-computer interaction,” IEEE Signal Processing Magazine, vol. 18, no. 1, pp. 32–80, 2001

2001
[16]

LSCs: Breathing life into message sequence charts,

W. Damm and D. Harel, “LSCs: Breathing life into message sequence charts,” in Springer Formal Methods in System Design , vol. 19, 2001, pp. 45–80

2001
[17]

A scenario-based mde process for dynamic topology collaborative reactive systems – early virtual prototyping of car-to-x system speciﬁcations,

J. Greenyer, L. Chazette, D. Gritzner, and E. Wete, “A scenario-based mde process for dynamic topology collaborative reactive systems – early virtual prototyping of car-to-x system speciﬁcations,” in Modellierung 2018, Workshops zur Modellierung in der Entwicklung von kollabor...

2018
[18]

Scenariotools – a tool suite for the scenario-based modeling and analysis of reactive systems,

J. Greenyer, D. Gritzner, T. Gutjahr, F. König, N. Glade, A. Marron, and G. Katz, “Scenariotools – a tool suite for the scenario-based modeling and analysis of reactive systems,”Elsevier Science of Computer Programming, vol. 149, pp. 15 – 27, 2017, special Issue on MODELS’16

2017

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.

[1] [8]

Towards self-explaining digital systems: A design methodology for the next generation,

R. Drechsler, C. Lüth, G. Fey, and T. Güneysu, “Towards self-explaining digital systems: A design methodology for the next generation,” in 2018 IEEE 3rd International Veriﬁcation and Security Workshop (IVSW) . IEEE, 2018, pp. 1–6

work page 2018

[2] [9]

Combining monitoring and autonomous feedback requests to elicit actionable knowledge of system use,

D. Wüest, F. Fotrousi, and S. Fricker, “Combining monitoring and autonomous feedback requests to elicit actionable knowledge of system use,” in Requirements Engineering: Foundation for Software Quality , E. Knauss and M. Goedicke, Eds. Cham: Springer International Publishing, 2019, pp. 209–225

work page 2019

[3] [1]

Why and why not explanations improve the intelligibility of context-aware intelligent systems,

B. Y . Lim, A. K. Dey, and D. Avrahami, “Why and why not explanations improve the intelligibility of context-aware intelligent systems,” in SIGCHI Conference on Human Factors in Computing Systems (CHI) , 2009, pp. 2119–2129

work page 2009

[4] [2]

Improving user conﬁdence in concept maps: Exploring data driven explanations,

P. Le Bras, D. A. Robb, T. S. Methven, S. Padilla, and M. J. Chantler, “Improving user conﬁdence in concept maps: Exploring data driven explanations,” in CHI Conference on Human Factors in Computing Systems. ACM, 2018, pp. 1–13

work page 2018

[5] [3]

An architectural blueprint for autonomic computing,

“An architectural blueprint for autonomic computing,” IBM, White Paper, Jun. 2005

work page 2005

[6] [4]

Sommer and F

C. Sommer and F. Dressler, Vehicular Networking. Cambridge University Press, 2014

work page 2014

[7] [5]

On generating explainable plans with assumption-based argumentation,

X. Fan, “On generating explainable plans with assumption-based argumentation,” in International Conference on Principles and Practice of Multi-Agent Systems . Springer, 2018, pp. 344–361

work page 2018

[8] [6]

Interactive explanation for planning-based systems,

E. Zhao and R. Sukkerd, “Interactive explanation for planning-based systems,” in 10th ACM/IEEE International Conference on Cyber-Physical Systems (ICCPS 2019) , 2019

work page 2019