►Conceptual Model ^?

Conceptual Information Model ^?

The potentially relevant object types are:

customers,
service desks,
workObject waiting lines,
service clerks.

Potentially relevant types of events are:

workObject arrivals,
customers queuing up,
customers being notified/invited to move forward to the service desk,
receptions and case handlings,
workObject departures.

Notice that receptions and case handlings are activities, which consist of a start and an end event.

Both object types and event types, with their participation associations, can be visually described in a UML class diagram, as shown below.

A conceptual information model describing object types and event types.

Conceptual Process Model ^?

Event rules.
ON (event type)	DO (event routine)
workObject arrival	If the reception desk is busy, then the newly arrived workObject queues up, else a new reception service for this workObject starts.
end of reception	If the case handling desk is busy, then the served workObject queues up, else a new case handling service for this workObject starts. If there are still customers waiting in the reception desk queue, the next reception service starts.
end of case handling	The served workObject departs. If there are still customers waiting in the queue of the case handling desk, the next case handling service starts.

►Simulation Design Model ^?

In this model of the Department of Motor Vehicles, the two consecutive reception and case handling activities are modeled as the activities of two different processing nodes, using the standard modeling concepts of Processing Networks.

Information Design Model ^?

Since the simulation model is entirely based on the pre-defined Processing Network modeling concepts of WorkObject, EntryNode, Arrival, ProcessingNode, ExitNode and Departure, there is no need to to define any object type or event type.

The initial state definition consists of an entry node, two consecutive processing nodes, and an exit node. Since the number of arrivals at the entry node is limited by setting the entry node attribute maxNmrOfArrivals to 100, the simulations ends not because it reaches its end time, but because it runs out of future events (the FEL gets emptied).

Process Design Model ^?

Since the simulation model is entirely based on the pre-defined Processing Network modeling concepts of WorkObject, EntryNode, Arrival, ProcessingNode, ExitNode and Departure, there is no need to to define any event rule.

►See also

Other OES models for the same system/problem/domain:

ServiceDesk-1: A service queue model (one service and one queue) with two statistics: maximum queue length and service utilization. The model abstracts away from individual customers and from the composition of the queue.
ServiceDesk-2: A service queue model (one service and one queue) with one statistic: the Mean Response Time, which is the average length of time a customer spends in the system from arrival to departure. For recording their arrival time, individual customers are represented explicitly in a waitingCustomers queue.
ServiceDesk-3: A service queue model where the service is modeled as an activity with the service desk as its resource, for which the utilization statistics is computed automatically.
ServiceDesk-4: A service queue model where the service desk is modeled as a processing node of a processing network that has an entry node and an exit node for arriving and departing customers. The model is based on the pre-defined Processing Network concepts: WorkObject, Arrival, EntryNode, ProcessingNode and ExitNode, such that processing objects 'flow through the system'.
ConsecutiveServices: An activity-based service queue model of two consecutive service providers with customer waiting lines.

A Processing Network Model of Two Consecutive Services Back to simulation

►Conceptual Model ?

Conceptual Information Model ?

Conceptual Process Model ?

►Simulation Design Model ?

Information Design Model ?

Process Design Model ?