Platform

Conundrum Platform is the runtime that closes the loop. It calculates optimal setpoints from live plant data, applies them and dispatches them to the control system, so a circuit runs hands-free inside the limits it has been given. Around that runtime sits a graphical environment for building, running and monitoring those solutions.

Isometric illustration of a control cabinet with screens showing a predicted trajectory, and signal paths running to a vessel and its pumps

What it is worth

The case for it is operational before it is technical.

  • The return comes out of assets already installed. Throughput, yield, energy per tonne and quality giveaway all move, because the controller trades them against each other rather than hitting one target at the expense of the next. Nothing is added to the plant to release it.
  • Weeks, not months, to a working solution. Solutions are assembled from reusable templates rather than written from nothing, so engineering time goes into the circuit rather than into the plumbing.
  • No production downtime to deploy. The platform joins the existing network as a layer above it. Nothing in the control system is modified or taken out of service to make room for it.
  • The gain is defended, not just delivered. The process model adapts as the plant changes, so holding the benefit does not depend on booking a re-engineering project every time the ore does.
  • It scales with the scope it is given. The same runtime drives one circuit or a coordinated plant-wide solution, and the value grows as more of the chain comes under control.

What makes it different

The controller tracks the plant

The Conundrum process model adapts against operating history instead of being frozen at commissioning, so the controller keeps tracking the plant rather than the plant it was built on.

Circuits are optimised together

Conundrum provides a plant-wide runtime, so sequential circuits are optimised as one system rather than reduced to simplified models that hide the interactions between them.

Your engineers build the next one

The Conundrum Python SDK and graphical user interface let your own process control engineers build and run new controllers, instead of raising a change request with a vendor.

See confirmation in the case studies. A grinding circuit held +2.64% mean throughput across a full operating year and the ore types in it, and classification and thickening controlled as one problem raised plant feed rate by 1.6 to 1.8%.

Inside the platform

Interactive process flow diagram in the Conundrum platform

Interactive process flow diagrams

Draw the circuit from an equipment library and bind live signals to it, so the control scheme is read against the plant it runs on.

Equipment library

Signal binding

Runtime application configuration showing job parameters and input parameters for an optimisation step

Runtime applications

Each solution runs as a sequence of configurable steps. Parameters, resources and handlers are declared and versioned, so what is running is inspectable.

Versioned steps

Python and Docker

AI-driven control dashboards in the Conundrum platform

Dashboards for each role

Operators, control engineers and managers each get the view their decision needs. The controller shows history, its forecast and the action it plans, against the limits it works inside.

Role-based views

Active constraints

Data connector configuration showing the choice of industrial data source protocols and sampling interval

Data quality and connectivity

Connectors bring in historian and control system data over standard industrial protocols, with signal validity, sampling and operating ranges set explicitly.

Standard protocols

Signal validity

Deployment, integration and security

An optimiser drives a running plant, so its design starts from what must never happen.

Above the control layer

Conundrum sits on top of the existing control system. Base-layer controls, interlocks and emergency shutdown keep their authority; the optimiser works inside the boundaries they set.

Deterministic in the loop

The algorithms in the running loop are mathematically defined and repeatable. Generative models are used offline only, for design and code generation. What reaches the plant ships as signed, scanned containers.

Operators keep the final say

One click moves between advisory and autonomous. Operators see which constraints are active and why a move is being asked for, so a recommendation can be judged rather than accepted.

Fails back cleanly

The platform holds a heartbeat with the control system and tracks every loop's health and latency. If the heartbeat stops, control sheds back to the operator bumplessly, with an alert.

On-premises, vendor-agnostic

Runs at Level 3 of the Purdue model: on-premises or in a cloud. Connects to Honeywell, Siemens, ABB, Rockwell and Schneider over OPC UA, MQTT, OData and the CIMPLICITY Open Interface.

Controlled and auditable

Permissions are set by role and attribute. Every user action, setpoint change and accepted recommendation is journalled for audit. Authentication uses the corporate directory; events go to existing security monitoring.

See it on your own plant

A desktop review of historian exports. No site visit.

Request a data assessment