Software & Application Development

Where it pays off

A plant can have a working control layer and still write its output figure into a spreadsheet by hand at the end of the shift. That is usually where software work starts: making data that already exists on the floor usable, or beginning to record something that was never captured at all.

The applications asked for most often:

• Production tracking and reporting. Records by work order, batch, shift and downtime reason; downtime analysis and the OEE components (availability, performance, quality) read from one place.
• Operator terminal. Selecting a work order on the touch panel at the line, confirming a recipe, entering a downtime reason, logging a quality measurement.
• Field mobile app. Maintenance rounds, periodic checklists, fault reports and stock counts — on a phone, often outside network coverage.
• Test and measurement software. Desktop applications that collect data from instruments, evaluate it against an acceptance criterion and leave behind a record tied to a serial number.
• Data capture points. Barcode and RFID readers recording where a product passed; handhelds for warehouse and shipping movements.

What makes industrial software different

Compared with an enterprise application doing nominally the same job, the difference is not in the feature list — it is in the assumptions:

• “There is internet” does not hold. Wireless coverage on a production floor is patchy: behind machines, down warehouse aisles and inside cold rooms are blind spots in most plants. The app has to work offline, keep data locally and sync when the link returns.
• The interface is used with gloves on. Large touch targets, few steps, as little keyboard entry as possible. The most frequent action should come down to a single tap.
• Shift handover is an event. Software has to tie “who is working” to the shift; a session left open and a half-finished entry contaminate the next shift’s data.
• Clock synchronisation matters as much as the data. If terminal, PLC and server disagree on the time, downtime durations come out meaningless. Every component takes its time from a common source (NTP).
• Response time must not hold up production. A screen the operator waits on is a line waiting. The entry completes locally at once and the upload runs in the background.

How we work

We start with the data model: which events get recorded and which key (work order, serial number, batch) ties them together. Drawing screens before that is settled ends with a report that, three months later, cannot answer the question actually being asked.

Then we test the interface on the floor. A screen that looks fine in the office can be unreadable under the lighting at the line, or simply not match how the operator stands. We run a terminal with its real users, in real noise, before accepting it.

Integration is done against a contract: an OpenAPI or proto file, sample requests and responses, and the error cases written down. That is how you can see what broke when the other system changes.

Deployment can be on-premise or hosted; the deciding factors are whether the data may leave the site and what happens when the internet is cut. For on-premise we package with Docker, so upgrading and rolling back come down to a single command.

What we watch for

Records cannot be deleted. The audit trail is part of the data model, not a feature bolted on later.

Permissions are actually enforced. Hiding a menu item is not authorisation; the check always happens on the server.

Backups are verified by restoring them. A backup that has never been restored does not count as a backup.

The application makes its own failures visible. A sync that silently returns nothing is the most expensive class of bug; failed transfers should sit in a queue and be counted on an administrator screen.

How this connects to the other areas

A software layer is only as good as the source beneath it. Data from a line whose tag dictionary was never set up properly will count wrongly no matter how good the interface looks — which is why we usually plan applications together with industrial automation and data acquisition and analytics. The network side of terminals and field devices is handled under industrial communication systems.