Our solution
Model the whole plant as one API
A distributed control system for regulated plants
A distributed control system (DCS) is the software that drives a batch process from raw materials to finished product. It runs recipes, controls temperatures and flows, opens and closes valves, records every action, and alerts the operator of events.
Cloud-Native DCS does all of this for regulated plants. Every piece of equipment, recipe, running batch, and alarm becomes a declarative API object. You define what each one should be, and the plant runs from those definitions.
Everything is an API object
Site, area, and unit are typed objects, and a recipe carries its own sign-off
The hierarchy follows ISA-88, the international standard for batch control. An engineer who has worked on a DeltaV or PCS 7 plant will recognize the hierarchy immediately.
A recipe, the procedure for making a product, is a versioned API object. It moves from draft to approved to released under role-based sign-off. Each transition is signed and recorded.
One Kubernetes cluster, from the data center to the plant floor
An ordinary industrial computer takes the place of the vendor's proprietary controller
That computer sits out at the equipment, on the same network as the sensors and valves it reads. It is one node of the cluster, and it runs the control logic. If it loses the link to the rest of the cluster, it keeps the control loop running on its own.
A long outage ends in a deliberate, ordered safe state
When an outage runs long, a watchdog follows the unit's own holding program and brings the unit to a safe state one step at a time. The batch resumes only when an operator restarts it. If the controller itself goes down and comes back, it reloads its last control program from its own disk and holds the unit in its last-known state.
Everything else runs on standard servers your IT operates, no internet connection needed
Cloud-native describes how the software is built. The plant model, the shared API, and the audit trail run on nodes you own and qualify, in the control room, in your data center, or in a private cloud you operate. The computer out at the equipment keeps the control loop on your plant floor, and no part of the system needs an internet connection to run.
Three interfaces, one model
System, HMI, and Data are three views of one shared plant model, all served through a single API
Across all three views, the agitator is one object
Its faceplate in HMI, its live logic in System, its trend in Data
In the System view, a plant engineer configures the plant as one typed object hierarchy
One click unfolds the plant into its areas, process cells, units, and control modules
In the System view, a running control module's logic streams live, its signal values moving block to block
The function block diagram, then the same program as Structured Text
In the HMI view, an operator runs the batch on screens laid out automatically from the plant model
Every control module in the unit is a live card, each opening to the faceplate the operator commands it from
In the Data view, a quality engineer reviews a control module's own trends and alarms
A tag-trend chart above an alarm history that names each alarm's batch
How it's different
On Emerson DeltaV, Siemens PCS 7, Rockwell PlantPAx, and Honeywell Experion, the plant model, its history, and its change record stay inside a proprietary stack. Cloud-Native DCS keeps them as Kubernetes objects your own tools can read.
Put the plant in Git
The plant's equipment, recipes, and control programs are plain text
See the change flowEnforce the approved model
The platform reverts unapproved changes on its own
Watch drift correctedAuthor logic in the browser
Any machine with a browser is an engineering workstation
See the editorsPoint your AI at the live plant
The plant model is standard API objects, and one open API serves their live values
See the open APIElastic where it's safe, deterministic where it must be
The API and operator screens scale out on load, while one writer at a time drives each piece of equipment
See how it scalesGive every team one model
Operations, engineering, and quality work from the same live API objects
See the shared modelPut the plant in Git
Every change is reviewed and e-signed before it reaches production
The plant's equipment, recipes, and control programs are plain text, so the plant can live in your own Git, where each change is e-signed at Promote before it lands as a pull request. From there you can compare any two points in its history or roll back.
A traditional DCS keeps its version history inside the vendor's stack
The history is proprietary, separately licensed, and reachable only through the vendor's own software.
What's declared is what's running
Cloud-Native DCS redeploys the declared version on its own when a unit drifts
The platform compares every unit against its declared version every few seconds, so whether a given unit is running what was approved has a built-in answer. That declared version configures ten sites as readily as one.
A traditional DCS relies on a person to keep the live controller and the offline master copy in agreement
An engineer can edit logic directly on the live controller, and that change lives there until someone uploads it back to the master copy. The gap is well enough known that the DCS vendors and third parties sell separate change-management products whose only job is to periodically compare the two and flag the differences for a person to resolve.
Author logic in the browser
Any machine with a browser is an engineering workstation
A new engineer starts with a browser and Git. The keys to the plant stop living in a license file taped to a workstation. The same editors run offline. Authoring on the engineer's own machine covers local development and air-gapped sites. The review and approval that makes a change the official record still goes through the connected promotion flow, so the compliance path is the same whether the work happened online or off.
A traditional DCS pins authoring to a licensed engineering station
On DeltaV, engineers author the plant's control logic in Emerson's own DeltaV Explorer and Control Studio.
A control engineer builds a new module template from an empty canvas
Blocks are dragged and wired on the canvas before one typed line of Structured Text grows the diagram a block the engineer never drew
A process engineer types a phase's control logic as Structured Text
The charge-and-confirm phase messages the operator and blocks on their acknowledgement, written with the editor's MESSAGE and PROMPT builtins
A new recipe version is created in the browser with its number and name assigned by the system
New Version on the effective recipe yields the next draft with procedure and parameters carried along
The same work runs offline, in the engineer's own editor and Git
A phase template is edited as plain text on the engineer's own machine and proposed from the command line into the same approval flow
AI-consumable by construction
The model is Kubernetes objects, its live values one open API
Every unit, recipe, running batch, and alarm in Cloud-Native DCS is a typed object in a Kubernetes API server, read with any Kubernetes client. Its live and historical values are served by the product's own gateway API, a versioned REST interface with a historian behind it. Both are interfaces that modern data, observability, and automation tooling already speaks. An open extraction layer ships, so there is none to build.
A traditional DCS needs a custom extraction per platform
On a traditional DCS, getting at the plant for an AI copilot, an analytics platform, or a digital twin means building a custom extraction per platform, against data copied out of the control system.
$ kubectl get batches -n site-plant-01
NAME BATCHID PHASE MASTERRECIPE AGE
batch-7kp2x FERM-2026-0412 Running bds-v2 2h14m
batch-9md4q FERM-2026-0413 Running bds-v2 8m
$ kubectl get batch batch-7kp2x -n site-plant-01 -o yaml
apiVersion: batch.dcs.io/v1alpha1
kind: Batch
metadata:
name: batch-7kp2x
namespace: site-plant-01
spec:
batchID: FERM-2026-0412
masterRecipeRef: bds-v2
parameterOverrides:
- name: targetTemperatureC
value: "25"
- name: fermentTime
value: "120h"
status:
phase: Running
state: Running
startTime: "2026-04-12T08:31:04Z"
controlRecipeRef: batch-7kp2x-cr
procedureRef: batch-7kp2x-proc
allocatedUnits:
- unitName: fermenter-1
capability: ferment
allocatedAt: "2026-04-12T08:31:04Z"Elastic where it's safe, deterministic where it must be
Exactly one writer at a time drives each piece of equipment
Cloud-Native DCS runs on Kubernetes, the system that decides how many copies of a service run and where. Kubernetes calls those copies replicas. Control works the other way. Two copies would race for the same reactor or valve, so a single writer keeps control deterministic.
A traditional DCS adds a separately licensed node for each function
A DeltaV plant licenses a ProfessionalPLUS, a Batch Executive, batch and continuous historians, and engineering and operator stations. That is its server layer. At the controller layer it grows the same way Cloud-Native DCS does, by adding controllers.
Give every team one model
The quality record and the operator's live screen cannot disagree
There is no second copy to reconcile. A change to the plant reaches every team the moment it lands.
A traditional DCS gives downstream teams a historian copy, with a second model to keep aligned
On a traditional DCS, downstream teams usually read a separate process historian, commonly OSIsoft/AVEVA PI, that the control system streams its tags into. Its own model of the plant has to track every change.
Where the technical detail lives
The full API reference, the architecture, and the deployment and protocol detail live in the documentation
