Request-Based Production Planning in Refinery Simulation Models

       Many refinery simulation models represent a process as a network of material flows connecting process units, storage tanks, pipelines, and loading facilities. This approach is sufficient for mass balance calculations in steady-state process simulation. However, real refinery operations are governed by much more than product movement.
       Production decisions are continuously influenced by operational information originating from multiple independent sources. Process units adjust production according to monthly production plans, shipment schedules, customer orders, available tank capacity, product quality status, laboratory certification, equipment availability, and many other operational constraints. As a result, two refinery models with identical material flow diagrams may exhibit completely different operational behavior depending on the information available to decision makers.
       Within AnyLogic, material flows are typically represented using Fluid Library components, whereas request propagation is implemented as an event-driven logical layer provided by Petroleum Refining Library
       For example, a tank farm may contain enough diesel residuals, but if none of the tanks has completed quality certification, shipment cannot begin. Conversely, production may need to increase even when current product residual levels appear sufficient because a large shipment is scheduled for the following month or because another tank must be filled to the minimum level required for passportization. These decisions cannot be derived from material balances alone on which additionally affected by losses, additives, and removable streams.

       Therefore, an industrial digital twin must simulate two interconnected systems simultaneously:
        - the physical system, where hydrocarbons move through pipelines, process units, and storage tanks;
        - the information system, where production requests, shipment plans, quality status, operational priorities, and scheduling decisions propagate between model components, with production requests traveling upstream in the opposite direction of material flows.
       Only by modeling both material and information flows can a digital twin reproduce the decision-making logic used in real refinery operations. Information becomes an active driver of production rather than merely a record of completed events.

       Material flows and information flows serve fundamentally different purposes within a refinery digital twin. Material flows represent the physical movement of hydrocarbons through process units, pipelines, storage tanks, and loading facilities. The same request-based coordination principles apply to crude oil supply chain simulation.Information flows, in contrast, coordinate operations by communicating production requirements, shipment plans, operational priorities, and control requests between model components. Different request propagation strategies are required for flowing and accumulative tank farms.
       While material flows determine what is physically moving, information flows determine what should happen next. A production unit may continue operating without interruption even though no new information is received, but production schedules, tank allocation, shipment preparation, and operating modes are driven by information rather than by product movement itself. The two types of flows complement each other and together reproduce both the physical and decision-making behavior of a real refinery.
       While request-based control determines when equipment should change its operating mode, storage availability remains a separate constraint. In refinery digital twins, this constraint can be addressed through dynamic tank reallocation, which temporarily assigns reserve tanks between tank farms to balance storage capacity and support uninterrupted request execution. The execution of incoming requests can be monitored using accumulative tank farm performance metrics.

       Unlike conventional simulation models, Petroleum Refining Library (PRL) uses a request-based architecture to coordinate refinery operations. Some model components can generate requests, receive requests from other components, modify them according to its current state, and propagate them further through the network.
       Instead of relying solely on predefined control logic, decision-making becomes distributed across the model. Each object contributes to operational coordination based on local conditions while interacting with other components through a common request mechanism. This approach enables the digital twin to reproduce realistic planning and operational behavior across the entire refinery.

       Example. Consider a refinery model consisting of a process unit, an accumulative tank farm, a loading rack, and a pumping station. At the beginning of the simulation, the pumping station loads the monthly diesel shipment plan from the database, while the loading rack imports the arrival schedule and composition of rail tank cars for gasoline and diesel shipments. Based on this information, both components independently generate product requests to the tank farm. The execution of incoming requests can be monitored using accumulative tank farm performance metrics.
       The tank farm consolidates these requests and determines the required production volume. When generating a production request for the upstream process unit, it considers not only the planned shipment volume but also the current inventory of certified products, expected transfer losses, additive consumption, and other operational constraints. During the simulation, the tank farm may also issue lower-priority requests to prepare residuals for future shipment plans, replenish tanks whose residuals has fallen below the minimum level required for quality certification, or satisfy other operational objectives.

       A request-based architecture extends simulation beyond simple material flow calculations by introducing distributed operational decision-making. As a result, a refinery digital twin can reproduce the planning logic used in real industrial facilities while remaining scalable and easy to maintain.

       Together, these capabilities enable Petroleum Refining Library to model refinery operations as an interconnected decision-making system rather than a collection of independent material flows, resulting in more realistic production planning, logistics simulation, and digital twin behavior.
       Request-based production planning becomes even more effective when combined with dynamic tank reallocation. While requests coordinate equipment operation and production priorities, dynamic tank reallocation optimizes storage resource allocation by temporarily transferring reserve tanks between tank farms experiencing different capacity demands.

       Material flows determine what moves through a refinery, while information flows determine why equipment changes its operating mode. A realistic refinery simulation therefore requires both physical product transportation and information-driven operational coordination.
       By introducing a request-based architecture, Petroleum Refining Library extends conventional material flow simulation with distributed production planning, logistics coordination, and operational decision-making. Requests propagate through the model according to production plans, shipment schedules, residual levels, product quality status, and operational priorities, enabling downstream facilities to dynamically influence upstream production.
       As a result, the digital twin reproduces not only the physical behavior of refinery processes but also the planning and control logic used in real industrial operations. This approach enables more accurate production planning, refinery logistics simulation, shipment scheduling, and operational optimization while providing a scalable architecture for complex refinery digital twins.

1 What is request-based simulation?
Request-based simulation is an approach in which model components exchange operational requests instead of relying solely on material flows. These requests coordinate production, storage, and logistics according to current operational needs.

2 Why are material flows alone insufficient for refinery simulation?
Material flows describe how products move through the refinery but cannot represent production planning, shipment schedules, residual management, or operational priorities. Information flows are required to reproduce real decision-making processes.

3 What information can be carried by requests?
Requests may include production requirements, shipment plans, customer orders, inventory targets, quality certification status, tank availability, operational priorities, and other planning information.

4 How do requests propagate through the model?
Unlike material flows, which move downstream through the process, requests can propagate upstream. For example, shipment requirements generated by a loading rack or pumping station can trigger additional production at upstream process units.

5 What are the advantages of a request-based architecture?
A request-based architecture enables realistic production planning, flexible scheduling, distributed decision-making, production optimization, scalable model development, and seamless integration with refinery digital twins.

6 Is request-based simulation suitable only for refineries?
No. The same architecture can be applied to oil terminals, tank farms, gas processing plants, petrochemical facilities, pipeline transportation systems, and other industrial logistics networks where operational decisions depend on production plans and downstream demand.