5.2. The Load-Haul-Dump Model

Image by Clker-Free-Vector-Images

A haul service company accepts requests for hauling large quantities of earth from a loading site to a dump site, using dump trucks and wheel loaders.

You can run this model from the OES GitHub website, or inspect its OESjs code.

Our Load-Haul-Dump modeling problem is based on the chapter "Example Model 2: Earthmoving operation" in the book The Art of Process-Centric Modeling with AnyLogic by Arash Mahdavi.

Conceptual Model

A haul service company has resource pools for dump trucks and wheel loaders. While the activities go (back) to loading site, haul, dump and go home just require a truck (or a wheel loader) as a resource, load activities require both a truck and a wheel loader.

Conceptual Information Model

The potentially relevant object types are:

  1. haul service company,
  2. wheel loaders,
  3. dump trucks.

Potentially relevant types of events and activities are:

  1. haul requests coming in from customers,
  2. going to the loading site (an activity performed by trucks and by wheel loaders),
  3. loading (performed by wheel loaders using trucks as resources),
  4. hauling (performed by trucks),
  5. dumping (performed by trucks),
  6. going back to loading site (performed by trucks),
  7. going home when the job is done (performed by trucks and by wheel loaders).

Both object types and event types, together with their participation associations, can be visually described in a conceptual information model in the form of a special kind of UML class diagram, called Object Event (OE) class diagram, as shown below.

Figure 5-6. A conceptual OE class model describing object, event and activity types.

Notice that the association end annotations «rr» and «rp» denote resource roles and resource pools. A haul service company has resource pools for trucks and wheel loaders. The activity types haul, dump and go back to loading site have a resource role truck for assigning a truck to any activity of one of those types. The activity types go to loading site and go home have either a a resource role truck or a resource role wheel loader, as indicated by the alternative association constraint expressed with a dashed line annotated with {xor}. The activity type load has both resource role truck and a resource role wheel loaders for assigning at least one and at most two wheel loaders to any load activity (as indicated by the multiplicity "1..2" at the «rr» association end at the class wheel loaders).

Conceptual Process Model

The involved types of events and activities can be related with each other via resource-dependent activity start arrows and event scheduling arrows, as shown in the following DPMN process diagram:

A DPMN diagram showing a conceptual process model

Notice that there are three types of arrows in this DPMN diagram:

  1. Event Scheduling arrows, like the one between load and haul, have the meaning that the succeeding activity is started as soon as the preceding activity has been completed (there is no need for enqueuing a planned activity, since all resources required by the succeeding activity are provided by the preceding activity). Event Scheduling arrows are not part of BPMN, rather they have been proposed by Schruben (1983) for Event Graphs.
  2. A Multiple Events Scheduling arrow, like the one between requests and go to loading site, means that one instance of the preceding event type triggers multiple instances of the succeeding event type. In our example model, this means that one request event is followed by multiple go to loading site activities, one for each truck and each wheel loader assigned to the job.
  3. A Resource-Dependent Activity Start arrow, like the one between go to loading site and load activities, means that as soon as an activity of the preceding activity type has been completed, a new planned activity is added to the queue of planned activities of the succeeding type (and started as soon as all required resources are available).

The model shows that when a haul request comes in, the haul service company deploys multiple trucks and wheel loaders to the loading site, each of them performing a go to loading site activity, as indicated by the double arrow between the haul requests event circle and the go to loading site activity rectangle. Each of these activities leads to enqueuing a new planned load activity, as indicated by the resource-dependent activity start arrow from the go to loading site activity shape to the load activity shape. Such an enqueued (planned) activity is going to be dequeued and started as soon as the required resources become available. This means that as soon as a wheel loader is available, the next load activity is going to be started. When a load activity is completed, a haul activity and then a dump activity are going to start immediately, as indicated by the event scheduling arrows between them.

A more complete model prevents trucks to go back to the loading site and perform a load activity even when the job has been completed during the go back activity (resulting in haul and dump activities with an empty truck). For avoiding this uneconomic behavior, a second decision if the job has been done needs to be taken after the go back activity. In addition, the model has to describe that wheel loaders also go home when their job has been done. This is shown in the following refined model:

Figure 5-7. A refined conceptual process model.
Simulation Design

In our simulation design, we consider only one particular haul service company, which does not have to be modeled as an explicit object. Also, we abstract away from the fact that also wheel loaders have to go to, and return from, the loading site by assuming that they are already at the site when the dump trucks arrive.

Information Design Model

In the information design model, we need to define a status attribute for all resource object types, such as Truck and WheelLoader, and a duration function, typically representing a random variable, for each activity type:

Figure 5-8. An information design model defining object, event and activity types.

Notice how functions representing random variables, like the duration function of all activity types, are marked with the keyword (or UML 'stereotype') «rv» standing for "random variable". These random variable functions sample from a probability distribution function (PDF), which is symbolically indicated with expressions like Tri(30,50,40) standing for the triangular PDF with lower and upper bounds 30 and 50, and a median of 40.

Each activity type is associated with Truck or WheelLoader as their resource role(s), indicated with the association end stereotype «rr» standing for "resource role".

Process Design Model

A process design model, in the form of a DPMN process diagram as shown below, is derived from a conceptual process model by

  1. Abstracting away from items that are not design-relevant.
  2. Defining event variables, if needed.
  3. Defining object variables in the form of Data Object boxes for specifying state changes of objects affected by events.
  4. Formalizing decision conditions on the basis of event and object variables.
Figure 5-9. A computationally complete process design for the Load-Haul-Dump business process.