To unlock the full potential of Optioneer, you need to understand the key elements of Optioneer: components, multi-asset functionality and multi-objective optimisation (MOO). This article introduces these concepts, which will discussed in more detail throughout the remaining modules.
🧱Design Rules
Optioneer is configured via design rules. Each design rule contains unique logic which allows our user to model their development and implement their engineering assumptions. Each design rule can be toggled on/off and configured via the Parameters Window in Optioneer.
Figure 1 provides an overview of the key design rules in Optioneer and the flow of information from global parameters to asset design rules, from asset design rules to installation design rules etc.
Note that the asset installation priority design rule requires inputs from either the asset design rules or installation design rules. This leads to dependencies.
Figure 1. This flow chart shows the flow of information between the design rules in Optioneer. Data flows from the global parameters design rule to the asset design rules, to the installation design rules and then to the asset installation priority design rule. Data also flows from the asset design rules to the asset installation design rule.
👩👧👧Dependencies
👩👧👧Dependencies
Since data flows from the left to the right of the flow chart, this means the design rules to the right cannot be activated without the components to the left being activated. In practical terms, Optioneer cannot determine where to put tower foundations, without first determining where the towers can go. In the case that you activate a combination of design rules which do not satisfy dependencies, Optioneer will let you know.
If you create a configuration that contradicts the dependencies, Optioneer will prompt you to carry out an action that will resolve this. Follow the steps in 🔧Configuring the Core Design Rules to avoid issues relating to dependencies.
This modular design allows Optioneer to:
🎚 be applied to both simple routing scenarios and the most challenging ones.
🔎 be used for both a high-level skim of the project and for a more in-depth analysis
🧠 support those with little knowledge of the tool and turbo-charge our super-users!
Design Rules will be taught over three modules:
Advanced Onboarding 2: This module covers the core design rules. These are the only design rules you need to understand to configure Optioneer independently.
Advanced Onboarding 4: Installation design rules are discussed here.
Advanced Onboarding 5: All additional functionality can be explored via our design rules are discussed here. This includes routing within a specified corridor, considering the viewshed of your development or following other assets!
🌈Multi-Asset Functionality
Optioneer can take multiple asset types into account. For example, if you have an overhead line development, but need to underground it to cross a motorway, Optioneer can model that.
Multi-asset functionality offers a range of benefits:
Constraints are considered relative to the assets that can be installed there.
It automates the process of determining if routes are shorter or cheaper if parts of it are underground.
The cost estimates are reflective of the assets that are most suitable along the route.
For an example of how this works practice see 🌈Multi-Asset Projects.
🐮Multi-Objective Optimisation (MOO)
Multi-objective optimisation (MOO), is part of Optioneer's in-built AI functionality. It has been specifically designed to handle the unique challenges of linear infrastructure routing.
Linear infrastructure planning is an inherently complex process that involves teams specialising in many disciplines:
Engineering and network planning teams
Environmental and planning experts
Land Agents
Project/portofolio managers
Local communities
Routing of infrastructure is complex, with many different factors to take into account. A 'good' route from an environmental perspective, can often be far from ideal from a technical perspective.
Usually, when we think of optimisation, we think of trying to find the “best” solution for a given problem. By “best” we usually mean a solution that minimises some sort of function (usually called the “objective function”) that represents the problem we are interested in solving. For example, we might be interested in finding the path that has the shortest length, lowest CAPEX etc. Figure 2 provides an example of what this looks like. We have a range of solutions in which the objective, f(x), changes. The best solution in this case is where the CAPEX is minimised, at min(f(x)).
Figure 2. An example of a single objective being optimised. An example of this in the context of routing can include finding the route that costs the least, has the least environmental impact, or is the shortest.
However, routing of linear infrastructure often does not have a clear “best” solution. Different stakeholders are concerned about different factors and not everyone agrees on what “best” means. This is where multi-objective optimisation (MOO) comes in. In MOO, we are optimising for multiple objective functions simultaneously.
Let’s consider how Figure 2 would look if this is extended to consider two objectives. See Figure 3. This shows two objectives, in this case, penalty and costs. Various solutions are plotted in the form of points, each with an associated penalty and cost.
The solutions will create what is called a pareto front which is indicated by the light purple curve. These are the cases which are considered the ‘best’ because they either
have a low cost
have a low penalty
have a relatively low penalty and cost
Figure 3. An example of two objectives being optimised. An example of this in the context of routing can include finding the route that has a low cost, low environmental impact, or provides a good balance of both.
Understanding MOO is fundamental for unlocking the full value of Optioneer and understanding your results.
For supporting material on this topic see the following articles: