Cloud-Native DCS

The record comes out of the system that ran the batch

Put your process on this model

The same system, and the same record, whatever the plant makes

A distributed control system (DCS) is the software that drives a batch process from raw materials to finished product. Cloud-Native DCS does that for regulated plants. It holds the procedure and the record in one model, so the record is a by-product of running the batch.

Whatever the plant makes, it is built from equipment several makers supplied, and the system owns the procedure that spans them.

Request a demo
Every actuator, valve, and sensor on the fermenter is a control module in the same plant model

A contract manufacturer's line, built from packaged equipment

One batch record, produced by the system that ran the line

One master recipe carries the client's program across the machines on the line

Process equipment commonly arrives as a packaged unit with its own controller, and often its own local screen. Nothing in that package is responsible for the run as a whole.

Getting one procedure across the line is integration work: data mapping, custom code, and handshakes between systems. It is done again for every program that moves.

Cloud-Native DCS models the program once as an ISA-88 master recipe, the standard model for batch procedures. The recipe names what each machine does and in what order. It is versioned and reviewed like any other configuration.

Every machine controller and every validated safety system stays where it is

Cloud-Native DCS orchestrates above the equipment and reaches each machine over Modbus TCP and OPC UA, the standard protocols for talking to industrial equipment. Each machine keeps its own control loops and its own screen.

SIL-rated safety functions run on a separately certified safety instrumented system. That is how a regulated plant is built under IEC 61511, and how both Emerson and Siemens ship it. Cloud-Native DCS sits on the control side of that separation, in the category the industry calls a basic process control system.

The record is produced while the batch runs, on an audit trail immutable once written

Every command the system issues, and every value it collects, is written to the audit trail and the process historian as it happens. The record is assembled from those, so nothing is transcribed and nothing has to be reconciled afterwards.

The audit trail records the action, the identity behind it, and the time. A reviewer opens one record and reads what happened on every machine, in the order it happened.

One master recipe runs three machines that each keep their own controller and screen, and one batch record collects what every one of them did. At the top, a card reading "One master recipe," the client program held as a versioned procedure. A line drops from it to a horizontal bus, and three identical connectors drop from that bus to three machines standing side by side, annotated once "Modbus TCP and OPC UA." The machines are drawn in grey, as equipment the system reaches and leaves in place, and each one holds its own controller and its own operator screen. They are named Charging, Drying and Filling. Three identical lines return from the machines to a second bus, and one line runs from that bus into a card reading "One batch record," annotated "captured as the batch runs." The machines hang off the buses as parallel taps, so no machine sits in front of another. One master recipethe client's program, versionedModbus TCPOPC UAChargingDryingFillingown controllerown controllerown controllercaptured asthe batch runsOne batch recordwhat each machine did, as it did it
One master recipe drives machines that each keep their own controller, and one batch record collects what they did
The completed record read section by section, from the recipe snapshot taken at batch start through the as-run phase history