Every day, pipeline operators face complex operational decisions that need to be made quickly, on the ground, by the people running the business. Route optimisation, working out the most efficient path for product through a network, is one of the clearest examples: it has to account for constantly shifting conditions, and the answer that was right an hour ago might not be right now.
This whitepaper walks through how EnergySys, a low-code, cloud-native platform, was used to configure a working route optimisation application using Dijkstra’s algorithm, applied to a pipeline network. It’s a practical problem pipeline operators face constantly, and a clear example of how an algorithm most people associate with computer science can be configured and run by the business, not built for it by a specialist vendor.
Contrast that with typical gas management solutions built to handle this kind of routing logic: they’re often unwieldy and costly, requiring specialist skills to implement, customise, and maintain. The result is usually a brittle, inflexible application with a high total cost of ownership. This paper shows a different way to get the same answer.
This isn’t an academic exercise
Shortest-path algorithms like Dijkstra’s aren’t a theoretical curiosity borrowed from a computer science course. They’re an active area of applied research in exactly this field.
Research published in MDPI’s Energies journal on the optimisation of high-pressure gas networks confirms what operators already know from experience: getting this right measurably improves network efficiency and security of supply, not just theoretical elegance. Separate academic work has gone further still, applying modified versions of Dijkstra’s algorithm specifically to carbon capture and storage network planning, factoring in environmental sensitivity alongside cost, which is precisely the kind of extension this paper touches on later.
The platform choice matters just as much as the algorithm. Gartner projects the low-code development market to reach $44.5 billion by 2026, growing at a 19% compound annual rate. That growth is happening because enterprises want exactly what this paper demonstrates: the ability to configure genuinely technical logic themselves, on their own timeline, without the cost and rigidity of a bespoke build.
The problem: too many moving parts for a spreadsheet, too rigid for most software
Pipeline operators manage a long list of operational and commercial factors at once, all of them changing continuously:
- Pressure drop, caused by frictional resistance in the pipe wall and other components.
- Capacity, or line pack, which varies with pressure for compressible fluids.
- Operational limits based on the pipeline’s nameplate characteristics.
- Planned and unplanned maintenance affecting the delivery of the transmission service.
- Commercial factors, including capacity rights and the financial impact of operational decisions.
- Compressor management, ensuring compressors run when needed, for as long as needed, at the right output.
Working all of this out on a whiteboard or in a spreadsheet isn’t realistic once a network reaches any real size. But most enterprise solutions built to handle it are costly, slow to implement, and need constant specialist attention just to keep pace with the business. The question this paper answers is whether there’s a middle ground: the flexibility of a spreadsheet, with the integrity and power of a proper application.
The scenario
Picture a bi-directional pipeline network made up of nodes, receipt, storage, and delivery points, connected by pipeline sections. Not every node is connected to every other node. Each connecting section carries a weighting, an index number the business derives from continuous analysis of the operational factors above.
In this example, a pipeline operator needs to move gas from node A to node K across the network, and needs to know the optimal route from the chosen entry point to the chosen delivery point. Gas can be stored at intermediate nodes along the way, so the algorithm has to treat every node as a potential target, not just the final destination. And because the weighting across each section shifts throughout the day, the calculation needs to run fast and be easy to check.
Configuring the algorithm in EnergySys
Dijkstra’s algorithm is a well-established way to solve exactly this kind of network problem. At a high level, it starts at a given node, looks at every connected node it hasn’t already assessed, picks the one with the lowest weighting, and uses that as the starting point for the next round. It repeats until every node has been analysed.
EnergySys lets the end user configure objects, essentially data tables, to hold the data, and processes to perform the calculations against it, with the logic defined using standard Excel functions and formulas. For this example, four objects were needed:
- Node: the list of nodes, with a description, longitude, and latitude for each.
- Visited: the list of nodes the algorithm has already assessed during its run.
- Network: the relationship between nodes and the weighting on each connecting section.
- Result: the output of each execution of the algorithm as it works through the network.
With those objects in place, the algorithm logic itself sits in a process chain built from two processes. Process 10 takes the user’s chosen start node, organises the inputs, and kicks off the workflow. Process 20 applies Dijkstra’s algorithm to a single node at a time, using logic written in ordinary Excel functions, and calls itself again on the next node in the sequence until the whole network has been processed. Using Excel functions inside EnergySys’s calculation engine means the user gets the simplicity of a spreadsheet while handling one node at a time, at production scale.
Running the process
EnergySys offers several ways to trigger a process. This example uses a manual trigger, though in a live deployment an event-driven or scheduled trigger would be more likely. Process 10 takes the Node and Network objects as inputs, along with the chosen start node, runs the calculation logic, and writes the results back into the Visited, Result, and Run Process objects, the last of which hands off to Process 20. Process 20 then works through the network, tracking the node currently being analysed, the current round, and the previous round, filtering the input data as it goes to keep the process fast and the resulting log easy to follow.
Results and the audit trail
The results are visible directly in the application screens. As the workflow runs, the shortest path being identified builds up on screen, round by round, and the final screen shows the completed result once the algorithm finishes.
Every process run in EnergySys has an associated calculation log, showing the inputs, the logic applied, and the outputs written to the database. That log doesn’t just provide a complete, readable audit trail; it also lets users run their own offline scenario modelling. Opening any file in the log means the logic is fully visible and traceable, which removes the usual problem with black-box solutions: logic that only a costly consultant with little knowledge of your actual operation can create or check.
Results can be exported in .xlsx, .txt, .csv, or .pdf formats. EnergySys’s O-Data compliant web services API also lets business intelligence tools such as Power BI and Spotfire pull live data directly from the database, and recording each node’s longitude and latitude means the network itself can be mapped geographically to support further analysis, alongside other EnergySys solutions for pipeline operations more broadly.
The most efficient route
For this example, the algorithm finds that the most efficient path from node A to node K carries a total weighting of 34. The path itself, and how the algorithm builds up to that answer round by round, is visible directly in the Result screen and the calculation log described above, exactly the kind of transparency a pipeline operator needs when a regulator or commercial partner asks how a routing decision was made.
Beyond this example
This paper deliberately keeps the scope narrow, to show how straightforward it is to configure a genuinely technical application in EnergySys, and how capable the underlying calculation engine is. There’s plenty of room to extend it. Maintenance events, nomination forecasts, and commercial data could all be pulled into the same logic, and the platform could notify key business users of potential network issues before they happen.
The same style of calculation shows up elsewhere too. It’s typical of the kind of logic used in emissions and CCUS data management, for example, configuring routes to be selected by their environmental impact as well as their operational efficiency, so operators can weigh up commercial and environmental trade-offs side by side rather than as two separate exercises. This isn’t a hypothetical extension either: the academic research referenced above shows the same underlying algorithm already being adapted specifically for carbon capture and storage network planning, weighing environmental sensitivity alongside cost when deciding where a network should run. A configurable platform means that kind of extension is a configuration change, not a new procurement project.
That distinction matters more than it might seem. Building this kind of routing logic as a bespoke system, or buying it as part of a fixed gas management suite, usually means specialist consultants for the initial build and specialist consultants again every time the business changes how it wants to weigh a route, add a new node, or bring in a new data source. A configurable platform puts that second cost back in the hands of the people who understand the network, which is where the total cost of ownership argument in the abstract of this paper actually comes from: it isn’t that EnergySys is cheaper to build once, it’s that it stays cheap to change.
Ancala Midstream took a similar approach when building STAR on EnergySys for the Scottish Area Gas Evacuation pipeline: nominations, allocation, and network logic configured directly by the team who run the pipeline, not built for them by an outside vendor, and extended by that same team as new requirements, including emissions tracking, came in over time.
EnergySys also connects to a wider network of partners who bring their own products, algorithms, and template applications, giving engineers, analysts, and technologists a substantial head start when building their own enterprise-scale technical applications.
Want to see what this could look like for your own network? Explore the EnergySys platform, or book a call with our team.
