1. Introduction
Verified Artificial Intelligence [
1] calls for exact procedures ascertaining whether a model of the system
abides by the specifications in
through yes or no answers (
) when written in a formalism for efficient computations, either for verifying the compliance of a system to a specification (formal verification [
2,
3]) or for producing a system abiding by a given specification (formal synthesis [
4,
5,
6]). This can be determined after a specification mining phase used to extract
from a system
[
7,
8]; these considerations bridge temporal reasoning with artificial intelligence, as in both we can extract a specification from the data that can be used to determine decision problems. Under these assumptions, we are interested in a temporal description of such systems when different runs are collected as logs
and referred to as traces
. These are temporally ordered records of observed and completed (or aborted) labelled activities. We are then interested in temporal specifications expressible over a fragment of Linear Temporal Logic for Finite traces (LTL
f), where LTL
f assumes that there is only one possible immediately following event to another and that the traces of interest contain a finite number of events. The major difference between LTL [
9] and LTL
f is that, while the former might also prescribe the need for traces of infinite length, the latter will discard any temporal behaviour requiring such infinite traces to occur. This is evident from their procedural characterization through automata: while LTL specifications can be expressed as Büchi automata, LTL
f can be conveniently represented as NFAs only accepting finite traces [
10]. To the best of our knowledge, this paper studies these situations for the first time and refers to them as
temporal short-circuits:
Example 1. Let us assume to have a temporal specification : while the interpretation of the former in LTL accepts any trace either containing neither -s nor -s or accepting either or where ω is the first infinite ordinal, the latter can never occur in LTL
f, thus prescribing the absence of any -s or -s from the patterns. By interpreting Φ in LTL
f, we can then express it equivalently to (Section 3.3) while preferring the latter representation as it completely removes the need to check whether the constraint leads to infinite behaviour never expressible in finite traces. Declarative languages in the context of Business Process Management (BPM) such as Declare [
11] ease the practitioners’ task to understand complex log patterns of interest in a straightforward way: by restricting the set of all the possible temporal behaviours of interest to the one in
Table 1, we can conveniently extract compact specifications in which conformance checking tasks determine the abidance by the hospitalization procedures [
12].
These specifications do not necessarily have to be hard-coded, but can be mined from such logs. For BPM, each event is associated with exactly one single label [
13] and, under the occasion that each event is also dataful and therefore associated with some data payload, we can always generate a finite set of mutually exclusive atoms partitioning the data space into non-overlapping intervals [
14]. This ensures the theoretical possibility of defining atoms so an event will satisfy at most one of them. This evidence is also corroborated by data as represented in the real world: recent work on time series segmentation showed the possibility of representing a time series as a sequence of dichotomous increase and non-increase events [
15] as well as the transitioning of a system into distinct non-overlapping states [
16]. Furthermore, different types of malware can be distinguished just from the distinct names of the system calls invoked at the operative system level [
17,
18]. As it is a common assumption in specification mining algorithms using Declare to return a finite conjunction of specifications, it is quite common to return inconsistent specifications under the
temporal non-simultaneity axiom (
Section 3.4) when support metrics below
are considering returning declarative clauses satisfying only a subset of the clauses (see Example 2). Declare works under such an axiom, as BPM’s practitioners implicitly assume that each trace event corresponds to explicitly one activity event, where all the distinct activity labels are assumed to be mutually exclusive predicates. Detecting this in advance will prevent running any verified temporal artificial intelligence technique on such specifications for the aforementioned practical scenarios, as no trace will ever satisfy an inconsistent specification.
Example 2. Given the DECLAREd specification aa, ca, d, this can be equivalently expressed in LTLf as . Under the non-simultaneity axiom prescribing that the same activity label cannot co-occur at the same time with another one, the occurrence of any “a” would entail that, immediately following it, we should have an immediately-following activity label being both c and d, which is prevented by this axiom. As these two last clauses then force Absence(a) as the only possible way to avoid falling into an inconsistency, , the clauses rewritten as such now conflict with the firstly occurring clause, thus generating a globally un-satisfiable specification ⊥.
Please observe that, at the time of the writing, current specification mining algorithms interpret the set of clauses being mined as a conjunctive model. Given this, when support value is set below 100%, the specification might contain clauses not necessarily satisfying all the traces in a log, thus easily leading to inconsistencies. For example, the aforementioned specification can be the result of a specification mining task with support over a log , thus postulating the need for identifying and quantifying inconsistencies within declarative conjunctive specifications [19]. This paper focuses on a DECLARE fragment, DECLARE
d (
Table 1), still affected by the aforementioned problem. These two preliminary definitions, where the second is optional, alongside the determination of a set of equivalence rules for DECLARE
d (
Figure 1) and the definition of an algorithm for DECLARE
d rewriting
(
Section 4) lead to our major result, that our proposed algorithm, Reducer, runs in
PolyTime (
Section 5). Reducer (Available on the 26 March 2024:
https://github.com/gyankos/reducer/releases/tag/v1.0) returns ⊥ if the module has inconsistencies, ⊤ if this is detected trivially true, and a rewritten set of DECLARE
d clauses
when possible. As a byproduct of the previous result, we show that such running times were not achieved by other tools not running on the same fragment:
Our rewritten equivalent specification
speeds up the time of existing verified temporal artificial intelligence algorithms (
Section 2) if compared with their runtime over the original specification
, thus proving that such algorithms do not support the notion of
temporal short-circuit (
Section 6.1).
Under
temporal non-simultaneity, the time required for both running a verified temporal artificial intelligence task and computing
is also smaller than the running time of running such tasks over
(
Section 6.2).
Graph Notation
(See
Appendix A) We denote a
(finite) graph G as a pair
, where
V is a set of vertices and
is a set of directed edges; to denote a vertex (or edge) set of a graph
G, we use the notation
(or
).
(or
) is the set of the vertices reachable through the
outgoing (or
incoming) edges for
.
Removing a vertex from a graph
G (
) requires also removing all the incoming and outgoing edges from a graph while
removing an edge from such a graph (
) also requires removing the nodes
u or
v if such removal nullifies the degree of such nodes.
is the
powerset of
S. We represent a
(hash)multimap f associating a single activity in
to a finite subset of
as a finite function
where, for each
not being a key for the multimap, we guarantee
and
otherwise; an empty multimap
f returns ⌀ for each
.
removes
x as a key of the multimap while
adds
u to the set of values associated to
x in
f. Given
V a set of vertices and
a bijection enumerating each vertex in
V, a
directed circulant graph on
n vertices has each vertex
adjacent to the immediately preceding and following vertices in
V in the order expressed within a set of natural numbers
, i.e.,
. Given this, we define
as a cyclic graph representing exactly one
chain and
is a
complete graph.
2. Brief Related Work
2.1. Formal Synthesis
Lydia [
4] (Available on 26 March 2024:
https://github.com/whitemech/lydia) generates a DFA for a LTL
f specification
such that it will accept a trace
iff.
. This works over a finite alphabet
inferred from such formula. The authors efficiently do so by exploiting a compositional bottom-up approach after rewriting a LTL
f formula into an equivalent LDL
f one. Automata operations are implemented using MONA [
20,
21] for compact representation. Benchmarks show the effectiveness of such an approach if compared to competing ones. By considering the effects of specification rewriting in automata generation, we want to verify whether temporal short-circuit rewriting tasks are already occurring over Lydia while building the automaton instead of pursuing the approach in
Section 3.3 (see Lemma 1 vs. Corollary A1).
2.2. Formal Verification
KnoBAB [
2] (Available on 26 March 2024:
https://github.com/datagram-db/knobab) is a tool implementing the semantics for LTL
f operators into custom relational operators (
xtLTL
f) providing a 1-to-1 mapping with the former. This was achieved by adequately representing all the traces in a log
under a main memory columnar representation. Its architecture stores all the activities associated to traces’ events in an
ActivityTable, which is then sorted by increasing activity id in
, trace id, and event id. At loading time, the system also builds up a
CountingTable, which determines the number of occurrences of each activity label per trace. This architecture supports MAX-Sat queries, declarative confidence and support, and returning the traces satisfying a given clause alongside its associated activated and target conditions (
for
). As KnoBAB outperforms existing tools for formal verification, we take this as a computational model of reference for determining the computational complexity of formal verification tasks over given specifications
in
xtLTL
f (see Lemma 2).
2.3. SAT-Solvers
AALTAF [
22] (Available on 26 March 2024:
https://github.com/lijwen2748/aaltaf) is a SAT-solver determining whether an LTL
f formula is satisfiable by generating a corresponding transition system where each state represents subformulæ of the original LTL
f specification while leveraging traditional SAT-solvers. Differently from KnoBAB, which determines whether traces in a log satisfy an LTL
f specification expressed in algebraic terms (
xtLTL
f) or not, AALTAF is more general than this and determines whether no traces will ever satisfy a given specification, thus determining its unsatisfiability, or whether there might exist a finite trace allowing this. AALTAF also applies LTL
f equational rewritings for reducing the specification size before running the solver. Thus, any running time discrepancy between the aforementioned tool and our solution will remark the novelty of the derived equivalence temporal rules from LTL
f as not previously considered in tools also supporting equational rewriting. This paper will show that DECLARE
d provides a polytime fragment of LTL
f for which our equational rewriting algorithm (
Section 4) also provides a decidable polyspace decision function for satisfiability (see Theorem 1).
2.4. LTLf Modulo Theories
While LTL
f is generally known as a decidable language, most recent research [
23] also consider decidable fragments of LTL
f also involving first-order logic arithmetic properties. Unlike our proposed characterization, events are not labelled as required when actions need to be ascertained. Furthermore, none of the proposed decidable fragments with arithmetic properties involves considerations on polytime complexity while still referring to polyspace complexity. This research lead to the implementation of BLACK (Available on 18 May 2024:
https://www.black-sat.org/en/stable/).
3. Materials
3.1. DECLAREd
We consider temporal specifications
expressed in DECLARE
d as a finite set of clauses from
Table 1 being instantiated over a finite set of possible activity labels
. This language considers almost the same clauses from the Declare Patterns listed in [
22] while ignoring the counting-based Declare Templates [
2,
22] determining the number of times a specific declarative temporal pattern is expected to occur; i.e., this fragment cannot express
(or
), requiring the presence of the activity condition
A within a trace for at least
n times (or at most
times) for
. As our fragment will not consider data-driven scenarios, where predicates are associated with either activation, target, or correlation conditions, we are neither considering any potential extension of such declarative clauses with such data-aware conditions [
2]; i.e., this fragment cannot express “
” requiring that, each occurrence of an activating event
with activity label
A satisfying a data predicate
p, it always exists at least one targeted event
in the future with activity label
B and satisfying a data predicate
q while also satisfying the binary data predicate
as
. Last, it cannot express some negated patterns presented in current Business Process Management, such as the negation of the Precedence pattern [
14]. While it can be shown that any data-aware declare specification can be reduced to a dataless one containing no data predicates [
14], we cannot similarly derive the Declare Templates from the clauses stated from
Table 1.
Still, this restriction does not pose a major limitation in practical use case scenarios, as these often exploit a subset of the aforementioned patterns [
12]. Similar considerations can also be applied in current Business Process Management literature, which sometimes cherry-picks the declarative patterns of interest depending on the specificity of the algorithm of interest [
8]. Last, scenarios involving the run-time reconfiguration of software architectures consider an even fewer set of clauses, where just Response, its negation, and possibly NegSuccession are considered [
24].
By interpreting this as conjunctive specifications [
14], we can equivalently represent
as the finite conjunction of the LTL
f semantics associated to such clauses, i.e.,
, where
denotes the LTL
f semantics associated to the DECLARE
d clause
as defined in
Table 1. We use both notations interchangeably. Proofs are moved within
Appendix B,
Appendix C, and
Appendix D.
3.2. Rewriting Rules
Figure 1 identifies any possible rewriting of the DECLARE
d clauses into
Absence or
Exists while determining the effects of the latter when interfering with the templates’ activation (
A) or target (
B) conditions. If available, we are also interested in rewriting rules to identify an inconsistency leading to an unsatisfiable specification ⊥. We now consider rewriting rules not assuming the temporal non-simultaneity axiom, thus remarking on the possibility of encoding these in already-existing tools as an LTL
f pre-processing step without any further assumption. As
can be rewritten as the LTL
f expression associated to
as well as
, we named
AltPrecedence rewriting rules only the ones related to this LTL
f expression. We omit the proofs, but the reader can easily verify their correctness by checking that both sides of the equivalences generate the same automata. This can be easily verified by exploiting this online tool:
http://ltlf2dfa.diag.uniroma1.it/ (Accessed on 18 May 2024).
In all the rules, we assume that
where
. Other rewriting rules (Lemma A6) are implicitly assumed in forthcoming algorithmic subroutines (
Section 4.1) and while loading and indexing specifications (Algorithm 1).
Algorithm 1 Loading binary clauses in primary memory |
- 1:
function SpecificationLoading() - 2:
match each with - 3:
case : if not Ex(a) then return ⊥ - 4:
case : if not Abs(a) then return ⊥ - 5:
case : - 6:
case : ; - 7:
case s.t. : - 8:
case s.t. : - 9:
case s.t. : - 10:
case : - 11:
if then - 12:
if not Abs(a) then return ⊥ - 13:
else - 14:
; - 15:
case : - 16:
case s.t. : - 17:
; - 18:
case s.t. : - 19:
; - 20:
case : - 21:
; ; - 22:
case s.t. : - 23:
; - 24:
case : - 25:
if then - 26:
if not Abs(a) then return ⊥ - 27:
else - 28:
; - 29:
case : - 30:
if then - 31:
if not Abs(a) then return ⊥ - 32:
else ; ; ; - 33:
case : - 34:
if then - 35:
if not Ex(a) then return ⊥ - 36:
else - 37:
case : - 38:
if then return ⊥ - 39:
- 40:
- 41:
case : - 42:
if then - 43:
if not Abs(a) then return ⊥ - 44:
else
|
3.3. Temporal Short-Circuit Rewriting
A finite conjunction of LTLf statements leads to a temporal short-circuit if this can be rewritten as a finitary conjunction, either or , for each distinct atom freely occurring in when is not syntactically equivalent to . We apply a (temporal) short-circuit rewriting to a LTLf specification if we replace any sub-formula in leading to a temporal short-circuit with .
Short-circuits based on ChainResponse boil down to the absence of each of its atoms:
Lemma 1. Given , is equivalent to in LTLf.
Such a rewriting will streamline formal verification tasks:
Lemma 2. Given , computing in the place of always leads to a positive average speed-up.
After representing all the in an input specification as a graph with edge and nodes , we can show as a corollary of the first lemma that this boils down to removing all circuits appearing over some nodes and rewriting such clauses as in polytime on the size of (Corollary A1). We can infer similar lemmas for AltResponse in terms of rewriting such resulting temporal short-circuits to absences (Lemma A2), thus resulting in time speed-up (Corollary A3).
3.4. Temporal Non-Simultaneity
Axiom 1 (Temporal Non-Simultaneity). Given the set of all the possible activity labels Σ, we prescribe that no distinct activity could occur simultaneously in the same instant. This can be expressed as .
As we assume a finite set of activity labels to be fully known from our specification or data, we can represent this axiom as an extension of the properties to be checked as a new property . As prior approaches using LTLf did not consider this assumption, should be directly stated as for both Lydia and AALTAF. On the other hand, our solver Reducer only takes as it works under such an axiom. KnoBAB automatically assumes that each distinct activity label is different from the rest, thus entailing an implicit semantic difference between different types of events.
3.4.1. Rewriting Rules
We can identify that the following rewriting rule holds for
in
, as we can never have an event being labelled with both
and
after the same occurring event:
3.4.2. Temporal Short-Circuit Rewriting
We now consider temporal short-circuit rewriting rules that only hold under temporal non-simultaneity. For
in
, as any
shall always occur after the first occurring
for
, we can express it as:
Due to this, we need to discard the eventuality that , as is, on the other hand, trivially true and leads to no temporal short-circuit.
Lemma 3. Given with , is equivalent to in LTLf.
Lemma 4. Given with , computing in the place of always leads to a positive average speed-up.
4. Reducer: A Method for Equational Rewriting
The Reducer algorithm for rewriting
into
proceeds as follows: after showing the subroutines for removing redundant clauses from the specification while propagating the detection of an inconsistency towards the function call chain (
Section 4.1), we outline how a specification
can be efficiently loaded as a collection of graphs
for each DECLARE
d template ⋆ for clause indexing (
Section 4.2). After applying the aforementioned equivalence rules (
Section 4.3), we apply the temporal short-circuit rewriting (
Section 4.4) before returning the rewritten specification
from the edges remaining from
and values in an
F map storing
Absence and
Exists clauses. Upon detecting the joint satisfaction of an Absence(x) and Exists(x) for an activity label x, we immediately detect an inconsistency for which we return ⊥. If the resulting specification appears to be empty despite no inconsistency being detected, we then obtain a trivially true specification ⊤. Otherwise, we return a rewritten specification
.
4.1. Algorithmic Subroutines
Algorithm 2 shows crucial algorithmic subroutines ensuring to propagate the detection of an absence/presence of an activity label while dealing with clauses derivable from the input specification clauses of the specification.
Let F be a finite multimap associating each activity label to a set of booleans, where true (and false) denotes that (and ) can be inferred from the specification. If both and are entailed, we deem the overall specification as inconsistent, for which we will return ⊥. Ex in L. 1 (and Abs in L. 2) returns false whether the addition of Exists (or an Absence) to a specification makes it explicitly inconsistent.
Clear at L. 3 removes all the clauses in which activation condition x would never occur per Absence(x). For , this triggers the generation of which, in turn, might lead to an inconsistent specification (L. 5 and 6). For , the absence of the activation requires , which is then in turn added while testing for the specification’s inconsistency (L. 9). The function returns true if the specification is not currently detected as inconsistent (L. 10).
Reduce at L. 11 can be applied to templates ⋆ such as ChainResponse, Response, and AltResponse for implementing a cascade effect upon the specification supporting by also requiring that the associated activations should be absent from the specification (L. 18). We return true if no inconsistency was detected and false otherwise. This idea was revised to be applied to Precedence (L. 24): for this, the absence of the activation triggers the necessity of the second argument to be absent as well, thus enforcing to visit the graph towards the outgoing edges (L. 31). We also ensure to remove all the vertices and edges associated with x (L. 32).
Dually, Expandre works by recursively applying the head from the tail of the RespExistence clauses upon the request that an event x shall exist in the data (L. 45). As this trivially exists, we remove all the clauses having this condition in the head of such rules (L. 42) while, if x appears as a second argument of a , we still postulate for the absence of u from the specification (L. 43).
Algorithm 2 Algorithmic Subroutines for our specification rewriter |
- 1:
function Ex(x) F ← PutF; return - 2:
function Abs(x) F ← PutF; return -
- 3:
function Clear(x):= - 4:
; ; ; ; ; - 5:
for all b ∈ OutGch(x) do if not Ex(b) then return false - 6:
for all b ∈ InGch(x) do if not Ex(b) then return false - 7:
- 8:
for all b ∈ OutGp(x) do - 9:
if not Abs(x) then return false else - 10:
return true -
- 11:
function Reduce⋆(x):= - 12:
- 13:
- 14:
while do - 15:
x ← Pop - 16:
if then continue else - 17:
if not Abs(x) or not Clear(x) then return false - 18:
InG⋆(x) - 19:
if then - 20:
OutG⋆(x) - 21:
for all do: if not Expandre(y) then return false - 22:
return true - 23:
return true -
- 24:
function Reducep(x) override := - 25:
- 26:
- 27:
while do - 28:
Pop(toremove) - 29:
if then continue else - 30:
if not Abs(x) or not Clear(x) then return false - 31:
OutGp(x) - 32:
- 33:
return true -
- 34:
function Expandre(x):= - 35:
- 36:
- 37:
while do - 38:
Pop(toremove) - 39:
if then continue - 40:
- 41:
if not Ex(x) then returnfalse else - 42:
for all InGre(x) do: - 43:
for all InGns(x) do: if not Abs(u) or not Clear(u) return false - 44:
for all OutGre(x) do - 45:
if () then - 46:
|
4.2. Specification Loading as Graphs
Algorithm 1 shows the process of loading and indexing the clauses from in primary memory.
We add Absence and Exists in map F; at this stage, the specification is deemed inconsistent (returning ⊥) if a given activity label a is required to both appear and be absent from each trace.
Binary clauses are loaded as edges of a graph where . Clauses being the conjunction of other clauses are then rewritten into their constituents; is rewritten into , to be stored in an edge for , and , to be stored in an edge for . For binary clauses entailing the universal truth ⊤ when both arguments are associated with the same activity label (e.g., Response), we avoid inserting this clause as an edge. For other clauses (e.g., AltResponse, L. 26), this same situation might be rewritten as the absence of a specific activity label, which, if leading to an inconsistency, also immediately ensures the return of an empty specification. Conversely, a Choice having both arguments being the same boils down to an Exists, which is also added in place of Choice (L. 35), while we might never have an ExclChoice where both arguments are the same (L. 38). For clauses being symmetric (e.g., Choice), we avoid duplicated entries by preferring only one of the two equivalent writings (e.g., over for , L. 36).
4.3. Applying Equational Rewriting
Equational rewriting for rules in
Figure 1 is run as follows: we consider each graph in order of appearance in
Section 3.2, and we iterate over its edges. For each of these, we detect their match with one of the cases appearing in the first binary clause
on the left-hand side of the formula, and we look up for the occurrence of any clause appearing in the same hand-side.
If the condition described by the left-hand side is then reflected by the specification represented by edges for graphs and F, we determine the rewriting strategy depending on the definition of the right-hand side. If the latter is ⊥, we immediately return it and detect an unsatisfiable specification. Also, we remove any edge from if does not appear on the right-hand side of the formula, and we add any edge in not appearing on the left-hand side. If an (or ) appears only on the right-hand side, we add it by invoking Ex() (or ), while immediately returning an empty specification if an inconsistency is detected while doing so. These methods are also changed according to the interdependencies across templates: e.g., the generation of new Exists(x) for RespExistence rules triggers Expandre(x) instead, and the Absence(x) for NotCoExistence invokes Reducech(x) which, in turn, will also call for Expandre(x) as per Algorithm 2; Absence(x) for RespExistence will call for Reducere(x). Similar considerations can be provided for other templates and rules. This process does not clear clauses, as we at least fill in F, from which we also return Exists or Absence for .
After applying the rules on a single graph , we then iterate over all the activities x required to be absent by the specification (), for which we run all the Reduce⋆ methods and Clear, through which we propagate the effect of requiring the absence of a specific activity label to all the clauses in the specification. If, while doing so, any inconsistency is detected by returning a false, we immediately return ⊥ (see Lemma A5).
4.4. Applying Short-Circuit Rewriting
This further algorithmic step is run after running the AltPrecedence rules and before running the RespExistence ones, thus potentially reducing the number of clauses to be considered due to the absence of a specific activity label.
We prefer to detect the existence of a circuit
of length
through a DFS visit of the graph with back-edge detection [
25]. Once we detect a circuit, we generate
Absence(
) clauses for each node
in it while removing such nodes from the graph. The latter operation is efficiently computed by creating a view over such a graph through an absence set
R, containing all nodes in the removed circuit. Then, for each graph traversal, we avoid starting the visit from nodes in
R, and we avoid traversing edges leading to nodes in
R. This avoids extremely costly graph restructuring operations. As by construction we cannot have a single non-connected node as each clause is represented by one single edge, if at the end of this reduction process we obtain nodes with zero degrees, such nodes were previously connected to nodes belonging to cycles and that were therefore also part of cycles: those also constitute
Absence clauses.
For all the novel clauses being inserted in the specification in the place of the detected temporal short-circuits, we also run all the available Reduce⋆(x) methods as well as Clear(x), thus ensuring a cascading effect removing the remaining clauses that will never be activated while keeping searching for inconsistencies via subroutine calls.
5. A PolyTime SAT-Solver for DECLAREd
This section is mainly to prove that satisfiability in DECLAREd can be carried out in polytime over the size of the original specification ; this strengthens the previous informal results over conformance checking provided over KnoBAB over such a fragment. We twin this result with the overall algorithmic correctness.
Theorem 1. The Reducer specification rewriting process is a decidable SAT-Solver for DECLAREd running in Poly-time.
Proof. The main lemmas supporting this proof are reported in the appendix. First, we need to prove that the previous section describes an always-terminating computation: given Lemmas A6–A8 and Corollary A4, we have that each previous subsection in
Section 4 describes a
PolyTime procedure. Trivially, by never inventing new activity labels, we guarantee the fragment to be decidable. We express the set of all the declarative clauses appearing within a specification and associated to the same pattern as a single graph, where we correspond to each activity labels a node, and where each declarative clause is expressed as an edge describing that the occurrence of an activity label within a trace (edge’s source) requires the presence of another one (edge’s target); any cycle appearing from such graphs will then represent a temporal short-circuit requiring for the absence of the nodes appearing in the cycle; as detecting a cycle does not require a complete enumeration of all possible cycles within the graph [
26], we show this detection can be computed in
PolyTime (Corollary A4). The continuous application of the rewriting rules leading to explicit requirements concerning the absence of a specific activity label is then propagated across graphs by removing the edges connecting such absent activity labels (Lemma A8). Contextually, we keep track of the Absence and Exists clauses associated to each activity label a through a map
F, thus including the ones generated via the application of the rewriting rules and the propagation of the outcome of the short-circuit rewriting operations. Through this, we can immediately detect the inconsistency of the model if
stores evidence for both
and
(Lemma A6). Last, we detect inconsistency in polynomial time from the application of the rules from
Figure 1 (Lemma A8) and at loading time (Lemma A7). As the composition of each single non-mutually-recursive sub-routine being the constitutive building blocks of the proposed algorithm terminates and leads to a
PolyTime decision function, the overall Reducer algorithm terminates in
PolyTime.
Last, we discuss the correctness of the resulting procedure. If in input were a tautology, all the clauses in the original specification would have been cancelled out as they would have trivially held, thus providing no further declarative clause to be returned (Lemma A4). If, on the other hand, any inconsistency was detected, the computation would have stopped before returning the reduced specification, thus ignoring all the remaining rewriting steps (Lemma A5). If neither of the previous cases holds, we have then by exclusion a satisfiable specification which is also rewritten into an equivalent specification under the temporal non-simultaneity axiom (Axiom 1). □
6. Empirical Evaluation
We determine a set of activity labels
from the Cybersecurity dataset [
18] and by creating 8 distinct subsets
of size
such that
for each
. We then consider each
as a set of vertices for which we instantiate a complete graph, a cyclic graph representing a chain, and a circulant graph
. Given each of these graphs
g, we then generate a specification
for each of these
by interpreting each edge
in the generated graph as a declarative clause:
c = ChainResponse:
c = Precedence:
c = Response:
c = RespExistence + Exists:
c = RespExistence + ExclChoice + Exists: ,
For the last two cases, we also add a clause for . Given the same and u, we also generate two other specifications where clauses are instead generated for each activity label :
c = (Chain + Alt)Response: ,
c = ChainResponseAX: .
We then expect that, if any of the aforementioned verified temporal artificial intelligence tasks provide no LTLf or Declarative rule rewriting as per this paper, running any verified temporal artificial intelligence task over a being generated from will take more time than running it over a where , which in turn will take more time than running a specification generated over . This last consideration also includes the aforementioned rewriting task in its worst-case scenario. As we are expecting that, for each c, each of these for any of such graphs g will be then always rewritten into the same specification , we are expecting to have similar running times for each rewritten specification, as we expect the running time in the latter to be dependant on the number of atoms/vertices and not on the number of clauses as the former.
Each generated specification is then fed to our rewriting algorithm, which returns the specification in the LTL
f representation required by Lydia and AALTAF and the declarative specification for KnoBAB. We discard parsing and query plan generation times for each solution: running times for Lydia only considered the time required for generating the DFA from the LTL
f formula as per their internal main-memory representation. For the formal verification task run in KnoBAB as a relational database query, we consider a sample of 9 traces from the original log over which we run the generated specifications. To alleviate potential out-of-memory issues, we test the specifications in batches of 10 at a time, thus sacrificing greater query plan minimization with the certainty of completing the computation without out-of-memory errors. On the other hand, the two aforementioned tools do not require a log to work, for which it is sufficient to have a specification. The dataset for specifications and logs is available online (Accessed on 24 March 2024:
https://osf.io/fyb4j/).
We present a condensed version of the benchmarks, while
Appendix E gives more extensive plots.
6.1. Rule Rewriting without Temporal Non-Simultaneity
We now consider all the resulting specifications being generated except Response and ChainResponseAX, which are discussed in the next subsection as they assume the temporal non-simultaneity axiom. The ones discussed here are a mere application of temporal short-circuit rewriting. Therefore, this section aims to remark on our result’s generality, which can be shown even without assuming Axiom 1.
Each plot in
Figure 2 is grouped by
c, and the black solid line refers to the time required for the solver to generate
from
in milliseconds. Missing data points refer to data not being collected as the solutions went out of primary memory. For both Lydia and AALTAF, we consider running those over both the non-rewritten specification
as well as over the rewritten one
(LYDIA(R) and AALTAF(R) in
Figure 2). In its worst-case scenario, Reducer has a running time comparable to AALTAF over the non-reduced specification, while, in the best-case scenario, it has a running time inferior or comparable to AALTAF over the rewritten specification. This ensures that running our solver as a pre-processing mechanism can benefit existing verified temporal artificial intelligence algorithms.
Given these experiments, such tools did not support our suggested rewriting rules. Otherwise, the tasks’ running time on the original specification
would have been comparable to the one for
plus the running time for Reducer. Since experimental evidence suggests that the running time for
is always greater than the one for
, we have thus empirically demonstrated both the novelty and necessity of these rewriting rules in the aforementioned tools.
Figure 3 shows the benchmarks for the formal verification task running on KnoBAB. This plot was separated from the rest to improve the plot’s readability. Even in this scenario, the formal verification task over the reduced specification comes, in the worst case scenario, with a running time comparable to the one over the original specification while, in the best case scenario, we have a speed-up of seven orders of magnitude, as all the tasks requiring the access to the ActivityTable are rewritten into clauses that can leverage the sole CountingTable. This also remarks that the query plan minimisation strategy cannot satisfactorily outperform any declarative specification pre-processing strategy, leading to a resulting reduced specification, as its associated running time would otherwise have had a comparable running time.
6.2. Rule Rewriting Requiring Temporal Non-Simultaneity
We now consider rewriting rules assuming the temporal non-simultaneity axiom. For this, we then need to compare the running time for
where the axiom is grounded over the finite set of activity labels
to the one resulting from the rewriting process by
. In
Figure 4, we give running times for
for detecting any additional overheads implied by the axiom’s instantiation over the atoms in
. If both Lydia and AALTAF supported LTL
f rewriting rules as per this paper, carrying a task over
would have a comparable running time to
, while a considerable overhead for computing
if compared to
denotes that the additional rules coming from the instantiation to the axiom provide a significant computational burden rather than helping in simplifying the specification.
This set of experiments confirms all our previous observations from the previous set-up regarding comparisons between our specification rewriting strategy and the existing verified temporal artificial intelligence tasks. We observe that, in the best-case scenario, such tasks exhibit a running time for
comparable to the one for
while, in the worst-case scenario, they increase their computational gap proportionally to the increase of the number of clauses. Still, the tasks running over
are consistently outperforming the same tasks running in
while also guaranteeing to minimise the out-of-memory exceptions. In the case of AALTAF, these are then completely nullified. Similar considerations can be drawn for running formal specification tasks over the 9 traces sampled from our Cybersecurity scenario,
Figure 5 shows that running
gives speed-ups between 3 and 7 orders of magnitude by consistently exploiting the CountingTable instead of the ActivityTable if compared to the running times for the original specification
.
7. Discussion
This paper remarks the importance of the equational rewriting rules remarked within this paper holding independently from Axiom 1 as they showed to be beneficial in fastening up any verified artificial intelligence algorithm, be it related to formal synthesis, formal verification, or a SAT-solver. Among all the possible SAT-solvers, we focus on AALTAF for two main reasons: first, the authors’ benchmarks provided an almost overlapping set of declarative clauses for their experiments as the ones proposed from our fragment, while also considering a preliminary LTLf equational rewriting step before actually running the SAT-solver, thus guaranteeing to run the specification over a reduced representation. Our experiments empirically showed that AALTAF solver did not support such equational rewriting rules since, if it had otherwise supported them, execution times would have been comparable to those obtained by providing the rewritten specification directly to the algorithm.
Furthermore, this paper proposes a novel graph-based algorithm for determining whether temporal short-circuits occur via cycle detection, not requiring the enumeration of all the cycles within a graph representing all the clauses associated with the same DECLAREd template, thus ensuring its polynomiality. This contrasts with the customary ExpTime procedure involving the creation of an NFA, which has an exponential size over the number of clauses occurring in the specification. This limitation is also remarked by the current empirical evaluation of Lydia, where the algorithm went most of the time out-of-memory for models considering a large number of activity labels while exhibiting an exponential running time.
This article has demonstrated that our proposed equational rewriting leads to an effective simplification of the resulting specification, which is not limited to the deduplication of sub-expressions occurring multiple times within the same specification. If that were the case, the reduced specification on KnoBAB would have had the same running time as the non-rewritten one, as KnoBAB already extensively merges the LTLf sub-expressions occurring within the specification while ensuring to run them at most once. On the other hand, by improving KnoBAB’s running time by several orders of magnitudes, we remark the benefit of rewriting the specification by partially replacing it with a conjunction of Absence or Exists.
Last, this algorithm identifies specification inconsistencies by implicitly targeting the minimally inconsistent sets through equational rewriting. With reference to Lemma A5, this boils down to identifying either
(i)–(iii) joint requirements for the absence and presence of given activity labels
from the map
F, or
(ii) through rewriting rules in
(
Figure 1) joining the conditions in
F with non-elementary DECLARE
d clauses appearing in the specification. Either way, we quantify the model’s inconsistency through the minimally-inconsistent set metric
[
27]: given
the set of all the activity labels a making the model inconsistent as derived by the map
F, and
the rules in
triggered by the specification
as leading to an inconsistency after instantiating them with a specific activity label replacement function
, we quantify the overall model inconsistency using the aforementioned metric as
. The algorithm resulting from this simple tweaking of Reducer also proposes a more efficient inconsistency measurement tool for DECLARE
d if compared to using the general-purpose approach for the full LTL
f as presented in [
19].
8. Conclusions and Future Works
This paper showed for the first time the existence of a polytime fragment of LTLf, DECLAREd by simply circumscribing the temporal expressiveness of the language. This was possible by observing differences between LTLf and LTL and, to some extent, assuming mutually exclusive conditions across events. We, therefore, design a scalable SAT-Solver working under equational rewriting, thus rewriting a temporal specification into an equivalent and more tractable rewritten temporal specification .
Future works will analyse DECLARE
d’s time complexity by also considering first-order arithmetic conditions [
23] and, to a minor extent, we will also reflect whether the extension of the fragment with data-aware conditions as well as the counting-based Declare Templates [
2,
22] also in use in practical domains related to healthcare [
12] will also affect its polynomial time complexity.
Experiments on Lydia remarked that the latter does not support adequate rewriting for internal formula minimisation as computing
is always slower than
: no algebraic rewriting is considered, as the minimisation steps are only performed while composing the DFA and never at the LTL
f level. Running Lydia on
significantly improves the running time for temporal formal synthesis. Future works will assess whether the construction of the DFA over the alphabet
instead of
per Axiom 1, where ⌀ denotes any other atom not in
, will boost the algorithm. We will also consider using graph equi-joins in the place of product construction for conjunction of states, as the former technique already proved to be more efficient than traditional automata composition for DFA generation over Φs [
28].
Experiments on AALTAF showed it does not exploit rewriting rules as introduced in this paper: computing is also more costly than , and the computation over as generated by our solver is always faster than computing either or , thus remarking the benefit of our approach in rewriting the formula. Future works will consider generalising the rewiring rules here defined for DECLAREd, a fragment of LTLf, to be implemented in any LTLf tool considering such a rewriting step.
Last, our tool also proved beneficial as a specification preprocessing step for optimising formal verification tasks over relational databases, as computing is always faster than computing . Future work will consider defining a query plan optimisation strategy not only by computing each shared sub-expression within a given specification once, but also implementing suitable algebraic rewriting rules while supporting Axiom 1.