2.1 The s(CASP) system and the Event Calculus

The s(CASP) system, presented by Arias et al. (Reference ARIAS, CARRO, SALAZAR, Marple and Gupta2018), extends the expressiveness of ASP systems, based on the stable model semantics by Gelfond and Lifschitz (Reference GELFOND and LIFSCHITZ1988), by including predicates, constraints among non-ground variables, uninterpreted functions, and, most importantly, a top-down, query-driven execution strategy. These features make it possible to return answers with non-ground variables (possibly including constraints among them) and to compute partial models by returning only the fragment of a stable model that is necessary to support the answer to a given query. Answers to all queries can also include the full proof tree, making them fully explainable.

In s(CASP), thanks to the constructive negation, can return bindings for for which the call would have failed. Thanks to the interface of s(CASP) with constraint solvers, sound non-monotonic reasoning with constraints is possible.

Like other ASP implementations and unlike Prolog, s(CASP) handles non-stratified negation and returns the corresponding (partial) stable models, for example, for the program , under the stable model semantics there are two possible models for this even loop (Lifschitz, Reference LIFSCHITZ2019), with either or being true. Even loops are used in s(CASP) to implement abductive reasoning via the directive, where we automatically search for suitable values of the predicates in the corresponding even loop so we can satisfy the main query. We use abduction in Section 4.2 to detect a violation of a critical safety property in the PCA pump requirements.

The Event Calculus (EC) is a formalism for reasoning about events and change by Mueller (Reference MUELLER2014), of which there are several axiomatizations. There are three basic concepts in EC: events, fluents, and time points: (i) an event is an action or incident that may occur in the world, for example, the dropping of a glass by a person is an event, (ii) a fluent is a time-varying property of the world, such as the altitude of a glass, (iii) a time point is an instant of time. Events may happen at a time point; fluents have a truth value at any time point, and these truth values are subject to change upon an occurrence of an event. In addition, fluents may have quantities associated with them as parameters, which change discretely via events or continuously over time via trajectories.

For example, the event of dropping a glass initiates the fluent that captures that the glass is falling, which enables a trajectory that determines the decreasing value of a fluent that represents the glass’s height above the ground, and the event of catching a glass terminates the fluent that the glass is falling, which disables the trajectory. An EC description consists of a universal theory and a domain narrative (see the book by Mueller (Reference MUELLER2014) for details). The theory is a conjunction of EC axioms, for example, axiom BEC6 states that a fluent $f$ is true at a time $t_2$ if it is initiated by some event $e$ occurring at some earlier time $t_1$ and it is not stopped between $t_1$ and $t_2$ :

\begin{align*} {HoldsAt}(f,\,t_2)\leftarrow {Happens}(e,\,t_{1}) \wedge {Initiates}(e,\,f,\,t_{1})\,\wedge\,t_{1} \lt {t_{2}} \wedge \lnot {StoppedIn}(t_{1}, f, t_{2}). \end{align*}

The domain narrative consists of the causal laws of the domain and the known events and fluent properties. Mueller (Reference MUELLER2014), in his book in Example 14, reasons about turning a light switch on and off using the event $\mathit{Happens}(e,t) \,\equiv \, (e=\mathit{TurnOn} \,\land \, t=1/2)$ $\lor \, (e=\mathit{TurnOff} \,\land \, t=4)$ that states that the $\mathit{TurnOn}$ event will happen exclusively at time $t=1/2$ and that $\mathit{TurnOff}$ will happen exclusively at $t=4$ .

Two key factors contribute to the s(CASP)’s ability to model EC: the preservation of non-ground variables during the execution and the integration with constraint solvers. Using the translation rules introduced by Arias et al. (Reference ARIAS, CARRO, CHEN and GUPTA2022), one can translate the BEC axioms by Mueller (Reference MUELLER2014) into s(CASP) programs that follow the logic programming convention: constants and predicate symbols start with a lowercase letter, variables start with an uppercase letter, and constraints can be written with a prefix (#<). For example, the BEC6 axiom and events are translated as:

2.2 The Patient-Controlled Analgesia (PCA) Pump project

The Open PCA Pump Project, introduced by Hatcliff et al. (Reference HATCLIFF, LARSON, CARPENTER, JONES, ZHANG and JORGENS2019) and available at https://openpcapump.santoslab.org/, provides a full set of realistic artifacts used in the development process of a Patient-Controlled Analgesia Infusion Pump, which is a safety-critical medical device. The artifacts were created at the behest of the US Food and Drug Administration to provide an open-source example of model-based systems engineering for industry, and a subject matter for researchers. The primary function of the device is to automatically and safely deliver the appropriate amount of pain-relief drugs to a patient via infusion into their bloodstream. The pump needs to do so without delivering an amount that would harm the patient, it needs to notify clinicians about hazards, and it needs to maintain safe operation even when failures occur or when hazards are detected. The delivery parameters, such as drug flow rates or maximum safe doses, are either prescribed by a physician or specified in a drug library.

In this paper, we use version 1.0.0 of the PCA specification (Open-PCA-Pump-Requirements.pdf in GitHub, which we reference as [PCA page N] in the following when referring to page N). The PCA pump delivers drug using four different types of delivery: (i) Basal delivery is the baseline which delivers drug using a small flow rate during normal operation. It is the initial type of delivery after starting the pump. (ii) Patient-requested bolus is an extra dose which can be requested by the patient via a button. Upon a valid request, the PCA pump delivers a prescribed amount of drug called VTBI (volume-to-be-infused) using a higher flow rate in addition to the baseline basal flow rate and then returns to basal delivery. (iii) Clinician-requested bolus is a second, similar, extra dose of the same VTBI spread over many minutes. It differs in that it can only be requested by a clinician and that they can select a duration for the bolus. (iv) KVO delivery (Keep-Vein-Open) is an emergency delivery with the smallest flow rate to prevent clotting of the needle in response to certain alarms.

The specification defines a number of alarms and how the PCA pump should respond to them. Most of the alarms are related to hardware failures or physical issues detected by sensors, while others are raised by the logic of the PCA pump, for example, to prevent an overdose of the patient.

4.1 Validating consistency of use/exception cases and the requirements

We show an example of using s(CASP) reasoning to simulate UC2: Patient-Requested Bolus in order to validate its consistency with the requirements specification.

A use case consists of pre-conditions, a sequence of steps, and post-conditions. We create a narrative of event occurrences based on the pre-conditions and input events from the steps. Then, we form a query based on the post-conditions and triggered events from the steps. The below excludes the initialization of system parameters, for example, that the VTBI is $1\,ml$ and the bolus flow rate is $1\,ml.min^{-1}$ . The implementation can be found in uc2.pl and general_utils.pl (utility predicates and ).

The occurrence times of input events are randomly chosen. The model should behave according to the UC for any event times. In the future, we plan on allowing narratives with events at variable timepoints (currently, fixed narratives are required). The above query succeeds, meaning that the model and the requirements are consistent with UC2.

4.1.1 Results of experiments with consistency validation

We have simulated all relevant UCs and ExCs from the PCA pump specification on a 2.67 GHz Xeon CPU, using at most 40 MB of memory. Selected representative results are shown in Table 1, the rest can be found in Appendix A.3 (available online as supplementary material at the TPLP archive).

Table 1.

Results of simulation of relevant use cases and exception cases

Some of the cases appear in multiple variants of the narrative. For instance, in UC3, a clinician-requested bolus can be delivered uninterrupted (UC3a) or it may be suspended by a patient-requested bolus and resumed afterward (UC3b). To save space, we aggregate the measurements of variants of the same case that led to the same result. All implementations can be found in the narratives_and_queries folder.

All UCs were simulated successfully, but quite a few ExCs failed. This has led to the discovery of a number of issues in the specification, such as inconsistencies in alarm responses or defined constants. In particular, Step 1 of ExC7c [PCA page 34] says that an alarm should be raised if the drug flow rate exceeds the prescribed rate for longer than 10 seconds, while the requirement R6.4.0(4) [PCA page 58] defines 1 minute instead. Very similar issues were found in ExC7e and other ExCs. Further, the second post-condition of all variants of ExC7 expects infusion to be halted, but Table 4 [PCA page 59] requires a switch to KVO delivery.

Cases UC3b and ExC13a-c are significantly slower than the others due to their narratives containing multiple bolus requests (2–3), while the others only contain one or none. In general, we have observed the biggest (exponential) increase in execution time when increasing the number of bolus requests, that is, the number of system input events. ExC21 is also slower despite featuring no bolus requests due to its use of full reasoning about the level of the drug reservoir, which is discussed in Section 5.5.

4.2 Validating the requirements wrt. general properties

We use ExC13: Maximum Safe Dose as an example of reasoning about general properties of the system and, later, to demonstrate abductive reasoning capabilities of s(CASP). ExC13 defines that the pump should prevent an overdose of the patient by reducing the drug flow rate. This is a general property, and so ExC13 had to be implemented in three narratives based on whether the overdose would occur during (a) basal delivery, (b) a patient-requested bolus, or (c) a clinician-requested bolus. The implementations can be found in ec13a.pl, ec13b.pl, and ec13c.pl . For example, ExC13b contains 3 patient bolus requests, while the max dose prescription is defined to allow 2.5 boluses in 4 hours. The implemented narrative consists of and three instances of for equal to , , and . The third bolus would cause an overdose if delivered. This overdose is prevented by the requirement R5.2.0(5) (discussed as R5 in Section 3), according to which the bolus will be denied. A similar measure is defined for a clinician-requested bolus by R5.3.0(7) [PCA page 56].

The query (implemented in analysis_utils.pl) checks the amount of drug delivered within the max dose time window with the end of the window at time . It succeeds if the maximum dose was exceeded and will return by how much via . This query returns no models on ExC13b meaning that an overdose did not happen at any time . However, if we modify the narrative by changing the bolus request times to , , and (switching from ExC13b to ExC13a), then the query succeeds with bindings and . This overdose happens during basal delivery due to a missing requirement (discussed in Section 4.2.2).

4.2.3 Results of experiments with validation of general properties

Table 2 shows results and execution times of querying overdose on variants of ExC13 (discussed in Section 4.2) and of using abduction on UC2 (discussed in Section 4.2.1). Execution of the overdose queries takes much longer than the simulation queries from Table 1 (minutes instead of seconds) due to the higher complexity of the overdose query. However, the abductive queries are the slowest ones due to the higher complexity of abduction in general but also due to the limitations of its current implementation in s(CASP), discussed in Section 5.3.

Table 2.

Overdose querying on ExC13 and UC2

5.1 Improved implementation of the Event Calculus axioms

Our implementation of the BEC axioms (in bec_scasp-pca_pump.pl) differs from the one by Arias et al. (Reference ARIAS, CARRO, CHEN and GUPTA2022) in two aspects in order to avoid non-termination. First, inspired by Varanasi et al. (Reference VARANASI, ARIAS, SALAZAR, LI, BSUA and GUPTA2022), we use a custom implementation of the keyword. Namely, we implement negated predicates, such as , as simplified versions of the dual rules that s(CASP) generates to compute the negated predicates. These simplified versions contain only the dual rules that are relevant for the intended evaluation of the negated predicates. Second, we introduce new predicates , , , and . These are created by preprocessing the source code and introducing a new fact for each fact and/or rule (and likewise for others). Our implementation of the BEC6 axiom (cf. Section 2.1) using these new predicates follows:

This construction is motivated by an observation that, in our experiments, proving the original predicate first often leads to non-termination due to its sub-goals, while proving first often leads to non-termination and enlarges the search space due to the unconstrained . On the other hand, proving the sub-goal-free first has proven reliable in avoiding non-termination and pruning the search space by constraining . A similar approach was used by Shanahan (Reference SHANAHAN2000).

5.2 Modeling non-termination-prone self-ending trajectories

The main challenge during the modeling of the PCA pump was non-termination caused by trajectories which we refer to as self-ending. A trajectory, defined by a rule with a head , starts when its control fluent is initiated at some time , and the body of the rule then determines how the value of its continuous fluent may be computed for any time , where , until is terminated. The trajectory is self-ending if may be terminated at some time while the trajectory is active by some event that gets triggered when the value of satisfies a certain predefined condition. We call such an event a self-end event of the given trajectory. In the PCA pump, almost all trajectories are self-ending, for example, bolus deliveries terminate themselves based on how much drug they deliver. For example, the , defined in a similar way as was shown in Section 3, is self-ending, and one of its self-end events is because its trigger rule depends on the value of (the code below is simplified for space reasons, details can be found in 04-clinician_bolus_trajectory.pl):

The above rule will, currently, cause non-termination in s(CASP) (trace on GitHub). It is triggered when the amount of drug delivered within the max dose time window reaches the maximum allowed dose. The cause of the issue is that a different trajectory, in this case representing KVO delivery, can be used to determine the value of while at the same time the start event of that trajectory, , is triggered by the event . This particular loop is created because KVO delivery is being considered as a way to prove the value of at time . However, clinician bolus delivery is the only type of delivery which can lead to success because only one delivery can be active at a time, and if clinician bolus delivery was not active, then we would not need to reason about triggering its halt.

To avoid this issue, we introduce a new predicate and a new axiom for EC. We use the new predicate to force the use of the right trajectory when proving the value of at at line 4 (defined above) by adding as a parameter to . The new axiom is the same as the BEC3 axiom, except for the addition of as the third parameter:

Specifying ensures that only the trajectories controlled by that fluent will be considered when trying to prove . In general, the predicate should be used in self-end event trigger rules when one needs to prove the value of a continuous fluent while its self-ending trajectory is active.

5.3 Abduction using incremental refinement to enforce consistent models

Abductive reasoning in s(CASP) can abduce a different value of an abducible every time the abducible is reached in the reasoning tree. This is, however, unsuitable when some constant or a tuple of constants, representing, for example, values of some parameters of the modeled system or of some scenario in which it is evaluated, is to be abduced.

Since the above problem appears in our model, we have proposed its solution suitable for abducing numerical values. It is based on repeatedly refining the values abduced at different points in the reasoning tree—through repeatedly tightening constraints on possible values of the abducibles—until the same values are obtained everywhere (or the abduction fails). The solution consists of two phases; the first one follows:

The result of the first phase will be a set of models, each containing a tuple of intervals $I^{p_1}, \ldots, I^{p_n}$ of possible values of $p_1, \ldots, p_n$ . However, in order to obtain one concrete witness of the result of the query, one cannot just take any tuple of values $v_1, \ldots, v_n$ , where $v_i \in I^{p_i}$ , since the values of the different parameters may depend on each other. Therefore, in the second phase of our solution, for each of the models, we proceed as follows. We select a value $v_n \in I^{p_n}$ and repeat the first phase with this value fixed, leading to new intervals $J^{p}_{1} \subseteq I^{p}_{1}, \ldots, J^{p}_{n-1} \subseteq I^{p}_{n-1}$ . We then likewise gradually select and fix values for the parameters $p_{n-1}, \ldots, p_2$ . For $p_1$ , it is not needed to repeat the process since it is the last interval to pick a value from and, therefore, any choice will be valid.

We use the above approach in Section 4.2.1 to abduce the initial value of a constant fluent with two variable parameters (the implementation is available in incremental_abduction.sh). The described approach can find witnesses of a property violation but, due to the cutoff bound in Step 2(c) of the first phase, it cannot guarantee that the property is not violated. It is also inefficient due to repeated executions which explore nonrealistic parts of the state space, and, further, each execution is slower than our other experiments because it cannot use the experimental cache we introduced to optimize s(CASP) reasoning (discussed in Section 5.4). However, despite the inefficiency, it was able to detect an error in the requirements specification (discussed in Section 4.2.2) in reasonable time. Introducing an efficient solution to this problem into s(CASP) is part of our future work.

5.4 Prototype cache for predicate proof results

The runtimes presented in Tables 1 and 2 (except for abduction) were measured using s(CASP) version 0.24.04.04 under a new, preliminary implementation of tabling that caches the first (un)successful evaluation of specific predicates. These predicates are selected using the directive, in a similar way as mode-directed tabling, described by Guo and Gupta (Reference GUO and GUPTA2008) and Arias and Carro (Reference ARIAS and CARRO2019b), and implemented in several Prolog interpreters. Under this cache mode, when one of the selected predicates fails to be proved as a ground sub-goal of any rule, s(CASP) caches the failure (failure-tabling), and similarly, when the evaluation of the sub-goal succeeds, the success is cached. Subsequent attempts at proving the ground cached predicate will then use these results instead of attempting to prove it again. Note that since s(CASP) implements non-monotonic reasoning, the result is only valid while the current assumptions are valid—therefore, the result stays cached until current assumptions change.

Using the cache on our test suite, we have observed a reduction of execution time by up to 95 % on individual test narratives with an overall average of 66 % across the whole test suite while still obtaining the same models (up to the cached parts of the proof tree). We believe that a more sophisticated implementation of tabling, based on TCLP by Arias and Carro (Reference ARIAS and CARRO2019a), would increase the performance without losing soundness (note that for non-grounded sub-goals, we may lose other valid answers by storing only one answer, affecting the soundness of negated sub-goals) or completeness.

In our experiments, we cached all EC predicates by including the file cache.pl with the corresponding directives. Due to the nature of EC, proving anything at a timepoint requires reconstructing the whole history from time zero to the given timepoint. Therefore, the history which had to be proven for the value of a fluent at will potentially have to be re-proven again for where . The new cache is especially useful to prevent repeated failing attempts to prove a predicate such as . We found that even reasoning about simple narratives would attempt and fail to prove many times for the exact same parameters. When using cache, the predicate will only fail to be proven once for each set of parameters.

5.5 Decoupling triggers and effects of events into multiple executions

Based on our experiments, we believe that triggered events, especially the ones that can terminate a trajectory, very significantly contribute to the solving complexity. This holds even for narratives in which such events are never actually triggered—because the reasoning keeps trying to prove their trigger due to their potential effects. To reduce the performance impact of triggered events, we propose below an approach that targets particularly those of such events that may only trigger once per narrative, such as certain alarms in the PCA pump. The idea is to use a multi-run reasoning in which we decouple the trigger of such an event from its effect. This is done by removing all effects of and moving them to a newly introduced event instead (see an example in Appendix A.2, available online as supplementary material in the TPLP archive). We then use one dedicated run to check whether happens at some time in the given narrative. If not, will stay undefined in further reasoning. If does happen at , we introduce a fact , which will then allow further reasoning to take the effect of into account without having to reason about its trigger.

We use the above approach for alarms related to the drug reservoir contents— and (defined in 08-drug_reservoir.pl).Footnote ³ Each of the alarms can only happen once in a narrative in response to the level of drug in the reservoir reaching a certain threshold since the reservoir cannot be refiled during a narrative. This approach was needed because implementing alarms related to the drug reservoir contents caused an unbearable slowdown for some narratives—the worst case in our test suite was a slowdown from 6.7 mins to 6.3 hours, in a narrative where neither of the alarms happens. This is due to the fact that prior to implementing these alarms the PCA model only contained three triggered events that could terminate a trajectory, each terminating only one trajectory, and adding the new alarms introduced two new triggered events which together can terminate all trajectories. Indeed, the effect of is stopping any drug delivery and switching to KVO delivery and the effect of is stopping the pump entirely.

We use the proposed approach for both the low reservoir warning and the empty reservoir alarm at the same time for a total of three executions (cf. three_runs.sh): the first query introduces a new fact for the low reservoir, the second one introduces a new fact for the empty reservoir while using the fact from the first query, and the third and final query considers both of the new facts. For a narrative based on UC2 which reasons about both the low reservoir warning and the empty reservoir alarm, the three run approach takes 12 s while a single run with full reasoning takes 35 minutes (cf. empty_reserv-uc2-multirun-* and empty_reserv-uc2-onerun.pl). We are experimenting with a similar approach for incremental reasoning about all triggered events as future work.