Real-time compliance checking

Abstract

This disclosure relates to determining compliance of a process. A processor receives a directed graph representing the process, the directed graph comprising a full execution representing a path within the process. Based on the annotation of one of the nodes having multiple possible changes, the processor branches the full execution at the one of the nodes into multiple branches, each of the multiple branches representing a continuation of the full execution for one or more of the multiple possible changes. The processor then creates a first set of mathematical expressions including constraints to represent one of the continuations, an obligation required for compliance and a domain of the variable indicative of the annotations; and executes a solver with the first set as input to create a first output indicative of a solvability of the first set. The processor then determines, based on the first output, the compliance of the process.

Description

"Real-Time Compliance Checking" Cross-Reference to Related Applications

[0001] The present application claims priority from Australian Provisional Patent Application No 2023903224 filed on 9 October 2023 and Australian Provisional Patent Application No 2023903225 filed on 9 October 2023, the contents of which are incorporated herein by reference in their entirety. Technical Field

[0002] This disclosure relates to determining compliance of a process. Background

[0003] Processes or procedures such as manufacturing, engineering and cyber security procedures can be represented by process models, which model the procedure as a sequence of events. More generally, process models are used to represent the set of possible procedures that an organisation can use to achieve a given objective, such as a production line, for example. These procedures are usually subjected to strict requirements or obligations, which can be imposed based on government regulations, target requirements, physical constraints, or other technical requirements. Examples of such requirements may include constraints on emissions, resource requirements, production efficiency, etc. Being subjected to these requirements or obligations means that the process or procedure must be in compliance with these requirements or obligations, where compliance checking techniques can be applied to an associated process model to verify whether this process satisfies some required properties. In the context of regulatory compliance checking, these properties usually refer to the regulations that an organisation must follow.

[0004] Compliance checking techniques are used to verify whether processes satisfy some required properties, such as strict requirements or obligations. Regulatorycompliance checking is typically performed during the design-time of the process model used to represent and model the process, such that a process model is guaranteed to be compliant prior to deployment. That is, each possible execution in the model complies with the strict requirements or obligations it is subject to, such that, the process model executes as expected with respect to the strict requirements or obligations during run-time of the process model.

[0005] However, proving whether a process model is compliant with some given requirements is a difficult problem, as rules and regulations that model real world and practical application require a highly detailed, data-oriented perspective to ensure compliance. As such, being able to determine compliance of a process is complex, time consuming and computationally intensive. Evaluating data requirements during design- time has its limitations due to uncertainties in run-time activity outcomes and deferred choices, which further increases the complexity and computational intensity of compliance checking.

[0006] Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each of the appended claims.

[0007] Throughout this specification the word “comprise”, or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps. Summary

[0008] According to the present disclosure, there is provided a computer- implemented method for determining compliance of a process, the method comprising:receiving a directed graph representing the process, the directed graph comprising nodes, wherein the directed graph comprises a full execution representing a path within the process; one or more of the nodes is associated with a state comprising one or more values of a variable, wherein an order of one or more of the nodes in the path determines the state; and for one or more of the nodes, the directed graph comprises an annotation representing a set of possible changes to the one or more values of the variable of a projected state upon transitioning to the associated node; based on the annotation of one of the nodes having multiple possible changes, branching the full execution at the one of the nodes into multiple branches, each of the multiple branches representing a continuation of the full execution for one or more of the multiple possible changes; creating a first set of mathematical expressions including constraints to represent one of the continuations of the full execution, an obligation required for compliance and a domain of the variable indicative of the annotations; and executing a solver with the first set as input to create a first output indicative of a solvability of the first set; and determining, based on the first output, the compliance of the process.

[0009] It is an advantage to branch the full execution into multiple branches as this enables all possibilities to be explored and compliance of the process can be accurately determined as all possibilities are considered. Furthermore, it is an advantage to create the first set of mathematical expressions as determining the compliance of the process can be performed in a similar and efficient manner.

[0010] In some embodiments, branching the full execution at the one of the nodes into multiple branches is based on two or more obligations states of the obligation being reachable from the one of the nodes as a result of the multiple possible changes, wherein each of the multiple branches represent a continuation of the full execution for one of the two or more obligation states.

[0011] In some embodiments, the method further comprises: creating a second set of mathematical expressions including constraints to represent an obligation required for compliance and the domain; executing the solver with the second set as input to create a second output indicative of a solvability of the second set; and determining, based on the second output, whether the two or more obligation states of the obligation are reachable.

[0012] In some embodiments, the two or more obligation states of the obligation are reachable when the second output comprises multiple solutions to the second set of mathematical expressions, wherein each of the two or more obligation states corresponds to one of the multiple solutions.

[0013] In some embodiments, the first and second set of mathematical expressions comprise evolution constraints indicative of compatible changes of the variable along the full execution or multiple branches.

[0014] In some embodiments, determining, based on the first output, the compliance of the process comprises determining whether the obligation state of the obligation is violated; and the obligation state of the obligation is violated when the first output comprises a solution to the first set of mathematical expressions.

[0015] In some embodiments, the solver is a constraint satisfaction problem (CSP) solver.

[0016] In some embodiments, the CSP solver is a Maintaining Arc Consistency Algorithm.

[0017] In some embodiments, the two or more obligation states are: not triggered;triggered and fulfilled; and triggered and pending.

[0018] In some embodiments, the method further comprises creating a third set of mathematical expressions including constraints to represent one of the continuations of the full execution indicative of the obligation state being not triggered, the obligation and the domain; executing the solver with the third set as input to create a third output indicative of a solvability of the third set; determining, based on the third output, whether two or more obligation states of the obligation are reachable; and upon determining that the two or more obligation states are reachable, branching the one of the multiple branches at the one of the nodes into further branches.

[0019] In some embodiments, at least two of the multiple branches have a common prefix sub-path and the method further comprises storing each of the at least two of the multiple branches in memory by storing the common prefix sub-path once.

[0020] In some embodiments, the method further comprises, upon determining that the process is out of compliance with respect to the obligation, modifying the one of the annotations to achieve compliance.

[0021] In some embodiments, the obligation is one of multiple obligations and the full execution is one of multiple full executions, wherein the method further comprises repeating, for each of the multiple obligations and multiple full executions, branching the full execution and determining compliance for each state in the full execution to determine full compliance of the process.

[0022] In some embodiments, the directed graph satisfies workflow properties.

[0023] In some embodiments, the directed graph representing the process is a Petri net.

[0024] In some embodiments, the method further comprises generating a report indicating a result of determining compliance of the process.

[0025] In some embodiments, the method comprises traversing the directed graph and repeating the steps of the method of some of the previously described embodiments or part thereof for each of the nodes.

[0026] In some embodiments, the method further comprises terminating repeating the steps of the method of some of the previously described embodiments or part thereof for each of the nodes upon determining that the obligation state of the obligation is violated.

[0027] According to the present disclosure, there is provided software that, when executed by a computer, causes the computer to perform the method of any one of the preceding claims.

[0028] According to the present disclosure, there is provided a computer system for determining compliance of a process, the computer system comprising: a processor configured to: receive a directed graph representing the process, the directed graph comprising nodes, wherein the directed graph comprises a full execution representing a path within the process; one or more of the nodes is associated with a state comprising one or more values of a variable, wherein an order of one or more of the nodes in the path determines the state; and for one or more of the nodes, the directed graph comprises an annotation representing a set of possible changes to the one or more values of the variable of a projected state upon transitioning to the associated node;based on the annotation of one of the nodes having multiple possible changes, branch the full execution at the one of the nodes into multiple branches, each of the multiple branches representing a continuation of the full execution for one or more of the multiple possible changes; create a first set of mathematical expressions including constraints to represent one of the continuations of the full execution, an obligation required for compliance and a domain of the variable indicative of the annotations; and execute a solver with the first set as input to create a first output indicative of a solvability of the first set; and determine, based on the first output, the compliance of the process.

[0029] Optional features provided in relation to the method, equally apply as optional features to the software and the system. Brief Description of Drawings

[0030] An example will be described with reference to the following drawings:

[0031] Fig.1 illustrates a system for determining compliance of a process.

[0032] Fig.2 illustrates a method for determining compliance of a process.

[0033] Fig.3 illustrates an example direct graph represented by a Petri net, where the process is the production process of a brewery.

[0034] Fig.4a illustrates the life cycle of an achievement obligation.

[0035] Fig.4b illustrates the life cycle of a maintenance obligation.

[0036] Fig.5 illustrates a high-level overview of a preferred embodiment of the disclosed method, which verifies full compliance of a process model with data.

[0037] Fig.6 illustrates a flow diagram of the example embodiment of the disclosed method.

[0038] Fig.7a shows Algorithm 1, which is the disclosed method represented by an algorithm shown as pseudocode.

[0039] Fig.7b shows pseudocode of Algorithm 2, which implements the evaluation step of an execution-obligation combination.

[0040] Fig.7c shows pseudocode of Algorithm 3, which shows the conditional splitting in the branching.

[0041] Fig.7d shows pseudocode of Algorithm 4, which shows the trigger splitting in the branching.

[0042] Fig.7e shows pseudocode of Algorithm 5, which shows the fulfilment splitting in the branching.

[0043] Fig.7f shows pseudocode of Algorithm 6, which shows the verification function.

[0044] Fig.7g shows pseudocode of Algorithm 7, which maintains the symbolic description structure.

[0045] Fig.8 illustrates a graphical example of an elementary sequence.

[0046] Fig.9 illustrates a graphical example of a XOR modelling construct.

[0047] Fig.10a illustrates a directed graph in Example 1.

[0048] Fig.10b illustrates a branching structure of the directed graph of Fig.10a in Example 1.

[0049] Fig.10c illustrates a further branching structure of the branching structure of Fig.10b in Example 1.

[0050] Fig.11a illustrates a directed graph in Example 2.

[0051] Fig.11b illustrates a branching structure of the directed graph of Fig.11a in Example 2.

[0052] Fig.11c illustrates the branching structure of Fig.11b with a further state and labelling changes in Example 2.

[0053] Fig.12a illustrates a directed graph in Example 3.

[0054] Fig.12b illustrates a branching structure of the directed graph of Fig.12a in Example 3.

[0055] Fig.12c illustrates the branching structure of Fig.12b with a further state and labelling changes in Example 3.

[0056] Fig.13a illustrates a directed graph in Example 4.

[0057] Fig.13b illustrates the not triggered branch of the initial branching of the directed graph in Fig.13a in Example 4.

[0058] Fig.14a illustrates a directed graph in Example 5.

[0059] Fig.14b illustrates the triggered branch of the initial branching of the directed graph in Fig.14a in Example 5.

[0060] Fig.15a illustrates a directed graph in Example 6.

[0061] Fig.15b illustrates a branching structure of the directed graph of Fig.15a in Example 6.

[0062] Fig.16 shows Table 1, which presents the performance overview of the experiments.

[0063] Fig.17 shows Table 2, which presents the performance overview of the experiments in comparison to other methodologies. Description of Embodiments

[0064] This disclosure provides a method and system for verifying full compliance of a process model which represents a process, by annotating each activity in the process model with an expected numerical domain for each of its affected variables and subsequently transforming the requirements into a succession of mathematical expressions and using a solver with these mathematical expressions as input to determine compliance of the process. In essence, the complexity of determining compliance of a process is represented in a manner that is easy to implement and efficient to solve, as the mathematical expressions representing the compliance of the process can be formulated in such a way that known solvers can be used, which are optimised to solve such formulated mathematical expressions.

[0065] Enabling annotations to assume numerical values provides a higher expressivity compared to using Boolean values, for example. Furthermore, the method supports a degree of uncertainty, by verifying compliance for the entire domain of each annotation across an execution, ensuring compliance of the process if at run-time each annotation is within the respective domain. In doing so, the disclosed method provides a significant increase in expressivity, as process models can be designed with uncertainty in the outcomes of each activity and the overall compliance of the model can still be guaranteed.

[0066] While the annotations provide more robustness and expressivity in the representation of the process, the annotations introduce possibilities where the process model could comply with an obligation during once instance and could violate the obligation in another instance. Hence, the annotations introduce the possibility of theprocess model proceeding along one of multiple paths during run-time. Therefore, to ensure that the process model is compliant with respect to the obligation for all instances, each possibility based on the annotations needs to be accounted for during the compliance check to verify whether the process is fully complaint. As such, given a full execution of the process model representing a path within the process, the full execution is branched into each possibility, thereby representing a tree structure. Each of these branched paths that result from branching the full execution can be checked for compliance to determine if there is a possibility that a non- compliant state in the process is reachable. In some scenarios, a branch may trigger the in force instance of an obligation and hence, this branch is checked to determine whether there is a possibility that the obligation can be violated, which would lead to non-compliance of the process. Some branch may never trigger the in force instance of the obligation and hence, these branches will always be in compliance with respect to that obligation. These possibilities are accounted for in the disclosed method by including the additional constraints indicative of the respective branches into the solvable mathematical expressions when determining compliance of the process.

[0067] Fig.1 illustrates an example system 100 for determining compliance of a process. Fig.1 is one example of a configuration of system 100. However, system 100 is not strictly limited to this configuration and this may be one possible embodiment of system 100. System 100 comprises a device 101, which may be computer or similar device. Device 101 comprises a processor 102 connected to a program memory 103 and a data memory 104. Processor 102 receives data through all these interfaces, which includes memory access of volatile memory, such as cache or RAM, or non-volatile memory, such as an optical disk drive, hard disk drive, storage server or cloud storage. The program memory 103 is a non-transitory computer readable medium, such as a hard drive, a solid state disk or CD-ROM.

[0068] Software, that is, an executable program stored on program memory 103 causes processor 102 to perform methods for determining compliance of a process. For example, once executed, the software causes processor 102 to receive a directed graphrepresenting the process, branch a full execution at the one of the nodes into multiple branches, create a first set of mathematical expressions, execute a solver with the first set as input, and determine the compliance of the process.

[0069] The data memory 104 stores the process in the form of a directed graph and retrieve the directed graph for later use. The directed graph representing the process model may be stored on the data memory 104 as an XML file or a similar / equivalent file format. The directed graph comprises nodes indicative of states and transitions, which may be specified in the XML file. Further, the directed graph may comprise annotations, representing sets of expected values from executing the transition, which may be specified in the XML file. Even further, sequences of the transition may define executions which represent paths within the process, which may be specified in the XML file. The value of the variables determined during the execution of the process may also be stored of data memory 104.

[0070] It is to be understood that any receiving step may be preceded by processor 102 determining or computing the data that is later received. For example, processor 102 may then store a directed graph representing a process on data memory 104, such as on RAM or a processor register. Processor 102 then requests the data from the data memory 104, such as by providing a read signal together with a memory address. The data memory 104 provides the data as a voltage signal on a physical bit line and processor 102 receives the directed graph representing the process model via a memory interface.

[0071] Device 101 may further comprise a communication port 105, enabling the device 101 to establish a communication with a server 106. In some examples, communication port 105 may be a wireless transmitter and / or receiver, that is configured to send and receive data, such as a directed graph representing a process model, with the server 106. Similar to device 101, server 106 may comprise a processor, data memory, program memory, and one or more communication ports. In this sense, server 106 may have similar functionally to device 101, and may be configured to perform similar methods and / or processes to that of device 101.

[0072] While only one device 101 is depicted in Fig.1, there may be a network of many devices that may communicate with the server 106. The network of devices may also communicate directly with one another via the Internet, any other means of wireless communication or wired connections.

[0073] Server 106 may retrieve and store data such as a directed graph representing a process. Additionally, the server 106 may then communicate this data back to device 101. The directed graph may be received from a source external to system 100, such as another system located remotely to system 100, which may be in communication with the server 106. The remote system may be located within the same facility as system 100 or may be completely remote from system 100. The directed graph representing the process model may be stored on the server 106 as an XML file or a similar / equivalent file format.

[0074] Software may provide a user interface presented to the user on device 101. The user interface is configured to accept input (via buttons or text fields etc.) from the user, via a touch screen or a device attached to device 101 such as a keyboard or computer mouse. These devices may also include a touchpad, an externally connected touchscreen, a joystick, a button, and a dial. In an example, device 101 may display multiple directed graphs each representing a different process, and the user may choose one of the multiple processes to perform the disclosed method. The user may choose one of the multiple processes by interacting with the touch screen or inputting the selection with a keyboard or computer mouse.

[0075] Processor 102 may receive or send data, such as a directed graph representing a process, from data memory 104 as well as from the communication port 105. In one example, processor 102 sends the directed graph from the device 101 to server 106 via communications port 108, such as by using a Wi-Fi network according to IEEE 802.11. The Wi-Fi network may be a decentralised ad-hoc network, such that no dedicated management infrastructure, such as a router, is required or a centralised network with a router or access point managing the network. System 100 may further be implementedwithin a cloud computing environment, such as a managed group of interconnected servers hosting a dynamic number of virtual machines.

[0076] Although communication port 105 is shown as single entity, it is to be understood that any kind of data port may be used to receive data, such as a network connection, a memory interface, a pin of the chip package of processor 102, or logical ports, such as IP sockets or parameters of functions stored on program memory 103 and executed by processor 102. The parameters of functions may be stored on data memory 104 and may be handled by-value or by-reference, that is, as a pointer, in the source code.

[0077] While not shown in Fig.1, device 101 may be a monitoring system which connects to a device being monitored, such as a robotic manufacturing arms during a manufacturing process, for example. As such, device 101 may comprise or connect to multiple sensors, such as inertial measurement units (IMU), to monitor the operation of the device being monitored. Processor 102 may receive measurements from such sensors and compare these measurements to the received directed graph representing a manufacturing process. The disclosed method may be used to determine whether a process (which may represent the operation of the robotic manufacturing arm, for example) is compliant with certain requirements (which may be indicative of physical constraints of the robotic manufacturing arm, for example). As such, the disclosed method enables a process to be designed to ensure the operation of the robotic manufacturing arm will operate as intended, once deployed.

[0078] Fig.2 illustrates a method 200 for determining compliance of a process. Fig.2 is to be understood as a blueprint for the software program and may be implemented step-by-step, such that each step in Fig.2 is represented by a function in a programming language, such as C++ or Java. The resulting source code is then compiled and stored as computer-executable instructions on program memory 103, which causes processor 102 to perform method 200. Method 200 will now be explained with specific mathematical detail about process models, obligations and compliance.Preliminaries

[0079] In method 200, processor 102 receives 201 a directed graph representing the process. The directed graph comprises nodes where the nodes may be indicative of states within the process, conditions within the process and / or transitions within the process. Processor 102 may receive 201 the directed graph from data memory 104 or server 106 in the form of an XML file, for example. The process may be a procedure or operation such as, but not limited to, a manufacturing process, an engineering process, a cyber-security process. The directed graph may be a direct acyclic graph or a directed bipartite graph. Preferably, the directed graph is a Petri net.

[0080] Process models are used to describe processes such as operations, procedures, and behaviours. Petri nets provide a convenient way to rigorously describe and analyse these process models. Fig.3 illustrates an example Petri net 300 representing the production process of a brewery. Petri nets are directed bipartite graphs with two types of nodes: places 301 (graphically denoted by circles) which represent states (such as conditions or points within the process) and transitions 302 (graphically denoted by rectangles). Transitions represent actions or events, while places determine which transition can be executed. States may be considered as places with the values of the variables during execution of the process. Nodes of a Petri net are connected via directed edges called arcs 303.

[0081] For explanatory purposes, this disclosure uses Petri nets, specifically structured acyclic Petri nets to describe the possible executions of a model. However, other directed graph comprising nodes can be used. For example, the directed graph may simply comprise nodes indicative of states and hence, may not comprises nodes indicative of transitions between states.

[0082] Definition 1 [Petri net] A Petri net P is a tuple(P , T , A , ^ ), where: - P is a finite set of places, - T is a finite set of transitions, such that P ^ T = ^ , -A ^ ( P ^ T ) ^ ( T ^ P )is a set of arcs, and- ^ :P ^ T → L is a labelling function.

[0083] Each place of a Petri net can contain one or more tokens, and a net marking ^ of a Petri net P = ( P , T , A , ^ ) is a function that associates places with numbers, i.e.,^:P → N 0. A marked net is a tupleP = ( P , T , A , ^ , ^ 0 ), where(P , T , A , ^ )is a Petri net and^ 0is the initial marking. The pre-set ofy, denoted by• y, is the set of all input nodes of y : •y ={ x ^P ^ T | ( x , y ) ^ A } . The post-set of y , denoted by y • , is the set of all output nodes of y : y• ={ x ^P ^ T | ( y , x ) ^ A } . Given a net marking ^ , transitiont ^ Tis said to be enabled if ^p ^• t : ^ ( p ) > 0. If transition t is enabled, t t can fire (denoted by ^→ ^'), which leads to a new marking ^'such that ^ p ^• t ,^'( p ) = ^ ( p ) − 1and^ p ^ t •,^'( p ) = ^ ( p ) + 1. A Petri net is strongly connected if and only if (iff), for every pair of nodes x and y , there is a directed path leading from x to y .

[0084] In some embodiments, the process is a workflow process and the directed graph representing the process comprises one start node and one end node. As such, the directed graph may be a workflow Petri net or simply a workflow net (WF-net), such that it satisfies the workflow properties (given in Definition 2). While the process does not need to be a workflow process, workflow processes conveniently describe operations such as manufacturing procedures. Therefore, for simplicity and explanatory purposes, the remainder of this disclosure is directed towards the directed graph being a WF-net.

[0085] Definition 2 [WF-net] A marked net P = ( P , T , A , ^ , ^0) is a WF-net iff: - P has a special source place i , such that •i = ^ and^p ^P \ i,• p ^ ^. - P has a special sink place o , such that o• = ^ and^p ^P \ o,p• ^ ^. - if a transition twis added to P such that= o and tw• = i , then P is strongly connected.

[0086] A WF-net is said to be sound when it is bounded, live, deadlock-free and properly completed. In other words, the WF-nets are well-behaved. In this disclosure, the WF-nets are assumed to be sound.

[0087] Execution of transitions in a WF-net affect variable values and, as such, the global data state. Outcome expressions are used to specify how variables are affected by the execution of a transition as described formally as follows:

[0088] Definition 3 [Outcomes Expression] An outcome expression E is constructed using the following grammarv :op{domain}, where: - v is the variable affected. -op ^ { + , − , ^ , ^ ,=}is the operation to be applied tov. -domainis a set of possible values for the outcome {...}, one of which is applied to v through op when the transition is executed.

[0089] Given an outcome expression v :op{domain} and x ^ domain : v = x , if op equals “ = ”, v = v op x , otherwise.

[0090] For one or more of the nodes in the directed graph, the directed graph comprises an annotation representing the expected or possible changes to the set of one or more values of a variable of a projected state upon transitioning to the associated node. The projected state being a future state. For example, the directed graph may contain 5 nodes (a start and an end note, and 3 intermediate nodes), where each of the 3 intermediate nodes has an associated annotation that describes the expect values of a variable associated with that node. When considering the directed graph as a Petri net, the disclosed method may use annotations to describe the effects of executing the transitions of the directed graph.

[0091] When considering the directed graph as a Petri net and with reference to Fig. 3, for each one of the transitions 302, the directed graph 300 may comprise an annotation 304 representing an expected or possible set of one or more values of avariable resulting from the respective transition 302. Hence, when the directed graph is a Petri net, only the nodes corresponding to transitions have annotations. The values of an annotation 304 may be numerical values or non-numerical values, such as Boolean values, for example. Moreover, an annotation 304 may be an infinite set of numbers specified by a range, or an annotation 304 may be a finite set of values. The associated set of possible outcomes (expected values) represent a degree of uncertainty in the execution of a process model. This introduces more robustness into the process model and enables the execution of the process model to be more resilient to variations in the outcome of the transitions 302.

[0092] Specifying the outcomes of executing a transition allows to determine the execution’s state of a WF-net, where the execution’s state is represented by a set of variables and their associated values. The effects of executing transitions in a WF-net are represented using annotations by connecting outcome expressions to transitions, resulting in an annotated WF-net. Fig.3 shows an annotated WF-net as each transition 302 t1, t2,..., t11has an annotation 304 representing the expected set of values for variables (t , w , b or c ) upon executing (firing) the respective transition 302. An annotated WF-net is defined formally in Definition 4.

[0093] Definition 4 [Annotated WF-net] An annotated WF-Net is a tuple P = (P , T , A , ^ , ^0, ^ ) , where ^ is the annotation function T→ 2Eassigning the outcomes expressions set E to each transitiont ^T.

[0094] Defining the outcomes of executing a transition through its annotations also enables processor 102 to determine to which variables the transition has access to. It is assumed that transitions always have read access to any variable, where annotations define the specific write access to a particular variable.

[0095] The directed graph comprises a full execution representing a path within the process. In some embodiments, multiple sequences of the nodes in the directed graph define multiple executions, each one of the multiple executions representing a pathwithin the process. When corresponding the directed graph as a Petri net, multiple sequences of the transitions in the directed graph define the multiple executions. In other words, a sequence of transitions (either all transitions or a subset of all transitions) define an execution, wherein the directed graph may comprise one or more executions. For example, directed graph 300 in Fig.3 comprises two full executions. More specifically, transitions 302 t1, t2, t3, t4, t5, t6, t11correspond to one execution (i.e., one path within the process) and the transitions 302correspond to a different execution.

[0096] During the run-time instance of the process represented by the directed graph, the instance proceeds according to one of the multiple executions. Then during another run-time instance of the process, the instance may proceed according to a different execution or the same execution. The execution of an instance may be dependent on different conditions relating the value of a specific variable. It is noted that the directed graph can be considered an execution. For example, the directed graph may be a single sequence of nodes, hence the directed graph may one comprise one execution.

[0097] In the disclosed method, the directed graph comprises a full execution representing a path within the process. However, as described in the previous paragraph, the directed graph can be considered an execution, if the directed graph can only proceed along a single path. Hence, in some examples, receiving 201 the directed graph can be considered as receiving the full execution, especially if the directed graph can only proceed along a single path.

[0098] A sequence of transitions in a WF-net is an execution when the net marking resulting from one transition is in the preset of the following transition in the sequence. An execution is a full execution of a WF-net when its first transition is the source and its last the sink. However, this can be generalised by referring to a partial execution of a WF-net, starting from a given marking of the model. In this disclosure, the reference to “an execution” generally refers to a full execution, as opposed to a partial execution,which is generally a sub-execution of a full execution. An execution is defined formally in Definition 5.

[0099] Definition 5 [Execution] Given a WF-netP = ( P , T , A , ^ , ^ 0 ), an executionò of the WF-net is a sequence of transitionsstarting from the initial marking ^0and leading to the final marking ^nsuch that:enabled transitions in ^n.

[0100] In the disclosed method, one or more of the nodes is associated with a state comprising one or more values of a variable, where an order of one or more of the nodes in the path determines the state. For example, the directed graph may contain 5 nodes (a start and an end note, and 3 intermediate nodes), where each of the 3 intermediate nodes has an associated annotation that describes the expect values of a variable associated with that node, but each of the 5 nodes is associated with a state. In another example, when considering the directed graph as a Petri net, there may be 5 nodes (3 places and a transition between these places for a total of 2 transitions), where only the 3 nodes corresponding to the places are associated with a state. It is noted that the variable of a state may have a single value (for example, during the run-time of the process) or one or more values (for example, during the design-time when the process is being checked for compliance). In terms of a WF-net, state is defined formally as:

[0101] Definition 6 [State] Given a WF-net P = ( P , T , A , ^ , ^0) and one of its executions ò = (t1, , tn) , the intermediate execution states ^ti( P , ò ) are mapping functions: Vthat output a possible value of a variable v ^V after the execution of . The values are calculated by taking ^ti−1( P , ò )( v ) and applying one of the outcomes in ^ (ti)( v ) , with^t 0representing the initial value of variables in the model.

[0102] A condition, as described in Definition 7, is a Boolean function that is evaluated over the execution’s intermediate states. Conditions are used for several purposes, for instance to identify when a regulatory requirement needs to be evaluated or to determine whether an execution’s state satisfies a given requirement.

[0103] Definition 7 [Condition] A condition c is a quantifier-free first-order predicate, using variables x = x1, , xn, with xi^ X for 0 < i ^ n , the fragment of simple Boolean predicates{ ^ , ^ , ^ }, and the fragment of binary relations

[0104] As an additional constraint to determine whether a transition can be enabled, guards may be used. Guards are conditions that allow a transition to be enabled depending on the execution’s state in addition to the net marking of the WF-net. Guards may be used to determine which execution path to take within XOR branching structures of a model depending on the execution’s state holding at the time of the branching.

[0105] Definition 8 [Guard] Given an annotated WF-net P = ( P , T , A , ^ , ^0) , a guard condition gtis a condition associated to a transitiont ^ Twhich allowstto be enabled to be executed if gtis true in the immediately preceding state ( ^ (P , ò )) . If a guard conditiong tis associated to a transition t , then t is enabled iff:^ (P , ò ) ‘ g t

[0106] For example and with reference to Fig.3, directed graph 300 uses guards 305, 306 to determine which production line should be activated. The guards 305, 306 specify conditions over the amount of workers clocked in, and if this amount is greater or equal to 15, then the beer production line is activated, otherwise the cider production line is.

[0107] Requirements, either regulatory or of other nature, can be formally represented by obligations. As such, the obligations are required for compliance. In other words,obligations are indicative of compliance requirements. In some embodiments, there may be a single obligation, while in other embodiments, there may be multiple obligations. Obligations are composed of a set of elements determining how they are evaluated over the execution states of a WF-net and the required execution behaviours depending on the obligation’s type: achievement and maintenance. For example, an achievement obligation may be to produce at least 15 kegs of beer between the start and the end of the brewery production process. A maintenance obligation may be indicative of the legal requirement that the brewery cannot stay open longer than the 8-hour shift (or a technical requirement that the brewery production must shut town after 8 hours for inspection and cleaning for hygiene reasons).

[0108] Obligations (more specifically conditional obligations) are defined formally as follows:

[0109] Definition 9 [Conditional Obligation] A conditional obligation is a tupleOo^ z , ^ , ^ ,^ ^, whereo ^ { a , m }represents whether the obligation represented by the obligation is of type achievement or maintenance.^ , ^ , ^are condition elements determining: - when an execution’s state triggers an in force instance of the obligation ( ^ ), - when an execution’s state terminates an existing in force instance of the obligation ( ^ ), and - the requirement for one or more states within an in force instance to satisfy such instance of the obligation ( ^ ).

[0110] In force instances are used to identify the individual sub-sequences of the states of an execution where the evaluation of the requirement of an obligation occurs. An execution satisfies an obligation if it satisfies every in force instance of that obligation.

[0111] An obligation of type achievement represents a requirement that needs to be satisfied once while the obligation is active, in other words after the trigger of the obligation has been satisfied and before the deadline is satisfied. Differently, anobligation of type maintenance represents a requirement that needs to be satisfied at all times when the obligation is active. This is summarised graphically in Fig 4a and Fig. 4b.

[0112] When evaluating an execution, each subsequent execution state may be analysed to determine whether the execution satisfies the obligation. Initially, the obligation may be considered in its inactive state, while during the analysis of each state of the execution, the obligation’s life-cycle state can change. If the trigger holds at some state ( ^ ), the obligation’s state may becomeactive. An achievement obligation’s state may become satisfied as soon as the state verifies the requirement ( ^ ). However, when the deadline ( ^ ) is verified before that, the achievement obligation’s state may become violated instead. A maintenance obligation, on the other hand, may become violated as soon as the requirement ( ^ ) does not hold. However, when the deadline ( ^ ) is verified without observing ^ ^ , the maintenance obligation may be satisfied.

[0113] Each of the edges between the obligation’s states can be applied once per state of an execution, which means that potentially an obligation’s state can startinactiveand go through it all life-cycle and end inactive again, but would not keep looping through its life-cycle. Furthermore, the obligation’s states satisfied and violated are temporary and do not persist between states of an execution as their function is to identify whether a violation occurs. The evaluation of an execution against a conditional obligation is formally defined in Definition 10 below.

[0114] The execution’s states where an instance of an obligation is active as its active interval. In force instances are used to identify the individual sub-sequences of the states of an execution where the obligation has been triggered and not yet fulfilled. An execution complies with an obligation if no violation occurs in any of the in force instances of that obligation. It is noted that in force instance and active instance may have similar meaning and may be used interchangeably throughout this disclosure.

[0115] Definition 10 [Obligation evaluation] Given a conditional obligationO = Oo^ ^ , ^ , ^ ^ and an executionò=, , tn) , the set of active intervals ofOoverò, represented asI (O , ò ) , where every active interval inI (O , ò ) is a subsequencewhere:• the starting transition of each active interval (t i) is not included in any other active interval inI (O , ò ) , and • each active interval is either: o a violated active interval, where: ▪ ^ ti‘ ^ , ^tk‘ ^ , there exist notjsuch thatti° tj° tkand ^ tj‘ ^ when o is achievement. ▪ ^ ti‘ ^ , ^tk ‘ ^ , there exist notjsuch thatti° tj° tkand ^ tj‘ ^ when o is maintenance. o a satisfied active interval, where:there exist notjsuch thatti° tj° tkand ^ tj‘ ^ when o is achievement. ▪ ^ ti‘ ^ , ^tk‘ ^ , there exist notjsuch thatti° tj° tkand ^ tj‘ ^ when o is maintenance. o an undecided active interval, where: ▪ ^ ti‘ ^ , there exist notjsuch thatti° tj° tkand ^tj‘ ^ or ^ tj‘ ^ for o being either achievement or maintenance.

[0116] The evaluation of an obligationOover an execution ò depends on the evaluation of the active intervals inI (O , ò ) as follows: • violated if any of the active intervals is a violated active interval, • or the same evaluation as the evaluation of the last active interval in the set I (O , ò ).

[0117] In other words, an in force instance of an obligation is the part of the process where the obligation is “in force” or “active”. For example, an obligation may be “in force” at a particular point in the process and may stop being “in force” and a further point in the process. The in force instance of this achievement obligation would therefore correspond to the part of the process between these two points. Hence, the in force instance can be represented by the transitions between these two points in the process.

[0118] Evaluating an obligation over an execution may result in undecided when one of the active intervals cannot be decided into either satisfied or violated. This may occur when the last active interval reaches the last state of an execution while being still active and neither being satisfied or violated. Recognising an undecided active interval may be useful for the cases where a partial execution is being evaluated, or an execution of a model being part of a bigger choreography. In either case, the currently undecided active interval may be further evaluated in the execution’s continuation.

[0119] This disclosure is focussed on proving whether a WF-Net net is fully compliant with the required regulations, meaning that each possible execution of the net must satisfy each in force instance of each obligation representing the regulations.

[0120] Definition 11 [Full Compliance] Given a WF-net P : ( P , T , A , ^ , ^0) , the set of its possible executions^ ( P ), and a set of obligations O . P is fully compliant with respect toO, written P ‘ O , if and only if^ò ^ ^ ( P ),^O ^ O,^practical in force intervals of O ^ ^ ( P ) : the in force interval is satisfied. Method outline

[0121] Using the formal framework provided above, the annotations allow for a range of values for each transition that is on the path of such a future completion of the execution. As such, different futures can exist depending on the specific value that would be assumed during execution, requiring not only branching of the analysis withrespect to control-flow (i.e. if the process comprises multiple alternative paths) but also on the data. Therefore, existing design-time approaches for evaluating compliance that branch the analysis exclusively on control-flow may not be sufficient, as they may result in the wrong compliance outcome.

[0122] Fig.5 illustrates a high-level overview of a preferred embodiment of the disclosed method, which verifies full compliance of process model 500 with data. The evaluation (verification) cycle highlights the main procedure of the disclosed method, where the full execution of the directed graph is independently evaluated against the obligation. In some examples, the obligation is one of multiple obligations and the full execution is one of multiple full executions (hence, the directed graph comprises multiple full executions). In this case, every full execution of the directed graph is independently evaluated against each possible instance of each obligation. Each combination (obligation and full execution) is subsequently evaluated by the evaluation cycle.

[0123] In some examples, processor 102 may generate a report 501 indicating a result of determining compliance of the process after performing method 200. In other examples, if processor 102 determines that the process is out of compliance with respect to the obligation (or one of the multiple obligations), processor 102 may raise an alert or communicate a message (such as an error message) to a user. This may prompt the user to act accordingly based on the alert. The alert may also indicate to the violation to the user so the user can address the violation accordingly.

[0124] The evaluation cycle 502 evaluates the states of an execution against the given instance of an obligation. More precisely, a solver 503 is used to evaluate conditions over the execution’s states. Because of the degree of uncertainty in the outcomes as a result of the annotations, these states represent a set of possible values for each variable at a given point in the execution. As discussed previously in this disclosure, the consequence of these multiple possible interpretations is that a condition (i.e. trigger / fulfilment of an obligation) can be satisfied for a subset of these possible values,which means that the evaluation cycle 502 needs to evaluate both cases. As a result, the evaluation cycle 502 evaluation resembles a tree structure.

[0125] In other words and with reference to Fig.2, after receiving 201 the directed graph representing the process, based on the annotation of one of the nodes having multiple possible changes, processor 102 branches 202 the full execution at the one of the nodes into multiple branches. Each of the multiple branches represents a continuation of the full execution for one or more of the multiple possible changes. For example, processor 102 may branch 202 the full execution for each possible scenario provided by the respective annotations. In an example, an annotation for variable x may be x+ [0,1,2] , for which the value of 0, 1 or 2 is added to value of x . Processor 102 may branch for each of these possibilities and hence, processor 102 would branch the full execution into three branches.

[0126] In other examples, processor 102 may optimise this branching 202 based on the obligation states (i.e., not triggered, trigger and pending, or triggered and fulfilled). As a result, the evaluation cycle 502 evaluation resembles a tree structure, where branching occurs in states where a condition can be both satisfied and not satisfied and future execution states are assessed independently depending on whether the obligation is in or out of force.

[0127] More specifically, processor 102 may branch 202 the full execution at the one of the nodes into multiple branches based on two or more obligations states of the obligation being reachable from the one of the nodes as a result of the multiple possible changes. For this case, each of the multiple branches represent a continuation of the full execution for one of the two or more obligation states. For example, if it is possible for an obligation to be trigger and not triggered when transitioning to a node, processor 102 may branch the full execution at this node into two branches: one branch corresponding to triggering the obligation and one branch corresponding to not triggering the obligation.

[0128] Processor 102 may then create 203 a first set of mathematical expressions including constraints to represent one of the continuations of the full execution, an obligation required for compliance and a domain of the variable indicative of the annotations. For example, processor 102 may determine whether a non-compliant state along a branch of the full execution is reachable by creating 203 the first set of mathematical expressions which include constraints indicative of the branch and the requirement condition of the obligation.

[0129] It is noted that an annotation may only have one possible change to the one or more values of the variable and hence, processor 102 may not branch the full execution as the branching is based on the annotation of one of the nodes having multiple possible changes. However, in this situation, processor 102 would still create 203 a first set of mathematical expressions in order to determine compliance of the process. As such, the continuation, for which the first set of mathematical expressions is indicative of, may simply be a continuation of the full execution itself, rather than indicative of a branch.

[0130] Processor 102 then executes 204 a solver with the first set as input to create a first output indicative of a solvability of the first set. For example, the solver may determine whether any values of the variables are possible given the constraints, such as the branching constraint and requirement condition of the obligation, and the domain of the variable indicative of the annotations. In other words, the solver may not necessarily find a solution to the first set of mathematical expressions, where the solution corresponds to a value for each variable that satisfies the first set of mathematical expressions. Rather, the solver may simply provide an indication that a solution is possible (or not possible). For some solvers, this provides more computational efficiency, as the indication can be more easily calculated than an actual solution.

[0131] Processor 102 then determines 205, based on the first output of the solver, the compliance of the process. It is noted that the compliance of the process can be either: (1) the process is compliance or in compliance, or (2) the process is not complaint, or out of compliance. In some examples, processor 102 may determine, based on the firstoutput, the compliance of the process by determining whether the obligation state of the obligation is violated, where the obligation state of the obligation is violated when the first output comprises a solution to the first set of mathematical expressions.

[0132] As an example of determining compliance, the first set of mathematical expressions may represent a violation check of the obligation, such that if there is a solution to the first set of mathematical expressions (or the solver provides an indication that a solution is possible or the solution exists), then the obligation is violated and processor 102 determines that the process is not compliant or is out of compliance. However, if no solution (or indication of a solution) to the first set of mathematical expressions exists (or if provided by the solver), then this represents the situation where it is not possible to violate the obligation given the annotations and hence, processor 102 determines that the process is compliant.

[0133] In other words, when the instance of the obligation being evaluated is within an in force branch (such as a triggered branch, for example), the solver 503 is used to check its compliance by determining the possibility of the obligation’s violating condition. The analysis terminates when a violation is identified, which is sufficient to conclude that the process is not fully compliant. Otherwise, the algorithm completes all iterations in the verification cycle without identifying a violation.

[0134] In some embodiments, the existence of each branch may be determined by a solver after introducing additional constraints related to the conditions that enable each branch. As such, processor 102 may creating a second set of mathematical expressions including constraints to represent an obligation required for compliance and the domain. Processor 102 may then execute the solver with the second set as input to create a second output indicative of a solvability of the second set, and then determine, based on the second output, whether the two or more obligation states of the obligation are reachable. This solver may be the same solver applied to the first set of mathematical expressions for determining compliance of the process.

[0135] In some examples, processor 102 determines that the two or more obligation states of the obligation are reachable when the (second) output of the solver comprises multiple solutions to the second set of mathematical expressions. In this example, each of the two or more obligation states corresponds to one of the multiple solutions and processor 102 may have to executing the solver multiple times to determine the multiple solutions. Processor 102 may use the same second set of mathematical expressions to determine whether two obligation states are reachable, as the mathematical expressions would include the constraint that determines both obligation states (such as the trigger condition of the obligation, for example).

[0136] After processor 102 determines that two or more obligation states are reachable, processor 102 may then create 203 a first set of mathematical expressions including constraints to represent one of the continuations of the full execution, the obligation and a domain of the variable indicative of the annotations. In other words, after branching 202, processor 102 creates mathematical expressions to define the compliance verification along the branch where the obligation is “in force” or “active”. The mathematical expressions may include constraints indicative of the branch (i.e., the continuation) as referred to as a branching constraint.

[0137] It is noted that an annotation may only have one possible change to the one or more values of the variable and hence, processor 102 may not branch the full execution as the branching is based on the annotation of one of the nodes having multiple possible changes (or more specifically, that two or more obligation states are reachable from the one of the nodes). However, it may still be possible that the obligation state of the obligation changes. For example, each possibility resulting from the annotation may trigger the obligation and hence, processor 102 may not branch the full execution as it does not need to consider the possibility of the obligation not being triggered. In this situation, processor 102 would still create 203 a first set of mathematical expressions in order to determine compliance of the process. As such, the continuation, for which the first set of mathematical expressions is indicative of, may simply be a continuation of the full execution itself, rather than indicative of a branch.

[0138] In some examples, the first and second set of mathematical expressions comprise evolution constraints (evolution equations) indicative of compatible changes of the variable along the full execution or multiple branches. More specifically, the value of a variable in a state is indicative of the values of the variable in the previous states. Hence, when evaluating a state or projected state for compliance or branching possibility, processor 102 needs to account for the evolution of each variable and does so using evolution constraints. Processor 102 may determine the evolution constraints of a variable in a state or projected state by traversing the previous state in order and tracking how the variable updates based on the annotations.

[0139] In some examples, upon determining that the process is out of compliance with respect to the obligation (or one of multiple obligations), processor 102 may modify the one of the annotations to achieve compliance. For example, processor 102 may generate a report indicating a result of determining compliance of the process, which specifies where the violation occurred in the process. Processor 102 may receive user input, for example, indicative of a modification to one or more of the annotations in order to achieve a compliant process. This may occur several times during the design-time of the process and may involve repeating method 200, then modifying the annotations until processor 102 determines that the process is compliant by applying method 200.

[0140] It is noted in the preferred embodiment of method 200, processor 102 evaluates each of the states of an execution against the given instance of an obligation. In other words, processor 102 transverses the directed graph (or the full execution) and repeats the steps of method 200 or part thereof for each of the nodes. This ensures that each state in the full execution and each possibility given by the annotations is accounted for in the compliance checking process. Moreover, processor 102 may terminate the repetition of the steps of method 200 or part thereof for each of the nodes upon determining that the obligation state of the obligation is violated.

[0141] In more detail, given a WF-net, each possible execution of that WF-net is evaluated against each given obligation. A step in the evaluation corresponds to anexecution state and obligation’s lifecycle state. The initial step is composed by the initial state of an execution and an obligation in its initial lifecycle state (i.e. inactive). During each step, the execution state is branched into multiple enriched states, each containing some constraints from the obligation for each potential obligation’s lifecycle state. Each enriched state is formulated as a CSP and evaluated using a CSP solver, to determine the existence of the alternative next states in the lifecycle of the obligation given the current execution’s state. For each alternative obligation’s lifecycle state determined to exist by the CSP solver, the process may then be recursively repeated by including information leading to the next execution’s state, until the entire execution is parsed. As the full compliance is evaluated, when a violation state for an obligation is determined to exist in its lifecycle, the method can terminate with the not fully compliant result. This recursive exploration of the WF-net is depicted graphically in Fig.5.

[0142] The disclosed method may be thought of as evaluating a tree representing the possible executions of a process model. Each node of the tree represents a set of possible execution states, which are symbolically represented within a symbolic description structure and subsequently evaluated to determine whether any of the given requirements are violated by the possible executions of the process model. Example embodiment

[0143] An example embodiment of the disclosed method is now presented. However, it is noted that alterations and alternatives from the preferred embodiment are equally possible. Fig.6 illustrates a flow diagram of the example embodiment of the disclosed method (denoted as method 600). To simplify the explanation, the flow diagram of Fig. 6 and the compliance thereof is with respect to one obligation. However, preferably, method 600 (or parts thereof) are repeated for each of multiple obligations.

[0144] Processor 102 receives 601 a directed graph representing the process. It is noted that 601 of method 600 is similar to 201 of method 200. Similarly, the processor may comprise one or more full executions. As can be seen in Fig.6, processor 102iterates over each full execution in the process. If each of the full executions in the process are compliant, then it can be said that the process itself is compliant. In an iteration of each of the full executions, processor 102 may consider each state in the respective full execution sequentially. Hence, processor 102 may iterates over each state in the respective full execution.

[0145] Processor 102 then branches 602 the state in the iteration into multiple branches. Processor 102 may branch 602 the state into multiple branches based on the corresponding annotations of the state and one or more obligations. As shown in Fig.6, processor 102 may iterate the process over each of multiple branches of the state. Processor 102 then creates 603 a set of mathematical expressions. The set of mathematical expressions may be indicative of the existence of one of the multiple branches of the respective state. It is noted that 603 of method 600 is similar to 203 of method 200.

[0146] Processor 102 then executes 604 a solver to determine if the branch (corresponding to the mathematical expressions created in 603) exists. In other words, processor 102 may apply a solver or solving algorithm to the set of mathematical expressions to determine an output indicative of the existence of the branch. The output may be indicative of the solvability of the set of mathematical expressions. Hence, the actual solution to the set of mathematical expressions may not be relevant. Rather, the existence of the solution may be enough information to confirm the existence of the corresponding branch. If processor 102 determines that the corresponding branch exists, then the method continues. Otherwise, the method goes back to 603, where a new set of mathematical expressions in created for a different branch of the state.

[0147] Upon determining the existence of a branch, processor 102 may then execute 605 a solver to determine compliance of the branch. For example, processor 102 may create another set of mathematical expressions based on the branch (and the annotations thereof) and the obligation. This set of mathematical expressions may be indicative of a violation of the obligation. As such, the existence of a solution to this set of mathematical expressions may indicate that a violation of the obligation is possible.If processor 102 determines that the branch is compliant (e.g., no solution exists to the set of mathematical expressions indicative of the obligation and the branch) then the method continues. More specifically, processor 102 may apply 606 the next step in the execution. In other words, if processor 102 determines that the branch is compliant, then the method may return back to 602 and repeat for another branch of the state. Otherwise, processor 102 returns 607 the violation. After returning 607 the violation, method 600 may terminate as it was determined that the process is not compliant based on the violation returned at 607. Algorithm

[0148] The specific algorithm indicative of method 200 is now described. Fig.7a shows Algorithm 1, which is the disclosed method represented by an algorithm shown as pseudocode. The iteration over the possible combinations is coordinated by Algorithm 1, while the evaluation of each combination is recursively performed by Algorithm 2 shown in Fig.7b over the sequence of states of the execution. If no violations are detected for each execution-obligation combination, then the algorithm returns fully compliant.

[0149] Initialisation

[0150] For each execution-obligation pair, the algorithm initialises a symbolic description structure that is used to represent the possible values of the variables involved at a given point in time of the execution of the WF-net. The symbolic description structure contains the following elements: - S . I : A map assigning a set of possible values to each variable. This element is initialised as, which corresponds to the initial possible values of the variables at the start of an execution of the WF-net. The set of possible values of a variablevis referred- S . E : A map assigning the possible values’ evolution to each variable in the given execution. These are referred to as evolution equations and arerepresented by the series of updates associated to a variable across the annotations associated to the transitions of the execution. -S . P: A set of constraints further limiting the possible values of a variable. Although the sets of possible values provide an indicative maximal domain, not every possible combination may be achievable in the executions due to e.g. constraints describing relations between variables at a certain point of the execution (expressed in S . E ). For instance, the condition a > b at a given point of the execution constrains their values for the remainder of the execution and projection. -S . R: A constraint pair containing both the violating and fulfilment constraints to be evaluated when the obligations are in its active state. Following from Definition 10, these constraints are ^ and^for achievement, and^ ^and ^ for maintenance. When the evaluated obligation is active and the violating constraint is satisfied, then a violation is detected. On the other hand, if the fulfilment constraint is satisfied, then the obligation becomes inactive.

[0151] With this structure, the symbolic states can be represented as different paths of the execution being analysed.S . Irepresents the possible values that the variables can individually assume in a given path, while S . E records the changes for the individual possible values of the variables across such path. Keeping track of how variables evolve is necessary, as the constraints inS . Pcan refer to the values of variable at past points in time in the path, which in turn influence the effective possible values allowed for the variables among the ones specified in S . I .

[0152] Alternative paths in an execution are created and recorded in their own symbolic description structure (and subsequently analysed independently) when the possible states allow two exclusive scenarios (i.e., activating an obligation or not). In this case, the structure is split by including the alternative constraints in its two alternative versions. Finally, S . R contains a pair of constraints that are used to evaluate if a violation can occur given the possible values or when the evaluation of this constraint can terminate.

[0153] One of the contributing factors of the computational complexity of checking compliance of process models is the number of executions that a model allows. In general, due to concurrency, the number of possible executions of a model can be combinatorial with respect to the transitions composing a model. Some optimisation techniques can be used to reduce these to the relevant ones, such as for instance reducing the model by only considering the subset of transitions containing the variables relevant to the obligation being evaluated, creating subgraphs from the model based on conditions in the requirements, or reducing concurrent components to linear ones when they are guaranteed to be independent. These kind of optimisation techniques can be embedded without changing the disclosed method.

[0154] As the disclosed method may verify full compliance in some examples (full compliance being where each of multiple full executions satisfy each of multiple obligations), each obligation and their possible identifiers is evaluated in isolation, as violations must be absent from all possible obligation instances. This evaluation is performed in isolation as analysing all obligations at once would increase the branching factor of the recursive step. The disclosed method can be adapted to evaluate partial compliance by evaluating all obligations and their possible identifiers together, as in this case it is required to identify a single execution that satisfies all obligation instances.

[0155] Step

[0156] TheStepalgorithm (Algorithm 2 of Fig.7b) takes an execution and an obligation, and “steps “ through the execution to build the symbolic description structure and simultaneously evaluates whether it allows violations for the obligation being checked. This evaluation consists of identifying which paths along the obligation’s lifecycle can be taken according to the values represented by the symbolic description structure. As a symbolic description structure describes a set of possible interpretations for the variables, it is possible that multiple paths are allowed for the given set of interpretations. An interpretation is a valid assignment of values to the variables composing the execution’s state.

[0157] TheStepalgorithm starts from the symbolic description structure, as initially constructed by Algorithm 2. After this initial evaluation, the structure is updated using the annotation of the next transition of the execution and the Step algorithm is applied again over the resulting structure.

[0158] Branching Analysis

[0159] Alternative symbolic description structures are constructed during the Step algorithm, describing these different paths along the obligation’s lifecycle, and each of these alternative descriptions are then individually evaluated by different instances of the Step algorithm (representing the progression along the execution being evaluated according to the different alternative obligation’s lifecycle’s possible states.) if no violation is identified during this evaluation. These alternative paths originate from the conditions determining the obligation being evaluated, and the functions calculating these splitting execution paths are illustrated in Algorithm 3-5 (shown in Figs.7c-e, respectively).

[0160] The function ConditionalSplit in Algorithm 3 of Fig.7c evaluates which subsets of the interpretations allow different evaluations of the conditions, given a condition and a symbolic description structure. The functions TriggerSplit and Fulfilmentsplit (Algorithm 4 and 5, respectively) use ConditionalSplit to determine the possible execution paths and additionally include in the associated symbolic description structures the necessary information to keep track of the state of the obligation being evaluated.

[0161] Within the Step algorithm, the analysis of a symbolic description structure can create up to three execution paths, as shown through the following cases: 1. The obligation is initially active: In this case, two execution paths are possible: one where the obligation is fulfilled and one where it remains undecided.2. The obligation is initially inactive: In this case, two execution paths are immediately possible: one where the obligation remains inactive, and one where it becomes active. This second execution path can further split into two more execution paths exactly as for the case where the obligation was initially active, which finally leads to a total of three execution paths.

[0162] In essence, processor 102 keeps track of the obligation state of the obligation when evaluating each state in the execution. As described above, processor 102 may determine whether the two or more obligation states of the obligation are reachable, processor 102 may branch the full execution at the one of the nodes into multiple branches is based on two or more obligations states of the obligation being reachable from the one of the nodes as a result of the multiple possible changes (given by the annotations). In this case, the two or more obligation states are not triggered, triggered and fulfilled; and triggered and pending. The obligation state can also be violated, however, this obligation state does not cause processor 102 to branch the full execution.

[0163] Note that there can be at most 3 branches in one recursive step: if the obligation is already in force, there would be 1 branch for the trigger and that branch can have at most 2 branches for fulfilment. If the obligation is not in force, there can be 2 branches for the trigger, but only the trigger true branch will have the obligation in force prior to the fulfilmentSplit call, so only this branch can result in 2 branches for fulfilment. The trigger false branch will result in 1 branch for fulfilment, which results, therefore, in a maximum of 3 branches in total.

[0164] As such, in some examples, processor 102 may repeat the process of creating a set of mathematical expressions and executing a solver to determine existence of a triggered branch originating from a not triggered branch. More specifically, processor 102 may create a third set of mathematical expressions including constraints to represent one of the continuations of the full execution indicative of the obligation state being not triggered, the obligation and the domain. Processor 102 may then execute the solver with the third set as input to create a third output indicative of a solvability of the third set. Finally, processor 102 determines, based on the third output, whether two ormore obligation states of the obligation are reachable and upon determining that the two or more obligation states are reachable, processor 102 branches the one of the multiple branches at the one of the nodes into further branches.

[0165] The correctness of the approach is guaranteed (1) by each individual recursive step, which reports a violation of any in force instance of an obligation, leading immediately to a failure of the full compliance check, and (2) by the branching analysis covering all possible scenarios across an execution of the process model with respect to a specific instance of an obligation.

[0166] Solver

[0167] In essence, processor 102 formulates the problem of determining compliance and branching the full execution into several subproblems by representing these problems as sets of mathematical expressions. In more detail, the solver inputs (1) a set of constraints and (2) for each variable represented in the constraints, a finite domain of values that can be assigned to that variable. By executing the solver, processor 102 determines whether an assignment exists across every variable such that all constraints are satisfied. The brute force approach to solving this problem (backtrack search) has a worst-case time complexity ofO ( c * dn), where c is the number of constraints, d is the maximum domain size and n is the number of variables.

[0168] In some embodiments, the solver is a constraint satisfaction problem (CSP) solver. As such, the sets of mathematical expressions described herein may represent CSPs. Constraint propagation techniques (which is part of CSP solving) can offer a more efficient approach, by continuously applying local consistency to restrict the domain of unassigned variables whenever the search instantiates a variable assignment.

[0169] It is noted that many algorithms may be used at the solver. Some algorithms are typically optimised to provide solutions and hence, can offer computational efficiency to the disclosed method. For the results disclosed herein, the Maintaining Arc Consistency algorithm (specifically, the MAC-3) has been used, for simplicity ofimplementation. The order of variable assignments can also affect the solver’s speed. In the results disclosed herein, a static variable ordering was used, ensuring that all variables related to more recent constraints (as introduced during Algorithm 2) are considered before the remaining variables related to less recent constraints.

[0170] Verification

[0171] Fig.7f shows pseudocode of Algorithm 6, which verifies whether values of the variable can possibly satisfy a violation condition (violating constraint) of an obligation. In other words, Algorithm 6 shows how a CSP solver is used in the disclosed method to evaluate whether a given symbolic description structure describing the possible execution states at a determined point in time allow an interpretation that violates the obligation being evaluated if in its active state.

[0172] Updating the Symbolic Description Structure

[0173] During the execution of the Step algorithm (Algorithm 2, the symbolic description structure must be adapted to reflect the possible execution states in the different possible paths. This task is performed by the functions described in Algorithm 7 shown in Fig.7g.

[0174] More precisely, the function AddProjectionConstraint includes any constraint into the substructure that needs to be satisfied at this given point of the execution path (i.e. guards or obligation’s conditions). As these conditions must always be true, they influence the possible values of the variables following this path. The function UpdateEvolutionEquations updates the equations in the substructure that describe the relationships between the different points in time during the execution.

[0175] Computational Complexity

[0176] The worst-case complexity can be estimated with the following components: - branching: the maximum branching factor in a recursive step is b = 3- recursive steps per execution: r = ( b|ò |− 1) / ( b − 1) - csp calls: 6 per recursive step - total recursive steps:^ (P ) ^O ^ D (z ) ^ r, whereD (z )is the maximal size of the codomains of the identifier functions of the obligations inO.

[0177] The complexity of solving a set of mathematical expressions is highly related to the size of variable interpretations, particularly since the verification check to ensure that an in force instance is not violated consists of trying to find a valid interpretation that satisfies the violating condition. This potentially requires the solver to evaluate the entire search space to determine that no such interpretation exists.

[0178] It is noted that upon determining existence of a branch, processor 102 does not need to evaluate all previous states. In other words, if the full execution branches at a node into two branches, processor 102 simply continues to evaluate the states on each branch from the node where the execution branches, without needing to check previously evaluated nodes. However, the previous states and states along the branch form an execution (which may be referred to as a branching execution) for which, processor 102 stores in memory.

[0179] Processor 102 may need to store each branching execution of the full execution in memory. However, as some of the branching executions contain overlapping paths (in particular, they share the same nodes or states), then processor 102 can reduce the amount of memory required as each entire branching execution does not need to be stored in memory. More specifically, at least two of the multiple branches may have a common prefix sub-path and processor 102 may store each of the at least two of the multiple branches in memory by storing the common prefix sub-path once. This reduces computation time of the disclosed method as processor 102 can evaluate each state on the common prefix sub-path to evaluate these corresponding states for each branch. Moreover, the branches are efficiently stored in memory using the common prefix sub-path, thereby reducing the overall memory requirements of the disclosed method.

[0180] It is noted that Algorithms 1-7 shown in Figs.7a-g are shown in the preferred embodiment. Modifications can be easily made to these algorithms to represent any other embodiment of this disclosure. Examples

[0181] Example 1

[0182] Consider directed graph 1000 representing a process shown in Fig.10a, which is a Petri net with a single full execution. Also consider the following obligation: type: achievement trigger: x = 1 requirement: y ^ 1 and y ^ 2 deadline: false

[0183] This example demonstrates why branching is needed to evaluate the compliance of obligations due to the different options for each annotation. As is dictated by annotation 1021, after executingxwill be equal to 1, meaning that the obligation will be triggered, so to satisfy the obligation, the required conditiony ^ 1 and y ^ 2must be achieved before the deadline. In some examples, the deadline corresponds to the end of an execution, but this is not always the case. However, in this example, as there is no deadline, the required condition must be achieved at some point before the end of the execution. It is noted that this is different from a maintenance obligation, where after the obligation is triggered, the requirement condition in a maintenance obligation must be satisfied throughout the remainder of the process.

[0184] In initial state 1010, the value of the variables are: x= 0, y = 0. Due to the two possibilities of y after executing t1and with reference to Fig.10b, processor 102 branches the execution at node 1011 (which corresponds to transition t1) into two branches 1031, 1032 for each of the possibilities of y . As such, branch 1031 representsy = 0 after and branch 1032 represents y = 1 after With two possibilities for updating y at, the obligation can be satisfied, but it also may still be pending, depending on whether the update is +0 or +1. If the obligation is simply considered to be pending, the possible values for y after t1would be {0, 1}, then after executing t2the possible values will be {1, 2, 3}. The y = 3 value does not satisfy the obligation’s requirement, and so it would appear that the end of the execution can be reached without the obligation being achieved, which would mean that the process is out of compliance. However, this is not the case.

[0185] After branching at node 1011, processor 102 determines whether states 1033, 1034 satisfy the obligation by creating a first set of mathematical expressions and executing a solver with the first set as input. The first set of mathematical expressions would include a constraint indicative of the requirement condition of the obligation (y ^ 1 and y ^ 2) and the values of states 1033, 1034. As this is a simplify example with only one value for each of the variables in the states, it is straightforward to check whether the obligation is satisfied. However, in practical uses of the disclosed method, a solver is used to determine compliance efficiently.

[0186] Processor 102 determines that state 1033 does not satisfy the obligation asy = 0. However, as dictated by annotation 1022, upon executingt 2, the value ofywill be 1 or 2. Hence, processor 102 determines that the obligation will be satisfied upon executing t2. Processor 102 also determines that state 1033 satisfies the obligation as y = 1. In this case, there is no need for processor 102 to check the state that results from executing t2as the requirement condition of the obligation has been achieved. This reduces the computational complexity of the disclosed method as not every state needs to be checked in order to determine compliance of the process. As a result, processor 102, determines that the process, represented by the directed graph in Fig.10a, is compliant with represent to the obligation as, for all possible annotations, the execution will conclude with the obligation being achieved.

[0187] Although processor 102 can determine compliance without further traversing each branch, in some examples, processor 102 may further branch the execution based on the multiple possible values given by the annotations. For example and with reference to Fig.10c, there are two further possible states on branches 1031, 1032 as annotation 1022 associated with t2has two possible value for y , which correspond to a further branches 1061, 1062, 1063, 1064. In some examples, processor 102 may check each of these further states on further branches 1061, 1062, 1063, 1064 to determine compliance of the process.

[0188] Example 2

[0189] Consider directed graph 1100 shown in Fig.11a, with the obligation from Example 1. Directed graph 1100 in Fig.11a is similar to directed graph 1000 in Fig. 10a, however annotation 1121 associated withis changed. This example is present to illustrate optimisation of the branching, rather than simply branching for each possibility resulting from the annotations.

[0190] Similar to Example 1, the obligation will be triggered after executingt 1. However, as y can be {-1,0,1,2} after executingthere are values that satisfy the obligation (by satisfying the requirement condition:y ^ 1 and y ^ 2) and there are values that do not satisfy the obligation. Therefore, rather than branching the execution into four branches, only two branches are necessary to consider the case where the obligation is satisfied and the case where the obligation is not satisfied.

[0191] As such, processor 102 branches the full execution at node 1111 (which corresponds to transition t1) into branches 1131, 1132, where branch 1131 represents when the obligation is not satisfied and branch 1132 represents when the obligation is satisfied. To determine the existence of each of the branches 1131, 1132, processor 102 may create a second set of mathematical expressions and execute a solver with the second set as input. Processor 102 then determines the existence of the branches using the output of the solver.

[0192] For example, to determine the existence of branch 1131, processor 102 needs to determine whether any possible values of y , resulted from executing t1, will not satisfy the obligation. As such, the second set of mathematical expressions will represent this problem mathematically in a way that is efficiently solvable. In some examples, the solver may be a CSP solver and hence, the second set of mathematical expressions may represent a constraint satisfaction problem. The constraint satisfaction problem to determine the existence of branch 1131 would be to find a value of y for the constraint y ^ 1 and y ^ 2 (which corresponds to not satisfying the requirement condition of the obligation), given the possible values of y (i.e., the domain of y which is indicative of the annotation). Hence, the domain of y is {-1,0,1,2}). Therefore, if the CSP solver determines a value of y given these constraints, then branch 1131 exists. In some examples, the solver may only provide an indication of whether a value exists, rather than providing the value explicitly. Due to the simplicity of this example, it is intuitive that there are possible values which do not satisfy the obligation, namely {-1,0}.

[0193] Similarly, processor 102 may execute the solver again using the second set of mathematical expressions input to determine the existence of branch 1132. It is noted that the second set of mathematical expressions are indicative of whether the two obligation states (i.e., triggered and pending, and triggered and fulfilled) are reachable. Hence, executing the solver multiple times may provide multiple solutions to the second set of mathematical expressions, where the multiple solutions correspond to the existence branches 1131, 1132.

[0194] If the solver were a CSP solver, then the constraint satisfaction problem to determine the existence of branch 1132 would be to find a value of y for the constrainty ^ 1 and y ^ 2 (which corresponds to satisfying the requirement condition of the obligation), given the possible values of y (i.e., the domain of y which is indicative of annotation 1121). Due to the simplicity of this example, it is intuitive that there are possible values which do not satisfy the obligation, namely {1,2}.

[0195] When processor 102 creates subsequent mathematical expressions for evaluating states along a branch, the constraints indicative of the branch become part of the mathematical expressions. More specific to this example, when determining the compliance of the process by checking the states along branch 1131, processor 102 creates a first set of mathematical expressions which includes y ^ 1 and y ^ 2 as an additional constraint on the variable y and annotation 1122.

[0196] Processor 102 then determines compliance of the process by continuing along each branch 1131, 1132 and checking each state along the branches. Processor 102 checks each state for compliance by creating a first set of mathematical expressions and executing a solver with the first set as input. However, in this case, there is no need for processor 102 to further check any of the states along branch 1132 as the requirement condition of the obligation has been achieved. This reduces the computational complexity of the disclosed method as not every state needs to be checked in order to determine compliance of the process.

[0197] Processor 102 does not need to check state 1133 as it does not satisfy the obligation. However, processor 102 needs to check further states to determine if the obligation can be satisfied or not satisfied to determine compliance of the process. In particular, processor 102 will need to determine whether a non-compliant state at node 1134 is reachable, as this would correspond to the situation where the end of the process is reached without achieving the requirement of the obligation. Hence, the process would not be compliant with respect to the obligation. For illustrative purposes, it can be better to label the variables at each state with a subscript as shown in Fig.11c.

[0198] To determine compliance of the process, processor 102 creates a first set of mathematical expressions indicative of state 1161 and the obligation. Processor 102 then executes a solver with the first set as input and determine the compliance based on the output of the solver. If the solver is a CSP solver, then the first set of mathematical expressions represent a constraint satisfaction problem. In particular, the CSP solver determines whether y ^ 1 and y ^ 2 (more specifically y2^1 and y2^ 2 ) is possiblegiven y2= y1+ [1,2] , y1= [ − 1,0,1,2] and y1^1 and y1^ 2. In this example, the solver would return that a solution exists (in particular= − 1 and y2= 0 ) and hence, a non- compliance state is reachable as this state does not satisfy the obligation. Therefore, in this example, the process is not compliant with the obligation as processor 102 determines that a non-compliant state is reachable.

[0199] Example 3

[0200] Consider directed graph 1200 shown in Fig.12a, with the following obligation: type: maintenance trigger: a ^ b requirement: a − b ^ 0 deadline: false

[0201] This example is to illustrate the situation where the execution branches due to the trigger condition of an obligation. More specifically, the execution branches as two obligation states (i.e., triggered and not triggered) are reachable. In initial state 1210,a = 0 and b = 0. When assuming execution of t1, there are a number of combinations possible for the values of a and b , as given by the table below:

[0202] Out of the combinations in this table, there are 3 for which the obligation is triggered (i.e., a ^ b ) and 6 for which it is not. Rather than evaluating and storing each of these combinations (which would be intensive for larger annotation sizes), the possibilities in each branch can be represented by simply using the branching condition, as visualised in Fig.12b. For instance, the triggered branchhas its state denoted by a set of possible values foraand b , and an additional relationship that must hold between the 2 variables, as the triggering condition is assumed to be met in this branch.

[0203] As such, processor 102 branches node 1211 (which corresponds to transitiont1) into branch 1231 of Fig.12b, which represents the triggered branch, and branch 1232, which represents the non-triggered branch. Processor 102 may determine the existence of each branch by creating a second set of mathematical expressions and executing a solver with the second set as input. For example, to determine the existence of branch 1231, the second set would include the trigger condition a ^ b as a constraint and the solver would determine whether the values can possibly satisfy this condition, given annotation 1221. Similarly, to determine the existence of branch 1232, processor 102 uses the same second set as input into the solver and the solver would determine whether the values can possibly satisfy the condition a ^ b (corresponding to not triggering the obligation), given annotation 1221.

[0204] Processor 102 would then continue along branch 1232 to determine whether the obligation can be violated, noting that the obligation in this example is a maintenance obligation, which is different from the achievement obligation in Examples 1 and 2. In particular, for a maintenance obligation, once the obligation is triggered, the requirement condition must be satisfied for each subsequent state until the end of the process (or the deadline in some examples). In this example, the deadline is false and therefore, the requirement condition must be satisfied for each subsequent state until the end of the process. If a state that does not satisfy the requirement condition is reachable (i.e., a non-compliant state), then processor 102 determines that the process is not compliant with the obligation.

[0205] Continuing along the triggered branch, t2in which either 0 or 1 is added to b . The current possible values for b are therefore[0,1,2,3]. As a consequence of this update, it is possible that the relationship a ^ b no longer holds. Nevertheless, not all permutations ofa = [0,1,2]andb = [0,1,2,3]will be possible on the triggered branch. For instance,a = 1andb = 2is an invalid combination, as there is no way to reach this att 2from the possible values atthat are triggered in based on the previous table. As such, the algorithm should not be able to use these values when considering the possibilities within this state. This is accounted for by including the branching constraint a ^ b in subsequent mathematical expressions.

[0206] In order to prevent the algorithm from assessing combinations that are invalid, processor 102 cleverly identifies which combinations of the current values are possible on this branch. To avoid generating a complete mapping between previous and current values, evolution equations are used which can link conditions that have been met at previous states to the current possible values. As such, the first set of mathematical expressions may comprise evolution equations or constraints indicative of compatible changes to the variables.

[0207] In essence, processor 102 keeps track of the evolution of variables, by storing the sequence of annotations 1221, 1222 that have been applied to it. This can be seen in state 1261 shown in Fig.12c, for which the value of the variable a at this state (i.e., a2) is equal to the value of variable a at the previous state (i.e., a1) as annotation 1222 associated with t2does not affect variable a . Similarly, the value of variable b at state 1261 (i.e., b2) is equal to the value of variable b at the previous state (i.e., b1) plus either 0 or 1. It is noted that the trigger constraint also carries over to state 1261 from the previous state. In other words, each state along branch 1231 will have this trigger constraint.

[0208] Processor 102 determines compliance of the process by creating a first set of mathematical expressions, which is indicative of the evolution constraints (i.e., a2= a1and b2= b1+ [0,1] ), the trigger constraint (i.e., a1^ b1), the domain of the variables (i.e., the possible values of a1and b1given by annotation 1221) and the violation condition, which is indicative of the requirement condition of the obligation. Specifically, the violation condition would be a ^ b . Processor 102 then executes a solver with the first set as input, which determines whether the violation condition is satisfied given the previously mentioned constraints. The output of the solver could be either that the violation condition can be satisfied or that the violation condition cannot be satisfied. If the former is the output, then processor 102 determine that the process is not compliant, whereas if the output is the latter, then processor 102 determines that all states along this branch are compliant. In other words, there are no reachable non-compliant states along this branch.

[0209] It is noted that processor 102 would also need to check the states on branch 1032 as the obligation may be triggered at a later state in the branch. However, in this example, processor 102 would determine that it is not possible to trigger the obligation given the constraints on the variables. Given that branches 1231, 1232 do not contain any reachable non-compliant states, processor 102 would determine that the process is compliant with respect to the obligation.

[0210] Example 4

[0211] Consider directed graph 1300 shown in Fig.13a, with the obligation from Example 3. Directed graph 1300 in Fig.13a is similar to directed graph 1200 in Fig. 12a, however annotation 1422 associated with t2is changed. This example illustrates the situation where an obligation can be triggered on a not triggered branch, resulting in further branching of an execution.

[0212] Similar to Example 3, the execution branches at node 1311 (which corresponds to transition t1) due to two obligation states being reachable. Due to the simplicity of this example, it is intuitive that the states on branch 1331 are compliantwith respect to the obligation as only variable a is affected by t2, and hence it is not possible to satisfy the violation condition a ^ b on this branch.

[0213] However, as compared to Example 3, it is possible that the obligation is triggered on the not trigger branch 1351 later in the process. For example and with reference to Fig.13b, which shown only branch 1351, if a1= 0 and b1= 0 (which satisfies the branching constrainta 1 ^ b 1), then it is possible thata 2 = 1, given annotation 1422 associated witht 2. Therefore, the obligation would be triggered asa2^ b2. Hence, processor 102 may further branch the execution based on two obligation states being reachable. Processor 102 may determine the existence of further branches 1361, 1362 by creating a (third) set of mathematical expressions including the branching constraint, the evolution constraints and annotations 1321, 1322. Processor 102 may then execute a solver with the (third) set as input and determine the existence of further branches 1361, 1362 based on the output of the solver.

[0214] It is noted that in this example, each state on further branches 1361, 1362 is compliant with respect to the obligation. As there are no further states along further branches 1361, 1362, processor 102 would determine that each state along the original not triggered branch 1351 is complaint. As the other branch also does not contain any reachable non-compliant states, processor 102 would determine that the process is compliant.

[0215] Example 5

[0216] Consider directed graph 1400 shown in Fig.14a, with the obligation from Example 3. Directed graph 1400 in Fig.14a is similar to directed graph 1200 in Fig. 12a, however there is an addition transition t3which has an associated annotation 1523. This example illustrates the situation where there are further states that processor 102 checks.

[0217] The directed graph shown in Fig.14a proceeds similar to Example 3, in which the execution branches at node 1411 (which corresponds to transition t1) as a result of two obligation state being reachable after executingdue to annotation 1421. Similar to Example 3, processor 102 would determine that state 1451 is compliant by creating a first set of mathematical expressions and executing a solver with the first set as input.

[0218] Processor 102 then continues along this triggered branch shown in Fig.14b and determines whether state 1452 is compliant. As such, processor 102 a further first set of mathematical expressions indicative of the branching constraint, the evolution constraints (i.e.,and b3= b1+ [0,1,2,3] ), and the violation condition ( a ^ b ). It is noted that processor 102 may create the further first set by updating the evolution constraints from the previous first set of mathematical expressions.

[0219] Processor 102 would then execute a solver with the further first set as input and determine compliance based on the output of the solver. In this example, it is possible to satisfy the violation condition (e.g., a1= 1 and b1= 0 satisfies the branching constraint and the domain of the variables, while a3= 1 and b3= 2 satisfies the evolution constraints). Hence, processor 102 would determine that a non-compliant state is reachable and therefore, would determine that the process represented by the directed graph in Fig.14a is not compliant.

[0220] Example 6

[0221] Consider directed graph 1500 shown in Fig.15a, with the obligation from Example 3. Directed graph 1500 in Fig.15a is similar to directed graph 1200 in Fig. 12a, however there are no transitions, and directed graph 1500 is not a Petri net. As such, the annotations associated with the transitions in Example 3, are now associated with nodes that also are associated with a state. Furthermore, each node in directed graph 1500 is associated with a state. This example illustrates the branching for a directed graph which is not a Petri net.

[0222] In this example, node 1511 is associated with initial state 1510 and annotation 1521. Similarly, annotation 1522 is associated with node 1512. Similar to Example 3, processor 102 determines whether two or more obligation states are reachable by creating a set of mathematical expressions including annotation 1521 and constraints indictive of the requirement condition of the obligation. Processor 102 then executes a solver with the set as input.

[0223] In this example, processor 102 determines that two obligation states (namely, triggered and not triggered) are reachable based on annotation 1521. Therefore, processor 102 branches the full execution at node 1511 into branches 1531, 1532 as shown in Fig.15b. Similar to Example 3, processor 102 then proceeds to determine compliance of the process by creating a first set of mathematical expressions and executing a solver using the first set as input. Evaluation

[0224] Model design

[0225] The models used in this evaluation are designed to represent multiple aspects of realistic problems, characterised by an increasing complexity of the following properties: 1) number of executions, 2) maximum length of the executions, 3) number of obligations, 4) number of variables, and 5) size of the variable domain. As the analysis focuses on testing the scalability of the approach, each model is required to be fully compliant with respect to the given obligations, such that it needs to be fully analysed in order to verify that they are indeed fully compliant. That is, none of the algorithms can terminate without exploring all relevant states, resulting in the worst- case runtime performance. As these five properties increase, the problem’s space grows proportionally.

[0226] 21 different process models that iteratively expand the problem size were created, while at the same time allowing to be analysed manually to ensure full compliance. In that regard, increasing numbers of possible executions are obtained bycomposing the models of sequences and (multiple) subsequent XOR-blocks, leading to an exponential increase of total possible executions. Fig.8 shows a graphical example of the elementary sequence used to compose the process models. Fig.9 shows a graphical example of the XOR modelling constructs used to compose the process models. Blocks with concurrent transitions have been omitted, as the complexity introduced by such constructs is exclusively related to the (combinatorically increasing) total execution count, while becoming significantly harder to design such that they are fully compliant. The complexity increases through execution length, however, is already obtained through the introduction of XOR-blocks. In addition, for each model, one or more obligations are formulated with increasing amounts of variables and increasing domain sizes for each variable. Experimental results

[0227] Scalability analysis

[0228] A scalability analysis of the disclosed method is presented on this set of artificial models and demonstrate its applicability and identify the core factors contributing to the complexity of the problem. Each of the created models have been labelled with a simple numerical label for reference, while their properties are reported in Table 1 along with the recorded measurements to reach their solutions. To eliminate load times, each experiment was run five times and recorded the average times of three executions, removing the fastest and the slowest executions. The experiments were performed on a SUSE Linux Enterprise Server 15.4 with 260GB available RAM, running on JVM16.

[0229] Results

[0230] From the experimental results reported in Table 1 shown in Fig.16, it follows that around half of the total time is required to solve CSPs. The bulk of the remaining time can be attributed to maintaining the describing structures to keep track of the analysis, as the various possible branches are recursively traversed. The cost ofmaintaining this structure becomes more dominant when the uncertainty in variable values increases, as the complexity of Line 6 in Alg.7 increases combinatorically with respect to the interpretations. This is particularly noticeable in problems 21 and 14_range.

[0231] As expected, the number of executions and number of obligations increase the time required by the procedure. Although the expected trend is linear, the actual results vary depending on whether the newly introduced executions or obligations involve more or fewer evaluations, which can be seen in the recursion and CSP call counts. Increasing the number of variables has a less consistent effect on the overall time, depending on whether the new variables introduce new in-force instances on different obligations.

[0232] While the number of CSP calls is almost linear with respect to the recursion count, the difficulty of each of these calls is highly variable. This is indicated by each maximum of relevant statistics across all calls to the CSP: the number of variables, domain size and number of constraints. Increasing any of these values generally tends to increase the max CSP time, though no precise trend can be described as the CSP procedure is highly dependent on the exact constraints and domain it is given.

[0233] Finally, it can be observed that when the experiments do not contain any critically problematic features (discussed in detail below), the overall time to verify the compliance of a process model is well below 0.5s. Problem sizes that resemble real-life scenarios (particularly 21) can be evaluated in less than a minute. Moreover, it can be observed that when a problem’s size is doubled, the evaluation time increases by one order of magnitude. This is mostly noticeable when looking at 14, 19, 20, and 21.

[0234] Comparison to other compliance-checking algorithms

[0235] The performance of the disclosed method is compared to three infinite-state linear temporal logic (LTL) verification algorithms. The maximum path-length for the algorithms was set to the maximum length of executions in the WF-net, while theremaining settings were left as default. Each experiment was run five times and recorded the average times of three executions, removing the fastest and the slowest executions.

[0236] Results for comparison to other compliance-checking algorithms

[0237] Table 2 shown in Fig.17 provides an overview of the execution times of the disclosed method against the three selected verification algorithms. While some variation in performance exists between each of the verification algorithms, the disclosed method performs better in solving the designed problems.

[0238] It is easy to observe that the properties discussed earlier have similar impact for the other verification algorithm. For more complex obligations (17_hard, 19_hard and 20_hard), the performance advantage of the disclosed method over the other verification algorithms is even more significant, showing an execution time that is several orders of magnitude lower. In general, the disclosed method outperforms any of the three selected algorithms by at least factor of 2 in the best-case scenario and at least a factor of 36 in the worst case.

[0239] It will be appreciated by persons skilled in the art that numerous variations and / or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

CLAIMS:

1. A computer-implemented method for determining compliance of a process, the method comprising: receiving a directed graph representing the process, the directed graph comprising nodes, wherein the directed graph comprises a full execution representing a path within the process; one or more of the nodes is associated with a state comprising one or more values of a variable, wherein an order of one or more of the nodes in the path determines the state; and for one or more of the nodes, the directed graph comprises an annotation representing a set of possible changes to the one or more values of the variable of a projected state upon transitioning to the associated node; based on the annotation of one of the nodes having multiple possible changes, branching the full execution at the one of the nodes into multiple branches, each of the multiple branches representing a continuation of the full execution for one or more of the multiple possible changes; creating a first set of mathematical expressions including constraints to represent one of the continuations of the full execution, an obligation required for compliance and a domain of the variable indicative of the annotations; executing a solver with the first set as input to create a first output indicative of a solvability of the first set; and determining, based on the first output, the compliance of the process.

2. The method of claim 1, wherein branching the full execution at the one of the nodes into multiple branches is based on two or more obligations states of the obligation being reachable from the one of the nodes as a result of the multiple possible changes, wherein each of the multiple branches represent a continuation of the full execution for one of the two or more obligation states.

3. The method of claim 2, wherein the method further comprises: creating a second set of mathematical expressions including constraints to represent an obligation required for compliance and the domain; executing the solver with the second set as input to create a second output indicative of a solvability of the second set; and determining, based on the second output, whether the two or more obligation states of the obligation are reachable.

4. The method of claim 3, wherein the two or more obligation states of the obligation are reachable when the second output comprises multiple solutions to the second set of mathematical expressions, wherein each of the two or more obligation states corresponds to one of the multiple solutions.

5. The method of claim 3 or 4, wherein the first and second set of mathematical expressions comprise evolution constraints indicative of compatible changes of the variable along the full execution or multiple branches.

6. The method of any one of the preceding claims, wherein determining, based on the first output, the compliance of the process comprises determining whether the obligation state of the obligation is violated; and the obligation state of the obligation is violated when the first output comprises a solution to the first set of mathematical expressions.

7. The method of any one of the preceding claims, wherein the solver is a constraint satisfaction problem (CSP) solver.

8. The method of claim 7, wherein the CSP solver is a Maintaining Arc Consistency Algorithm.

9. The method of any one of the preceding claims, wherein the two or more obligation states are:not triggered; triggered and fulfilled; and triggered and pending.

10. The method of claim 9, wherein the method further comprises creating a third set of mathematical expressions including constraints to represent one of the continuations of the full execution indicative of the obligation state being not triggered, the obligation and the domain; executing the solver with the third set as input to create a third output indicative of a solvability of the third set; determining, based on the third output, whether two or more obligation states of the obligation are reachable; and upon determining that the two or more obligation states are reachable, branching the one of the multiple branches at the one of the nodes into further branches.

11. The method of any one of the preceding claims, wherein at least two of the multiple branches have a common prefix sub-path and the method further comprises storing each of the at least two of the multiple branches in memory by storing the common prefix sub-path once.

12. The method of any one of the preceding claims, wherein the method further comprises, upon determining that the process is out of compliance with respect to the obligation, modifying the one of the annotations to achieve compliance.

13. The method of any one of the preceding claims, wherein the obligation is one of multiple obligations and the full execution is one of multiple full executions, wherein the method further comprises repeating, for each of the multiple obligations and multiple full executions, branching the full execution and determining compliance for each state in the full execution to determine full compliance of the process.

14. The method of any of the preceding claims, wherein the directed graph satisfies workflow properties.

15. The method of any of the preceding claims, wherein the directed graph representing the process is a Petri net.

16. The method of any one of the preceding claims, wherein the method further comprises generating a report indicating a result of determining compliance of the process.

17. The method of claim 1, wherein the method comprises traversing the directed graph and repeating the steps of claim 1 or part thereof for each of the nodes.

18. The method of claim 17, wherein the method further comprises terminating repeating the steps of claim 1 or part thereof for each of the nodes upon determining that the obligation state of the obligation is violated.

19. Software that, when executed by a computer, causes the computer to perform the method of any one of the preceding claims.

20. A computer system for determining compliance of a process, the computer system comprising: a processor configured to: receive a directed graph representing the process, the directed graph comprising nodes, wherein the directed graph comprises a full execution representing a path within the process; one or more of the nodes is associated with a state comprising one or more values of a variable, wherein an order of one or more of the nodes in the path determines the state; andfor one or more of the nodes, the directed graph comprises an annotation representing a set of possible changes to the one or more values of the variable of a projected state upon transitioning to the associated node; based on the annotation of one of the nodes having multiple possible changes, branch the full execution at the one of the nodes into multiple branches, each of the multiple branches representing a continuation of the full execution for one or more of the multiple possible changes; create a first set of mathematical expressions including constraints to represent one of the continuations of the full execution, an obligation required for compliance and a domain of the variable indicative of the annotations; execute a solver with the first set as input to create a first output indicative of a solvability of the first set; and determine, based on the first output, the compliance of the process.

Images