Industrial Automation and IT Systems: Implementation and Operational Experience

Why Industrial Automation Is Not "Just Another IT Project"

Industrial automation is increasingly treated as a software task: connect the equipment, write a service, build a dashboard, deploy to a server. In a way that framing is correct — modern production lines, utilities, and infrastructure objects generate data streams, expose protocols, and demand integration with ERP and reporting systems. But teams that come from web and corporate backgrounds often underestimate one fundamental difference. In a corporate system, a failed deployment means an error page and an annoyed user. On a production floor, the same failure can mean a stopped line, a spoiled batch, a tripped safety interlock, or damaged equipment worth far more than the entire software contract.

At OneDev we have worked with industrial and infrastructure clients where the IT layer sits directly on top of physical processes. The lesson is consistent: the engineering discipline you bring matters more than the framework you choose. This article shares the operational experience that separates an automation project that runs quietly for years from one that becomes a recurring source of incidents.

The Layered Reality: From Sensor to Dashboard

Every industrial IT system spans several layers, and each has different reliability and timing requirements. Understanding the boundaries is the first step to designing something that survives contact with the real plant.

• Field layer. Sensors, actuators, drives. Signals are physical and time-sensitive. This layer is usually governed by PLCs (programmable logic controllers) and is the domain where safety lives.
• Control layer. PLCs and SCADA systems that read the field, execute control logic, and enforce interlocks. This is deterministic, real-time territory.
• Supervisory / integration layer. Data collection, historians, OPC UA or Modbus gateways, edge services. This is where most custom software work happens.
• Business layer. MES, ERP, BI dashboards, reporting, predictive analytics. This is where stakeholders see value, but it must never be allowed to dictate behaviour down on the control layer.

A frequent and costly mistake is collapsing these layers — for example, letting a web dashboard write setpoints directly to a PLC over an unvalidated path, or running control logic inside a general-purpose application that was never designed for determinism. The golden rule of industrial IT is that the safety and control layers must remain functional and safe even if every layer above them goes offline.

Protocols and Integration: Speak the Plant's Language

Industrial equipment rarely speaks JSON over HTTPS. You will encounter Modbus TCP/RTU, OPC UA, Profinet, MQTT, proprietary vendor protocols, and sometimes nothing more than dry contacts and analog signals. The integration layer's job is to translate these into something your business systems can consume, without losing fidelity or timing context.

Two practical recommendations from our experience:

• Prefer OPC UA as the integration boundary where vendors support it. It gives you a typed information model, security, and a standard most modern equipment and SCADA platforms understand. Where it is unavailable, isolate the legacy protocol behind a small, well-tested gateway service rather than scattering Modbus calls across your codebase.
• Timestamp at the source. Data that is timestamped only when it arrives at the server is almost useless for diagnostics and process analysis. Network jitter and buffering reorder events; you need the device's notion of time (and you need to handle the reality that device clocks drift and sometimes report impossible values).

We have repeatedly seen analytics built on server-arrival time produce misleading conclusions because the underlying events were reordered or batched in transit. Capture both source time and ingest time, and reconcile them deliberately.

Edge vs Cloud: Where Should Logic Live?

One of the most consequential architecture decisions in any automation project is how much intelligence runs locally at the facility versus centrally in the cloud or a corporate data centre. In Uzbekistan this is sharpened by real-world connectivity: remote production sites, intermittent links, and the unacceptable cost of a plant that halts because an internet channel dropped.

Reliability Engineering: Designing for the Bad Day

Corporate software is often judged by its happy path. Industrial software is judged by its worst day. The engineering effort therefore shifts heavily toward failure modes.

• Store-and-forward everywhere. Every edge component should buffer locally and replay when connectivity or the upstream service recovers. Data loss during an outage is frequently worse than the outage itself, because it corrupts your historical record.
• Idempotency and ordering. When buffered data is replayed, your ingestion path must tolerate duplicates and out-of-order arrival without double-counting or corrupting state.
• Graceful degradation. If the analytics service dies, control continues. If the dashboard dies, the historian keeps recording. Each layer should fail in isolation.
• Watchdogs and auto-restart. Long-running edge services must restart automatically and report their own health. A process that silently dies and is never restarted is a classic source of "we lost three days of data" incidents.
• Explicit data validation. Sensors lie. They report frozen values, out-of-range spikes, and impossible timestamps. Validate at ingest and flag suspect data rather than feeding it into control or reporting blindly.

Security and Operational Discipline

Industrial environments have historically relied on isolation ("air gap") for security. That assumption breaks the moment you add remote monitoring, cloud sync, or vendor maintenance access — which almost every modern project does. Treat OT (operational technology) security as a first-class concern: segment networks, keep the control layer behind a firewall from the integration layer, use least-privilege accounts, and audit every write that can reach physical equipment.

Equally important is operational discipline around change. On the corporate side, a hotfix at noon is routine. On a production line, deployment windows are negotiated, changes are tested against a representation of the real equipment before they go live, and every change to control-adjacent code has a rollback plan. We strongly recommend versioned configuration, immutable deployment artifacts, and a staging environment that mirrors production protocols — even a software simulator of the PLC is far better than testing on the live plant.

Practical Recommendations Before You Start

• Map the layers and write down, explicitly, what must keep running if the network or the cloud disappears.
• Inventory protocols and equipment early — integration surprises are the leading cause of schedule overruns.
• Insist on source timestamps and capture both source and ingest time.
• Separate control-write paths from analytics-read paths, with auditing on the former.
• Build store-and-forward buffering into every edge component from day one, not as a later optimisation.
• Plan deployment windows, rollback procedures, and a test environment that mirrors real protocols.
• Define who owns the system after launch — operations, not just developers — and give them health visibility and runbooks.