An Operational Semantics for the Extended Compliance Rule Graph Language [original]

An Operational Semantics for the Extended

Compliance Rule Graph Language

David Knuplesch and Manfred Reichert

Institute of Databases and Information Systems,

Ulm University, Germany

[email protected]

Abstract

A challenge for any enterprise is to ensure conformance of its business processes with im-

posed compliance rules. Usually, the latter may constrain multiple perspectives of a business

process, including control flow, data, time, resources, and interactions with business part-

ners. Like for process modeling, intuitive visual languages have been proposed for specifying

compliance rules. However, business process compliance cannot completely be decided at

design time, but needs to be monitored during run time as well. In previous work we in-

troduced the extended Compliance Rule Graph (eCRG) language that enables the visual

monitoring of business process compliance regarding the control flow, data, time, and re-

source perspectives as well as the interactions a process has with business partners. This

technical report introduces an operational semantics of the eCRG language. In particular,

the state of a visual compliance rule is reflected through markings and annotations of an

eCRG. The proposed operational semantics not only allows detecting compliance violations

at run-time, but visually highlights their causes as well. Finally, it allows providing recom-

mendations to users in order to proactively ensure for a compliant continuation of a running

business process.

This work was done within the research project C3Pro funded by the German Research Foun-

dation (DFG) under project number RE 1402/2-1.

2 David Knuplesch and Manfred Reichert

1 Introduction

The correctness of business process models has been intensively discussed in literature for

more than a decade [1–3]. While earlier work focused on syntactical correctness and sound-

ness constraints (e.g., absence of deadlocks and lifelocks), the compliance of business pro-

cesses with semantic constraints has been increasingly considered during the last years [4, 5].

Usually, compliance rules stem from domain-specific constraints, e.g., referring to corporate

standards, legal regulations or evidenced best practices [6, 7] , and need to be ensured in all

phases of the process life cycle [8, 9].

Approaches dealing with the compliance of business processes during their execution are

covered by the notion of compliance monitoring. In order to detect and report run-time

violations of compliance rules, events of running business process instances need to be con-

sidered (cf. Fig. 1). Note that two kinds of monitoring need to be distinguished: reactive

and proactive monitoring. Regarding reactive monitoring, the process-aware information

system only reports a compliance violation once it has occurred. In turn, proactive moni-

toring aims to proactively prevent potential compliance violations that might occur during

the further course of process execution; e.g. by suggesting appropriate tasks that still need

to be executed to meet the compliance rule.

WfMS

System

CRM

System

ERP

System

...

Single

Client

...

Compliance Monitoring

Event Bus

Compliance

Rules

Compliance

Reporting

Fig. 1: Compliance monitoring [10, 5]

A multitude of approaches focusing on compliance monitoring at run-time were intro-

duced during the last years [11–13]. While early suggestions focused on the control flow

perspective, later proposals for monitoring compliance considered additional process per-

spectives as well [14, 15]. In particular, the data, resource, and time perspectives have been

addressed. Other approaches, in turn, have focused on the traceability of compliance vio-

lations [10, 16]. Furthermore, [5] proposed 10 fundamental compliance monitoring function-

alities (CMFs) that may be used to compare existing approaches for monitoring business

process compliance. In this context, the authors stated that existing approaches do not

provide a satisfactory solution that combines an expressive language with full traceability

capabilities [5].

To close this gap, this report introduces an operational semantics for the extended Com-

pliance Rule Graph (eCRG) language. The latter has been introduced in [17, 18] and enables

An Operational Semantics for the eCRG Language 3

the visual monitoring of business process compliance. In particular, the operational seman-

tics annotates eCRGs with text, colors and symbols. In order to deal with compliance rules,

which are triggered multiple times during the execution of a business process instance, the

operational semantic creates and annotates multiple instances of an eCRG in parallel. The

annotated instances of an eCRG not only indicate compliance violations, but may be also

utilized for recommending the next process steps (i.e. activities), whose execution will en-

sure compliance. Furthermore, they provide a suitable basis for compliance metrics. Note

that the eCRG language is a powerful visual notation for compliance rules that adequately

supports the control flow, data, time, and resource perspectives as well as interactions with

business partners. Consequently, this report not only provides the operational basis for mon-

itoring control flow constraints, but enables the monitoring of the latter perspectives as well.

Altogether the provided operational semantics provides the basis for

–utilizing the eCRG language for monitoring business process compliance during process

execution.

–monitoring the conformance with compliance rules related to any process perspective;

i.e., the control flow, data, time, resource perspectives as well as the interactions a process

has with business partners.

–dealing with compliance rules, which are are triggered multiple times.

–reasoning about the violation of compliance rules – reactively & proactively.

–specifying compliance metrics and measures.

The remainder of this report is structured as follows: Section 2 discusses related work.

Section 3 provides a motivating example. Backgrounds on the extended Compliance Rule

Graph (eCRG) language are introduced in Section 4. Section 5 provides an operational

semantics for the eCRG language. In particular this operational semantics formally specifies

the transitions between the states of compliance rules. In turn, Section 6 evaluates and

classifies the compliance of an eCRG. Furthermore, the specification of compliance metrics

and measures is introduced as well as the provision of recommendations to users. Finally,

Section 7 concludes the paper and provides an outlook on future research.

4 David Knuplesch and Manfred Reichert

2 Related Work

For a decade, business process compliance has increasingly gained attention and several sur-

veys have been published in the meantime (e.g., [19, 8, 20, 21, 5]). Along this trend, interest

in compliance monitoring and continous auditing [12] has grown as well. For example, [11]

enriches process models with a semantic layer of internal controls. In [13, 22], in turn, the

detailed architectures of an online auditing tools (OLAT) are described. An OLAT allows

monitoring the operations of an organization in detective, corrective and preventive modes.

The spectrum of techniques applied for compliance monitoring is wide spread: Behavioural

profiles [23] utilize ordering relations in this context, whereas Supeverisory Control Theory

[24] prevents users from performing actions leading to compliance violations. Furthermore,

visual declarative constraints [25], which are transformed into Event Calculus and Linear

Temporal Logic (LTL), have shown increasing popularity. Fuzzy conformance checking [26]

calculates an evaluation score that indicates how much the observed process instance com-

plies instead of providing a simple yes/no answer.

In order to enable fine-grained compliance diagnostics at run-time, Compliance Rule

Graphs [10] and colored automata [16] have been suggested. However, both mainly focus on

control flow perspective. In turn, [5] compares approaches for monitoring business process

compliance based on 10 compliance monitoring functionalities (CMF). In particular, it is

emphasized that existing approaches do not provide a satisfactorily solution that combines

an expressive language (CMF 1-5) with full compliance traceability (CMF 8+9). Table 1

summarizes the results from [5].

Table 1: Compliance monitoring functionalities [5]

CMF 1 CMF 2 CMF 3 CMF 4 CMF 5 CMF 6 CMF 7 CMF 8 CMF 9 CMF 10

time data resources non life- multi- reactive proactive root compl.

Approach atomic cycle instance mgmt mgmt cause degree

Mubicon LTL [16] +/- - - + - - + + + +/-

Mubicon EC [25, 15] + +/- + + + + + - +/- +/-

ECE Rules [26] + +/- + + - - + - +/- +

SCT [24] +/- - + + + - - + - -

SeaFlows [10] +/- +/- +/- + +/- + + + + +/-

As opposed to the approaches described above, [27] monitors performance measures in

the context of artifact-centric process models. In turn, [28, 14, 29] provide techniques to a

posteriori verify the compliance of execution logs with a set of constraints. Some of these

approaches not only focus on the control flow perspective, but take the time perspective [14]

or resource perspective [28] into account as well.

A priori or design time compliance checking has been addressed by a multitude of ap-

proaches for a long time. Most of them apply model checking techniques (e.g., [30–33]). In

addition, some of these design time approaches use visual compliance rules and not only

consider the control flow perspective, but the data, interaction or time perspectives as well.

Other compliance checking approaches, in turn, are based on Petri-Nets [34] and Mixed-

Integer Programming [35].

Finally, there are few frameworks, which address the integration of business process

compliance throughout the entire process lifecycle [9, 36, 8, 37, 38].

An Operational Semantics for the eCRG Language 5

3 Motivating Example

This section introduces a motivating example, which refers to the event log from Fig. 2

and deals with an order-to-delivery process. The latter is subject to three compliance rules,

which stem from internal guidelines.

Note that compliance rule c1is satisfied in one case, but violated in another. In partic-

ular, the depicted log refers to two different request items related to customers Mr. Smith

and Mrs. John. These items, in turn, trigger two different instances of compliance rule c1.

In both cases, the amount is greater than 10,000eand hence a solvency check is required.

However, the latter was only performed for the request item of Mr. Smith, but not for the

one of Mrs. John (i.e., c1is violated in the latter case). Besides the violation of c1, compli-

ance rule c2is violated twice as well. While the violated instance of rule c1will never be

successfully completed, the violations of c2still may be healed by informing the agent, who

sent the requests, about the results of the approvals.

The compliance rule examples further indicate that solely monitoring control flow de-

pendencies between tasks is not sufficient in order to ensure compliance at run-time. In

addition, constraints in respect to the data, time and resource perspectives of a business

process as well as the interactions this process has with partner processes must be moni-

tored [39, 21, 17, 18]. For example, the data perspective of compliance rule c1is addressed

by the request item and its amount. In turn, receiving the request item (cf. c1) represents

an interaction with a business partner. The phrase ”by different staff members” deals with

the resource perspective, whereas the condition ”at max three days” refers to the time per-

spective. To meet practical demand, compliance monitoring must not abstract from these

process perspectives.

# date time type id details

37 1/7/2013 15:27 receive 124 Request

38 1/7/2013 15:27 write 124 customer = Mr.Smith

39 1/7/2013 15:27 write 124 amount = 15.000€

39 1/7/2013 15:27 end 124 Request

55 1/7/2013 18:03 receive 592 Request

56 1/7/2013 18:03 write 592 customer = Mrs.John

57 1/7/2013 18:03 write 592 amount = 27.000€

58 1/7/2013 18:03 end 592 Request

77 2/7/2013 15:43 start 234 SolvencyCheck (Mrs. Brown)

78 2/7/2013 15:43 read 234 customer = Mr.Smith

79 2/7/2013 15:54 write 234 rating= high

80 2/7/2013 15:55 end 234 SolvencyCheck

91 2/7/2013 18:13 start 453 Approval (Mr. Muller)

92 2/7/2013 18:14 read 453 customer = Mr.Smith

93 2/7/2013 18:14 read 453 rating = high

94 2/7/2013 18:17 write 453 result= granted

95 2/7/2013 18:18 end 453 Approval

96 2/7/2013 18:19 start 642 Approval (Mrs. Brown)

97 2/7/2013 18:20 read 642 customer = Mrs.John

98 2/7/2013 18:23 write 642 result = granted

99 2/7/2013 18:23 end 642 Approval

When a request item with an amount

greater then 10,000 is received from

an agent, the request must not be

approved unless the solvency of the

respective customer was checked.

The latter task must be started at max

three days after the receipt. Further,

task approval and task solvency check

must be performed by different staff

members.

After approval of a request item, the

agent must be informed about the

result within one days.

After starting the production related to

a particular order the latter may only

be changed by the head of

production.

Compliance rules

... ... ... ... ...

Fig. 2: Event log of order-to-delivery processes and compliance rules

6 David Knuplesch and Manfred Reichert

4 Fundamentals of Extended Compliance Rule Graphs

This paper utilizes the extended Compliance Rule Graph (eCRG) language for compliance

monitoring. Since this language is based on the Compliance Rule Graph (CRG) language,

we first introduce CRGs before presenting eCRG fundamentals.

4.1 Compliance Rule Graphs

The Compliance Rule Graph (CRG) language was introduced in [40, 10, 41]. It allows for

the visual modeling of compliance rules that focus on the control flow perspective (i.e.,

sequence flow) of business processes. A CRG corresponds to an acyclic graph that consists

of an antecedence pattern as well as one or multiple related consequence patterns. Both

kinds of patterns are modeled using occurrence and absence nodes, which either express the

occurrence or absence of events (e.g. events related to the execution of a particular task).

Furthermore, the edges connecting these nodes express control flow dependencies.

As illustrated in Fig. 3, an event trace (i.e., a finite sequence of events related to the

same process instance) is considered as compliant with a CRG iff for each match of the

antecedence pattern there is at least one corresponding match for one of the consequence

pattern. In turn, a trace is considered as trivially compliant iff there is no match of the

antecedence pattern at all. As example consider the CRG from Fig. 3. It expresses that for

each B not preceded by an A, a D must occur. Further, there must be no C that precedes

B and D.

C D C D

Antecedence pattern Consequence pattern

only match < E, D, F, G, B >

only match < D, F, C, E, B >

no match (A is before B)

only match < C, F, B, G, E >

1st match < B, C, D, E, B >

2nd match < B, C, D, E, B >

< E, D, F, G, B >

< D, F, C, E, B > (C is after D)

no match (missing D)

< B, C, D, E, B >

no match (C is before B and D)

A B A B A B

< E, D, F, G, B >

< D, F, C, E, B >

< A, B, C, E, D >

< C, F, B, G, E >

< B, C, D, E, B >

compliant

trivially compliant

violation

Antecedence

Occurrence

Antecedence

Absence

Consequence

Absence

Consequence

Occurrence

CRG

Traces

Fig. 3: CRG example and semantics [8]

4.2 Extended Compliance Rule Graph

The CRG language focuses on the control flow perspective of compliance rules, but ignores

other perspectives. In [17, 18], therefore, we introduced the extended Compliance Rule Graph

(eCRG) as a visual language for modeling compliance rules not only covering the control flow

perspective, but providing integrated support for the resource, data and time perspectives as

well as for interactions with business partners. To cover these various perspectives, the eCRG

language allows for attachments in addition to nodes and connectors (i.e. edges). Thereby,

nodes refer to entities (e.g. a data object) or events, whereas edges and attachments are

used to refine the nodes or edges they are affiliated to. Furthermore, an eCRG may contain

instance nodes referring to particular objects, which exist independently from the respective

rule (e.g. Mr. Smith, postnatal ward, physician). Hence, instance nodes are neither part of

An Operational Semantics for the eCRG Language 7

the antecedence nor the consequence pattern, but constitute the instance patter. Fig. 4 gives

an overview of the elements of the eCRG language.

OccurenceAbsence

Antecedence Consequence

Task

Task Task

Task

Data

Object

Data

Object

Data Nodes

AntecedenceConsequence

Group Organizational

Unit

Staff

Member

Role

Group Organizational

Unit

Staff

Member

Role

Resource Nodes

Requests

Request

Particular

Data Nodes

Quality

Managers

Radiology

Department

Computer

Scientist

Mr X

Antecedence

Consequence

Time Conditions

>2d

March 23th

2013

Point in Time

Extended Compliance Rule Graph Language (eCRG)

Process Perspective Time Perspective

Resource Perspective Data Perspective

< value

> value

Antecedence

Consequence

Data Conditions

AntecedenceConsequence

Particular

Resources

Antecedence Consequence Antecedence Consequence

Sender

Receiver Message

Message

Sender

Message

Receiver

Message

Sender

Receiver Message

Message

Sender

Message

Receiver

Message

ReceiveSend

OccurenceAbsence

Interaction Perspective

Sequence

Exclusion

Antecedence

Alternative

Basic Connectors

Sequence

Exclusion

Consequence

Alternative

property

Antecedence

Consequence

Resource Conditions

Data Container

Resource Connectors

Time Nodes

Performing

Relation

Antecedence

assigned to

Performing

Relation

Consequence

assigned to

Data Connectors

Data Flow

Antecedence

Data Flow

Consequence

Knuplesch, Reichert, Ly, Kumar, Rinderle-

Ma: Visual Modeling of Business Process

Compliance Rules with the Support of

Multiple Perspectives. In: ER 2013, LNCS,

Springer (2013), pp. 106-120

Fig. 4: Elements of the eCRG language [17, 18]

The elements of the eCRG language are partitioned into the control flow, data, time,

resource and interaction perspectives that will be described in the following in more detail

(cf. Fig. 4).

Control flow perspective. Modeling the control flow perspective of compliance rules is

supported through four kinds of task nodes, i.e., antecedence occurrence, antecedence ab-

sence, consequence occurrence, and consequence absence task nodes. Based on these nodes

it can be expressed whether or not particular tasks shall be executed. In addition, two kinds

of sequence flow connectors are provided that allow constraining the execution sequence of

tasks. Note that the absence of a sequence flow indicates parallel flow. Furthermore, ex-

clusive connectors express mutual exclusion of the tasks they refer to. Finally, alternative

connectors express that at least one of the connected tasks must occur.

Interaction perspective. The interaction perspective supports the exchange of messages

with business partners. According to task nodes, four kinds of sending and four kinds of

receiving message nodes are provided, i.e., antecedence occurrence, antecedence absence,

consequence occurrence, and consequence absence nodes.

Time perspective. The eCRG language offers the following elements for modeling the time

perspective: Point-in-time nodes,time condition attachments, and time distance connectors.

Point-in-time nodes express a particular date or point-in-time (e.g. 26th October 2014).

Time conditions, in turn, may be attached to task nodes and sequence flow connectors to

constrain the duration of a task or the time distance between task nodes,message nodes and

point-in-time nodes. Finally, time distance connectors allow constraining the time distance

without implying a particular sequence.

8 David Knuplesch and Manfred Reichert

Data perspective. Data container nodes and data object nodes support the modeling of

the data perspective in eCRGs. Furthermore, data flow connectors,data relation connectors

and data condition attachments are provided. Data container nodes refer to process data

elements or global data stores. By contrast, data object nodes refer to particular data values

and data object instances. Both kinds of data nodes may be part of the antecedence or

consequence pattern, or represent a particular data container and data object, respectively.

Data flow connectors define which process tasks read or write which data objects or data

containers. To constrain data containers, data objects and data flow, data conditions may

be attached. In turn, data relation connectors allow comparing data objects.

Resource perspective. For modeling the resource perspective of compliance rules, resource

nodes are provided, i.e., staff member,role,group, and organizational unit nodes. Similar to

task nodes, resource nodes may be part of the antecedence or consequence pattern. Alter-

natively, they may represent a particular resource instance (e.g. Mr. Smith, postnatal ward,

physician). To specify dependencies among resources, resource relation connectors are pro-

vided. In turn, resource condition attachments constrain a particular resource node. Finally,

the performing relation indicates the performer of a task node.

Fig. 5 applies the eCRG language in order to model the compliance rules from our

motivating example in Section 3, which have been presented in verbalized form in Fig. 2.

In particular, Fig. 2(c1)addresses all process perspectives, i.e., the control flow, data, time

and resource perspectives as well as interactions with business partners. In turn, Fig. 2(c2)

does not refer to the resource perspective, whereas time and interaction perspectives are not

addressed in Fig. 2(c3).

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

customer

amount

> 10,000

Agent

Inform

Approval

- – - < 1d

result

Change O.

- – -

Start Prod.

- – -

head of

production

has role

order

<3d

Fig. 5: Modeling compliance rules c1−3with the eCRG language

An Operational Semantics for the eCRG Language 9

A formal specification of an eCRG is provided in Def. 1 (for a more detailed definition

of eCRGs including a formal definition of φsee [42]).

Definition 1 (Extended Compliance Rule Graph (eCRG)).

Let Tbe the set of points in time, Rbe the set of human resources, and Ωbe the

set of all data objects. Then: An extended Compliance Rule Graph (eCRG) is a tuple

Ψ=(N, E, ◇, type, src, tgt, at, pt)with

–N∶=T∪MN ∪O∪C∪R∪Pbeing the set of nodes that may be partitioned into the

sets of task nodes T,message nodes MN,data object nodes O,data container

nodes C,resource nodes R, and point-in-time nodes P⊂T.

–E∶=# »

sf ∪#»

df ∪# »

pfm ∪#»

rr being the set of edges that may be partitioned into the sets

of sequence flow edges

# »

sf,data flow edges

#»

df,performing relations

# »

pfm, and

resource relations #»

rr.

–◇∶=◇dc ∪◇tc ∪◇rr being the set of attachments that may be partitioned into the sets

of data conditions ◇dc,time conditions ◇tc, and resource conditions ◇rc,

–type ∶T∪MN ∪#»

df →Tmapping each task node (message node, data flow edge) to a

task type (message type,parameter name),

–src ∶E→N(tgt ∶E→N) mapping each edge to its source (target)node,

–at ∶ ◇ →N∪Emapping each attachment to the underlying node or edge it is

attached to, and

–pt ∶N∪E∪ ◇ →{AO, AA, CO, CA, I}mapping each element of an eCRG to the

corresponding pattern.

Further:

–ΛΨ∶=N∪E∪◇is the set of all elements,

–ΓΨ∶=T∪MN is the set of task and message nodes,

–φΦ∶ΛΨ→ΛΨmaps each element to its affiliation; i.e., the element to which it is

affiliated3.

–For each set X⊂ΛΨof elements of an eCRG and each pattern

y∈{AO, AA, CO, CA, I}, we define Xy∶={x∈X∣pt(x)=y}as the

pattern yof X.

Fig. 6: Dependencies of eCRG pattern

Function pt partitions the elements of an eCRG in five patterns, which are the instance

pattern (I) as well as the antecedence occurrence (AO), antecedence absence (AA), con-

sequence occurrence (CO), and consequence absence (CA) patterns. Dependencies among

these patterns are shown in Fig. 6, whereas the lower ones depend on the upper ones they

10 David Knuplesch and Manfred Reichert

are connected to. Based on the latter, Def. 2 formally specifies how connected elements con-

strain and depend on each other. In particular, a node, edge or attachment λ1depends on

another element λ2, if they are connected and the pattern of λ1depends on the one of λ2.

For example, task node production depends on its outgoing sequence flow edge in Fig. 5(c3).

In turn, in Fig. 5(c3), message node request does not depend on both outgoing sequence

flows. Instead, the latter depend on the message node.

Definition 2 (Pattern Dependency Order).

Let Ψ=(N, E, ◇, type, src, tgt, at, pt)be an eCRG and let λ1, λ2∈ΛΨbe two elements of

the eCRG. Then:

–▸defines the partial dependency order over the set of patterns as specified in Fig. 6

(e.g. I▸AA),

–We say λ1has a higher dependency level than λ(i.e., λ1▷λ2), iff the pattern of λ1is

greater than the one of λ2according to the dependency order ▸, i.e.,

λ1▷λ2∶⇔pat(λ1)▸pat(λ2)

–and ⊵,≜,◁and ⊴are defined accordingly.

An Operational Semantics for the eCRG Language 11

5 eCRG Operational Semantics

This section introduces the operational semantics of the eCRG language that enables visually

monitoring business process compliance at run-time. As discussed in Section 1, the latter is

based on event streams that occur during the execution of business processes. In particular,

compliance monitoring shall detect or, if possible, prevent compliance violations. For this

purpose, first of all, Section 5.1 introduces the different events that are supported. Second,

the fundamental states of a compliance rule are introduced in Section 5.2. Third, Section 5.3

specifies markings that annotate the elements of an eCRG with text, colors and symbols.

Finally, Section 5.4 specifies the processing of events and discusses how the latter evolve and

unfold markings of an eCRG (cf. Section 5.4).

5.1 Events

As this report addresses compliance monitoring in respect to multiple process perspectives,

we not only monitor events that refer to the start and end of tasks. In addition, we consider

events that correspond to the sending and receiving of messages as well as data flow events

that log how activities read from and write to data sources. Furthermore, events may include

temporal information as well as information about involved resources.

Table 2 summarizes the event types supported by our approach. Note that each event

includes the time it occurs as well as a unique id. The latter enables us to identify correlations

between the start, end and data flow events related to the same task or message.

Table 2: Supported Events

Task events start(time, id, tasktype, performer)

end(time, id, tasktype, performer)

Message events send(time, id, message)

receive(time, id, message)

end(time, id, message)

Data flow events write(time, id, value param

ÐÐÐ→ source)

read(time, id, value param

←ÐÐÐ source)

Based on the events from Table 2, Def. 3 formally specifies event logs and streams.

Definition 3 (Event Log or Event Stream).

Let Ebe the set of events (cf. Table 2) and let Tbe the discrete set of points in time. Then:

–L∶N→E∪{∅}is an event stream or event log,

–time ∶E→T∶time(event(ϑ,...))∶=ϑmaps each event to the corresponding point-

in-time.

Note that we assume that event streams are correct; i.e., they do not deviate (cf. [43])

from the real process, ids are unique, and events are provided in an ascending order (i.e.,

∀i, j ∈[1..posL]∶i<j⇒time(L(i))≤time(L(j))).

5.2 States of Compliance Rules

When monitoring the compliance of running process instances, compliance rules take vary-

ing states [10, 8]. Fig. 7 outlines the states that are supported by our approach. The most

12 David Knuplesch and Manfred Reichert

fundamental state is Not Activated, i.e., the compliance rule does not concern the run-

ning process instances until now. The opposite state Activated means that the compliance

rule affects the process instance and includes the sub-states TempSatisfied and Tem-

pViolated.TempSatisfied is further partitioned into Violable and Satisfied, whereas

TempViolated includes the sub-states Pending and Violated. As explained by our mo-

tivating example in Section 3, business process can multiply trigger (i.e. activate) compliance

rule. Hence, a compliance rule can be in state Activated multiple times as indicated by

superscript ”+”. Note that each of these activations of a compliance rule can take a different

sub-state. For instance, the event log of our motivating example activates compliance rule c1

twice (cf. Fig. 2). The first activation is Satisfied, whereas the second activation remains

in state Violated.

ACTIVATED

TEMPVIOLATED

(non-compliance)

TEMPSATISFIED

(compliance)

VIOLABLE

SATISFIED

PENDING

VIOLATED

NOT_ACTIVATED

(trivial compliance)

Fig. 7: States of compliance rules

5.3 eCRG Markings

To monitor the state of a compliance rule, we annotate and mark the elements of an eCRG

(cf. Section 4, [17, 18]) with symbols, colors and text (cf. Figs. 8). Such a marking of an

eCRG (i.e., annotated eCRG) highlights whether or not the events corresponding to a node

have occurred so far. Further, it describes whether conditions corresponding to edges and

attachments are satisfied, violated, or still will be evaluated (cf. Figs. 8). Since there may

be different activations and instantiations of a particular compliance rule, Def. 4 defines the

state of an eCRG in terms of a set of markings, which, in turn, can be utilized to calculate

the corresponding states of compliance as introduced in Section 5.2.

Points in time Tasks and Messages

not

activated

skipped

completed

running

activated

abs

occ

Task

date

performer

timestart–timeend

Sender

Message

date time

Task

performer

dateend timeend

datestart timestart

timestart

Receiver

Message

date time

December

23th 2023

future

October

26th 2013

past

< 2d

antec.cons.

< 2d

< 2d < 50

< 50

satisfied

Time

Condition

Resource/

Data

Condition

not marked

Attachments

antec.cons.antec.cons.

antec.cons.

≠

satisfied

Sequence

Flow Data

Flow Performing

Relation Resource/Data

Relation

not marked

Edges

antec.cons.antec.cons.

violated

Nodes

Fig. 8: Annotations of eCRG elements

An Operational Semantics for the eCRG Language 13

Definition 4 (Markings and State of an eCRG).

Let Ibe a set of unique identifiers. Let further Tbe the set of points in

time, Rbe the set of human resources, and Ωbe the set of all data ob-

jects, whereas is the empty value, i.e., the placeholder for not yet set iden-

tifiers, points in time, human resources, and data objects. Furthermore, let

Ψ=(N, E, ◇, type, src, tgt, at, pt)be an eCRG. Then: A marking Mof Ψis a tuple

M=(m, res, val, id, ts, te)where

–m∶ΛΨ→{◻,△,▶,✓,⨉}marks each element of the eCRG with either

Not Activated/Not Marked (◻), Activated (△), Running (▶), Completed/

Satisfied (✓), or Skipped (⨉).

–res ∶T∪R∪# »

pfm →{}∪Rassigns a resource to each task node, resource node and

performing relation edge,

–val ∶O∪#»

df →{}∪Ωassigns a value to each data object node and data flow edge,

–id ∶T∪MN ∪C∪#»

df →{}∪Iassigns an unique identifier to each task node,

message node, data container node, or data flow edge,

–ts∶T∪MN ∪P→{}∪T(and te∶T∪MN ∪P→{}∪Trespectively) assigns a

starting (ending)time to each task node, message node, and point-in-time node.

Further, we define

–Min

Ψ∶=(m, res, val, id, ts, te)as the initial marking of eCRG Ψ, where

●m(x)∶=◻marks every element xwith ◻,

●ts(x)∶=te(x)∶=sets starting and ending times to , and

●res(x)∶={, iff x∉I

x, else val(x)∶={, iff x∉I

x, else id(x)∶={, iff x∉I

x, else

only assign resources, values and identifiers to elements of the instance pattern.

–MΨas the set of all markings of Ψ,

–ML,i

Ψ⊆MΨas the state of eCRG Ψafter processing event stream L

until entry i∈N, and

–Min

Ψ∶={Min

Ψ}as the initial state of Ψ.

5.4 Operational Semantics

In order to enable the processing of events in the context of the extended Compliance Rule

Graph (eCRG) language, this section introduces the eCRG operational semantics. In par-

ticular Defs. 5-10 specify how the different event types are processed (cf. Fig. 9). First, all

markings must be updated to the point-in-time of the event occured (cf. Def. 5). Second,

effects of the update (i.e., the updated annotations) are propagated to adjacent elements (cf.

Def. 10). Third, Defs. 6-9 specify the actual handling of an event based on its type. Finally,

annotations are propagated once again before completing the processing of an event.

Note that the first two steps may be skipped if time does not differ from the one of the event

directly processed before. In turn, these two steps may be applied without the subsequent

ones in order to calculate the current state of a compliance rule at any point-in-time between

two events.

5.4.1 Update Marking

Def. 5 specifies the update of a marking to the current point-in-time. In particular, the

annotation of point-in-time nodes changes from Not Marked ◻to Completed ✓, if the

14 David Knuplesch and Manfred Reichert

Update

Marking

Effect

Propagation

Start Event

Handling

Message Event

Handling Effect

Propagation

End Event

Handling

Data Event

Handling

start(…)

end(…)

receive(…)

send(…)

read(…)

write(…)

Fig. 9: Processing of start, message, data and end events

points in time to which the nodes refer have passed (t1). Furthermore, time conditions on

running task nodes or sequence flow edges will be Skipped (⨉) if they are no longer satis-

fiable (t2).

Definition 5 (Update Marking).

Let M∶=(m, res, val, id, ts, te)∈MΨbe a marking of eCRG Ψand let ϑ∈Tbe a

point-in-time. Then: updϑ∶MΨ→MΨwith updϑ(M)∶=(m′, res, val, id, ts, te)calculates

the update of marking Mto point-in-time ϑ, where

m′(λ)∶=

⎧

⎪

⎨

⎪

⎩

✓,if λ∈P∧m(λ)=◻∧λ≤ϑ, (t1)

⨉,if λ∈◇tc ∧m(λ)=◻∧(t∶=at(◇tc)∈T)(t2)

∧(∀ς∈T∶(ς≥ϑ)⇒¬◇tc(ts(t), ς)),

⨉,if λ∈◇tc ∧m(λ)=◻∧((n1, n2)∶=at(◇tc)∈# »

sf)(t2)

∧(∀ς∈T∶(ς≥ϑ)⇒¬◇tc(te(n1), ς)),

m(λ),else

Fig. 10 updates marking Bof compliance rule c1from our motivating example (cf.

Fig. 2) to the point in time 4/7/2013 16:05. According to Def. 5(t2), the time condition

on the sequence flow edge from message node is marked as skipped, because it can not be

satisfied any more.

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 15:27

customer

Mrs.

John amount

27,000

Mrs. John

27,000

58 1/7/2013 18:03 end 592 Request

+ propagation of effects

> 10,000

<3d

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 15:27

B‘

customer

Mrs.

John amount

27,000

Mrs. John

27,000 > 10,000

<3d

## 4/7/2013 16:05 update

Fig. 10: Update of markings

An Operational Semantics for the eCRG Language 15

5.4.2 Start and Message Event Handling

Def. 6 (Def. 7) non-deterministically handles start events (message events), in order to

deal with different instantiations of a compliance rule. In particular, the set of matching and

activated task nodes (message nodes) is determined first. Then, for each subset a new mark-

ing is instantiated, which solely changes the marking of the selected nodes from Activated

(△) to Running (▶), and, accordingly, sets the identifiers, resources and starting times (cf.

Fig. 11). Node that the empty set is among the subsets and the result hence includes the

unchanged original marking as well.

Definition 6 (Start Event Handling).

Let M∶=(m, res, val, id, ts, te)∈MΨbe a marking of eCRG Ψand σ=start(ϑ, ι, τ, ρ)

be a start event. Then:

–∆σ(M)∶={λ∈T∣m(λ)=△∧type(λ)=τ}is the set of matching and activated task

nodes,

–For each subset δ⊆∆σ(M),hdlσ

δ∶MΨ→MΨwith hdlσ

δ(M)∶=(mδ, resδ, val, idδ, tδ

s, te)

calculates the handling of start event σby node set δand marking M:

mδ(λ)∶={▶,iff λ∈δ

m(λ),else resδ(λ)∶={ρ, iff λ∈δ

res(λ),else

idδ(λ)∶={ι, iff λ∈δ

id(λ),else tδ

s(λ)∶={ϑ, iff λ∈δ

id(λ),else

–hdlσ∶MΨ→2MΨwith hdlσ(M)∶={hdlσ

δ(M)∣δ∈∆σ(M)} calculates all handlings

of σby M.

Definition 7 (Message Event Handling).

Let M∶=(m, res, val, id, ts, te)∈MΨbe a marking of eCRG Ψand let σ=send(ϑ, ι, τ)

(and receive(ϑ, ι, τ)respectively) be a message event. Then:

–∆σ(M)∶={λ∈MN∣m(λ)=△ ∧ type(λ)=τ}is the set of matching and activated

message nodes,

–For each subset δ⊆∆σ(M),hdlσ

δ∶MΨ→MΨwith hdlσ

δ(M)∶=(mδ, resδ, val, idδ, tδ

s, te)

calculates the handling of message event σby node set δand marking M:

mδ(λ)∶={▶,iff λ∈δ

m(λ),else idδ(λ)∶={ι, iff λ∈δ

id(λ),else tδ

s(λ)∶={ϑ, iff λ∈δ

id(λ),else

–hdlσ∶MΨ→2MΨwith hdlσ(M)∶={hdlσ

δ(M)∣δ∈∆σ(M)} calculates all handlings

of σby M.

Fig. 11 illustrates the handling of a start and message events. In particular, the receipt

of the message request starts the corresponding message node of marking 0 in the upper

example; i.e., the node is marked as Running (▶) and labeled with the receive time of the

message. The lower example handles the start-event of task solvency check. The correspond-

ing task node is marked as Running. Furthermore, its the start time and performer of the

task are specified.

16 David Knuplesch and Manfred Reichert

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

customer

amount

> 10,000

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 15:27

customer

amount

> 10,000

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 18:03

customer

Mrs.

John amount

27,000

Mrs. John

27,000 > 10,000

Solvency C.

...

... – ...

37 1/7/2013 15:27 receive 124 Request

<3d <3d

<3d

## 1/7/2013 15:27 update

propagation of effects

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 18:03

customer

Mrs.

John amount

27,000

Mrs. John

27,000 > 10,000

Solvency C.

2/7/2013

Mrs. Brown

15:43 – ...

<3d

Mrs.

Brown

77 2/7/2013 15:43 start 234 SolvencyCheck (Mrs. Brown)

58 1/7/2013 18:03 end 592 Request

+ propagation of effects

Fig. 11: Handling of start and message events

5.4.3 End Event Handling

Since we use unique identifiers for start, message and end events, the latter can be pro-

cessed deterministically (cf. Def. 8). In particular, the annotations of all nodes assigned to

the identifier of the end event and marked with Running (▶), are changed to Completed

(✓) and their ending time is set accordingly (cf. Fig. 12).

Definition 8 (End Event Handling).

Let M∶=(m, res, val, id, ts, te)∈MΨbe a marking of eCRG Ψand σ=end(ϑ, ι, τ, ρ)

(and end(ϑ, ι, τ)respectively) be an end event. Then: hdlσ∶MΨ→2MΨwith

hdlσ(M)∶={(m′, res, val, id, ts, t′e)}calculates the the handling of end event σby mark-

ing M:

m′∶={✓,iff id(λ)=ι

m(λ),else t′e(λ)∶={ϑ, iff id(λ)=ι

id(λ),else

Fig. 12 shows the handling of an end event. In particular, the processing of the message

request is finished and the the corresponding message node of marking a5 is marked as

Completed (✓).

An Operational Semantics for the eCRG Language 17

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 15:27

customer

Mr.

Smith amount

15,000

Mr. Smith

15,000

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 15:27

customer

Mr.

Smith amount

15,000

Mr. Smith

15,000 > 10,000

propagation of effects

57 1/7/2013 18:03 write 592 amount = 27.000€

<3d

> 10,000

<3d

39 1/7/2013 15:27 end 124 Request

+ propagation of effects

Fig. 12: Handling of end events

5.4.4 Data Event Handling

We can also process data events deterministically, since the combination of the used

unique identifiers and the used parameter names clearly refers to the data flow edges con-

cerned (cf. Def. 9). In particular, the latter is marked as Satisfied (✓) and annotated with

the data value and the identifier of the data source or data target; i.e., the identifier of a

data container (cf. Fig. 13).

Definition 9 (Data Event Handling).

Let M∶=(m, res, val, id, ts, te)∈MΨbe a marking of eCRG Ψ. Further, let

σ=write(ϑ, ι, υ par

ÐÐ→ ω)(and read(ϑ, ι, υ par

←ÐÐ ω)respec-

tively) be a data event. Then: hdlσ∶MΨ→2MΨ,with

hdlσ(M)∶={(m′, res, val′, id′, ts, te)} calculates the handling of data event σby

marking M:

m′(λ)∶={✓,if λ=(n, t)∈#»

df ∧m(λ)=◻∧id(n)=ι∧m(n)=▶∧type(λ)=par

m(λ),else

val′(λ)∶={υ, if λ=(n, t)∈#»

df ∧m(λ)=◻∧id(n)=ι∧m(n)=▶∧type(λ)=par

val(λ),else

id′(λ)∶={ω, if λ=(n, t)∈#»

df ∧m(λ)=◻∧id(n)=ι∧m(n)=▶∧type(λ)=par

id(λ),else

Fig. 13 illustrates the handling of a data events. The writing data flow event amount

of the message request is handled in the upper example. In particular, the corresponding

outgoing data flow edge of message node request is marked as Satisfied (✓) and annotated

with the amount of 15.000. The lower example handles the reading data flow event customer

that marks the incoming data flow edge of task solvency check as Satisfied (✓) and anno-

tates it with the customer Mr. Smith. Note that the latter annotation Mr. Smith does not

meet the value Mrs. John of the data object customer; i.e., the handling of data flow events

allows for conflicts. Furthermore, note that we omit the identifiers of data sources (i.e., data

containers) in our examples for the sake of simplicity.

18 David Knuplesch and Manfred Reichert

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 15:27

customer

amount

propagation of effects

15,000 > 10,000

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

2/7/2013

Mrs. Brown

15:43 – ...

1/7/2013 18:03

customer

Mrs.

John amount

27,000

Mrs. John

27,000 > 10,000

Mr. Smith

<3d

Mrs.

Brown

38 1/7/2013 15:27 write 124 amount = 15.000€

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 15:27

customer

amount

> 10,000

<3d

37 1/7/2013 15:27 receive 124 Request

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 18:03

customer

Mrs.

John amount

27,000

Mrs. John

27,000 > 10,000

Solvency C.

2/7/2013

Mrs. Brown

15:43 – ...

<3d

Mrs.

Brown

propagation of effects 78 2/7/2013 15:43 read 234 customer = Mr.Smith

77 2/7/2013 15:43 start 234 SolvencyCheck (Mrs. Brown)

Fig. 13: Handling of data events

5.4.5 Propagation of effects

After each update or event handling, we propagate the corresponding effects (i.e., changes

to annotations) on adjacent nodes and edges in order to ensure correct annotations (e.g.,

activation of subsequent task nodes). Further, we detect contradictory annotations related

to the data and resource perspectives (cf. Def. 10).

In particular, resources are propagated from task nodes to Not Marked (◻), dependent

resource nodes (r2) by following resource edges (r1). In turn, data values and the identifiers

of data containers are propagated from data flow edges to Not Marked (◻), dependent

data object nodes (d1) as well as data container nodes (d2). Next, the edge and its target

node are marked with Satisfied (✓) (x3).

Note that the aforementioned propagation steps are not performed, if resources, data

values or identifiers of target resource nodes, data objects or data containers were already

set to another value before. To highlight such conflicts, the corresponding data flow and

resource edges will be marked with Skipped (⨉) (x4). Not Marked (◻) data flow edges

will be also marked with Skipped (⨉) if the corresponding task or message node is completed

(d5). Afterwards, all conditions (x6) and relations are reevaluated (x7). If any element

of the eCRG, affiliated to a dependent task or message node, is now Skipped (⨉), the

corresponding task or message node will be marked with Skipped (⨉) as well (x8).

Next, the outgoing sequence flows of completed nodes are marked with Satisfied (✓)

(cf1). In turn, Not Marked (◻), incoming sequence flow edges of already started nodes are

marked with Skipped (⨉). Further, sequence flow edges from and to Skipped (⨉) nodes

An Operational Semantics for the eCRG Language 19

are marked with Skipped (⨉) as well (cf2). Task and message nodes become Activated

(△) when all incoming sequence flows, on which it depends, are marked as Satisfied (✓)

satisfied (cf3). In turn, task or message nodes will be marked with Skipped (⨉) when they

depend on incoming sequence flows being Skipped (⨉) before (cf4). Note that the latter

might trigger (cf2) again.

Definition 10 (Effect Propagation).

Let M∶=(m, res, val, id, ts, te)∈MΨbe a marking of eCRG Ψ. Then: prop ∶MΨ→MΨ,

prop(M)∶=(m(⋆), res(1), val(1), id(1), ts, te)propagates effects on M, whereby

res(1)(λ)∶=⎧

⎪

⎨

⎪

⎩

ρ, if (λ=(t, r)∈# »

pfm ∧m(λ)=◻∧res(t)=ρ)(r1)

∨(λ∈R∧res(λ)=∧(∃e∶=(t, λ)∈# »

pfm ∧λ≜e∧res(e)=ρ))(r2)

res(λ),else,

val(1)(λ)∶={υ, if λ∈O∧val(λ)=∧(∃e∶=(n, λ)∈#»

df ∶λ≜e∧res(e)=υ)(d1)

val(λ),else,

id(1)(λ)∶={ω, if λ∈C∧id(λ)=∧(∃e∶=(n, λ)∈#»

df ∶λ≜e∧id(e)=ω) (d2)

id(λ),else,

m(1)(λ)∶=

⎧

⎪

⎨

⎪

⎩

✓,if (λ∈R∧m(λ)=◻∧res(1)(λ)≠)(x3)

∨(λ∈O∧m(λ)=◻∧val(1)(λ)≠)(x3)

∨(λ∈C∧m(λ)=◻∧id(1)(λ)≠)(x3)

∨(λ=(t, r)∈# »

pfm ∧m(λ)=◻∧res(1)(r)=res(1)(λ))(x3)

∨(λ=(n, o)∈#»

df ∧o∈O∧m(λ)=◻∧val(1)(o)=val(1)(λ))(x3)

∨(λ=(n, c)∈#»

df ∧c∈C∧m(λ)=◻∧id(1)(c)=id(1)(λ))(x3)

⨉,if (λ=(t, r)∈# »

pfm ∧m(λ)=◻∧res(1)(r)≠res(1)(λ))(x4)

∨(λ=(n, o)∈#»

df ∧o∈O∧m(λ)=◻∧val(1)(o)≠val(1)(λ))(x4)

∨(λ=(n, c)∈#»

df ∧c∈C∧m(λ)=◻∧id(1)(c)≠id(1)(λ))(x4)

∨(λ=(n, o)∈#»

df ∧o∈O∧m(λ)=◻∧m(n)=✓)(d5)

∨(λ=(n, c)∈#»

df ∧c∈C∧m(λ)=◻∧m(n)=✓)(d5)

m′(λ),else,

m(2)(λ)∶=

⎧

⎪

⎨

⎪

⎩

✓,if (λ∈◇∧m(1)(at(λ))=✓∧λ(at(λ)))(x6)

∨(λ=(r1, r2)∈#»

rr ∪ ∧m(1)(r1)=✓∧m(1)(r2)=✓∧λ(r1, r2))(x7)

∨(λ=(o1, o2)∈#»

dr ∪ ∧m(1)(o1)=✓∧m(1)(o2)=✓∧λ(o1, o2))(x7)

⨉,if (λ∈◇∧m(1)(at(λ))=✓∧λ(at(λ)))(x6)

∨(λ=(r1, r2)∈#»

rr ∪ ∧m(1)(r1)=✓∧m(1)(r2)=✓∧λ(r1, r2))(x7)

∨(λ=(o1, o2)∈#»

dr ∪ ∧m(1)(o1)=✓∧m(1)(o2)=✓∧λ(o1, o2))(x7)

m(1)(λ),else,

m(3)(λ)∶={⨉,if ∃λ′∈Λ∶φ(λ′)=λ∧λ′≜λ∧m(2)(λ′)=⨉(x8)

m(2)(λ),else,

m(4)(λ)∶={✓,if λ=(n1, n2)∈# »

sf ∧m(λ)=◻∧m(3)(n1)=✓(cf1)

m(3)(λ),else,

m(5)(λ)∶=⎧

⎪

⎨

⎪

⎩

△,if λ∈T∪MN ∧m(4)(λ)=◻

∧(∀e=(n, λ)∈# »

sf ∶e≜λ⇒m(4)(e)=✓) (cf3)

m(4)(λ),else,

20 David Knuplesch and Manfred Reichert

for i≥6:

m(i+1)(λ)∶=

⎧

⎪

⎨

⎪

⎩

⨉,if (λ=(n1, n2)∈# »

sf ∧m(i)(λ)=◻∧m(i)(n1)=⨉)(cf2)

∨(λ=(n1, n2)∈# »

sf ∧m(i)(λ)=◻∧m(i)(n2)∈{▶,✓,⨉})(cf2)

∨(λ∈T∪MN ∧m(i)(λ)=◻

∧(∃e=(n, λ)∈# »

sf ∶e≜λ∧m(i)(e)=⨉))(cf4)

m(i)(λ),else, and

m(⋆)∶=m(j)(j∶=min{i∈N∣i≥6∧m(i)=m(i+1)}) is the final marking, which is

reached, when the propagation terminates.

Figs. 14-17 highlight the propagation after updates as well as after the handling of start,

message, end, and data events. In particular, Fig. 14 transfers the annotation Skipped (⨉) of

the time condition on the corresponding sequence flow edge that was marked with Satisfied

(✓) before. Based on this change, the subsequent task node solvency check is marked with

Skipped (⨉) as well and its Non Marked (◻), incoming and outgoing sequence flow edges.

Finally, the annotation Skipped (⨉) is propagated to the consequence absence task node

approval as well as the consequence occurrence task node approval. Hence, the final marking

Fig. 14(B′′) shows a temporal conflict.

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 18:03

B‘‘

customer

Mrs.

John amount

27,000

Mrs. John

27,000 > 10,000

<3d

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 15:27

B‘

customer

Mrs.

John amount

27,000

Mrs. John

27,000 > 10,000

<3d

+ propagation of effects

## 4/7/2013 16:05 update

Fig. 14: Effect propagation after updates and temporal conflict

In Fig. 15, the effects of a start event are propagated. In particular, the adjacent resource

edge and resource node become Completed (✓) and are annotated with resource Mrs.

Brown. Further, the Non Marked (◻), incoming sequence flow edge of the just started

task node solvency check is marked with Skipped (⨉). Finally, the consequence absence

task node approval becomes also Skipped (⨉).

Fig. 16 propagates the effects of an end event. In particular, the outgoing sequence

flow edges of the just completed message node request are marked with Satisfied (✓).

Furthermore, the subsequent task nodes solvency check and approval become Activated

(△).

The effects of data events are propagated in Fig. 17. In the upper example, the value

15,000 of the data flow edge used is written on the target data object amount that also

becomes Satisfied (✓). Further, the antecedence data condition the respective data flow is

successfully evaluated and hence also marked as satisfied. As opposed to this, the comparison

of the data object customer and its just written outgoing data flow edge fails. Hence, the

latter data flow edge changes from Satisfied (✓) to Skipped (⨉). Due to this change, the

subsequent task node solvency check is marked with Skipped (⨉) as well and its outgoing

An Operational Semantics for the eCRG Language 21

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 18:03

customer

Mrs.

John amount

27,000

Mrs. John

27,000 > 10,000

propagation of effects

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

2/7/2013

Mrs. Brown

15:43 – ...

1/7/2013 18:03

customer

Mrs.

John amount

27,000

Mrs. John

27,000 > 10,000

Solvency C.

2/7/2013

Mrs. Brown

15:43 – ...

<3d

77 2/7/2013 15:43 start 234 SolvencyCheck (Mrs. Brown)

Mrs.

Brown

Fig. 15: Effect propagation after handling start events

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 15:27

customer

Mr.

Smith amount

15,000

Mr. Smith

15,000

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 15:27

customer

Mr.

Smith amount

15,000

Mr. Smith

15,000

> 10,000 > 10,000

propagation of effects

39 1/7/2013 15:27 end 124 Request

<3d <3d

Fig. 16: Effect propagation after handling end events

sequence flow edge. Finally, the annotation Skipped (⨉) is also propagated on the following

consequence occurrence task node approval. Hence, Fig. 14(D)highlights a data conflict.

Finally, Def. 11 formally specifies the update of the state of an eCRG to the current

point in time as well as the processing of a particular event based on Defs. 5-10 and Fig. 9.

Definition 11 (Event processing procedure).

Let ML,i

Ψbe the state of an eCRG Ψafter processing event stream Luntil the ith position

(i∈N), and let σ∶=L(i+1)be the upcoming event on the following position of Land

ϑ∶=time(σ)∈Tbe the current point in time. Then:

–ML,i→ϑ

Ψ∶={M′∣M′=prop(updϑ(M))∧M∈ML,i

Ψ}is the state of Ψafter processing

event stream Luntil position iand after the update to the current point in time ϑand

–ML,i+1

Ψ∶={prop(M′)∣M′∈hdlσ(M)∧M∈ML,i→ϑ

Ψ}is the state of Ψafter processing

σ, i.e. after processing event stream Luntil position i+1.

Table 3 outlines the set of markings that results when completely processing the event

stream from Fig. 1 for compliance rule c1. Note that marking Fensures that c1is satisfied for

the request of Mr. Smith as highlighted in Fig. 18. In turn, Figs. 14(B′′), 17(D), 18(I), and

18(J) highlight conflicts regarding the data, control flow, time, and resource perspectives.

22 David Knuplesch and Manfred Reichert

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 15:27

customer

amount

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

- – -

1/7/2013 15:27

customer

amount

15,000

15,000 > 10,000

propagation of effects

15,000 > 10,000

Agent

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

2/7/2013

Mrs. Brown

15:43 – ...

1/7/2013 18:03

customer

Mrs.

John amount

27,000

Mrs. John

27,000 > 10,000

Mr. Smith

Agent

Mrs.

Brown

rating

≠

Request

Approval

- – -

Approval

- – -

Solvency C.

2/7/2013

Mrs. Brown

15:43 – ...

1/7/2013 18:03

customer

Mrs.

John amount

27,000

Mrs. John

27,000 > 10,000

Mr. Smith

78 2/7/2013 15:43 read 234 customer = Mr.Smith propagation of effects

<3d <3d

<3d

Mrs.

Brown

38 1/7/2013 15:27 write 124 amount = 15.000€

Fig. 17: Effect propagation after handling data events and data conflict

Note that such conflicts only indicate why the considered events do not constitute a solution

of a particular compliance rule. However, there might be another set of events that provide a

satisfaction. In turn, Fig. 15(d2) indicates, which data values shall be read by task solvency

check and how task approval shall be performed afterwards in order to satisfy c1. Hence,

Fig. 15(d2) may be utilized as recommendation to users in order to proactively ensure

compliance.

Table 3: Compliance state ML,99

Request Approval Solvency Approval customer cust→cust→amount rating Activated

# (CA) Check (CO) App.(CA) Solv.C

0△◻ ◻ ◻     

A✓124 △△◻Smith   15.000 ✓

B✓592 △△◻John   27.000 ✓

C✓124 ⨉✓234 Brown △Smith Smith 15.000 high

D✓592 △⨉234 Brown ⨉John Smith 27.000 

E✓592 ⨉453 Muller △◻John Smith 27.000 

F✓124 ⨉✓234 Brown ✓453 Muller Smith Smith 15.000 high

G✓124 ✓453 Muller △◻Smith Smith 15.000 high

H✓124 ⨉✓234 Brown ⨉642 Brown Smith Smith 15.000 

I✓592 ✓642 Brown △◻John John 27.000 

J✓129 ⨉642 Brown △◻Smith John 25.000 

An Operational Semantics for the eCRG Language 23

Agent

rating

≠

Request

Approval

- – -

Approval

2/7/2013

Mr. Muller

18:13 – 18:18

Solvency C.

2/7/2013

Mrs. Brown

15:43 – 15:55

1/7/2013 15:27

customer

Mr.

Smith amount

15,000

Mr. Smith

15,000 > 10,000

Mr. Smith

high

<3d

Mrs.

Brown

Mr.

Muller

Agent

rating

≠

Request

Approval

- – -

Approval

2/7/2013

Mrs. Brown

18:19 – ...

Solvency C.

2/7/2013

Mrs. Brown

15:43 – 15:55

1/7/2013 15:27

customer

Mr.

Smith amount

15,000

Mrs. Smith

15,000 > 10,000

Mr. Smith

high

<3d

Mrs.

Brown

Mrs.

Brown

Agent

rating

≠

Request

Approval

2/7/2013

18:19 – 18:23

Approval

- – -

Solvency C.

- – -

1/7/2013 15:27

customer

Mrs.

John amount

27,000

Mrs. John

27,000 > 10,000

<3d

Mrs. Brown

Mrs. John

27,000

Fig. 18: Fulfilling marking as well as control-flow and resource conflicts

24 David Knuplesch and Manfred Reichert

6 Compliance Analytics

Another fundamental requirement of any compliance monitoring approach is to provide

detailed user feedback. In this context, Section 6.1 introduces well-defined compliance as-

sessments that not only highlight compliance violations, but also identify their causes. In

addition, Section 6.2 shows how compliance metrics can be specified and how corresponding

measurements can be obtained. Finally, Section 6.3 provide recommendations that support

users in selecting the next process steps, whose execution will ensure compliance.

6.1 Compliance Assessments

Providing compliance assessments requires the analysis of the state of an eCRG and the

markings it contains in order to clearly determine the corresponding states of compliance; i.e.,

either Not Activated,Violable,Satisfied,Pending, or Violated (cf. Section 5.2).

For this purpose, first of all, Def. 12 introduces a partial order over markings. The latter

allows clustering the markings that correspond to each other as well as to specify and distin-

guish between different activations of an eCRG in Def. 13. Based on the latter, Def.14 finally

provides compliance assessments; i.e., calculates the state of compliance (cf. Section 5.2) in

order to enable simple and intuitive classifications.

Definition 12 (Extensions of Markings).

Let Ψ=(N, E, ◇, type, src, tgt, at, pt)be an eCRG and MΨthe current state of compliance

of Ψ. Further, let M=(m, res, val, id, ts, te)and M′=(m′, res′, val′, id′, t′s, t′e)be two

markings of Ψ; i.e., M, M′∈M. Then: We say

–We say Mis extended by M′and write M⪯M′, iff M′only differs from Min

markings that are neither Running (▶) nor Completed (✓) in M, i.e.,

M⪯M′∶⇔∀n∈T∪M∶m(n)∉{▶,✓}∨id(n)=id′(n)

Definition 13 (Activated Markings).

Let Ψ=(N, E, ◇, type, src, tgt, at, pt)be an eCRG and MΨbe the current state of com-

pliance of Ψ. Further, let M=(m, res, val, id, ts, te)be a marking of Ψ; i.e., M, M′∈M.

Then: We say

–Mis activated or an activation of Ψ(written as Activated(M)), iff Mmarks

each element of the antecedence occurrence pattern as satisfied, but does not satisfy any

element of the antecedence absence pattern. Furthermore, neither extends Manother

activated marking nor exists a marking in Mthat extends Mand satisfies a condition

of the antecedence absence pattern.

Activated(M)∶⇔((∀λ∈ΛAO

Ψ∶m(λ)=✓)

∧(∀α∈ΓAA,CO,CA

Ψ∶m(α)∈{◻,△,⨉})∧id(α)=)

∧(∀M2∈Mwith M⪯M2∶∀α∈ΓAA

Ψ∶m2(α)≠✓)

∧(∀M3∈Mwith M3⪯M∶¬Activated(M3))

An Operational Semantics for the eCRG Language 25

Definition 14 (Compliance Assessments).

Let Ψ=(N, E, ◇, type, src, tgt, at, pt)be an eCRG and MΨbe the current state of Ψ.

Further, let M∈Mbe an activated marking; i.e. Activated(M).

Then: We say

–Mis temporally satisfied (written as TempSatisfied(M)), iff there exists a

marking M2that extends Mand satisfies the consequence; i.e. M2marks each element

of the consequence occurrence pattern with Satisfied(✓) and does not satisfy any

element of the consequence absence pattern. Further, there exists no marking in M

that extends M2and satisfies a condition of the consequence absence pattern.

TempSatisfied(M)∶⇔(∃M2∈Mwith M⪯M2∶(∀λ∈ΛCO

Ψ∶m2(λ)=✓)

∧(∀α∈ΓCA

Ψ∶m2(α)∈{◻,△,⨉}∧id(α)=)

∧(∀M3∈MwithM⪯M2⪯M3∶∀α∈ΓCA

Ψ∶m3(α)≠✓))

–Mis violable (violably satisfied) (written as Violable(M)), iff Mis temporally

satisfied, but for each M2extending Mand satisfying the consequence pattern, there

remains at least one consequence absence node that has not been marked with Skipped

(⨉) yet; i.e. that node might be executed in the following steps.

Violable ∶⇔TempSatisfied(M)

∧(∀M2∈Mwith M⪯M2∶(∀λ∈ΛCO

Ψ∶m2(λ)=✓)

∧(∀α∈ΓCA

Ψ∶m2(α)∈{◻,△,⨉}∧id(α)=)

∧(∀M3∈MwithM⪯M2⪯M3∶∀α∈ΓCA

Ψ∶m3(α)≠✓)

∧(∃α∈ΓCA

Ψ∶m2(α)∈{◻,△}))

–Mis (permanently) satisfied (written as Satisfied(M)), iff Mis temporally sat-

isfied, but not violable; i.e.,

Satisfied(M)∶⇔TempSatisfied(M)∧¬Violable(M)

–Mis (permanently) violated (written as Violated(M)), iff each marking M2ex-

tending Mmarks an element of the consequence occurrence pattern with Skipped (⨉)

or there exists a marking M3extending M2and satisfying a condition of the conse-

quence absence pattern.

Violated(M)∶⇔(∀M2∈Mwith M⪯M2∶(∃λ∈ΛCO

Ψ∶m2(λ)=⨉)

∨(∃M3∈Mwith M⪯M2⪯M3∶∃α∈ΓCA

Ψ∶m3(α)=✓))

–Mis pending (written as Pending(M)), iff Mis neither (temporally) satisfied nor

violated yet.

Pending(M)∶⇔¬TempSatisfied(M)∧¬Violated(M)

Table. 4 applies Def. 14 to markings Aand Bfrom Table 3. Note that Aand Bare

the only activations of c1in ML,99

c1, since all other markings extend either marking Aor

B(except the initial marking 0). In particular, Table 4 shows that c1is activated twice;

once satisfied and once violated. Further, Table 4 emphasises the events that complete the

activations (39+58), the fulfillment (95), and the violation (99).

26 David Knuplesch and Manfred Reichert

Table 4: Compliance assessments and metrics

# Extensions Activated TempSatisfied Violable Satisfied Violated Pending

A{A, C, F, G}39-. . . 95-. . . 95-. . . 39-95

B{B, D, E, H}58-. . . 99-. . . 58-99

6.2 Compliance Metrics and Measures

In the context of multiple instances and activations of compliance rules, providing compli-

ance assessments for single activations is no longer sufficient. In turn, additional summaries

on an higher level are required. For this purpose, compliance assessments (cf. Sec. 6.1) are

combined to realize more sophisticated compliance metrics and measures. First of all, this

section formally specifies the cardinality of properties in Def. 15 and, then, shows how the

latter can be utilized for calculating compliance metrics and measures.

Definition 15 (Cardinality of a Property).

Let Ψ=(N, E, ◇, type, src, tgt, at, pt)be an eCRG and MΨbe the current state of compli-

ance of compliance rule Ψ. Then:

#Prop

Ψ∶=∣{M∈MΨ∣Prop(M)}∣is the cardinality of property Prop; i.e., the number

of markings with property Prop ∈{Activated,TempSatisfied,Violable,Satis-

fied,Violated,Pending}.

Note that it is easy to specify metrics based on Def. 15. As example consider Table. 5,

which refers to 3 metrics. In particular, the compliance rate µ1, the critical rate µ2, and the

violation rate µ3are defined and calculated with respect to the motivating example from

Section 3. (cf. Fig. 2 and Table 4).

Table 5: Compliance assessments and metrics

compliance rate µ1(c1)critical rate µ2(c1)violation rate µ3(c1)

µ1(c1)=#TempSatisfied

#Activated

µ2(c1)=#Violable

c1+#Pending

#Activated

µ3(c1)=#Violated

#Activated

# date time

0 1/7/2013 15:00 n.d. n.d. n.d.

1 1/7/2013 17:00 0

1=0.00 0+1

1=1.00 0

1=0.00

2 1/7/2013 19:00 0

2=0.00 0+2

2=1.00 0

2=0.00

3 2/7/2013 17:00 0

2=0.00 0+2

2=1.00 0

2=0.00

4 2/7/2013 18:18 1

2=0.50 0+1

2=0.50 0

2=0.00

5 2/7/2013 19:00 1

2=0.50 0+0

2=0.00 1

2=0.50

Table. 5 shows the progress of the compliance rate µ1(c1), critical rate µ2(c1)and vio-

lation rate µ3(c1)for compliance rule c1over time and along the event log from Fig. 2. As

long as no request is received, there is no activation of c1and hence all rates are not yet

defined (cf. line 0). Due the request from Mr. Smith at 1/7/2013 – 15:27 compliance rule c1

An Operational Semantics for the eCRG Language 27

is activated once in state Pending. Therefore, the critical rate µ2(c1)becomes 1.00, but the

compliance rate µ1(c1)as well as violation rate µ3(c1)become 0.00 (cf. line 1). In turn, the

values of µ1(c1),µ2(c1)and µ3(c1)are neither changed by the request from Mrs. John at

1/7/2013 – 18:03, which activates c2the second time, nor by the solvency check at 2/7/2013

– 15:43 (cf. line 2+3). This is due to the fact that the second activation of c1starts also in

state pending as well as the first activation remains pending even after the solvency check.

However, when the request of Mr. Smith is approved at 2/7/2013 – 18:13, the corresponding

activation is Satisfied. Hence, the compliance rate µ1(c1)increases to 0.50 and critical

rate µ2(c1)decreases to 0.50 as well, whereas the violation rate µ3(c1)stagnates at 0.00 (cf.

line 4). Finally, the second activation of c1becomes Violated by the approval at 2/7/2013

– 18:19. Accordingly, no activation remains Pending and the critical rate µ2(c1)drops to

0.00 In turn, the violation rate µ3(c1)increases to 0.50 as the compliance rate µ1(c1)did

before.

6.3 Recommendations

Section 5.4 argues that steps ensuring the compliant continuation of business process in-

stances can be recommend based on markings. However, this requires the selection of appro-

priate markings. Note that the simple approach taking the marking that provides the most

extensive extension of an activation does not always fit. Consider Table 6, which provides

the set of markings M95

Ψafter processing the event log from Fig. 2 up to event 95. For

both activations Aand Bthere is an extending marking (A⪯Cand B⪯D). However,

in the first case, Cprovides the adequate recommendation, whereas in the second case the

recommendation is not D, but B.

Table 6: Compliance state ML,80

Request Approval Solvency Approval customer cust→cust→amount rating Activated

# (CA) Check (CO) App.(CA) Solv.C

0△◻ ◻ ◻     

A✓124 △△◻Smith   15.000 ✓

B✓592 △△◻John   27.000 ✓

C✓124 ⨉✓234 Brown △Smith Smith 15.000 high

D✓592 △⨉234 Brown ⨉John Smith 27.000 

Def. 16 provides a more advanced and proper selection of markings that may then be

used as recommendation.

Definition 16 (Recommendations).

Let Ψ=(N, E, ◇, type, src, tgt, at, pt)be an eCRG and MΨbe the current state of compli-

ance rule Ψ. Further, let M∈MΨbe an activated and not violated marking; i.e., it holds:

Activated(M)∧¬Violated(M). Then: We say

–M2∈MΨis a simple recommendation for activation Mof compliance rule Ψ(writ-

ten as M⪯rM2), iff M2extends Mand M2neither skips any part of the consequence

occurrence pattern nor satisfies any part of the consequence absence pattern nor it there

is another marking M3∈MΨfurther extending M2, i.e.,

M⪯rM2∶⇔M⪯M2

∧(∄α∈ΓCO

Ψ∶m2(α)=⨉)

∧(∄M3∈Mwith M⪯M2⪯M3∶∃α∈ΓCA

Ψ∶m3(φ(α))=✓)

28 David Knuplesch and Manfred Reichert

–M2∈MΨis a (real) recommendation for the activation of Ψthrough marking M

(written asM⪯RM2), iff M2is a simple recommendation for Mand there is no other

recommendation M3∈MΨfor Mextending M2, i.e.,

M⪯RM2∶⇔M⪯rM2

∧∄M3∈Mwith M⪯rM3∶M2≺M3(i.e., M2⪯M3∧M2≠M3)

–R∶Mψ→2Mψ∶R(M)∶={M′∈MΨ∣M⪯RM′}is the set of all recommendations

for M.

Note that each marking M, which is Activated and not Violated, must have at least one

simple and, hence, also one real recommendation. Otherwise, it would match the definition

of Violated (cf. Def. 14).

The application of Def. 16 on our example results in R(A)={C}and R(B)={B}. Note

that the application of Rto an activation might still result in more than one recommen-

dation. In this case, each recommendation corresponds to another, already started solution

approach ensuring compliance with the respective rule. However, if only a single recom-

mendation is desired, the most advanced recommendation (i.e., satisfying most consequence

occurrence nodes) or the latest one can easily be selected.

An Operational Semantics for the eCRG Language 29

7 Summary and Outlook

This report introduces an operational semantics for the extended compliance rule graph

(eCRG) language [17, 18]. Beyond the control flow perspective, the latter supports the mon-

itoring of the data, time, and resource perspectives as well as the monitoring of the inter-

actions with partners. In particular, eCRGs are annotated with text, colors and symbols in

order to visually highlight the current state of compliance. Furthermore, formal definitions

specify how observed events continuously change and evolve these annotations. Further-

more, formal criteria for assessing compliance are provided, which, in turn, constitute the

basis for compliance metrics introduced as examples. Finally, the recommendations are pro-

vided, which support users in selecting the next process steps, whose execution will ensure

compliance.

As opposed to other approaches enabling the monitoring of business process compliance

at run-time, the operational semantics of the eCRG language supports all 10 compliance

monitoring functionalities (CMF) that have been proposed in [5] (cf. Table 7). In particular,

full support of the control flow, data, time, and resource perspectives (CMF 1-3) is provided

as well as interactions with partners are considered. The proposed approach assumes activ-

ities to be non-atomic, but stateful (CMF 4+5). Different instantiations (i.e., activations)

of compliance rules are explicitly identified and are further extended to highlight the causes

of compliance violations (CMF 6+9). Beyond detecting the latter (i.e. reactive monitoring),

recommendations (i.e., proactive monitoring) are provided as well (CMF 7+8). Finally, the

operational semantics of the eCRG language builds a suitable basis for the specification of

compliance metrics in order to measure different degrees of compliance (CMF 10).

Table 7: Compliance monitoring functionalities [5]

CMF 1 CMF 2 CMF 3 CMF 4 CMF 5 CMF 6 CMF 7 CMF 8 CMF 9 CMF 10

time data resources non life- multi- reactive proactive root compl.

Approach atomic cycle instance mgmt mgmt cause degree

Mubicon LTL [16] +/- - - + - - + + + +/-

Mubicon EC [15] + +/- + + + + + - +/- +/-

ECE Rules [26] + +/- + + - - + - +/- +

SCT [24] +/- - + + + - - + - -

SeaFlows [10] +/- +/- +/- + +/- + + + + +/-

eCRG Op. Semantics + + + + + + + + + +

Next steps will be the implementation of a proof-of-concept prototype in order to eval-

uate the operational semantics for the eCRG language.

Note that this work was done within the research project C3Pro that deals with change

and compliance in cross-organizational business processes [21]. Accordingly, our overall aim

is to ensure multi-perspective compliance for all phases of the process life cycle. Hence, we

will investigate a priori compliance checking with the eCRG at design time as well as we

plan to consider compliance checking in the context of cross-organizational process changes

and change propagation [44].

30 David Knuplesch and Manfred Reichert

References

1. Reichert, M., Weber, B.: Enabling Flexibility in Process-Aware Information Systems - Chal-

lenges, Methods, Technologies. Springer (2012)

2. van der Aalst, W.M.P.: Verification of workflow nets. In: ICATPN’97. Volume 1248 of LNCS.,

Springer (1997) 407–426

3. Reichert, M., Dadam, P.: A framework for dynamic changes in workflow management systems.

In: DEXA’97. (1997) 42–48

4. Ly, L.T., Knuplesch, D., Rinderle-Ma, S., G¨oser, K., Pfeifer, H., Reichert, M., Dadam, P.:

SeaFlows toolset - compliance verification made easy for process-aware information systems.

In: Information Systems Evolution - CAiSE Forum 2010. Volume 72 of LNBIP., Springer (2011)

76–91

5. Ly, L.T., Maggi, F.M., Montali, M., Rinderle-Ma, S., van der Aalst, W.M.P.: A framework for

the systematic comparison and evaluation of compliance monitoring approaches. In: EDOC’13,

IEEE (2013) 7–16

6. Sadiq, S., Governatori, G., Naimiri, K.: Modeling control objectives for business process com-

pliance. In: BPM’07. Volume 4714 of LNCS., Springer (2007) 149–164

7. Lenz, R., Reichert, M.: IT support for healthcare processes premises, challenges, perspectives.

Data & Knowledge Engineering 61(1) (2007) 39–58

8. Knuplesch, D., Reichert, M.: Ensuring business process compliance along the process life cycle.

Technical Report 2011-06, Ulm University (2011)

9. Ly, L.T., Rinderle, S., Dadam, P.: Integration and verification of semantic constraints in adap-

tive process management systems. Data & Knowledge Engineering 64(1) (2008) 3–23

10. Ly, L.T., Rinderle-Ma, S., Knuplesch, D., Dadam, P.: Monitoring business process compliance

using compliance rule graphs. In: CoopIS’11. Volume 7044 of LNCS. (2011) 82–99

11. Namiri, K., Stojanovic, N.: Pattern-Based design and validation of business process compliance.

In: CAiSE’07. Volume 4803 of LNCS., Springer (2007) 59–76

12. Alles, M., Kogan, A., Vasarhelyi, M.: Putting continuous auditing theory into practice: Lessons

from two pilot implementations. Information Systems 22(2) (2008) 195–214

13. van der Aalst, W.M.P., van Hee, K.M., van der Werf, J.M.E.M., Kumar, A., Verdonk, M.:

Conceptual model for online auditing. Decision Support Systems 50(3) (2011) 636–647

14. Ramezani Taghiabadi, E., Fahland, D., van Dongen, B.F., van der Aalst, W.M.P.: Diagnos-

tic information for compliance checking of temporal compliance requirements. In: CAiSE’13.

Volume 7908 of LNCS., Springer (2013) 304–320

15. Montali, M., Maggi, F.M., Chesani, F., Mello, P., van der Aalst, W.M.P.: Monitoring business

constraints with the event calculus. Transactions on Intelligent Systems and Technology 5(1)

(2014) 17.1–17.30

16. Maggi, F., Montali, M., Westergaard, M., van der Aalst, W.M.P.: Monitoring business con-

straints with linear temporal logic: an approach based on colored automata. In: BPM’11.

(2011) 132–147

17. Knuplesch, D., Reichert, M., Ly, L.T., Kumar, A., Rinderle-Ma, S.: Visual modeling of business

process compliance rules with the support of multiple perspectives. In: ER’2013. Volume 8217

of LNCS., Springer (2013) 106–120

18. Semmelrodt, F., Knuplesch, D., Reichert, M.: Modeling the resource perspective of business

process compliance rules with the extended compliance rule graph. In: BPMDS’14. Volume 175

of LNBIP., Springer (2014) 48–63

19. Kharbili, M.E., de Medeiros, A., Stein, S., van der Aalst, W.M.P.: Business process compliance

checking: Current state and future challenges. In: MobIS’08. (2008) 107–113

20. Becker, J., Delfmann, P., Eggert, M., Schwittay, S.: Generalizability and applicability of model-

based business process compliance-checking approaches. BuR - Business Research 5(2) (2012)

221–247

21. Knuplesch, D., Reichert, M., Mangler, J., Rinderle-Ma, S., Fdhila, W.: Towards compliance

of cross-organizational processes and their changes. In: BPM’12 Workshops. Volume 132 of

LNBIP., Springer (2013) 649–661

22. Accorsi, R.: An approach to data-driven detective internal controls for processaware information

systems. In: DUMW’12. (2012) 29–33

An Operational Semantics for the eCRG Language 31

23. Weidlich, M., Ziekow, H., Mendling, J., G¨unther, O., Weske, M., Desai, N.: Event-based mon-

itoring of process execution violations. In: BPM’11. Volume 6896 of LNCS., Springer (2011)

182–198

24. Santos, E., Francisco, R., Vieira, A., de F.R. Loures, E., Busetti, M.: Modeling business rules

for supervisory control of process-aware information systems. In: BPM’11 Workshops. Volume

100 of LNBIP. Springer (2012) 447–458

25. Maggi, F.M., Montali, M., van der Aalst, W.M.P.: An operational decision support framework

for monitoring business constraints. In: FASE’12. Volume 7212 of LNCS., Springer (2012)

146–162

26. Bragaglia, S., Chesani, F., Mello, P., Montali, M., Sottara, D.: Fuzzy conformance checking of

observed behaviour with expectations. In: AI*IA’11. Volume 6934 of LNCS., Springer (2011)

80–91

27. Liu, R., Vaculn, R., Shan, Z., Nigam, A., Wu, F.: Business artifact-centric modeling for real-

time performance monitoring. In: BPM’11 Workshops. Volume 6896 of LNCS., Springer (2012)

265–280

28. Baumgrass, A., Baier, T., Mendling, J., Strembeck, M.: Conformance checking of RBAC policies

in process-aware information systems. In: BPM’12 Workshops. Volume 100 of LNBIP., Springer

(2012) 435–446

29. Outmazgin, N., Soffer, P.: A process mining-based analysis of business process work-arounds.

Software & Systems Modeling (2014) 1–15

30. Awad, A., Weidlich, M., Weske, M.: Specification, verification and explanation of violation for

data aware compliance rules. In: ICSOC’09. Volume 5900 of LNCS., Springer (2009) 500–515

31. Knuplesch, D., Ly, L.T., Rinderle-Ma, S., Pfeifer, H., Dadam, P.: On enabling data-aware

compliance checking of business process models. In: ER’2010. Volume 6412 of LNCS., Springer

(2010) 332–346

32. Knuplesch, D., Reichert, M., Fdhila, W., Rinderle-Ma, S.: On enabling compliance of cross-

organizational business processes. In: BPM’13. Volume 8094 of LNCS. Springer (2013) 146–154

33. Knuplesch, D., Reichert, M., Pryss, R., Fdhila, W., Rinderle-Ma, S.: Ensuring compliance of

distributed and collaborative workflows. In: CollaborateCom’13, IEEE (2013) 133–142

34. Accorsi, R., Lowis, L., Sato, Y.: Automated certification for compliant cloud-based business

processes. Business & Information Systems Engineering 3(3) (2011) 145–154

35. Kumar, A., Yao, W., Chu, C.: Flexible process compliance with semantic constraints using

mixed-integer programming. INFORMS Journal on Computing 25(3) (2013) 543–559

36. Ly, L.T., Rinderle-Ma, S., G¨oser, K., Dadam, P.: On enabling integrated process compliance

with semantic constraints in process management systems. Information Systems Frontiers 14(2)

(2012) 195–219

37. Ramezani, E., Fahland, D., van der Werf, J.M., Mattheis, P.: Separating compliance man-

agement and business process management. In: BPM’11 Workshops. Volume 100 of LNBIP.,

Springer (2012) 459–464

38. Koetter, F., Kochanowski, M., Weisbecker, A., Fehling, C., Leymann, F.: Integrating compliance

requirements across business and it. In: EDOC’14, IEEE (2014)

39. Cabanillas, C., Resinas, M., Ruiz-Cort´es, A.: Hints on how to face business process compliance.

Jornadas de Ingeniera del Software y Bases de Datos 4(4) (2010) 26–32

40. Ly, L.T., Rinderle-Ma, S., Dadam, P.: Design and verification of instantiable compliance rule

graphs in process-aware information systems. In: CAiSE’10. Volume 6051 of LNCS., Springer

(2010) 9–23

41. Ly, L.T.: SeaFlows - A Compliance Checking Framework for Supporting the Process Lifecycle.

Dissertation Thesis, University of Ulm, Germany (2013)

42. Knuplesch, D., Reichert, M., Ly, L.T., Kumar, A., Rinderle-Ma, S.: On the formal semantics

of the extended compliance rule graph. Technical Report 2013-05, Ulm University (2013)

43. Gou, Y., Ghose, A.K., Chang, C.F., Dam, H.K., Miller, A.: Semantic monitoring and compen-

sation in socio-technical processes. In: ER’2014 Workshops. Volume 8823 of LNCS., Springer

(2014) 117–126

44. Fdhila, W., Indiono, C., Rinderle-Ma, S., Reichert, M.: Dealing with change in process chore-

ographies: Design and implementation of propagation algorithms. Information Systems 49

(April 2015) 1–24