Home / Services / SCADA & HMI

Automation projects

SCADA and HMI systems, specified before they are bought

Most SCADA overspend happens at the licensing table, months before anyone writes a graphic. Client counts, tag counts and what a second operator console actually costs are decisions that quietly set the price of the next ten years.

Request a plant data audit

The short version

The licensing questions to settle first

Every major SCADA platform licenses on a different axis, and the axis is what makes two quotations for the same plant differ wildly.

AxisWhat to checkWhy it bites
Tag or I/O countWhether the count is physical I/O, server tags, or every derived pointAlarm, calculated and historian tags can multiply a count several times over
Client countHow many simultaneous viewers, and whether web viewers are counted differentlyA view-only web client is often free or cheap where a full client is not
Station vs serverWhether the product you are buying can serve other machines at allSome station-class products are standalone by design. A second console is then a second licence, not a client
RedundancyWhether the standby needs its own full licenceDoubles a line item that was presented as a single number
HistorianRetention, tag count, and whether the client tools are separateReporting is routinely quoted after the fact
Worked example

On one widely used platform, the station-class product cannot host networked clients at all. So a request for "a second screen in the control room" is not a client licence, it is a second station licence plus a second machine. On the same platform, read-only web clients are free. The difference between those two answers is the whole budget, and it is decided before anyone draws a graphic.

Some platforms publish no list price at all and quote only through a channel. That does not mean you cannot control the number. It means the specification has to pin the tag count, the client count and the redundancy model precisely enough that two quotations are comparable.

Screens that work at three in the morning

An operator screen has one job: answer the question the operator is holding, in one look, without hunting. Almost every bad HMI fails the same way, by putting everything on the top level so that nothing stands out.

The structure that survives a night shift is layered:

  • Level 1 answers one question. Is the plant normal. Sparse, high contrast, no decoration, and an abnormal state is the only thing that draws the eye.
  • Level 2 is the area or unit. Enough to localise a problem and see the interlock that is holding.
  • Level 3 is the loop, the device, the trend, the parameter set. This is where detail belongs, and it is one click away, not on the overview.

Two rules that matter more than any style guide. Colour means state, never decoration, which implies a grey plant with colour reserved for abnormality. And alarms are rationalised before they are configured. An alarm nobody actions is worse than no alarm, because it trains the shift to clear the list without reading it.

Architecture, redundancy and the boring parts that keep it alive

Where the data actually lives

Decide early whether the historian is on site, at a group level, or both, and who is responsible for its backup. A historian nobody backs up is a reporting obligation waiting to fail an audit.

Redundancy that has been tested

Redundant servers that have never been failed over are not redundant, they are expensive. Failover gets tested at FAT, at commissioning, and then on a schedule, with the result written down.

Remote access, decided deliberately

Every plant ends up with remote access. The choice is whether it is designed, with a defined path, named accounts, logging and a change window, or whether it accumulates as a series of individual exceptions nobody has a list of.

The handover pack

Licences in the plant's name. Source projects, not just runtime. Server build documentation. A restore procedure that has been performed at least once, by someone other than the person who wrote it.

Questions we get asked

Can you work on an existing SCADA rather than replacing it?

Usually yes, and usually that is the right call. Extending, rationalising alarms, rebuilding a screen hierarchy or adding a historian to a healthy system costs a fraction of a replacement. Replacement is justified when the platform is out of support, the licensing model has become the constraint, or the server operating system can no longer be patched.

Do we need a second operator console?

Answer the licensing question before the hardware one. On some platforms a second console is a client licence, on others it is a second full station. On several, a read-only web viewer would have satisfied the actual requirement at a fraction of the cost.

How many tags do we actually need to license?

Count physical I/O first, then ask the vendor specifically whether derived, alarm and historian tags are counted against the same limit. That single question changes the band on most platforms.

Can the SCADA be reached from outside the plant?

It can, and it should be designed rather than improvised. Outbound-only data paths, a defined change window for anything going the other way, named accounts and full logging. Anything safety-critical must keep working with the link down.

Start with the plant, not the proposal

Tell us the asset, the platform and the constraint. If it is not something we should be doing, we will say so and tell you who should.