Choosing a technology stack for industrial software
A stack should follow the shape of the problem, not a favourite tool. How to define an application's context, choose each of its nine layers, and connect it to plant systems from PLCs to ERP without opening the control network.
Key takeaways
- Choose a stack by the shape of the problem: how the screens behave, where state lives, what the data looks like and how the load arrives. Preference comes last.
- Industrial software spans the automation pyramid, from sensors and PLCs through SCADA and MES to ERP, and each level runs to its own clock and carries its own risk.
- Control systems change slowly for good reasons, chiefly safety, availability and service lives measured in decades. Good architecture works with that rather than around it.
- Plant data should leave the control network one way, through an industrial DMZ, and anything coming back should go through a person and the control system's own change process.
- The right choice is the one the evidence supports. Build the riskiest part first, measure it on real data and write down why the decision was made.
Most software decisions start with a favourite. A team that knows one framework reaches for it, and the project bends to fit. For a marketing site that rarely matters. For software that reads a control system, plans a shutdown or keeps running through a night shift in a remote control room, it matters a great deal.
The better question is not which tools a team knows best but which stack fits the shape of the problem. This article sets out how we answer it: what changes when software touches plant systems, the context to define before choosing anything, and how each of the nine layers of an application gets decided. It is written for the people who will own the result, usually for longer than anyone expects.
Industrial software spans the whole automation pyramid
Industrial operations are usually described with the automation pyramid set out in ISA-95, the standard for connecting control systems to business systems. At the base are the sensors, valves and drives on the plant itself. Above them sit the controllers that run the process, then the supervisory systems operators watch, then the operations systems that manage production, and at the top the business systems that plan and pay for it.
The Purdue model, which ISA-95 drew on, adds one more line that matters for software: an industrial DMZ between the plant networks and the business network. That line is where most integration work happens, and where most of the risk sits.
Each level runs to its own clock. A PLC scans its logic in milliseconds, an operator responds in seconds, a shift report covers hours and an ERP plans in weeks. Software that crosses levels has to respect every one of those clocks at once, along with the very different appetite each level has for change.
Business planning and logistics
ERPEAM and CMMSFinanceSupply
Days to months Moves at IT speed, with upgrades and releases through the year.
Industrial DMZ
Replica historianData brokerRemote accessPatching
The only door between the business network and the plant, and the place most integration work happens.
Operations management
MESHistorianLIMSScheduling
Shifts to days Upgraded in planned windows, because production reporting depends on it.
Supervisory control
SCADAHMIAlarm management
Seconds to minutes Changed under formal change control, often only in a shutdown.
Basic control
PLCDCS controllerRTUSafety system
Milliseconds Often in service for decades. A change here is an engineering change, tested and signed off.
The process
SensorsTransmittersValvesDrives
Continuous Replaced when it fails or wears out, one device at a time.
The value of plant data is realised at the top of the pyramid, but the data is born at the bottom, and the path between them is the design problem.
Why the plant floor changes slowly
Below level 3, technology has historically changed slowly. It is tempting to read that as inertia. It is better read as a set of engineering decisions that software has to respect.
- Consequence comes first. A fault in a control system can injure people, damage equipment or release product, so every change is engineered, tested and signed off like any other change to the plant.
- Availability outranks everything. Office systems protect confidentiality first. A control system protects availability first, because a plant that stops loses production for every hour it is down.
- Service lives are long. Controllers, drives and supervisory systems are bought to run for decades, and vendors certify combinations of hardware, firmware and software that are not changed lightly.
- Windows are rare. Many changes can only be made in a planned shutdown, and a shutdown has a long queue of work competing for the same hours.
- The protocols were built for trust. Control protocols such as Modbus were designed for closed networks and carry no authentication, so they cannot simply be exposed to a wider one.
Slow change on the plant floor is a safety and availability decision. Software that treats it as an obstacle will not be allowed near the plant, and should not be.
What has changed, and what it means for the enterprise
The pressure now runs the other way. Sensors are cheap, telemetry reaches remote sites, and analytics and AI models are only as good as the operational data they can see. Maintenance planning in the ERP wants condition data from the historian. Production reporting wants the MES and the weighbridge to agree. Leaders want one picture of the operation, from pit to port.
Meeting that demand does not mean flattening the pyramid. It means designing the path data takes through it. The pattern we start from, and the one current guidance points to, is that plant data leaves the control network one way, into a DMZ, and is joined to business data there or beyond it. The control network never accepts a connection from outside.
The security frameworks for this are mature and worth using as reference points. IEC 62443 groups industrial systems into zones joined by controlled conduits, NIST SP 800-82 is a practical guide to operational technology security, and the Australian Signals Directorate's principles of operational technology cyber security start from the position that safety is paramount.
Levels 0 and 1
Sensor and PLC · Measures and controls, in milliseconds.
Levels 2 and 3
SCADA and historian · Collects and stores every tag.
Level 3.5
Replica in the DMZ · A copy pushed out, never pulled in.
Level 4
Data platform · Joins plant data to the business.
Cloud or site
Your application · Plans, reports and models.
↓ Back down
Nothing writes into levels 0 to 2 directly. A change the application wants, a new setpoint or a stopped conveyor, arrives as a work order or a request that an operator reviews and makes through the control system.
Read freely, write carefully. Data can flow up and out by itself, but changes flow back down through people.
Define the context before choosing anything
With the plant boundary understood, the application itself can be shaped. We define four things before a single tool is chosen, and a fifth check closes the decision.
Interface shape. Some screens are documents: work instructions, reports, an asset register. Standard page rendering handles them well and server rendering keeps them fast. Some are feeds, such as an alarm and event journal with a hundred thousand entries, which need virtualised lists that draw only what is on screen. And some are canvases: a shutdown schedule with thousands of linked tasks, a trend with millions of points, a mine plan or a P&ID with live values. These outgrow the page structure entirely and need Canvas, WebGL or WebGPU rendering.
Where state lives. A thick client holds the working data in the browser, which suits heavy interaction and work that must carry on without a connection, such as inspection rounds in a pit or along a remote rail line. A thin client keeps state on the server, which suits datasets too large to download and environments with strict security, such as a control room terminal. Each has a cost. Thick clients need careful control of what crosses the network, and thin clients feel every delay on it.
Data shape. Asset registers, work orders and permits are relational, with known structure and strict integrity. Inspection forms and planning scenarios vary from one record to the next and suit flexible document storage. Sensor readings and events are time series, written once and read in ranges. Most industrial applications hold all three, so the choice is made for each data set rather than for the application as a whole. Our Time-Series Data Volume Calculator sizes the third kind.
Load pattern. Steady business-hours load runs well on provisioned servers. Spiky load, such as a re-planning run before a shutdown or month-end reporting, wants stateless services that scale out and back. Load spread across many sites with poor links wants processing at the edge that synchronises when it can, which is the industrial version of serving a global audience.
Worked example: a shutdown planning board
1Interface shape
Document
Server rendered pages, standard components
Feed
Virtualised lists
◆ Canvas
Canvas, WebGL or WebGPU
Thousands of tasks on a timeline, dragged and linked, is more than the page structure can redraw smoothly.
2Where state lives
Thin client
State on the server
◆ Thick client
State in the browser
Planners drag and re-sequence constantly, and every round trip to the server would be felt.
3Data shape
◆ Relational
PostgreSQL, SQL Server
Document
JSON columns, document stores
Time series
Time-series store, event log
Tasks, crews, permits and dependencies are known structures with strict rules between them.
4Load pattern
Steady
Provisioned servers
◆ Spiky
Stateless containers that scale out
Many sites
Edge nodes that sync
Quiet for weeks, then everyone re-plans at once when scope changes in the days before a shutdown.
The nine layers, and what each one decides
Once the context is clear, the application can be chosen layer by layer. Every application has the same nine, whether it is a small internal tool or a platform that runs a port. Each depends on the layers beneath it, and two of them, delivery and monitoring, run through all the others.
The industrial column is where the same layer earns different answers on a plant than in an office.
1Frontend
The screens people use, in an office, a control room or the field.
2API layer
The contract between the screens and the logic.
3Auth
Who you are and what you may do.
4Backend
Business rules, calculations and jobs.
5Database
Records, history and time series.
6File storage
Drawings, documents and photos.
7Hosting
Where it all runs: cloud, on premises, at the edge, or a mix.
| Layer | What it decides | In an industrial setting | Common options |
|---|---|---|---|
| Frontend | How people see and act on the system | Gloved hands, glare and rugged tablets in the field, and control room conventions such as ISA-101 high performance HMI design | React, Vue, Angular, Svelte, Blazor |
| API layer | The contract between the screens and the logic | Plant data arrives as subscriptions and events as well as requests, so the API has to carry both | REST, GraphQL, gRPC, tRPC |
| Auth | Who you are and what you may do | Roles follow the plant: operator, maintainer, engineer, contractor. A site network may not reach a cloud identity provider | Entra ID, Okta, Auth0, Keycloak |
| Backend | Business rules, calculations and scheduled jobs | Long runs such as optimisation and data reconciliation, kept deterministic and able to restart where they stopped | .NET, Node, Python, Go, Java |
| Database | Where records, history and time series live | Plant history runs to billions of rows, so retention, downsampling and partitioning are design decisions | PostgreSQL, SQL Server, time-series and document stores, the existing historian |
| File storage | Drawings, documents and photos | Controlled documents need versions and approvals, not just a folder | S3, Azure Blob, MinIO |
| Hosting | Where everything runs | Cloud, on premises, at the edge or a mix, decided by latency, connectivity and where data may go | AWS, Azure, GCP, on-site servers, edge gateways |
| CI/CD | How changes are tested and released | Releases follow the site's change process, and anything near the plant is tested against a simulator first | GitHub Actions, GitLab CI, Azure DevOps, Jenkins |
| Monitoring | How you know it is healthy | A stale or flatlined tag is a failure too, and alerts need the same discipline as plant alarms | Grafana, Prometheus, Datadog, Sentry |
No layer is chosen alone. A thin client moves load onto the API and the backend, and a time-series store changes what monitoring has to watch.
Where the plant meets the software
The layer that most often decides an industrial project is the one between the control system and everything else. A handful of patterns cover most of it.
- OPC UA for structured access to controllers and SCADA, with its own security model and an information model that carries meaning as well as values.
- MQTT with the Sparkplug specification for publishing plant data to many consumers at once, reporting by exception so a quiet signal costs almost nothing.
- Store and forward at the edge, so a satellite or radio link that drops for an hour loses no data and does not flood the network when it returns.
- Gateways for older protocols such as Modbus, translating at the boundary of the plant network rather than carrying the protocol beyond it.
- The historian as the integration point. Most sites already run one, and reading from its replica in the DMZ is usually safer and simpler than going near the controllers at all.
Use what the site already trusts. A historian and a DMZ that operations understand beat a cleverer path that nobody on site can support.
Evidence before commitment
A stack is a bet on the next ten years or more, so it should rest on evidence rather than enthusiasm. The method is plain, and it is the same whichever technologies end up winning.
- Build the riskiest part first. If a planning board has to redraw ten thousand tasks while a planner drags one, prove that before building the forms around it.
- Measure on the client's own data, at its real volume, not on a sample that flatters the design.
- Ask whether the problem is solved natively. A framework that needs heavy workarounds to do what the job requires is the wrong framework for this context, however good it is elsewhere.
- Write each decision down. A short architecture decision record captures the context, the options and the evidence, so the next team knows why as well as what.
- Test the exit. Settings kept outside the code, standard containers and open data formats keep a later move between hosts or tools a project rather than a rewrite.
- Check supportability. Industrial software outlives the people who build it. If another engineer cannot understand the architecture in six months, or support it in six years, the cleverness has cost more than it saved.
Why we go looking for the hard problems
We have defaults we know well, set out on our Software and AI page, and we leave them the moment the evidence points elsewhere. Familiarity with a wide range of technology matters less than discipline in choosing between them. The point is never the tool. It is software an operation can rely on, in places where getting it wrong has real consequences.
That is also why we would rather take on one hard project than twenty easy ones. The hard ones sit where the plant meets the enterprise: control systems that must stay untouched, data that has never left site, and decisions that need both. They are where architecture makes the biggest difference, and Bridging OT and IT with custom software shows what that looks like in practice.
Common questions
What is the automation pyramid?
A model of how an industrial operation's systems are layered, set out in ISA-95 (published internationally as IEC 62264). Level 0 is the physical process and its sensors, level 1 the controllers such as PLCs, level 2 the supervisory systems such as SCADA and HMIs, level 3 operations management such as MES and historians, and level 4 business systems such as ERP. Each level runs on a different timescale, from milliseconds at the base to months at the top.
What is the difference between ISA-95 and the Purdue model?
The Purdue model is a reference architecture developed at Purdue University in the early 1990s, and ISA-95 drew on it. ISA-95 defines how information moves between operations and business systems. The Purdue levels are now used mostly for security, with an industrial DMZ, often called level 3.5, added between the plant and business networks.
Can cloud software read data from a control system safely?
Yes, when the data leaves the control network one way. The usual pattern replicates the historian, or publishes data to a broker, in an industrial DMZ, and enterprise or cloud software reads from there. Nothing outside makes a connection into levels 0 to 2, and anything the software wants changed goes back as a request that a person acts on.
Should industrial software run in the cloud or on site?
It depends on latency, connectivity and where the data is allowed to go. Planning, reporting and analytics usually suit the cloud. Anything that must keep working when the site link drops, or respond in well under a second, belongs on site or at the edge. Many applications use both, with edge processing that synchronises to the cloud when it can.
What technology stack does Enco use?
We start from tools we know well, including Vue and Blazor on the front end, .NET on the back end and PostgreSQL for data, and we choose against the context of each job. Where the evidence points to a different framework, database or host, we use it. The method matters more than the default.
Key terms
Plain-language definitions from our glossary for the concepts this article leans on.
Standards and further reading
- ISA-95, enterprise-control system integration (IEC 62264) (ISA)
- ISA/IEC 62443 series, security for industrial automation and control systems (ISA)
- SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security (NIST)
- Principles of operational technology cyber security (Australian Signals Directorate)
- ISA-101, human machine interfaces for process automation systems (ISA)
- OPC Unified Architecture (OPC Foundation)
- MQTT, the standard for IoT messaging (OASIS)
- Sparkplug specification (Eclipse Foundation)
- The Twelve-Factor App (12factor.net)
- Architectural decision records (adr.github.io)
Related case studies and tools
- Bridging OT and IT with custom software (case study)
- Time-Series Data Volume Calculator (tool)
Related reading
Working through something like this?
See how we approach these initiatives, or tell us what you are dealing with.