Back to ontology

Table of Contents

Level Index

Logistics

Relations from Other Scenarios

Relations to Other Scenarios

Summary🔗

This scenario looks into how the cargo is transported to, from and within a construction site.

Models🔗

logs🔗

These are the topics (from topic_management) corresponding to the deliveries.

The delivery updates are converted to structured comments (from topic_management).

The comments (from topic_management) are appended to the topic (from topic_management) corresponding to a delivery.

status_labels🔗

The list of possible labels for a delivery status.

Definitions🔗

planner role🔗

Planner role (from actor_management) is for all people who are allowed to change a delivery.

delivery location🔗

The delivery location is the IfcZone where the cargo should be delivered.

delivery🔗

Delivery is a topic (from topic_management) which has a description, a Deadline and a Priority.

The delivery can be associated optionally with a delivery location.

The cargo is described as a text property of the delivery ("10 windows, 2 doors").

The delivery is assigned to an operator and associated with:

The topic (from topic_management) follows a pre-defined format.

The deliveries live in a semantically pre-defined topic board (from topic_management).

contact person🔗

The actor (from actor_management) who should be contacted if the operator have questions.

operator🔗

The operator is an actor (from actor_management) who executes the delivery.

Depending on the vehicle, this can be a truck driver or a crane operator etc.

delivery update🔗

A structured comment (from topic_management) representing the update of the delivery status:

The delivery updates live in logs.

The system should not allow the user to change the corresponding comment in the topic (from topic_management).

Scenario🔗

The labels for a delivery update are pre-defined during the system configuration in status_labels.

As-planned🔗

The tasks are imported from external <last planner system (from scheduling) such as Visilean (see "Scheduling").

Since it is too difficult to enrich the task information with the delivery-relevant information (such as selecting the operator and the delivery location), we have to provide an application that allows the user to add this extra information.

The planner role converts the corresponding task into a delivery (a structured topic (from topic_management)) and enriches it with the extra information.

The planner role can also update manually the status of the delivery (e.g., to cancel it) by adding delivery updates (as structured comment (from topic_management)).

The updates of the delivery status are kept track in the logs.

Analytics🔗

The KPI for delivery-in-time is updated, both delivery in number per week and variance.

The KPIs are based on the data from the logs.

Since delivery is a topic (from topic_management), many messages are structured as delivery update. However, unstructured messages are also possible. The unstructured messages should be ignored when computing the KPIs.

The planner role usually sets the last status of the delivery which is then used to determine how the delivery is counted in the KPIs (e.g., "on time", "delayed" etc.).

site

Scheduling🔗

The notifications regarding the unmet deadlines are handled by the "Topic Management".

Test Cases🔗

navigation correct on examples🔗

To be discussed. What is the easiest way to record a couple of scenarios so that we can repeatedly and automatically test them?

Acceptance Criteria🔗

To be discussed. What are the practically accepted refresh rates for the navigation? How much polling will be involved -- how many requests per second will the system face in low, normal and high usage?

What is the acceptable delay with sending out the messages? Can this be a bottleneck? How many messages per second in low, normal and high usage?