C.3.3 Twin Node Requirements

Go to C.3 Functional Requirements

This section identifies the requirements governing Twin Nodes used to represent, observe, simulate, reproduce, compare, select, or interact with corresponding Nodes within distributed verification and testing.

Twin Node requirements address the controlled relationship among a logical twin identity, one or more Twin Node realizations, and the corresponding real-world, virtual, simulated, or otherwise represented Node.

The requirements address twin identity, association, Configuration, realization selection, state acquisition, synchronization, simulation, comparison, controlled interaction, validation, and Traceability.

A logical twin identity may be associated with more than one Twin Node realization. A Test Execution may therefore select the applicable realization without changing the logical identity represented within the test.

A Twin Node may receive information from multiple eligible sources. Configuration, communication policies, and applicable Quality of Service controls govern source eligibility and communication behavior without assigning semantic authority to a source solely because the source participates in the communication mechanism.

The requirements in this section derive from the applicable source documents identified in Annex B.

The DIDO-TE BAA identifies Digital Twins as a means of representing systems or systems of systems and explicitly requires functionality to manage and select between virtual and real-world twin nodes during testing.

The U.S. Patent Application describes virtual and physical Twin Nodes addressed using an identifier shared by one or more other Twin Nodes. It also describes adding or modifying a Twin Node, comparing resulting test results against a baseline, and validating the Twin Node or emulated distributed system when the results correspond.

The DIDO Reference Architecture provides the broader Digital Twin, DDS publish-subscribe, and DDS Quality of Service concepts used to normalize and decompose these source concepts into individually verifiable architectural obligations.

A Twin Node requirement may be represented by an individual leaf requirement or by a non-leaf requirement group containing subordinate independently verifiable obligations.

• TWIN-001 — Establish Twin Identity
• TWIN-002 — Associate Twin Realizations
• TWIN-003 — Configure a Twin Relationship
• TWIN-004 — Select a Twin Realization
• TWIN-005 — Acquire Twin State
• TWIN-006 — Synchronize Twin State
• TWIN-007 — Simulate Twin Behavior
• TWIN-008 — Compare Twin Results
• TWIN-010 — Control Twin Interaction
• TWIN-011 — Maintain Twin Traceability

---

Twin Node requirements use the TWIN requirement prefix.

The explicit links under Contents remain while the Twin Node requirement pages are being created and reviewed. After all planned requirement pages exist, the explicit links may be removed because the indexmenu automatically discovers them.

Apply the requirement identification, decomposition, source and derivation, normative-language, quality, status, and page-structure rules defined by Annex C.

Preserve stable requirement identifiers when moving or reorganizing Twin Node requirement pages.

Do not allocate Twin Node requirements directly to a particular DDS implementation, product, or realization within the requirement Statement. Maintain realization relationships through Traceability.

---