Cloud & DevOps Engineering for Manufacturing

How do IEC 62443 zones and conduits constrain a delivery pipeline?

The standard organises an industrial system into zones of comparable risk, joined by defined conduits, each carrying a security level appropriate to what a compromise there would cost. The practical result for delivery is that a build system living in a cloud account sits in a different zone from a controller on the plant floor, and the conduit between them is deliberately narrow.

That rules out the pattern most cloud pipelines assume — a runner holding credentials that reaches into the target environment and pushes. The industrial equivalent is pull-based: signed artefacts are published to a repository in an intermediate zone, and an agent inside the plant network fetches, verifies and applies them, with no inbound connection from the enterprise side at all. Verifying the signature at the point of installation is what makes so narrow a conduit sufficient.

The consequences reach into everyday tooling. Remote shells into control networks, vendor agents that phone home continuously, and administrative credentials shared across sites all cross conduits that were drawn for a reason. Where a supplier's product requires one of them, the honest answer is a documented exception with compensating controls rather than a quiet allowance added to a firewall rule and forgotten.

What does ISA-95 layering mean for cloud architecture?

ISA-95, standardised as IEC 62264, describes the functional layers from sensing and control at the bottom, through supervisory control and manufacturing operations, up to business planning. It exists partly to keep timing-critical and safety-related functions separate from systems that are neither, and it is the reference most plant architectures are argued against in a review.

For a cloud team the operational rule is that data flows upward and commands do not flow straight back down. An analytics service consuming production data through a broker at the operations layer is ordinary; the same service writing a setpoint directly to a controller is not, because it bypasses the supervisory logic and interlocks that make the setpoint safe. Where cloud-originated changes are genuinely wanted, they are requested of the layer that owns the decision, which validates and applies them.

The boundary itself is usually an OPC UA server or a broker in a demilitarised zone, with a unidirectional gateway where the risk justifies one. Designing for that at the start avoids the expensive discovery that an application built on direct device access cannot be deployed at all — a far more common outcome than a security review merely asking for adjustments.

How do you deploy to plant-floor edge nodes that are offline or in production?

An edge fleet does not behave like a server fleet. Nodes go offline with the network at a site, they are mid-batch when your release is ready, bandwidth at a plant is shared with everything else that needs it, and a device that fails to boot after an update needs somebody physically present to recover it. Every one of those constraints pushes the design toward autonomy at the node.

The pattern that holds is dual-partition updates with automatic rollback: download and verify while the current version keeps running, switch at the next permitted restart, run a health check, and revert automatically if it fails. Downloads must be resumable and delta-based, updates must be idempotent so an interrupted attempt can simply be repeated, and the node must be able to finish or abandon an update without a central system telling it what to do.

Scheduling is a plant decision rather than an engineering one. Updates land in changeover windows, planned maintenance or shift breaks, staged site by site instead of fleet-wide, with a canary site running a release through a full production cycle before the rest follow. Underneath all of it sits an inventory answering what runs where — without one, a fleet drifts into a collection of unique configurations nobody can support.

What changes when a bad release can stop a line?

The cost model is different. A defect in a web application degrades an experience; a defect in a system feeding an MES or a supervisory layer can halt production, scrap work in progress, or create a safety event. That justifies controls which would look heavy elsewhere: management of change with named approvers, validation in a simulated or twin environment before production, and a documented, rehearsed way back.

Safety-instrumented functions are a separate matter and should stay separate. Systems designed under functional-safety standards such as IEC 61508 change under their own process, with their own validation and sign-off, and they are not candidates for continuous deployment. Being explicit about which side of that line each component sits on stops the pipeline from quietly acquiring responsibility it was never designed to carry.

Operations owns the go-ahead. A release affecting a line needs the plant's agreement on timing, an operator-visible record of what changed, and a rollback a site can execute without waiting for a remote engineer to wake up. Change records that link a release to the equipment it touched are also what make the investigation after an unplanned stop take hours instead of days.

How do you build this alongside a running plant?

The constraint is rarely knowledge of cloud tooling; it is that the people who understand the plant are the people keeping it running, and OT and IT teams are measured on different outcomes. Progress usually comes from a narrow first slice — one line, one site, one class of edge device — proven end to end before anyone generalises the pattern across the estate.

Appsierra works as an expert-supervised pod on the IT side of that boundary, building artefact promotion, edge rollout and fleet inventory tooling and documenting the interfaces your OT engineers review and approve. We do not perform functional-safety engineering, certify safety systems, or take responsibility for control decisions; those remain with the teams and standards that own them.