A modern plant — brewery, cement works, water treatment station, flour mill, mine, power station — is driven by measurement and control chains: a sensor reads a temperature, a pressure, a level, a flow; a transmitter sends that value to a programmable logic controller; the controller decides according to a program; an actuator — valve, motor, pump — executes; a supervision screen shows the operator what is happening. The automation and instrumentation technician designs, installs, tunes, troubleshoots and maintains these chains. Errors propagate in the order of the signal, from the process to the screen; they will be followed here in that same order.
The sensor and the transmitter: what the controller believes
Everything starts with an instrument chosen for the quantity to be measured, the range, the medium — corrosive, hot, abrasive, food-grade — and the useful precision. A sensor poorly chosen, poorly mounted or poorly wired gives a plausible and wrong value, and that is the worst case: the controller acts correctly on a reality that does not exist. The instrumentation technician checks the mounting — position on the line, straight lengths, impulse tappings, protection against vibration —, the wiring, the power supply, the earthing and the shielding of signals, because a noisy signal is as good as a wrong sensor.
Calibration: a measurement has a date
An instrument drifts. Calibration compares its reading with a known reference, corrects the deviation and records it; it has a date, a method, a result and a next due date. The technician keeps a register per instrument, uses references whose accuracy they know, and refuses to “adjust by eye” a transmitter on which a dosage, a safety pressure or a billing depends. A measurement without documented calibration is not a measurement: it is an opinion. The instruments used for calibration are themselves traced to more accurate references, at known intervals; it is that chain of traceability, and not a manufacturer’s label, that gives a value its credibility.
The controller: the logic and its consequences
The controller runs a program — sequences, control loops, interlocks, alarms — written by the automation engineer from a description of the process approved with the operator. The trade consists of translating that description without ambiguity, anticipating abnormal cases — faulty sensor, jammed actuator, power cut mid-cycle — and testing every situation before commissioning, on the bench then on the process empty. A program modified in a hurry on site, without a backup of the previous version or a note of what changed, is a time bomb: the automation engineer versions, comments and backs up.
Safety functions — emergency stop, hatch interlock, pressure limit — are not treated like the rest of the program. They are designed to bring the installation to a safe state whatever the failure, with dedicated components and logic, and they are not bypassed “to restart faster”. The ILO recalls that a safe and healthy working environment is a fundamental right; in an automated installation, that right is written into these functions.
Control loops: not too much, not too little, not too late
Between measurement and action there is often a control loop: holding a temperature, a level, a pressure or a flow at a setpoint despite disturbances. Tuning a loop is a skill in its own right — a control that is too nervous makes the valve oscillate and wears the actuator, one that is too sluggish lets the process drift — and it is done on the real process, in steps, watching the curves, not by copying parameters found on another site. The automation engineer records the settings chosen and the conditions under which they were obtained, because a change of raw material or of season may call them into question.
The actuator: where the command meets the world
A valve that does not reach its position, a badly set drive, a motor that starts without the safety allowing it: the chain ends in mechanical and electrical devices the automation engineer must know as well as the program. They check travels, limit switches, feedback signals — the command to open is not proof that the valve is open — and they work with the site’s mechanics and electricians, because a control problem often has a mechanical cause.
Supervision: showing, alerting, recording
The supervision screen is what the operator sees: process mimic, values, alarms, trends, histories. The automation engineer designs it to be understood at three in the morning by a tired person: prioritised alarms, rather than a hundred alarms screaming together; values displayed with their unit; histories that make it possible to understand an incident afterwards. A supervision system that records is also a maintenance tool: the drift of a sensor or the fatigue of a pump can be read on a curve before it is read on a breakdown. The automation engineer finally checks that what is displayed is indeed what is measured — a screen label linked to the wrong variable is a classic error, and it misleads the operator with total confidence.
Cybersecurity: the controller is connected
Controllers, supervision systems and drives communicate over networks, more and more often with remote access for remote maintenance. That convenience is a doorway: a factory password never changed, a shared remote access, an infected troubleshooting USB stick can stop a plant or, worse, trigger an actuator. The NIST cybersecurity framework, organised into simple functions — identify what you have, protect, detect, respond, recover —, applies to industrial systems as to information systems: inventory of connected equipment, proper passwords, industrial network separated from the office network, named and logged remote accesses, program backups and restoration procedures. The automation engineer who delivers an installation without these measures delivers a vulnerability.
Commissioning, training, contract
Commissioning proceeds in stages — every instrument checked, every loop tested, every sequence run empty then under load —, with signed reports. The automation engineer then trains the operators and the maintenance team in what they may do and what they must not touch, and hands over complete documentation: diagrams, list of instruments with their settings and calibration dates, commented and backed-up program, description of sequences and alarms, restart procedures.
The contract separates the study, the supply, the installation, the programming, the commissioning, the training and the maintenance, with their respective prices; it states what the automation engineer guarantees — conformity with the approved description — and what they do not guarantee: the behaviour of a poorly described process, the life of equipment they did not supply, a modification made by others without telling them.
Skills and boundaries
The automation and instrumentation technician is neither the electrician who wires the power, nor the mechanic who maintains the pump, nor the IT specialist who runs the office network — but they work with all three and speak their languages. The ILO stresses that automation demands a workforce that keeps training; for this trade, training covers as much the new generations of controllers and protocols as the fundamentals of measurement, which do not change. An automation engineer who can no longer read a loop diagram or check an earth connection is no longer quite an automation engineer.
In the African context
An automation cabinet delivered turnkey by a foreign integrator, program locked, documentation in a language no one on site reads, remote maintenance from another continent: that is the situation the continent’s automation engineer very often inherits when a plant, a pumping station or a mining unit changes hands or loses its service contract. Their first job is then neither to program nor to measure, but to open up: obtain the passwords, recover the program, rebuild the documentation, understand what the installation does before touching it. The local provider who manages this becomes indispensable; the one who replaces everything with what they know makes the customer pay twice for the same installation.
Remote maintenance raises a question specific to the continent: it assumes a stable connection and a provider reachable in another time zone, and it ends with the contract. The local automation engineer therefore builds a capacity to intervene on site — programs in their possession, spare parts for the most common controllers, competence in the protocols used — which turns foreign remote maintenance into a backup rather than a dependency. The ILO recalls that lifelong learning is the answer to technical change; here it is also the condition of industrial autonomy.
And there are the major clients — mines, brewers, cement makers — who impose their safety and documentation standards on their subcontractors: for an automation engineer who wants to work with them, those requirements are a school, and the one who then applies them to a small local unit raises the level of the whole market.
Six documents, one installation
Complete and up-to-date documentation, handed over at commissioning and after every modification. A calibration register per instrument. The controller program backed up, versioned and commented, in the customer’s own possession and not only at the provider’s. Safety functions identified and tested. Named and revocable remote accesses. Operator training and a written restart procedure.
None of this is visible on a supervision screen that works. All of it is visible the day it no longer does.