Industrial automation, layer by layer: from the sensor to the screen

Automation is often described as "putting a PLC on the machine". In practice a system that runs a plant reliably is a stack of layers, each with its own job, and most problems we are called in to fix come from one layer being designed without the others in mind.

This article walks through those layers in the order data travels - from the sensor on the machine to the screen in the control room - and ends with how we plan an automation project so it survives commissioning and the years after it.

Everything starts with what can be measured and moved. Sensors turn the process into signals; actuators turn decisions back into motion.

The PLC is the deterministic heart of the line: it reads inputs, runs its logic on a fixed scan cycle and drives outputs, whether or not any computer above it is working. That independence is the point - a line must stay safe and controllable if the network or the server goes down.

Good control programs are written to IEC 61131-3 (ladder, structured text, function block diagrams), are structured into reusable function blocks per machine module, and treat alarms, interlocks and manual/auto modes as first-class parts of the design rather than additions at the end. Where machines must follow a common state model, packaging and process lines often adopt ISA-88 (batch) or PackML state machines so every unit behaves the same way to the system above it.

Operators interact with the PLC through an HMI at the machine: a local panel for starting, stopping, recipes, alarms and maintenance screens. A clear HMI with consistent colours and alarm priorities (ISA-101 is a good reference) prevents more downtime than most clever code.

Below the PLC, fieldbuses and industrial Ethernet connect drives, remote I/O and devices; above it, standard protocols move data to supervisory systems.

SCADA gives the whole plant one view: process screens, trends, alarm management and operator actions across many machines. Modern SCADA runs in the browser, which means supervisors and maintenance can see the plant from any approved device - and means access control and auditing have to be designed in from day one.

A historian stores time-series data from every tag worth keeping. It is what turns "the line stopped yesterday" into a trend you can investigate, and it is the foundation for every analytics or AI project that comes later. Alarm management deserves its own attention: rationalised alarms with clear priorities and responses (ISA-18.2 describes the life cycle) are the difference between a system operators trust and one they silence.

Above SCADA sit the systems that run the business: MES for orders, genealogy, quality and OEE on the shop floor, and ERP for planning, inventory and finance. ISA-95 describes how these levels exchange information - production orders flow down, actual production, consumption and quality results flow up.

Not every plant needs a full MES on day one. Often the first useful step is simpler: production counts, downtime reasons and batch records captured automatically from the PLC instead of on paper, and sent to the ERP in a defined format.

Once machines are connected and their data is clean and in context, the higher-value work becomes possible: condition monitoring and predictive maintenance from vibration, current and temperature; machine vision for inspection at line speed; energy monitoring per machine and per shift; and dashboards that show losses where they happen.

Edge computers next to the line run these models close to the machine, so decisions don't depend on a round trip to the cloud. The order matters: AI built on unreliable signals produces unreliable answers, which is why we treat the automation layers as the foundation, not an afterthought.

Connecting the plant raises its exposure, so security is part of the architecture, not a later audit:

The layers above only work when they are planned together. Our projects follow the same path every time:

If you are planning an automation project - a new line, an upgrade of old controllers, or connecting machines that already run - start by writing down the problem in production terms: what stops, what is checked by hand, what you cannot see today. From there the right layer to begin with is usually obvious, and the rest of the stack can be planned so each step builds on the last.

Talk to our engineers about your site, and we will help you turn that problem into a practical architecture.