Jun 20, 2008 - In this work, we propose a reactive version of the Event Calculus ..... W.r.t. REC, we use the close history to clip all the fluents which still holds.
Universit`a degli Studi di Bologna DEIS
An Efficient Implementation of Reactive Event Calculus Federico Chesani
Paola Mello Paolo Torroni
Marco Montali
June 20, 2008 Draft
DEIS Technical Report no. DEIS-LIA-08-003
LIA Series no. 89
An Efficient Implementation of Reactive Event Calculus Federico Chesani 1
Paola Mello 1 Paolo Torroni 1
Marco Montali 1
1
DEIS – University of Bologna {federico.chesani | paola.mello | marco.montali | paolo.torroni}@unibo.it
June 20, 2008 Draft
Abstract. In this work, we propose a reactive version of the Event Calculus (EC) implemented on top of the SCIFF framework. Being reactive, such an implementation is able to dynamically update the status of fluents as events occur. Therefore, it can be employed to perform run-time reasoning and monitoring. Keywords: Cached Event Calculus, Computational Logic, Monitoring, Runtime Verification, Social Commitments
Contents 1 Introduction
3
2 A Brief Description of the SCIFF Framework
3
3 REC: a Reactive Axiomatization of Event 3.1 Ordering of Events . . . . . . . . . . . . . 3.2 Events Happening . . . . . . . . . . . . . 3.3 Maximum Validity Intervals . . . . . . . . 3.4 Fluents Initiation . . . . . . . . . . . . . . 3.5 Fluents Termination . . . . . . . . . . . . 3.6 Generation of Maximum Validity Intervals
DEIS Technical Report no. DEIS-LIA-08-003
Calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
in SCIFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
4 5 6 6 7 7 8
LIA Series no. 89
1
Introduction
Monitoring and run-time verification are challenging issues that we face in many emerging contexts, such as open multi-agent systems and service-oriented architectures. The Event Calculus (EC) is a logic-based formalism, which has been extensively used for specification and reasoning tasks in event-based systems with complex requirements. However, its has rarely been adopted for run-time reasoning in such systems. Typically, the EC is used in a goal-driven fashion, starting from a query and reasoning in a backward-chaining manner. Run-time monitoring instead requires an event-driven approach, and a dynamic update of the fluent status, as events occur. In this work, we propose a reactive version of the EC implemented on top of the SCIFF framework. SCIFF is an ALP-based framework with a clear declarative semantics based on the concepts of events and expectations, and is equipped with a sound and complete proof-procedure. The main distinctive feature of the proof procedure is that it natively supports incremental reasoning on dynamically occurring events, in a forward-chaining fashion. Our implementation builds on the Cached Event Calculus of Chittaro and Montanari [2], who have demonstrated that shifting the computational complexity from query to update processing leads to considerable performance improvements. The paper is organized as follows. In Section 2 we briefly recall the SCIFF framework. Then, Section 3 shows how Cached Event Calculus can be suitably axiomatized in SCIFF.
A Brief Description of the SCIFF Framework
2
SCIFF is a framework, based on Abductive Logic Programming, for the specification and verification of event-based systems [1]. It provides a rule-based expressive language, with a clear declarative semantics, to specify which events are expected (not) to happen when other events occur. The basic ingredients of the language are indeed the concept of happened events (represented by functor H) and positive/negative expectations (respectively represented by functor E and EN), expressing the (un)desired system behavior. Events are described by an arbitrary term1 . Both happened events and expectations are bound to time points, modeled as integer variables and respectively representing the time at which the event happens or is expected (not) to happen. Event and time variables can be constrained by means of Prolog predicates or CLP constraints [3]; the latter are especially useful to specify orderings between events and quantitative time constraints (such as delays 1
A l´ a logic programming.
3
and deadlines). SCIFF rules are forward body → head reactive rules which link happened events and expectations. In particular, body contains (a conjunction of) happened events, whereas the head envisages (a disjunction of conjunctions of) positive and negative expectations; when the body of a rule becomes true (i.e., the involved events happen), then the rule triggers and the expectations contained in the head are generated. To exhibit a correct behavior, the execution must fulfill all the generated expectations. The concept of fulfillment is formally captured by means of SCIFF declarative semantics [1], which intuitively states that positive expectations must have a corresponding matching happened event, whereas negative expectations forbid the happening of matching events. Generation and fulfillment of expectations is concretely carried out by the operational counterpart of the framework, namely the SCIFF proof procedure [1], which has been proven sound and complete w.r.t. the declarative semantics. The main distinctive feature of the proof procedure is its ability to reason upon occurring happening events in a run-time fashion, dynamically triggering rules, generating expectations, checking fulfillment and reporting violations.
3
REC: a Reactive Axiomatization of Event Calculus in SCIFF
Table 1 sketches our Event Calculus ontology. As we will see, EC is axiomatized in SCIFF by following a reactive approach: events are collected at run-time and the status of fluents is updated accordingly in a dynamic fashion. In this respect, we call the realized calculus Reactive Event Calculus (REC). Our axiomatization is inspired by the Cached Event Calculus (CEC) of Chittaro and Montanari [2]. The main distinctive feature of CEC is that it “caches” the outcome of the reasoning process carried out until the current time. In particular, CEC computes and stores fluents’ maximum validity intervals, which are the maximum intervals in which fluents hold, according to the already acquired events. The set of cached validity intervals is then extended/revised as new events occur. While in [2] the authors argue that such a caching provides a great improvement w.r.t. the computational complexity of the calculus, we exploit it to provide run-time monitoring and verification capabilities. The main distinctive feature of our axiomatization is that the holds/3 predicate, which is used to represent maximum validity intervals, is treated as abducible; SCIFF is therefore employed for reacting to events which initiate or terminate fluents, by coherently generate the corresponding holds or not holds predicates and handle their extreme time points. In the following, we discuss how the calculus should behave when events occur
4
happens(Ev, T ) holds(F, Ti , Tf ) not holds(F, Ti , Tf ) holdsat(F, T ) not holdsat(F, T ) initially(F ) initiates(Ev, F, T )
terminates(Ev, F, T )
Event Ev happens at time T Fluent F begins to hold from time Ti and persists to hold until time Tf Fluent F ceases to hold at time Ti and persists to not hold until time Tf Fluent F holds at time T Fluent F does not hold at time T Fluent F holds from the initial time Event Ev can initiate fluent F at time T ; this means that if F does not hold at time T , it is declipped by the happening of Ev at that time Event Ev can terminate fluent F at time T ; if F holds at time T , it is clipped by the happening of Ev at that time Table 1. The REC ontology.
in ascending order, and then we show how the ontology skteched in Table 1 can be suitably axiomatized in SCIFF.
3.1
Ordering of Events
An important issue is related to the order in which events occur. We envisage two different settings: • no guarantee about events ordering. In this case, it could be the case that an event e1 occurred at time T1 is processed by SCIFF after having already processed an event occured at a time greater than T1 ; the calculus must be able to deal with such a case, by properly revising the outcome of the reasoning process. While CEC makes use of Prolog assert/retract predicates to change the cached intervals, SCIFF exploits its underlying constraints solver. • events occur in ascending order. In this case, it would be desirable that the calculus proceeds in a “monotonic” way, namely that when an event is processed by the calculus, the outcome of the reasoning process does not revise (but only extend) the previously computed status of fluents. Only if this property is ensured, we can use the calculus to monitor the execution and obtain a constantly updated feedback about the status of fluents. To meet this requirement, REC follows a weak approach [2] w.r.t. maximum validity intervals2 . 2 A strong approach states that if two events capable of initiating the same fluent happen at a time T1 and T2 > T1 , without having a terminating event in between, then the fluent holds starting from T2 .
5
3.2
Events Happening
While CEC is a special-purpose engine written in Prolog, REC is realized on top of SCIFF, which is specifically tought to deal with event-based systems and perform run-time reasoning. Therefore, while CEC exploits assert/retract and negation as failure to acquire new events and suitably generate the corresponding maximum validity intervals, REC simply relies on the underlying SCIFF proof procedure, which directly handles the dynamic acquisition of events and exploits the notion of fulfillment/violation and constraints propagation to reason upon them. Since the concept of happened event is already present in SCIFF as a first-class object, the happens/2 predicates is simply mapped as follows:
happens(Ev, T ) ← H(Ev, T ).
3.3
(1)
Maximum Validity Intervals
We make use of two special events clip(Fluent) and declip(Fluent), which are internally generated events, not explicitly contained in the execution trace under study, and are used to model the clipping and declipping of fluents. These events are used to suitably characterize the notion of maximum validity interval, which is captured by means of the two following axioms. Axiom 1 (Extreme points consistency) The initial and completion time of a maximum validity interval are associated to the declipping and clipping of the corresponding fluent. In particular, if fluent F holds starting from time Ti , this means that at time Ti it has been declipped: holds(Ti , F, Tf ) → E(declip(F ), Ti ).
(2)
If fluent F holds until time Tf , then at time Tf it will be clipped: holds(Ti , F, Tf ) → E(clip(F ), Tf ).
(3)
Axiom 2 (Persistence consistency) If a fluent F holds (does not hold resp.) inside a time interval which spans from time Ti to time Tf , then it is not possible to (de)clip F between Ti and Tf . holds(Ti , F, Tf ) → EN(clip(F ), T ) ∧ T > Ti ∧ T < Tf .
(4)
Thanks to these axioms, the holds predicate is properly connected to the concept of clipping/declipping events, and the completion time Tf is bound to the nearest time, after Ti , at which the fluent is (de)clipped. 6
3.4
Fluents Initiation
We now capture the situation in which a certain fluent is declipped, consequently starting to hold. Two different cases may arise. The first one deal with the initial status of fluents. Axiom 3 (Initial status of fluents) If fluent F initially holds, a corresponding declipping (clipping resp.) event is generated at the initial time (i.e., at time point 0). initially(F ) → H(declip(F ), 0).
(5)
The second one deal with the case in which an event capable of initiating a certain fluent indeed happens. Axiom 4 (Fluents initiation) When an event Ev capable to initiate a fluent F happens at time T , and at this time F does not hold, then the fluent is declipped. H(Ev, T ) ∧ not holdsat(F, T ) ∧ initiates(Ev, F, T ) → H(declip(F ), T ).
3.5
(6)
Fluents Termination
As in the case of fluents initiation, two situations may arise when dealing with the clipping of fluents. The first situation is the one in which an event terminating a certain fluent occurs. Axiom 5 (Fluents termination) When an event Ev capable to terminate a fluent F happens at time T , and at this time F holds, then the fluent is clipped. H(Ev, T ) ∧ holdsat(F, T ) ∧ terminates(Ev, F, T ) → H(clip(F ), T ).
(7)
The other situation deals with the final status of fluents. In SCIFF, a special close history event is used to state that the execution is completed and no further event will occur. Such a special event is used by SCIFF to evaluate still pending expectations, deciding if they are violated or not; for example, a positive expectation which has not yet been fulfilled by a corresponding happening event is considered violated. W.r.t. REC, we use the close history to clip all the fluents which still holds (indeed, all these fluents still have a corresponding expectation about a clipping at the final time). Axiom 6 (Final clipping of fluents) All fluents are terminated by the special close history event. terminates(close history, F ).
(8) 7
3.6
Generation of Maximum Validity Intervals
The last axiom defines how the happening of a declip event affects the corresponding fluent (provided that such an event has been generated before the close history), abducing that the fluent begins to hold. Axiom 7 (Events effects) The happening of a declip(F) event causes fluent F starting to hold from time T . H(declip(F ), T ) ∧ T < T∞ → holds(T, F, Tf ) ∧ Tf > T.
(9)
where T∞ is the time at which the close history event happens.
References [1] M. Alberti, F. Chesani, M. Gavanelli, E. Lamma, P. Mello, and P. Torroni. Verifiable agent interaction in abductive logic programming: the SCIFF framework. ACM Transactions on Computational Logic, 9(4), 2008. To appear. [2] L. Chittaro and A. Montanari. Efficient temporal reasoning in the cached event calculus. Computational Intelligence, 12:359–382, 1996. [3] J. Jaffar and M. Maher. Constraint logic programming: a survey. Journal of Logic Programming, 19-20:503–582, 1994.
8
