Integration

How Cloud-Native DCS connects to the rest of the plant: supervisory systems (SCADA), manufacturing execution systems (MES), telemetry buses (MQTT), and the quality and identity systems that gate a change.

Start From What You Have in Hand

Two different questions bring readers here. One reader has a product to connect and needs to know which of our interfaces it should point at. The other has a protocol or a capability in mind and needs the contract for it. Use whichever table matches your question.

You have a product to connect

The product is...	Start here
An OEM skid or vendor unit with its own controller	OEM Skids and Vendor Units
A dashboard	Dashboards and Metrics, which picks between the three feeds a dashboard can consume
A historian or a long-term data archive (PI, IP.21, Canary, InfluxDB)	Historians and Data Archives
An AVEVA PI System, an Edge Data Store, or an AVEVA Data Hub	OMF Egress to AVEVA PI, which is the shipped path into all three
An MES or a production scheduler	MES Integration
A plant-wide SCADA that owns the operator HMI	SCADA Integration
An eQMS or change-control system (TrackWise, Veeva Vault QMS, MasterControl, ETQ)	ChangeRequest Backends
An OIDC provider or an LDAP directory	Identity Providers

You have a protocol or a capability in mind

You want to...	Use	Protocol	Direction
Stream real-time tag values to a dashboard or historian	MQTT Telemetry	MQTT	DCS → external
Dispatch batches from a production scheduler	MES Integration	REST	External → DCS
Read batch records and audit trails from a quality system	MES Integration	REST	External → DCS
Display control modules and issue batch commands from a plant-wide SCADA	SCADA Integration	REST + WebSocket/SSE	Bidirectional
Configure equipment, recipes, and the physical model via API	System Interface	REST	External → DCS
Command a vendor unit that runs its own logic	OEM Skids and Vendor Units	OPC UA or Modbus TCP	DCS → skid
Land tag values and ISA-88 context in a PI System as AF elements and PI Points	OMF Egress to AVEVA PI	OMF over HTTPS	DCS → external

Most plants use a combination. MQTT carries telemetry volume, REST carries recipes and batch dispatch, and WebSocket or SSE carries live updates where an existing SCADA is the authoritative HMI.

OPC UA in Cloud-Native DCS is southbound only. The unit runtime acts as an OPC UA client toward field devices, and the gateway exposes no northbound OPC UA server for another system to browse.

Sections

These five pages are the interface tier described under Adding a Page to This Section, and each one owns its protocol contract.

• System Interface -- the REST API (and the CRDs behind it) for configuring the control system declaratively: physical model, equipment library, and recipes.
• MQTT Telemetry -- a one-way publish stream out of the DCS. The system publishes tag values, alarm events, and state transitions to an MQTT broker. Dashboards and historians subscribe.
• MES Integration -- a REST API into the DCS at the ISA-95 Level 3/4 boundary, used by an MES or scheduler to dispatch batches and pull production records.
• SCADA Integration -- the REST, WebSocket, and SSE surfaces that expose tags, alarms, and batch state to a plant-wide SCADA acting as the authoritative HMI. Bidirectional means the SCADA can read live values, write tags, and issue ISA-88 commands (which flow through the Batch resource, or through the root of an ad-hoc run that has none).
• OMF Egress to AVEVA PI -- the northbound contract for OSIsoft Message Format over HTTPS. That is how a PI System, an Edge Data Store, or an AVEVA Data Hub receives plant data. It is the only interface here whose other end is a host the customer operates outside the cluster, and the only one whose names become a contract the moment a site publishes.

The partner-class tier owns no contract, and each of its pages routes to the interface pages and the references above.

• OEM Skids and Vendor Units -- the southbound case. A vendor-supplied unit that runs its own logic comes under recipe control as a Unit the DCS orchestrates or as control modules the DCS drives. Routes to device discovery, I/O authoring, and the MTP posture.
• Dashboards and Metrics -- which of the three feeds a dashboard should consume. Prometheus for platform and equipment metrics, the historian for process trends, and the gateway's tag routes for current values. Routes to the document that owns each feed.

Adding a Page to This Section

Integration documentation comes in two tiers, and a contributor's first decision is which tier new material belongs to.

Interface pages are normative. System Interface, MQTT Telemetry, MES Integration, SCADA Integration, and OMF Egress own the protocol contracts: endpoints, payloads, topic structure, authentication, and limits. Each contract lives in exactly one of them. Where two interfaces touch the same surface, one page specifies it and the other links to it.

Partner-class pages own no contract at all. A page organized around the software on the other end answers three questions and then hands off. Which interface should this class of product point at? What does such a product assume that we do not provide? Where is the authoritative reference for the mechanics? A partner page that begins specifying a payload has left its tier, and review treats that as a defect.

The rule exists because the drift already happened. Grafana is covered in Monitoring and Metrics under Grafana Dashboards, in Historian under Querying from other tools, and again in SCADA Integration under Integration Examples. A reader who finds all three has no way to tell which one is authoritative. Correct a wrong or stale treatment where it already lives. A new page that restates it becomes a fourth home for the same content.

A new partner-class page also adds its row to the product table above, so the routing stays complete as the section grows.

Related Documentation

• Architecture Overview -- where each interface sits in the system
• Data Interface -- retrieving historical data
• Historian -- time-series data model
• ChangeRequest Backends -- routing an approval to an external quality system over the webhook backend, or to a pull request over git-pr. The page lives under Platform Administration because the choice is an install-time one, and it is the authoritative reference for every eQMS seam.
• Identity Providers -- mapping a provider's group claim onto the roles a deployment defines, for Keycloak, Entra ID, Okta, Ping, Google Workspace and Auth0. It lives under Platform Administration for the same reason: the identity provider is chosen once at install time by whoever deploys the platform, with no per-interface choice.