dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane [2026/07/11 11:14] – removed - external edit (Unknown date) 127.0.0.1dido:99_annexes:annex-b-terms-and-definitions:r:runtime_plane [2026/07/18 12:33] (current) – external edit 127.0.0.1
Line 1: Line 1:
 +====== Runtime Plane ======
  
 +[[dido:99_annexes:annex-b-terms-and-definitions:start|Return to Terms and Definitions]]
 +
 +===== Discussion =====
 +
 +A Runtime Plane classifies the architectural purpose of runtime communication and behavior. 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 behavior 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 [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]].