SIRIUS’ planning beacon has started by developing a case study that looks at vessel movements and cargo transport in the North Sea. The goal is to improve the workflow of planners at Equinor by providing a better overview of the bottlenecks that could delay overall progress, the load on different vessels, and the quality of their logistics operations. We hope to improve both on the utilization of vessel capacity and on the timely delivery of material. In the initial phase of the project, we have used Real-time ABS as a modelling language to simulate and visualize the actual logistics operations. Compared to the tools currently used, Real-time ABS simulations provide a different level of overview which helps a user to gain precision in the decision-making phase.
Abstractly, a plan can be seen as a collection of tasks that are ordered by a dependency relation. To perform the plan, resources need to be allocated to different tasks. However, tasks from different plans compete for resources, which may delay the scheduling of plans. One idea we are pursuing, is to expose the resource requirements of the different tasks earlier in the planning process, such that a plan’s impact on the shared pool of available resources is explicit, and explore these requirements to improve visibility and facilitate scheduling.
Our initial case study already illustrates the general usefulness of Real-time ABS modelling, beyond the realm of computing systems. Thus far, we have only used Real-time ABS for simulations in this case study. The case study has also driven the development of new input and output facilities for the Real-time ABS simulator, to better facilitate the interaction between model simulation and real data about Equinor’s vessels and cargo transport. These new tools allow customizable visualization of output from the ABS simulator.
We are working with industrial data from different parts of a complex supply chain and integrate these into a uniform ABS model. The data covers transport plans for a large number of vessels moving between a supply base and installations, with logs for bulk and cargo delivery covering a twelve-month period, as illustrated below. In this use case, ABS is used to define a general framework for modelling transport plans by means of abstractions for, e.g., vessels, containers, bulk cargo, route segments, and delivery deadlines.
Raw operational vessel data
The model is populated by specific data to represent a plan. This is currently done by moving the data from Excel into a SQL database, then generating ABS data structures that correspond to the industrial data set. Thus, the industrial data set acts as the driver for the ABS simulation. The modeller specifies a time window, and data for this time interval is automatically extracted from the SQL database, converted into ABS data structures, and fed into the model as the concrete plan is simulated. This allows the ABS model of the concrete plan for the given time window to be simulated with up-to-date data. The planner is presented with a graphical view of the simulated plan, as depicted in the figure below. Our prototype allows the user to browse container lists for containers loaded to an offshore installation, or loaded on a vessel, and from there track the container’s content back to work orders. This graphical view is dynamically generated in-browser from JSON data fetched as output from the simulation. The display can be easily adapted by a frontend developer. No knowledge of ABS is needed to create different views over the simulation data.
We will combine these simulations with stronger analyses to generate solutions and verify their correctness with respect to requirements such as resource restrictions, safety regulations, and space limitations. This long-term perspective is illustrated by the following diagram, which shows the current work (in black) and some possible directions that can be explored (in red) to extend the current case study; these future directions provide concrete scientific challenges as well as added value in the planning processes.
Finally, it is important to remember that we can only plan up to a certain level of accuracy, and that external factors will always perturb the plans. For this reason, it is essential to have planning tools that expose changes in the underlying, assumed data, to facilitate fault mitigation and replanning on the fly. We are currently working with TechnipFMC and SAP to broaden the scope of planning beacon.