Keywords

1 Introduction

Compliance is about adherence to regulations, guidelines or predefined legal requirements like norms, laws and standards. Compliance verification in business process management is addressed at different levels of the life cycle i.e. deign time, runtime, post runtime. A hybrid approach addresses compliance verification for all levels [1]. Moreover, existing research has made significant contribution to addressing verification of models for compliance with a range of requirements such as, activity ordering requirements [2,3,4,5,6,7,8,9], resource assignment constraints [10,11,12,13], data requirements [14, 15], security requirements [16,17,18,19,20] and privacy [21,22,23,24,25,26,27], compliance between process variants [28,29,30,31]. These works show the state of the art in business processes compliance management and verification. They have also resulted into various compliance approaches, frameworks, methods, languages and tools. However, more compliance challenges need to be addressed to fully support collaborative processes in the context of a virtual factory.

In this paper, we look at the compliance of running collaborative business processes with data constraints. The paper proposes a new way to describe data constraints using descriptive logic (DL) and Linear Temporal Logic (LTL). The traces of the running processes are used to check whether the current collaborative business processes are compliant with the data constraints described in DL and LTL.

The structure of the paper is as follows: related work is presented in Sect. 2. Section 3 introduces an exemplary business process and related traces. DL and LTL are used to express the data constraints in Sect. 4. Section 5 shows how to present compliance properties as well as related verification algorithms. Future work and conclusion are presented in Sect. 6.

2 Related Work

Pesic et al. propose DECLARE, a declarative constraint based specification language and model compliance checking in relation to ordering requirements [2, 3]. The language is limited to control flow checking. Similar work is presented by Awad et al. and Wynn et al. Awad et al., propose a BPMN-Q language which extends BPMN to search for segments of a process model affected by changes and verify their compliancy in terms of control flow.

Whereas Wynn extends YAWL language with reset nets to determine correctness of business processes with cancellation and OR joins, other work by Elgammal et al. and Taghiabadi present compliance frameworks for managing the compliance of a business process during its life cycle. The constraints are organised according to patterns like control flow, resources, temporal and data [7, 9]. Despite the fact that the frameworks comprehensively cover all perspectives of the business process, the proposed languages employ complex mathematics and logics that are not intuitive for ordinary end users.

Data specific constraint checking approaches check compliance between the model and data requirements. Knuplesch et al. propose a graph method for modelling compliance rules and address verification through structured compliance checking based on compliance rules and data checking based on abstracted data [14]. The resultant graph based approach is data constraint based. Borrego and Barbara enhance earlier work of Declare to include data requirements compliance checking [15]. In this paper we extend our earlier work for supporting compliance verification in collaborative business processes [32,33,34]. Related work remains limited in various ways; the compliance management framework by Elgammal et al. results into a compliance request language in which constraints can be specified by ignores their verification. Taghiabadi’ s compliance approach caters for verification for control flow and data constraints. However, its application to collaborative environments is not demonstrated, it is also a domain specific approach and so is Declare language. Wynn et al.’s work based on YAWL is geared towards control flow verification to achieve model soundness. Data constraints are not considered by the authors. Moreover, non of these works presents mechanism easily comprehensible for non-expert end users. This limits their application. Our work leverages previous work by supporting specification of data constraints and verifying for their compliancy with collaborative business processes using an approach that empolys syntactic and semantic mechanism close to natural language. Besides, we provide a coarse grained approach in which we cater for data constraints in terms of accessibility, authentication and privacy by means of access control and authorisation. This is a valuable contribution in the wake of revised compliance requirements of the 2008 general data protection regulation.

3 An Exemplary Business Process and Related Traces

We adopt an abstracted industry based use case, the Pick and Pack business process proposed in [33]. In this case, customers submit orders online after registering on the system. Stores’ staffs check order details, and proceed to process the order as Fig. 1 illustrates.

Fig. 1.
figure 1

Pick and Pack business process

Full size image

Order processing involves activities summarised in Table 1 and assigned roles: Based on the role assignments, the following resource assignment conditions apply;

Table 1. Process activities and role assignments
Full size table
  1. 1.

    Pickers cannot participate in the verification of orders.

  2. 2.

    Packers can also do the verify order task.

  3. 3.

    Pickers can participate in hand over task at peak times

  4. 4.

    Supervisors oversee other employees and can execute any task.

Supervisors delegate or share rights of task execution to other staff, e.g. supervisors can delegate pickers to pack items.

Relatedly, the constraints governing data access are summarized;

  1. 1.

    Supervisors have full data access and can grant access to other staff.

  2. 2.

    Basic data must be accessible and available for staff to execute tasks that do not need much restriction and control. E.g. order list data.

  3. 3.

    Access control and authorization is observed for restricted data. For example, customer personal data, financial data among others.

  4. 4.

    For security of data and system, users must be authenticated by the system.

For illustration purposes, the business process is considered in terms of activities while traces are used as a mechanism to derive process execution to facilitate checking compliance to constraints. Table 2 lists sample traces based on the use case.

Table 2. Exemplified log showing events, activities, constraints and process instances
Full size table

4 Constraint Expression in Description Logic and LTL

To achieve constraint expression, descriptive logic (DL) [35] and LTL are adopted. While using DL, the business process is the domain of discourse with activities and constraints as concepts. The intention is to support expression of constraint requirements in a way close to natural language for easy intuition by non-experts yet expressive enough to support reasoning. DL is known for knowledge base representation and building in knowledge management systems [35]. Its application in business process design however has not received much attention with fewer applications in [10, 11]. The limitation is due to lack of known syntax to express unique business process requirements.

To enhance its expressiveness, we adopt logical operators and quantifier operators from temporal logic. Temporal logic is a formal method founded on mathematics. Models are specified and checked for correctness against a set of properties expressed as event orderings in time [36]. Role representation establishes a link between the constraints and the activities while the role restrictions impose specific existential and value restrictions of a constraint over the activity. We use unary predicates to represent sets of individual constraints while binary predicates denote relationships between individual constraints. We further use composite predicates to denote relationships between different constraints.

4.1 Expressions of Data Requirements as Constraints in DL and LTL

Data constraints are based on data patterns [37] and represented as unary predicate expressions using DL and logical operators and quantifiers from LTL. Task execution requires access to data. E.g., ‘delivery’ task needs access to customer address and contact to be accessible. Further still, actions that a user can do must be pre-authorized i.e. action to read, write, modify. Thus, task data assignment \( TD \) is composed of a task, data object \( \left( o \right) \), value \( \left( v \right) \) and action \( \left( \partial \right) \). \( TD \) assignment is achieved by a function \( f: a \to o,v,\partial \) which maps data item attributes like value and action to a task. Figure 2 exemplifies task data assignment and the required attributes.

Fig. 2.
figure 2

Task and data assignment attributes

Full size image

Using DL constructs, the expression for \( TD \) is derived as; \( TD = a \to \left( {o\,{ \sqcap }\,v\,{ \sqcap }\,\partial } \right) \) and formalized as; \( a \to \left( {o \wedge v \wedge \partial } \right) \) in LTL. Based on Fig. 2, the use case, it follows that;

$$ TD = \left[ {Deliver_{Order} \to \left( {customer\_address\,{ \sqcap }\,BH14AA\,{ \sqcap }\,Read} \right)} \right] $$

Table 3 presents some examples of expressions as derived for data constraints in;

Table 3. Data constant expression in DL
Full size table

5 Verification Algorithms for Compliance to Data Constraints

Data constraints are based on Boolean conditional evaluations where the condition is either true or false. Depending on the outcome of the conditional evaluation assessed against predefined access policies, access is granted or denied. To check for compliance, a constraint is satisfied if a trace is true for the given conditions, and the constraint is violated if trace is otherwise. To that effect, the following specifications and definitions are useful for the data constraints compliance checking algorithm.

Given a set of activities a1, a2 and a3 whose execution by role actor (r1) requires product catalogue data (Pcd). Access to this data is constrained by access and availability. If the assignment is true per the executed behavior, then the trace \( \left( \sigma \right) \) satisfies \( \left( { \vDash } \right) \) the constraint.

Definition 1: Accessibility and Availability (AA)

$$ \sigma \in (\left( {\left( {a_{1} ,a_{2} ,a_{3} } \right),r_{1} } \right):\left( {Pcd.\left[ {Read} \right]} \right):AA $$
(1)

If \( \sigma = True \) then \( \sigma \,{ \vDash }\,AA \)

The definition specifies accessibility and availability constraints for Pcd data object with action read granted to r1 for execution of activities a1, a2 and a3. During verification, the data compliance verification algorithm checks for compliance to the constraint for the data object, action by the user and tasks. If the outcome shows that the trace is true, then the availability and accessibility constraints satisfied. Otherwise, it is a violation detected for the AA constraint.

Definition 2: Authentication

$$ \sigma \in (\left( {\left( {a_{1} ,a_{2} ,a_{3} } \right),r_{1} } \right):\left( {Pcd.\left[ {True/False} \right]} \right):Authentication $$
(2)

If \( \sigma = True) \) then \( \sigma \,{ \vDash }\,Authentication \)

The definition specifies access control by authentication granted for Pcd data with actions to read and write for role actor (r1) who executes activities a1, a2 and a3. Satisfaction of the authentication constraint is achieved if the trace of the executed events exhibits the specified behavior. Otherwise, a violation is detected for the constraint.

Definition 3: Privacy (Prv)

$$ \sigma \in (\left( {\left( {a_{1} ,a_{2} ,a_{3} } \right),r_{1} } \right):\left( {Pcd.\left[ {Read} \right]} \right):Prv $$
(3)

If \( \sigma = True \) then \( \sigma \,{ \vDash }\,Prv \)

The definition specifies Privacy constraint for accessing Pcd data where action to read private data is to be granted for the resource actor r1 who executes activities a1, a2 and a3. During verification using the privacy compliance verification algorithm, the constraint is checked if it is satisfied before access is granted to private data. If trace is true to the specification, then the constraint is satisfied and thus compliance achieved. Otherwise, it is a violation detected for the privacy constraint.

5.1 Data Constraints Verification Algorithms

In this section, four algorithms are introduced, namely access and availability, authentication and privacy data constraints compliancy verification algorithms. At the end, an overall data constraint compliancy verification algorithm is presented.

Access and Availability Constraint Verification

Verifying Access and Availability data constraint ensures that basic non-exclusive data is accessible and available with less restriction to enable accomplishment of basic tasks. Algorithm 1 is composed to the effect. Violation occurs if role actors or tasks are denied access to data or where the permitted action type differs from the initial assignment, e.g. modify action type instead of read action type.

figure a

Violation of AA constraint as per Algorithm 1 exists when tasks or their actors(r, e.ac) are denied access. The violation results into to a deadlock or livelock. Deadlock occurs if running activities are denied access to data necessary for the process to progress, while livelock occurs when a task denied data access stays in waiting mode stagnating process execution. Another form of violation occurs when a task executes without necessary data resulting into wrong outcomes which compromise data integrity.

Verifying Compliancy with Authentication Data Constraint

Authentication Algorithm 2 verifies for compliance by checking that role actor credentials match the credentials stored in a database of authorized actors and their access privileges over tasks. Two forms of authentication errors lead to violations, i.e.;

  • Access leakage which occurs when non-authenticated users gain access to data. This is traced from running or finished events

  • Deadlocks which occur when users are authorised to execute activities but access to data is denied for technical or logical reasons e.g. improper configurations.

    figure b

When data constrained by authenticity constraint exists outside the constraint it leads to access leakage since it will be accessible by users without authentication or if it is accessed by non-authenticated role actors. Similarly, where data is not accessible to authenticated actors leads to a deadlock since they cannot progress with the current work being executed.

Verifying Compliancy with Privacy Data Constraints

Privacy constraint is enforced by means of access control and authorization. Authorization involves the process of validating that the authenticated user is granted permission to access the requested resources. Privacy as a data constraint restricts access to data regarded private as defined by GDPR. Data restricted from public access is enforced by authorization. Algorithm 3 checks whether the process is complying with the privacy data constraint. Violation to privacy constraint is checked targeting two forms of errors; deadlocks and privacy breach.

  • Deadlocks occur when the executing events authorised to access data are denied access for technical or logical reasons e.g. improper configurations,

  • Breach to privacy i.e. non-authorised activities eventually access private data and execute.

    figure c

When data constrained by privacy constraint exists outside the constraint, it leads to a leakage since it is accessible by non-authorized actors. Similarly, where authorized data is not visible in ‘seen’ and ‘finished’, it implies denied access as a form of violation.

The overall compliance verification Algorithm 4, is a general algorithm that invokes Algorithms 1, 2 and 3 to check whether the entire business process complies with above mentioned data constraints.

figure d

6 Conclusion and Future Work

Regardless of the industrial sector, compliance is a major concern not only to keep pace with changing regulations but to address the rising concerns of security, product and service quality and data privacy which are fundamental for implementing industry 4.0. With the EU GDPR in force, concerned organizations (European or otherwise) must meet its requirements by reviewing and realigning their business processes. It is necessary for software to be designed accordingly to reduce overheads from organizational measures used in the interim. In this spirit, we propose a new way to check the compliance of current running business processes. DL and LTL are used to describe the constraints related to data. Related algorithms are presented to detect the potential violations, i.e. data access and availability violation, data authentication violation, and data privacy violation. The research of collaborative process model verification covered also control flow and resource constraint verifications. For page limitation, we only present data constraint verification in this paper. Further research related to data constraint verification will carry out the practical implementation and evaluations as the next step.