3.1. Discrete Processes and Event Graphs
A discrete process (DP), or discrete event process, consists of a (temporally) partially ordered set of events that causes a corresponding sequence of state changes of affected objects. When two or more events within such a process have the same order rank, this means that they occur simultaneously.
As an example of a DP we consider a manufacturing process with a workstation and three types of events: PartArrival events, ProcessingStart events and ProcessingEnd events. For obtaining a short process duration, the recurrence of PartArrival events is limited to three events.
The example process is described by the following list of events: PartArrival@1, ProcessingStart@1.01, PartArrival@5.4, PartArrival@6.5, ProcessingEnd@8.47, ProcessingStart@8.48, ProcessingEnd@11.95, ProcessingStart@11.96, ProcessingEnd@17.48, where an event expression E@t represents an event of type E occurring at time t.
How this process unfolds in time is illustrated by the following process log:
| Step | Time | Current Events | System State | Future Events |
|---|---|---|---|---|
| 0 | 0 | WorkStation-1{ bufLen: 0, status: "AVAILABLE"} | PartArrival@1 | |
| 1 | 1 | PartArrival | WorkStation-1{ bufLen: 1, status: "AVAILABLE"} | ProcessingStart@1.01, PartArrival@5.4 |
| 2 | 1.01 | ProcessingStart | WorkStation-1{ bufLen: 1, status: "BUSY"} | PartArrival@5.4, ProcessingEnd@8.47 |
| 3 | 5.4 | PartArrival | WorkStation-1{ bufLen: 2, status: "BUSY"} | PartArrival@6.5, ProcessingEnd@8.47 |
| 4 | 6.5 | PartArrival | WorkStation-1{ bufLen: 3, status: "BUSY"} | ProcessingEnd@8.47 |
| 5 | 8.47 | ProcessingEnd | WorkStation-1{ bufLen: 2, status: "BUSY"} | ProcessingStart@8.48 |
| 6 | 8.48 | ProcessingStart | WorkStation-1{ bufLen: 2, status: "BUSY"} | ProcessingEnd@11.95 |
| 7 | 11.95 | ProcessingEnd | WorkStation-1{ bufLen: 1, status: "BUSY"} | ProcessingStart@11.96 |
| 8 | 11.96 | ProcessingStart | WorkStation-1{ bufLen: 1, status: "BUSY"} | ProcessingEnd@17.48 |
| 9 | 17.48 | ProcessingEnd | WorkStation-1{ bufLen: 0, status: "AVAILABLE"} |
The events of a real-world DP happen in a coherent spatio-temporal region determined by the locations of the events' participants. In a simulation model, we may abstract away from the aspect of space and model objects without locations, implying that events and processes happen in time, but not in space.
A DP may be an instance of a discrete process type defined by a discrete process model. A discrete process type can be modeled in the form of an Object Event Graph, which is a basic DPMN Process Diagram.
The Event Graph modeling language proposed by Schruben (1983) defines directed graphs where the nodes are Event circles (representing typed event variables) that may be annotated with state change statements in the form of state variable assignments, and the directed edges are arrows representing event flows that may be annotated with conditions or delay expressions. In the case of a conceptual process model, event flow arrows express the causation of follow-up events. In the case of a simulation design model, event flow arrows express the scheduling of follow-up events according to the event scheduling paradigm of Discrete Event Simulation.
Object Event Graphs extend the Event Graph diagram language by adding object rectangles containing declarations of typed object variables and state change statements, as well as gateway diamonds for expressing conditional and parallel branching.
The following DPMN diagram shows an Object Event Graph defining a process pattern that is instantiated by the above discrete event process example.
This process model is based on the following Object Event (OE) class model:
Notice that the multiplicity 1 (standing for "exactly one") at the association end touching the object type class WorkStation expresses the constraint that exactly one workstation must participate in any event of one of the associated types (PartArrival, ProcessingStart, or ProcessingEnd), while the multiplicity 0..1 (standing for "at most one") at the other association ends (touching one of the three event type classes) expresses the constraint that, at any time, a workstation participates in at most one PartArrival event, in at most one ProcessingStart event, and in at most one ProcessingEnd event. Notice that a further constraint may be added: a workstation must not participate in both a ProcessingStart and a ProcessingEnd event at the same time.
A DPMN process design model specifies a set of chained event rules, one rule for each Event circle of the model. The above model specifies the following three event rules:
- On each PartArrival event, the inputBufferLength attribute of the associated WorkStation object is incremented and if the workstation's status attribute has the value AVAILABLE, then a new ProcessingStart event is scheduled to occur immediately.
- When a ProcessingStart event occurs, the associated WorkStation object's status attribute is changed to BUSY and a ProcessingEnd event is scheduled with a delay provided by invoking the processingTime function defined in the ProcessingStart event class.
- When a ProcessingEnd event occurs, the inputBufferLength attribute of the associated WorkStation object is decremented and if the inputBufferLength attribute has the value 0, the associated WorkStation object's status attribute is changed to AVAILABLE. If the inputBufferLength attribute has a value greater than 0, a new ProcessingStart event is scheduled to occur immediately.