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).

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.