Skip to content

What a Site Publishes Upstream

This guide is for the platform administrator or plant engineer deciding which of a plant's data may leave the cluster. Cloud-Native DCS can publish process values, ISA-88 equipment state, batch context, device health, and alarms to a system outside itself, such as a customer's process historian. Whether a particular site does that is a declaration on the Site CR, and this page is about making it.

Two switches, held by two people

Nothing is published unless both of the following are true, and they are deliberately not the same setting.

The deployment decides whether the product can reach an upstream system at all. That is the egress component being installed, the endpoint it posts to, and the credential it posts with, and it lives in the Helm chart because it is plumbing about an installation.

The site decides whether its equipment is anybody's to see. That is the northbound block on the Site CR, and it lives there because what a plant sends upstream is a statement about that plant. It belongs beside the rest of the site's declared configuration, where it is reviewable per site and shows up in the same change control as every other equipment declaration.

Either switch off means nothing leaves. An administrator who installs the egress has not thereby published anything, and a site that declares itself published has not thereby caused an egress to exist.

The default is unpublished

A Site CR with no northbound block publishes nothing. A cluster that has never opened this file cannot send a plant's process data outside itself, and that default is the point, arrived at deliberately.

The two mistakes available here do not cost the same. A site left unpublished by accident is discovered quickly, because an engineer is waiting for data that has not arrived. A site published by accident is discovered after the data has already left, and no setting changed afterwards recalls it.

Publishing a site

Set publish: true on the site whose equipment may be seen upstream.

apiVersion: physical.dcs.io/v1alpha1
kind: Site
metadata:
  name: plant-01
spec:
  enterpriseName: riverbend
  description: Riverbend distillery, plant 01

  northbound:
    publish: true

Every northbound transport reads this one declaration. A site's answer is therefore the same whichever transport is installed, and adding a second one later does not mean revisiting the decision on each site.

What is published, once a site is, is the declared equipment tree from the enterprise down to the tag, with the ISA-88 state, batch, procedural, health, and alarm context beside it. ADR 0044 settles that model, and a transport publishes no node the model does not carry. Only declared tags are published, so an address the runtime is reading without a declaration stays inside the cluster.

Withholding one unit

A site that publishes can still hold back individual units by name.

spec:
  northbound:
    publish: true
    excludeUnits:
      - toll-fermenter-04

This is for the unit a site cannot share while sharing the rest of itself, such as equipment running under a toll agreement with another customer, or a line where the recipe is the thing being protected. Entries are Unit CR names, and the list is read only when publish is true, because a site that publishes nothing has excluded every unit already.

A name matching no unit excludes nothing and is not an error. A unit is often declared after the exclusion written in anticipation of it, and rejecting the site's whole exposure declaration over one unmatched name would fail in the unsafe direction by leaving the site's real exclusions unapplied.

Reading a cluster's answer

kubectl get sites carries a Northbound column. Which sites publish is therefore one command, with no inspection of each object.

$ kubectl get sites
NAME        ENTERPRISE   AREACOUNT   NAMESPACE        NORTHBOUND
plant-01    riverbend    3           site-plant-01    true
plant-02    riverbend    2           site-plant-02

An empty column is a site with no northbound block, which publishes nothing.

What this does not control

This block governs equipment exposure to upstream systems outside the cluster. It is not an access-control mechanism for the product's own surfaces. The gateway's REST API, the web UI, the HMI, and the MQTT topic tree inside the cluster are governed by authentication and RBAC, and a site that publishes nothing upstream is still fully visible to the engineers who operate it.

Publication is also read-only in both directions of that sentence. An upstream system receives data and cannot command equipment through this path, because a write arriving that way would bypass the gateway's authenticated, audited, and attributed write path.