This is an old revision of the document!
Runtime Plane
Discussion
A Runtime Plane classifies the architectural purpose of runtime communication and behaviour. Runtime Planes help the architecture keep distinct the different kinds of runtime activity, including control, data, health and observability, policy and release, and audit and provenance.
Runtime Plane classification helps authors and reviewers understand why an interaction exists, what concern it supports, and which governance, traceability, evidence, or access-control expectations may apply.
A Runtime Plane exists at the conceptual level. Later parts may represent or enforce runtime-plane separation through naming conventions, DDS Topics, DDS partitions, Kubernetes namespaces, network segmentation, security policies, or deployment configuration. Those mechanisms do not define the Runtime Plane.
Definition
classification of runtime communication and behaviour by architectural purpose
Source
Adapted from FX Demo Reference Architecture, Sections 4.4 and 4.4.1 through 4.4.7, Runtime Plane Model; aligned with SIP-RA separation of data, control, semantics, interpretation, governance, and evidence concerns.
Note
A Runtime Plane is not a DDS Domain, DDS partition, Kubernetes namespace, network segment, container group, security zone, or deployment environment.
Example
A heartbeat message may belong to the Health and Observability Plane, while a command acknowledgement may belong to the Control Plane.