Talk to an engineer

· 2 min read · BluMargins

Digital control systems: the part of IT that has to be right the first time

A control system cannot pause for an update, cannot ask a person to retry, and has to justify every action it took. That changes how the software is built.

  • digital control systems
  • industrial

Most enterprise software gets a second chance. A failed request retries, a bad deploy rolls back, a user refreshes. A digital control system running a refinery, a grid, or a production line gets none of that. It cannot pause for an update, it cannot ask an operator to try again, and every action it takes has to be authorised, logged, and defensible months later in front of somebody who was not there.

Determinism is a requirement, not a target

Control loops need timing guarantees, which means deterministic fieldbus interfaces, redundant controllers, and a design where the failure of any single component is a documented degradation rather than a surprise. Availability of 99.999 per cent is not marketing; it is roughly five minutes of unplanned downtime a year, and it is achieved by engineering for failure rather than by hoping to avoid it.

The alarm system is the user interface

An operator during an upset does not need more information. They need less of the wrong information. Alarm rationalisation, shelving with an expiry, flood suppression, and priorities that reflect actual consequence are the difference between a system that helps and one that adds noise at the exact moment noise is most expensive. ISA-18.2 exists because this was learned the hard way.

Where AI genuinely helps

A fixed alarm threshold on a single tag cannot see a machine drifting out of its normal operating envelope across six correlated variables. A multivariate model can. So can a soft sensor that infers a laboratory result hours before the laboratory produces it, recalibrating itself every time the real result lands. This is where machine learning earns its place in a plant: not replacing control, but seeing what a limit cannot.

Why we do both halves

The hardest part of industrial IT is not the control layer or the enterprise layer. It is the boundary between them: getting plant data into the business without opening the plant up. Purdue-model segmentation, unidirectional gateways where the risk demands them, and contextualisation that turns a raw tag into a measure a business system can reason about. Firms that only do one half tend to design that boundary badly, because they only have to live with one side of it.

More from the blog

A model is not a product

Most AI projects do not fail at the model. They fail at the retrieval layer that never had the right context, the evaluation nobody wrote, and the guardrail nobody set.

All posts

Bring us the whole problem.

Tell us where the work is stuck, whether that is a model that never reached production, an application nobody can change, a data platform nobody trusts, or a plant the business cannot see. An engineer replies with a first read, not a sales deck.