Skip to content

Notes

Engineering notes

Answers to the narrow questions that cost a day each and are written down almost nowhere. No product pitch in them — if a note saves you hiring anyone, it has done its job.

Integration and protocols

Reading a protocol off the wire rather than out of the manual. None of these needs a Niagara station to be useful.

Connected devices

Devices on a radio network, and what has to be true before their data is worth anything to the system on the other end.

Agents and AI

Giving a program rather than a person access to a live control system: what the station enforces, and what the client has to enforce for itself.

The web and the pipeline

What a stranger can measure about a site from outside it, and the one-line fix behind each measurement. None of these has a building in it.

Modules and deployment

Building something that installs, runs and keeps running on a controller.

Drivers and field buses

Getting values off equipment and commands back onto it, and why what you get is wrong or late.

Station engineering

The work between a working driver and a station somebody else can maintain.

Data, alarms and time

What the station records, who it tells, and when it decides to act.

Running an estate

Doing the same thing to fifty stations, and moving them forward a version.

Security and access

Who can reach the station, and what they can do once they are in.

Why these exist

Written from the framework, not from memory

Every claim here is checkable against a stock installation, a published standard or the code itself — for the station notes that means the documentation modules, the default properties and the shipped drivers — or it is flagged as an opinion. Where the honest answer is "it depends", the note says what it depends on instead of picking a side.

Next step

Tell us the version, the hardware, and what it has to do.

You will get a written scope and a fixed price against it. If the honest answer is that you do not need us, you will get that instead.