OT Domains
Model operational function without confusing it with security architecture.
A security zone answers one question: what is protected together, and to what expectation. A functional domain answers a different one: what operational job is this part of the plant doing. Collapsing the two loses both answers.
- Customer-defined: OTReady ships no fixed domain taxonomy
- Hierarchical, with stable identity that survives renaming
- Many-to-many across zones, subzones, conduits, channels and assets
Two different questions about the same object.
One object routinely serves several operational functions while sitting in exactly one security scope. A model that offers only one of these forces the operator to distort the other.
Neither answer is derivable from the other. That is precisely why they are separate relations rather than one field with two meanings.
Security zone
What is grouped together for protection, and what it is expected to withstand. One object sits in one scope, and that scope carries approval state and target context.
OT Domain
What operational function the object serves. An object can belong to several domains at once, and a domain spans as many objects as it needs to.
Canonical properties
What an OT Domain actually is.
- Customer-defined
- The operator names their own domains. Nothing in the product hardcodes a sector's vocabulary.
- Hierarchical
- Domains can nest, so a broad function can contain more specific ones.
- Stable identity
- Renaming a domain changes its label and keeps every assignment already made against it.
- Many domains per object
- One zone, conduit, channel or asset can carry several domain assignments.
- Many objects per domain
- A domain spans whatever set of objects genuinely performs that function.
- Assignment is explicit
- Nothing is inferred from a name, a Purdue level or an address. A domain assignment exists because someone made it.
Illustrative only
Examples, not a product taxonomy.
Operators typically name domains after the work being done: grid operations, substation automation, telecontrol, crane operations, process control, safety systems. Those are examples of the shape, not options in a dropdown.
This matters for more than tidiness. Hardcoding a utility's vocabulary would put it in front of a port operator, and a taxonomy that has to be argued with is a taxonomy that gets filled in badly.
What an OT Domain is not.
A domain is not a security zone, not a Purdue level, not a Security Level and not a score. It carries no target, contributes no rating and changes no assessment outcome. It is context: a way of asking "show me everything that serves telecontrol" without that question pretending to be a security judgement.
In the product
Assigned where the object lives.
Domains are assigned on the object itself, on a zone, a conduit, a channel or an asset, rather than in a separate registry that has to be kept in step.
Because assignment is many-to-many and explicit, the same object can appear under several functional views without any of them claiming to be its security scope.
Related capabilities
Architecture
The canonical objects domains are assigned to.
Assurance
How context is used to explain a derived reading.
Describe your plant in your own words.
Bring your operational vocabulary and see it modelled without being flattened into a security diagram.