The concepts of ATAPIS are implemented in a tool package, the ATAPIS Toolset. The ATAPIS Toolset allows specifying time-aware process schemas as well as checking their temporal consistency at design time. Furthermore, time-aware process instances may be executed and be continuously checked for any temporal constraint violation at run time.
Specifying Time-Aware Process Schemas
Fig. 1 depicts the process editor of the ATAPIS Toolset. It is based on the AristaFlow Process Template Editor, which we enhance with capabilities and language elements required to capture and implement fundamental time patterns. Currently, the ATAPIS Toolset covers the following time patterns: Time Lags between two activities (TP1), Durations (TP2), Fixed Date Elements (TP4), Schedule Restricted Elements (TP5), Time-Dependent Variability (TP8), and Cyclic Elements (TP9).
In order to enable time lags between two activities (TP1) and cyclic elements (TP9) we extend AristaFlow's process modeling language with time edges. In the process editor, such a time edge between two activities is visualized by a dashed line (cf. Fig. 1). In accordance with TP1, a time edge may be added between arbitrary activities that can be conjointly executed in the context of a process instance (i.e., a time edge must not be added between activities from exclusive branches). Furthermore, a time edge is configured in respect to the represented restriction (i.e., minimum and/or maximum time distance) and the kind of time lag (i.e., start-start, start-end, end-start, or end-end). The concrete configuration settings are reflected by a label attached to the time edge; e.g., the label E[0h, 2h]S which is attached to the time edge between activities prepare patient and perform treatment (cf. Fig. 1), describes a time lag with a minimum time distance of 0 hours and a maximum time distance of 2 hours between the end (E) of the former activity and the start (S) of the latter.
In turn, time patterns restricting a particular activity (or the process) (i.e., Duration, Fixed Date Element, and Schedule Restricted Element) may be configured with the corresponding properties editor. In Fig. 1, for example, activity prepare treatment is selected and the properties editor is shown in the lower part. In the upper section of this editor, the duration of the activity must be specified. In ATAPIS, durations are specified through three values, which can be interpreted as follows: usually, activity durations are contingent, i.e., it is possible to set up a duration range for any activity, the contingent minimum and maximum duration, however, the PAIS becomes aware of the effective activity duration only after its completion. Hence, the duration must not be restricted by the PAIS. In practice, however, activity durations usually represent worst case estimates; i.e., most durations may be restricted to some extend; we call this the flexible maximum duration. For better usability, the duration of the activity is visualized on the right side section of the properties editor.
In the lower section of the properties editor (cf. Fig. 1), two fixed date elements are specified for activity perform treatment. The one restricting the earliest start date of the activity retrieves its value from data element date. In turn, the fixed date element restricting the latest start date is set relatively to (i.e., 30 minutes after) the one on the earliest start date of the activity.
Similarly a schedule restricted element may be specified for any activity. In turn, this constraint is based on a language for representing collections of temporal intervals (e.g., formula [1-5]/days:during:weeks represents the first 5 days of each week; i.e., Monday--Friday).
Checking Temporal Consistency
A time-aware process schema is enacted by performing its activities in the specified order, while obeying the specified temporal constraints. Generally, a time-aware process schema is denoted as temporally consistent if it is possible to perform all execution paths without violating the temporal constraints involved. Note that temporal consistency of a time-aware process schema and its instances constitutes a fundamental prerequisite for a robust and error-free execution. For any PAIS supporting time-aware processes, therefore, a crucial task is to check temporal consistency of the process schema at design time as well as to monitor and ensure temporal consistency of process instances during run time. This is challenging since temporal constraints might interact with each other resulting in complex (hidden) interdependencies. For example, assume that a time lag is added between activities prepare patient and inform patient in the process schema depicted in Fig. 1 (cf. Fig. 2). Assume further that the time lag specifies that activity prepare patient must be completed at least one hour before inform patient may be started. In this scenario, ---although not directly obvious---the process schema can never be enacted without violating at least one of its constraints, i.e., the process schema is temporally inconsistent (cf. Fig. 2).
To check whether a particular process schema is temporally consistent, ATAPIS maps it to a specific time model (cf. Fig. 2). The latter allows us to capture the complex interdependencies between constraints, which are not explicit in process models. To support various consistency notions, the ATAPIS Toolset provides different implementations of the time model; e.g., using conditional simple temporal networks to check for weak or dynamic consistency or conditional simple temporal networks with uncertainty to check for dynamic controllability---a more restricted form of temporal consistency. Particularly, we choose these models since they allow us to exploit and reuse correct and sound checking algorithms for well founded models representing temporal constraints.
When analyzing the temporal perspective of a process schema one may also view the corresponding time model including any hidden temporal constraints resulting from interdependencies of the specified temporal constraints (cf. Fig. 2). To support a thorough analysis of the temporal perspective of a process schema (e.g., to analyze the impact of a particular date for a fixed date element), we additionally provide editing capabilities for these time models.
In the following we describe some processes which were implemented using the ATAPIS Toolset. These and other process schemas are also available for download and can be edited and executed using the ATAPIS Toolset.
Example 1: Thesis Management Process
This process describes the management of a bachelor or master thesis by a student. It was developed as part of our ongoing involvement in the analysis, modeling and optimization of the business processes at the Ulm University to be automated by its new campus management system.
The process comprises 12 activities with a duration (TP2). Moreover, it contains six time lags between activities (TP1), three fixed date elements (TP4), six schedule restricted elements (TP5), and one time-based variability (TP8).
Example 2: Engineering Change Management Process
This process schema represent an engineering change management process of a large german car manufacturer.
The process consist of ten activities with a duration (TP2). Moreover, it comprises three time lags between activities (TP3), three fixed date elements (TP4), one schedule restricted element, and one cyclic element (TP9).
Example 3: Customer Request Handling Process
This process originates from a project we conducted with a small order-to-build manufacturer, were we analyzed the complete process landscape of the company. It represents the main customer request handling process of the company.
The process itself consists of 14 activities with a duration (TP2). Moreover, it comprises seven time lags between activities (TP1), and one schedule restricted element (TP5).
(more coming soon)