Count your variables before you shop for a solver
Four decisions that often sit in different operational disciplines: how to coordinate signal timing across a network, where to route an evacuation in a tunnel that has just lost three assets, how to stage ventilation fans at minimum energy without eating into the safety margin, and when to send maintenance crews out given parts availability and the low-traffic windows they need.
Each one reads like a traffic engineering question. Several can be formulated as combinatorial optimisation problems instead, and that reformulation is worth doing carefully before anyone starts comparing solvers.
When the time budget becomes the constraint
Take ventilation staging in a tunnel with twelve jet fans, each with four settings. Four to the twelfth power, about 16.8 million configurations. The combinatorics alone stay manageable as long as each configuration is cheap to evaluate.
The single decision is therefore not the interesting case. The hard version is that same decision across a rolling horizon, with several sections coupled through the airflow they share and a traffic state that keeps shifting underneath you. A fire scenario branches off the whole thing, though the immediate response is a pre-engineered case that does not wait for a solver to finish; optimisation belongs to the staging and traffic decisions that follow.
Classical solvers handle large combinatorial problems extremely well. The interesting cases are those where a rolling horizon, a changing network state, and a tight decision window turn solution quality against computation time into an operational constraint. That is the baseline a quantum-inspired approach has to beat.
What a QUBO formulation actually involves
QUBO, quadratic unconstrained binary optimisation, is a common formulation for annealing-based and quantum-inspired optimisation, and it is the input format Fujitsu’s Digital Annealer accepts. Everything becomes a binary variable and a single quadratic cost function, and the solver hunts for the configuration with the lowest energy.
For the fan staging problem, let x(i,s) be 1 when fan i runs at setting s. The solver minimises the objective, the total electrical power of all selected settings. Constraints then arrive as penalty terms. Each fan runs at exactly one setting, so a term punishes any solution where a fan’s settings don’t sum to one.
Then the airflow requirement, and this is where it gets awkward. The section needs at least a given volume of air moving in the right direction. That is an inequality, and the U in QUBO stands for unconstrained: the format has no inequalities. In a conventional slack-variable formulation the requirement gets re-expressed with additional binary variables, whose only job is to absorb the difference between the required minimum and whatever the configuration delivers. Slack-free penalty formulations exist, so the encoding is a design choice, not a given.
Constraints can dominate the variable count
This is the part that catches people out on their first real formulation.
Twelve fans with four settings gives you 48 binary variables. A QUBO may start there and grow substantially once you encode the operating constraints: the airflow requirement, the CO threshold, the safety margin, and run-hour balancing if you constrain it rather than fold it into the objective. In a conventional slack-variable formulation, the constraint representation can add as many variables as the equipment model itself, or more, depending on the numeric range and resolution being encoded.
So a better question to ask any QUBO platform than how many variables it supports is: how many of yours will turn out to be constraint encoding once the operational requirements are written down honestly.
Quantum-inspired means classical hardware
Fujitsu’s Digital Annealer deserves precision here, because the naming invites confusion. It is quantum-inspired classical computing implemented with digital circuitry, not a quantum computer. Fujitsu documents room-temperature operation without the cryogenic environment required by quantum annealing hardware.
It has been a commercial service since 2018, and the current service accepts QUBO input and supports problems up to roughly 100,000 binary variables. That 100,000-bit figure is the solver-service maximum; the dedicated hardware unit provides 8,192 fully coupled bits.
Independent researchers have benchmarked Digital Annealer against Gurobi and D-Wave approaches in an industrial scheduling case, comparing solution quality and end-to-end runtime across different formulations and solver combinations (Schmidbauer and colleagues, Scientific Reports 13, 17471, 2023, on an industrial transport-robot scheduling problem). The results reinforce the reason to benchmark the actual use case rather than infer performance from a solver label or vendor chart.
A benchmark without a credible classical baseline proves little. Any result we eventually publish will carry one.
Where this belongs in the architecture
This kind of optimisation belongs in the decision-support layer. Safety-critical execution remains in the deterministic control architecture and follows the applicable safety, cybersecurity and authorisation requirements.
The same boundary applies that we described for live simulation in the control room and for pre-engineered response cases in tunnel operations. A solver proposes a ventilation plan or a set of signal offsets, and the configured authorisation workflow decides whether to apply it. A tunnel management system that lets an optimiser act directly on the road has moved it into the control layer, where it inherits every obligation attached to it.
That boundary also has a cybersecurity dimension. Where the optimisation layer connects to operational control, the interface, identities, permissions and communication path become part of the OT security architecture. The ISA/IEC 62443 series provides a relevant framework for securing industrial automation and control systems and for addressing cybersecurity across the system lifecycle.
For a first production deployment, the credible path is additive: place optimisation alongside the existing control architecture as decision support, with execution remaining under the established authorisation workflow. For this deployment path, traffic flow optimisation starts as decision support; direct execution would require a separate control and assurance case.
Where we actually are
Benchmarking these use cases on quantum-inspired annealing hardware is the next step. The quantum simulator and real quantum hardware sit on a longer research track behind it.
No results to report yet. What exists is a formulation discipline: work out which operational decisions are genuinely combinatorial, write them as QUBO with every constraint made explicit instead of assumed, then hold whatever comes out against a classical baseline before it leaves the building.
That discipline pays off whichever solver wins, because quantifying the decision space honestly turns the choice of hardware into an engineering comparison rather than a procurement bet.
If you operate a network or tunnel where one of those four decisions is currently made by experience under time pressure, that is the conversation worth having. The real subject is which of your operational decisions runs on a search space your current process has never quantified.
Lillyneir designs and integrates traffic and tunnel management systems for motorway operators and road authorities. We are developing quantum-inspired optimisation as a decision-support capability alongside that work. If you have a problem class that looks like the ones above, we would like to hear about it.
