Conceptual Model
A conceptual information model of a workstation system, defining two object types and four event types, is shown in Figure 2
Figure 2: A conceptual information model of manufacturing workstation systems.
As expressed by the associations between the four event types and the two object types, for all fourtypes of events, there are the same two types of objects participating in them: parts and workstations,implying that each event of these four types involves a specific part and a specific workstation
Notice that the input buffer (filled with waiting parts) is modeled as an association end with namewaiting parts at the parts side of the association between parts and workstations, expressing the fact that atany point in time, a workstation has zero or more parts waiting in its input buffer for being processed
A conceptual process model of this system, describing four causal regularities in the form of eventrules, one for each type of event, is shown in Figure 3 in the form of a BPMN Process Diagram using Eventcircles connected with Sequence Flow arrows expressing (conditional) causation, and Data Objects attachedto Event circles
Figure 3: A conceptual process model of a manufacturing workstation system.
The four event rules described by the model shown in Figure 3 are
- When a part arrives, it is added to the input buffer and, if the workstation is available, there will be a processing start event for processing the newly arrived part.
- When a processing start event occurs, the next part from the input buffer is being processed and a processing end event is caused to occur sometime later (after the processing time has elapsed).
- When a processing end event occurs, this will cause a part departure event and, if the input buffer is not empty, another processing start event involving the next part from the buffer.
- When a part departure event occurs, the processed part will be removed from the workstation.
While BPMN requires to categorize all Event circles into one of the three categories Start or Intermediate or End Event and use a different visual syntax for them, this is not the case in DPMN.
Design Model
A simulation design model is based on a conceptual model. Depending on the purposes/goals of asimulation study, it may abstract away from certain elements of the real-world domain described by theconceptual model, and it adds computational elements representing design decisions, such as randomvariables expressed in the form of random variate sampling functions based on specific probabilitydistributions for modeling the random variation of certain system variables
An information design model of the single workstation system described above is shown in Figure 4.This model defines the multi-valued waitingParts association end to be ordered, which means that itcorresponds to a multi-valued reference property holding an ordered collection (such as an array list or aqueue) as its value
The information design model of Figure 4 defines that a PartArrival event must reference both a Partand a WorkStation, representing situations where specific parts arrive at specific workstations. Notice that,computationally, this model requires creating new Part objects (or retrieving them from an object pool)before a new PartArrival event is created (or scheduled), while it is more common in simulation models tocreate a new Part object only when an arrival event has occurred, which can be modeled by defining amultiplicity of 0..1 for the Part end of the PartArrival-Part association (with the meaning that PartArrivalhas an optional, instead of a mandatory, reference property with name part)
Figure 4: An information design model.
Notice that the model defines two class level operations (designated with the stereotype «rv») implementingrandom variate sampling functions: PartArrival::recurrence() complies with a triangularprobability distribution with minimum, mode and maximum parameter values 3, 4 and 8, whileProcessingStart::processingTime() complies with an exponential distribution with an event rateparameter value of 6
A process design model based on the object and event types defined by the information design modelof Figure 4 and derived from the conceptual process model of Figure 3 is shown in Figure 5
Figure 5: A process design model in the form of a DPMN Process Diagram.
Notice that, since all events happen at the same workstation, all three event scheduling arrows areannotated with the same event property assignment workStation := ws, which simply propagates the objectreference to the given workstation along the event scheduling chain. Such property propagation assignments(in event property assignment annotations), where a property value of a follow-up event is set to thecorresponding property value of the scheduling (or triggering) event, will be omitted (as implied by eventtypes having the same property names) for avoiding to clutter the process model diagrams
A DPMN Process Diagram, like the one shown in Figure 5, can be split up into a set of event rule diagrams, one for each of its Event circles, as shown in Table 1. This reduction of a DPMN process design model to a set of event rule design models, together with the operational semantics of event rules presented in (Wagner 2017), provides the semantics of DPMN Process Diagrams
Notice that an event rule design model can also be expressed textually in the form of a pseudo-code block with four parts: part 1 indicates the triggering event type and declares a rule variable representing the triggering event, part 2 declares further rule variables and initializes them, part 3 contains a state change script consisting of state change statements, and part 4 schedules follow-up events
Table 1: Event rule design models.
SIMPLE ACTIVITIES
A simple activity is an activity with zero or more participants, none of which is having a special meaning (such as being a resource or a processing object).
Conceptual Modeling of Simple Activities
Conceptually, an activity is a composite event that is temporally framed by a pair of start and end events. Consequently, whenever a model contains a pair of related start and end event types, like processing start and processing end in the model of a manufacturing workstation shown on the left-hand side of Figure 6 and Figure 7, they can be replaced with a corresponding activity type, like processing, as shown on the right-hand side
Figure 6: Introducing an activity type in a conceptual information model.
It is obvious that applying this replacement pattern leads to a conceptual and visual simplification of the models concerned
Figure 7: Introducing an activity type in a conceptual process model.
Design Modeling of Simple Activities
Like in a conceptual model, also in a design model, a pair of corresponding activity start and end event types (or Event circles), like ProcessingStart and ProcessingEnd in the source models shown in Figure 8 and Figure 9, can be replaced with a corresponding activity type (or Activity rectangles), like Processing , as in the target models shown in these figures
Figure 8: Extending basic OEM to OEM-A class models by introducing activity types.
In the case of an information design model, this replacement pattern implies allocating all features (attributes, associations and operations) of the classes defining the start and the end event type in the class defining the corresponding activity type, possibly with renaming some of them. In the example of Figure 7, there is only one such feature: the class-level operation ProcessingStart::processingTime , which is allocated to Processing and renamed to time
In the case of a process design model, the replacement pattern implies that an Event circle pair consisting of an Event circle intended to represent an activity start event type and an Event circle intended to represent an activity end event type, with an event scheduling arrow from the activity start to the activity end event circle annotated by a delay expression, is replaced by an Activity rectangle such that:
- All Data Objects attached to the activity end event circle get attached to the Activity rectangle (since an activity occurs when it is completed).
- All event scheduling arrows going out from the activity end event circle are turned into event scheduling arrows going out from the Activity rectangle.
- All activity start event scheduling arrows are replaced with corresponding activity scheduling arrows having an additional creation parameter assignment for the duration of a scheduled activity, which is set to the delay expression defined for the activity end event scheduling arrow. In the example above, Processing::time() in the target diagram is the same as the delay
- ProcessingStart::processingTime in the source diagram.
- When the activity start event circle has one or more attached Data Objects or any outgoing eventscheduling arrow that does not go to the activity end event circle, then an activity start event circlehas to be included in the Activity rectangle for attaching the Data Object(s) and as the source of theoutgoing event scheduling arrow(s).
Figure 9: Extending basic DPMN to DPMN-A process models by introducing Activity rectangles.
This Activity-Start-End Rewrite Pattern, which can also be applied in the inverse direction, replacing an Activity rectangle with an Event circle pair, defines the meaning of an Activity rectangle in a DPMN diagram. It allows reducing a DPMN-A diagram with Activity rectangles to a basic DPMN diagram without Activity rectangles
Notice that the target model of Figure 9 specifies two event rules:
- On each part arrival, if the workstation’s status is AVAILABLE, then the rule variable wsAllocatedis set to true and the workstation’s status attribute is set to BUSY, else the arrived part is added tothe workstation’s input buffer waitingParts. If the rule variable wsAllocated has the value true, thena new Processing activity is scheduled to start immediately with its (inherited) duration attributeset to the value obtained by invoking the time function defined in the Processing activity class.
- When a Processing activity ends, if the workstation’s input buffer waitingParts is empty, then theworkstation’s status attribute is set to AVAILABLE, else the rule variable wsReallocated is set totrue and the next part is removed from the input buffer waitingParts. If the rule variablewsReallocated has the value true, then a new Processing activity is scheduled to start immediatelywith its (inherited) duration attribute set to the value obtained by invoking the time function definedin the Processing activity class.
Notice that a workstation is an exclusive resource of its processing activity. The concepts of resources and resource-constrained activities are discussed in the following sections.
RESOURCE-CONSTRAINED ACTIVITIES
A Resource-Constrained Activity is an activity where one or more participants play a Resource Role (suchas Performer). Typically, a Resource-Constrained Activity is a component of a business process thathappens in the context of an organization or organizational unit, which is associated with the activity as itsProcess Owner
An activity of a certain type may require certain resources for being performable. At any point in time,a resource required for performing an activity may be available or not
A resource is not available, forinstance, when it is busy or when it is out of order.Resources are objects of a certain type. The resource objects of an activity include its performer. Whilein a conceptual model, describing a real-world system, a performer is required for any activity, a simulationdesign model may abstract away from the performer of an activity
For instance, a consultation activity may require a consultant and a room. Such resource constraintsare defined at the type level. When defining the activity type Consultation, these resource constraints aredefined in the form of two mandatory associations with the object types Consultant and Room such thatboth associations’ ends have the multiplicity 1 (“exactly one”). Then, in a simulation run, a newConsultation activity can only be started, when both a Consultant object and a Room object are available.For all resource-constrained activities, a simulator can automatically collect the following statistics:
For each activity type:
- the (average, maximum, etc.) queue length of its queue of planned activities;
- the (average, maximum, etc.) cycle time, which is the sum of the waiting time and the activity duration;
- the percentage of time each involved resource object is busy with an activity of that type (its utilization by activities of that type).
The percentage of time each resource object is idle or out-of-order.
For modeling resource-constrained activities, we need to define their types. A resource-constrained activity type is composed of:
- a set of properties and a set of operations, as any entity type
- a set of resource roles, each one having the form of a reference property with a name, an objecttype as range, and a multiplicity that may define a resource constraint like, e.g., “exactly oneresource object of this type is required” or “at least two resource objects of this type are required”.
The resource roles defined for an activity type may include the performer role. A simulation language for simulating activities needs to allow defining activity types with two kinds of properties: ordinary properties and resource roles. At least for the latter ones, it must be possible to define multiplicities for defining resource constraints. These requirements are fulfilled by OEM Class Diagrams where resource roles are defined as stereotyped properties using the stereotype «resource role» or, shorter, «res»
The extension of basic OEM by adding the concepts needed for modeling resource-constrained activities (in particular, resource roles with constraints, resource pools, and resource-dependent activity start arrows) is called OEM-A.
Conceptual Modeling of Resource-Constrained Activities
Modeling resource-constrained activities has been a major issue in the field of Discrete Event Simulation (DES) since its inception in the nineteen-sixties, while it has been neglected and is still considered an advanced topic in the field of Business Process Modeling (BPM). For instance, while BPMN allows assigning resources to activities, it does not allow modeling resource pools, and does neither allow specifying resource cardinality constraints nor parallel participation multiplicity constraints
In the DES paradigm of Processing Networks, Gordon (1961) has introduced the resource management operations Seize and Release in the simulation language GPSS for allocating and de-allocating (releasing) resources. Thus, GPSS has established a standard modeling pattern for resource-constrained activities, which has become popular under the name of Seize-Delay-Release indicating that for simulating a resource- constrained activity, its resources are first allocated, and then, after some delay (representing the duration of the simulated activity), they are de-allocated (released).
Resource Roles and Process Owners
As an illustrative example, we consider a hospital consisting of medical departments where patients arrive for getting a medical examination performed by a doctor in a room of the department. A medical examination, as an activity, has four participants: a patient, a medical department, a doctor and a room, but only two of them play a resource role: doctors and rooms. This can be indicated in an OEM class diagram by using the stereotype «resource role» for categorizing the association ends that represent resource roles, as shown in Figure 10
Notice that both the event type patient arrivals and the activity type examinations have a (mandatory functional) reference property process owner. This implies that both patient arrival events and examination activities happen at a specific medical department, which is their process owner in the sense that it owns the process types composed of them. A process owner is called “Participant” in BPMN (in the sense of a collaboration participant) and visually rendered in the form of a container rectangle called “Pool”. In Figure 10, the resource role of doctors is designated as the performer role. Also in BPMN, Performer is considered to be a special type of resource role. According to Section 10.2.2 in the BPMN 2.0 specification (BPMN 2011), a performer can be “a specific individual, a group, an organization role or position, or an organization”
One of the main reasons for considering certain objects as resources is the need to collect utilization statistics (either in an operational information system, like a workflow management system, or in a simulation model) by recording the use of resources over time (their utilization) per activity type. By designating resource roles in information models, these models provide the information needed in simulations and information systems for automatically collect utilization statistics.
Resource Pools and Resource Allocation
In the hospital example, a medical department, as the process owner, is the organizational unit that is responsible for reacting to certain events (here: patient arrivals) and managing the performance of certain processes and activities (here: medical examinations), including the allocation of resources to these processes and activities. For being able to allocate resources to activities, a process owner needs to manage resource pools, normally one for each resource role of each type of activity (if pools are not shared among resource roles). A resource pool is a collection of resource objects of a certain type. For instance, the three X-ray rooms of a diagnostic imaging department form a resource pool of that department
Resource pools can be modeled in an OEM class diagram by means of special associations between object classes representing process owners (like medical departments) and resource classes (like doctors and rooms), where the association ends, corresponding to collection-valued properties representing resource pools, are stereotyped with «resource pool», as shown in Figure 10. At any point in time, the resource objects of a resource pool may be out of order (like a defective machine or a doctor who is not on schedule), busy or available
Figure 10: The activity type “examinations” with two resource roles and two resource pools.
A process owner has special procedures for allocating available resources from resource pools to activities. For instance, in the model of Figure 10, a medical department has the procedures “allocate a doctor” and “allocate a room” for allocating a doctor and a room to a medical examination. These resource allocation procedures may use various policies, especially for allocating human resources, such as first determining the suitability of potential resources (e.g., based on expertise, experience and previous performance), then ranking them and finally selecting from the most suitable ones (at random or based on their turn). See also (Arias et al 2018)
In the conceptual process model shown in Figure 11, a doctor and a room are always allocated and released (de-allocated) together
Figure 11: A conceptual process model based on the information model of Figure 10.
This process model describes two causal regularities in the form of the following two event rules, each stated with two bullet points: one for describing all the state changes and one for describing all the follow- up events brought about by applying the rule
When a new patient arrives:
- if a room and a doctor are available, then they are allocated to the examination of that patient; otherwise, if a room or a doctor is not available, the patient is added to the waiting line;
- if a doctor and a room have been allocated, then start an examination of the patient.
When an examination is completed by a doctor in a particular room:
- if the waiting line is empty, then the room and doctor are released; otherwise, if there are still patients in the line, the next patient is fetched to be examined by that doctor in that room;
- if another patient has been fetched, then start the examination of that patient.
These conceptual event rules describe the real-world dynamics of a medical department according to business process management decisions. Changes of the waiting line and (de-)allocations of rooms and doctors are considered to be state changes (in the, not necessarily computerized, information system) of the department, as they are expressed in Data Object rectangles, which represent state changes of affected objects caused by an event in DPMN.
