Industrial
Where software fits in industrial automation
There is a clear line between the systems that move machinery and the software that surrounds them. We work on one side of it.
Industrial automation means two different things depending on who is saying it. To a controls engineer it means PLCs, drives, safety circuits and the systems that physically operate plant. To an operations manager it often means the mountain of recording, scheduling and reporting that surrounds those systems.
The distinction matters, because the disciplines, the certifications and the consequences of getting it wrong are not comparable.
What we do not do
We do not program controllers, modify safety systems, or touch anything whose failure mode is physical. That work belongs to licensed controls and safety specialists, and no amount of software experience substitutes for it.
If an engagement turns out to need that, we say so and stop. It is a boundary rather than a preference.
What we do
The software layer around the plant: production numbers that currently get keyed in from a clipboard, maintenance history that lives in somebody's memory, compliance paperwork assembled the night before an audit, shift reports typed twice.
Read-only access to data a system already produces is usually enough to remove a large amount of manual recording, without going anywhere near the systems that control equipment.
Read before you write
A good sequencing rule for anything industrial: start by reading data and producing better records, and only later consider writing anything back. Reading has no failure mode beyond a wrong report.
That order also builds the trust the work needs. A team that has watched a system report accurately for six months has a reasonable basis for letting it do more.