What Plant Engineers Need to Know About Edge Computing Before IT Chooses for Them
- May 26
- 7 min read
By Eric Seme
A practical, source backed guide to latency, reliability, data ownership, cybersecurity, and architecture decisions that directly affect plant operations.
Why this decision cannot be left entirely to IT
Edge computing is quickly becoming one of the most important architecture decisions inside manufacturing environments. It determines where operational data is processed, how fast people can respond to production events, how resilient the plant is during connectivity issues, and how safely IT systems can connect with OT systems.
That decision often starts as an IT infrastructure conversation. Servers, cloud platforms, cybersecurity controls, lifecycle management, and vendor standardization all matter. However, the most important requirements do not begin in a data center. They begin on the production floor.
Plant engineers understand which signals are time sensitive, which alarms require immediate action, which machines cannot tolerate downtime, which protocols are actually present in the plant, and which workflows operators will trust. If those requirements are not captured early, the selected edge architecture may look clean on paper while creating friction in daily operations.
The goal is not for plant engineering to replace IT. The goal is for plant engineering to define the operational reality before IT chooses the platform, network model, or cloud dependency pattern.
What edge computing actually means in a factory
Edge computing means placing compute, storage, analytics, and application logic closer to the machines, people, and devices that generate or use the data. AWS describes edge computing as bringing information storage and computing abilities closer to the devices that produce information and the users who consume it [6]. NIST has also described intelligent edge capabilities as a convergence of artificial intelligence, computing hardware, networking capabilities, and standard protocols that support Industry 4.0 environments [8].
In a manufacturing plant, edge computing can support tasks such as protocol translation, local historian buffering, machine vision, condition monitoring, operator dashboards, quality checks, and local analytics. It can also host applications that need to keep running when internet connectivity is limited or intentionally restricted.
The practical question is not whether the plant should use edge or cloud. The better question is which decisions need to happen close to the line and which decisions can move upward to enterprise systems.
Practical rule: if a decision affects safety, quality, line stoppage, operator response, or near real time control context, plant engineering should define the requirement before the architecture is selected. |
The requirements plant engineers should define first
Before IT standardizes an edge platform, plant engineering should document the operational requirements that determine whether the architecture will work in production. These requirements are not generic IT preferences. They come from the physics, timing, maintenance practices, and production constraints of the facility.
Requirement area | Question plant engineering should answer | Why it matters |
Latency | Which decisions need response in seconds, milliseconds, or production cycles? | Determines what must stay on premise and what can move to cloud or enterprise systems. |
Availability | What must keep running during WAN outages, maintenance windows, or cloud service interruptions? | Defines local redundancy, buffering, failover, and offline operation requirements. |
Protocol reality | Which PLCs, historians, drives, robots, cameras, and meters need to connect? | Prevents architecture choices that ignore actual plant assets and legacy constraints. |
Data context | What machine events need product, batch, operator, maintenance, or quality context? | Turns raw signals into usable operational information. |
Operator workflow | Who acts on the insight, when, and through which system? | Avoids dashboards that are technically functional but operationally ignored. |
Cyber boundaries | Which assets should be segmented, monitored, or isolated from enterprise networks? | Aligns edge deployment with OT risk management and security zones. |
Lifecycle support | Who maintains edge applications, patches, backups, and version control? | Prevents unmanaged infrastructure from becoming a plant liability. |
What IT often optimizes and what the plant actually needs
IT teams are usually measured on security, standardization, scalability, cost control, and supportability. Those priorities are legitimate. Problems begin when they are applied without enough operational context. A factory edge environment has to satisfy enterprise governance while respecting production realities.
IT priority | Plant engineering concern | Balanced edge decision |
Centralized management | Local systems must continue running when external connectivity fails. | Use central governance with local autonomy for critical workloads. |
Cloud analytics | Some decisions lose value if the data leaves the line first. | Run time sensitive analytics locally and replicate curated data upward. |
Security hardening | Remote support is still required for production continuity. | Use segmented access, bastion hosts, identity controls, and audited sessions. |
Vendor standardization | Plants often contain mixed equipment generations and protocols. | Choose platforms that integrate with existing assets rather than forcing replacement. |
Cost efficiency | Downtime cost may exceed infrastructure savings. | Evaluate total operational risk, not only software or hardware cost. |
Cybersecurity is part of the architecture, not a bolt on control
NIST defines operational technology as programmable systems or devices that interact with the physical environment or manage devices that interact with the physical environment [7]. That makes OT security different from traditional IT security because cyber decisions can affect physical processes, safety, quality, and production continuity.
NIST SP 800-82 Rev. 3 emphasizes the need to protect OT systems while preserving safe and reliable operations [1]. ISA/IEC 62443 also frames industrial cybersecurity as a holistic discipline that bridges operations, information technology, process safety, and cybersecurity [5].
For plant engineers, this means edge computing cannot be treated as simply another server deployment. Edge nodes may sit between PLCs, historians, MES, quality systems, and enterprise platforms. If they are poorly segmented or poorly governed, they can create a new path into OT. If they are designed well, they can become a controlled bridge that improves visibility without exposing the plant unnecessarily.
The architecture should follow the workload
A common mistake is selecting a platform first and then forcing every use case into that platform. A better approach is to classify workloads by their operational requirements.
Some workloads need to stay close to the line because they depend on low latency, local context, or continuous availability. Others can run in a plant DMZ, regional environment, or cloud platform because they are less time sensitive and benefit from scale.
A practical workload placement matrix
Workload | Best fit | Why | Plant engineering input required |
Machine state monitoring | Edge | High frequency signals and line context lose value when delayed. | Define sampling rate, events, and critical states. |
Vision inspection | Edge | Image decisions often need immediate pass or fail action. | Define defect classes, reject logic, and quality ownership. |
Predictive maintenance | Edge plus cloud | Local inference supports response while cloud can support model training. | Define failure modes, assets, and maintenance actions. |
OEE and downtime tracking | Edge plus plant applications | Events need machine context and operator reason codes. | Define states, downtime categories, and validation rules. |
Enterprise reporting | Cloud or enterprise data platform | Aggregated KPIs benefit from central scale. | Define which metrics are approved for enterprise use. |
Recipe or batch genealogy | Edge plus MES or QMS | Traceability must remain reliable during production. | Define batch context, audit needs, and retention rules. |
Remote support | OT DMZ with controlled access | Support is needed, but direct exposure is risky. | Define who can access what, when, and under approval. |
Questions plant engineers should ask before the selection is made
Plant engineers do not need to become infrastructure architects, but they should challenge any edge strategy that cannot answer basic operational questions.
Key questions include:
1. What happens to the system when internet connectivity is unavailable?
2. Which workloads keep running locally, and which ones stop?
3. How are PLC, SCADA, historian, MES, and quality systems integrated?
4. How will the system handle buffering, store and forward, and data reconciliation?
5. Who owns application updates, backups, and rollback procedures?
6. How are remote access sessions approved, monitored, and audited?
7. How does the architecture support segmentation and zone based security?
8. Can the platform integrate with existing equipment without forcing replacement?
9. What data leaves the plant, and what context goes with it?
10. What KPI proves that the edge deployment improved operations?
What a good decision process looks like
The strongest edge projects do not begin with a platform shortlist. They begin with an operating problem.
A practical sequence is simple:
1. Define the operational constraint.
2. Identify the signals and context needed to understand it.
3. Decide which actions must happen locally.
4. Define security boundaries and access requirements.
5. Select the edge architecture that fits the workload.
6. Prove value with a plant KPI before scaling.
This approach keeps the conversation grounded. It also helps IT make better decisions because the architecture is tied to measurable plant requirements rather than assumptions.
Final takeaway
Edge computing is not just an IT infrastructure decision. In manufacturing, it determines how fast the plant can see problems, how reliably people can act, how safely OT connects with enterprise systems, and how much operational independence the facility keeps when external services are unavailable.
IT should absolutely be involved. Cybersecurity, lifecycle management, identity, governance, and standardization matter. But plant engineers must define the operational requirements first.
If they do not, someone else will choose the architecture using incomplete information. The result may be secure, scalable, and easy to manage, but still poorly suited to the way the plant actually runs.
A future-ready factory needs both perspectives. IT helps make the system governable. Plant engineering helps make it usable, reliable, and valuable in production.
References
[1] NIST. SP 800-82 Rev. 3, Guide to Operational Technology Security. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf
[2] CISA. Guidance and Strategies to Protect Network Edge Devices. https://www.cisa.gov/resources-tools/resources/guidance-and-strategies-protect-network-edge-devices
[3] CISA, NSA, and partners. Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators. https://www.cisa.gov/resources-tools/resources/foundations-ot-cybersecurity-asset-inventory-guidance-owners-and-operators
[4] NIST. SP 800-207, Zero Trust Architecture. https://csrc.nist.gov/pubs/sp/800/207/final
[5] ISA. ISA/IEC 62443 Series of Standards. https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
[6] AWS. What is Edge Computing? https://aws.amazon.com/what-is/edge-computing/
[7] NIST CSRC Glossary. Operational Technology. https://csrc.nist.gov/glossary/term/operational_technology
[8] NIST. The Future of Connected Devices. https://www.nist.gov/blogs/manufacturing-innovation-blog/future-connected-devices
[9] IEEE. IEEE 1934-2018, Standard for Adoption of OpenFog Reference Architecture for Fog Computing. https://standards.ieee.org/standard/1934-2018.html
[10] CISA and partners. Adapting Zero Trust Principles to Operational Technology. https://www.cisa.gov/resources-tools/resources/adapting-zero-trust-principles-operational-technology
