| Next revision | Previous revision |
| dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:twin-005-acquire-twin-state:start [2026/08/20 15:40] – created nick_dido | dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:twin-005-acquire-twin-state:start [2026/08/20 17:32] (current) – nick_dido |
|---|
| ====== TWIN-005 — Access Twin State ====== | ====== TWIN-005 — Access Twin Realization State ====== |
| |
| [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:start|Go to C.3.3 Twin Node Requirements]] | [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:start|Go to C.3.3 Twin Node Requirements]] |
| |
| TWIN-005 is a non-leaf requirement group governing controlled access to the state represented by a [[dido:99_annexes:annex-b-terms-and-definitions:t:twin_realization|Twin Realization]] within a [[dido:99_annexes:annex-b-terms-and-definitions:t:twin_relationship|Twin Relationship]]. | TWIN-005 is a non-leaf requirement group governing establishment, determination, access, and contextualization of the state of a [[dido:99_annexes:annex-b-terms-and-definitions:t:twin_realization|Twin Realization]] within a [[dido:99_annexes:annex-b-terms-and-definitions:t:twin_relationship|Twin Relationship]]. |
| |
| Access to Twin State includes identification of the represented state, access to its values, identification of the [[dido:99_annexes:annex-b-terms-and-definitions:d:data_source|Data Source]], association of the state with time, preservation of provenance, and identification of unavailable state. | The state of a Twin Realization describes the condition of the characteristics represented by that Twin Realization at a specified time. That state provides a controlled basis for synchronization, simulation, comparison, [[dido:99_annexes:annex-b-terms-and-definitions:v:validation|Validation]], and [[dido:99_annexes:annex-b-terms-and-definitions:t:test_execution|Test Execution]]. |
| |
| The communication mechanism used to obtain state does not, by itself, establish the semantic meaning, source eligibility, or authority of the state. | Access to the state of a Twin Realization includes establishment of an initial state, determination of its current state, access to state values, identification of the originating [[dido:99_annexes:annex-b-terms-and-definitions:d:data_source|Data Source]], association of state with time, preservation of provenance, and detection of an invalid or unknown state. |
| | |
| | The communication mechanism used to obtain state information does not, by itself, establish the semantic meaning, validity, source eligibility, authority, or temporal context of that state. |
| |
| Conformance is assessed against the individual leaf requirements listed below. TWIN-005 does not establish a separate conformance obligation. | Conformance is assessed against the individual leaf requirements listed below. TWIN-005 does not establish a separate conformance obligation. |
| |
| ^ Requirement ID ^ Requirement Title ^ Purpose ^ | ^ Requirement ID ^ Requirement Title ^ Purpose ^ |
| | TWIN-005a | Identify Twin State | Identify the state represented by a Twin Realization that participates in the Twin Relationship. | | | TWIN-005a | Establish the Initial State of a Twin Realization | Establish a controlled starting state for a Twin Realization before its use in Test Execution. | |
| | TWIN-005b | Access Twin State Values | Obtain the values associated with identified Twin State. | | | TWIN-005b | Determine the Current State of a Twin Realization | Determine the current condition of the represented characteristics of a Twin Realization. | |
| | TWIN-005c | Identify Twin State Source | Identify the Data Source from which an accessed Twin State value originated. | | | TWIN-005c | Access Twin Realization State Values | Provide access to the values that constitute the determined state of a Twin Realization. | |
| | TWIN-005d | Associate Twin State with Time | Associate an accessed Twin State value with the time information required to interpret that value. | | | TWIN-005d | Identify the State Data Source | Identify the Data Source from which each accessed state value originated. | |
| | TWIN-005e | Preserve Twin State Provenance | Preserve provenance information associated with accessed Twin State. | | | TWIN-005e | Associate Twin Realization State with Time | Associate the state of a Twin Realization with the temporal information required to interpret that state. | |
| | TWIN-005f | Identify Unavailable Twin State | Identify when required Twin State is unavailable. | | | TWIN-005f | Preserve Twin Realization State Provenance | Preserve provenance associated with the state of a Twin Realization and its constituent values. | |
| | | TWIN-005g | Detect an Invalid or Unknown Twin Realization State | Detect when the state of a Twin Realization cannot be established as valid and known. | |
| |
| ===== Contents ===== | ===== Contents ===== |
| |
| * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:twin-005-acquire-twin-state:twin-005a-identify-twin-state|TWIN-005a — Identify Twin State]] | |
| * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:twin-005-acquire-twin-state:twin-005b-access-twin-state-values|TWIN-005b — Access Twin State Values]] | |
| * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:twin-005-acquire-twin-state:twin-005c-identify-twin-state-source|TWIN-005c — Identify Twin State Source]] | |
| * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:twin-005-acquire-twin-state:twin-005d-associate-twin-state-with-time|TWIN-005d — Associate Twin State with Time]] | |
| * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:twin-005-acquire-twin-state:twin-005e-preserve-twin-state-provenance|TWIN-005e — Preserve Twin State Provenance]] | |
| * [[dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:twin-005-acquire-twin-state:twin-005f-identify-unavailable-twin-state|TWIN-005f — Identify Unavailable Twin State]] | |
| |
| {{indexmenu>dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:twin-005-acquire-twin-state#1|js navbar nocookie maxjs#1 id#dido_te_twin_005_requirements_nav}} | {{indexmenu>dido:03-dido-te:99-annexes:annex-c-requirements:03-functional-requirements:03-03-twin-node-requirements:twin-005-acquire-twin-state#1|js navbar nocookie maxjs#1 id#dido_te_twin_005_requirements_nav}} |
| ===== Source ===== | ===== Source ===== |
| |
| * [[dido:03-dido-te:99-annexes:annex-b-references:dte-001|[DTE1] U.S. Patent Application US20220237111A1]], virtual and physical Twin Node concepts, observation of Twin Node behavior, baseline results, and comparison of results | * [[dido:03-dido-te:99-annexes:annex-b-references:dte-001|[DTE1] U.S. Patent Application US20220237111A1]], virtual and physical Twin Node concepts, baseline test results, modification of Twin Nodes, comparison of results, and validation |
| * [[dido:03-dido-te:99-annexes:annex-b-references:dte-002|[DTE2] Non-Traditional BAA Submission]], Digital Twin concepts, real-time monitoring, scenario testing, and Twin Nodes Selection | * [[dido:03-dido-te:99-annexes:annex-b-references:dte-002|[DTE2] Non-Traditional BAA Submission]], Digital Twin concepts, real-time monitoring, scenario testing, and Twin Nodes Selection |
| * [[dido:03-dido-te:99-annexes:annex-b-references:dte-009|[DTE9] Distributed Immutable Data Object Reference Architecture (DIDO-RA)]], Digital Twin and distributed data concepts | * [[dido:03-dido-te:99-annexes:annex-b-references:dte-009|[DTE9] Distributed Immutable Data Object Reference Architecture (DIDO-RA)]], Digital Twin and distributed data concepts |
| ===== Rationale ===== | ===== Rationale ===== |
| |
| A [[dido:99_annexes:annex-b-terms-and-definitions:t:twin_relationship|Twin Relationship]] depends on access to represented state when that state is used for monitoring, synchronization, simulation, comparison, or Test Execution. | A [[dido:99_annexes:annex-b-terms-and-definitions:t:twin_relationship|Twin Relationship]] represents selected characteristics of a logical twin through one or more [[dido:99_annexes:annex-b-terms-and-definitions:t:twin_realization|Twin Realizations]]. Testing requires more than access to isolated values. The DIDO-TE requires a controlled understanding of each participating Twin Realization's state. |
| |
| The [[dido:99_annexes:annex-b-terms-and-definitions:t:twin_data_mapping|Twin Data Mapping]] establishes the semantic correspondence between represented characteristics and their data representations. TWIN-005 governs access to the resulting state values and the contextual information required to interpret those values. | The [[dido:99_annexes:annex-b-terms-and-definitions:t:twin_data_mapping|Twin Data Mapping]] establishes the semantic correspondence between represented characteristics and their data representations. The state of a Twin Realization describes the condition represented by those characteristics at a specified time. |
| |
| State access must remain distinguishable from source eligibility and [[dido:99_annexes:annex-b-terms-and-definitions:s:source_selection|Source Selection]]. A technically available value does not become authoritative Twin State solely because it is reachable or received through a communication mechanism. | Establishing the initial state of a Twin Realization provides a controlled starting point for Test Execution. Determining its current state provides the basis for observing subsequent changes and comparing actual state with expected or previously established state. |
| |
| State values also require sufficient context to support reproducibility and comparison. This includes identification of their source, temporal association, provenance, and availability status. | Access to state remains distinct from Data Source eligibility and [[dido:99_annexes:annex-b-terms-and-definitions:s:source_selection|Source Selection]]. A technically available value does not establish the state of a Twin Realization solely because the value is reachable or received through a communication mechanism. |
| | |
| | Interpretation of state also depends on the origin, temporal context, and provenance of the values from which that state is determined. The architecture therefore preserves those relationships independently of the communication technology used to obtain the data. |
| | |
| | An invalid or unknown state requires detection because synchronization, simulation, comparison, Validation, or Test Execution performed from an indeterminate state can compromise reproducibility and interpretation of results. |
| |
| ===== Applies To ===== | ===== Applies To ===== |
| * [[dido:99_annexes:annex-b-terms-and-definitions:t:test_definition|Test Definition]] | * [[dido:99_annexes:annex-b-terms-and-definitions:t:test_definition|Test Definition]] |
| * [[dido:99_annexes:annex-b-terms-and-definitions:t:test_execution|Test Execution]] | * [[dido:99_annexes:annex-b-terms-and-definitions:t:test_execution|Test Execution]] |
| | * [[dido:99_annexes:annex-b-terms-and-definitions:v:validation|Validation]] |
| |
| ===== Traceability ===== | ===== Traceability ===== |
| ===== ConOps Relationship ===== | ===== ConOps Relationship ===== |
| |
| This requirement group supports ConOps activities that access Twin State after the Twin Relationship, Twin Data Mappings, eligible Data Sources, Source Selection criteria, and communication characteristics have been established. | This requirement group supports establishment and determination of the state of a Twin Realization before and during Test Execution. |
| |
| Accessed Twin State supports subsequent synchronization, simulation, comparison, Validation, monitoring, and evidence-producing activities. | The initial state establishes the controlled starting condition for a Twin Realization. Subsequent determination of its state supports observation of state changes, synchronization among Twin Realizations, simulation, comparison, Validation, monitoring, and evidence-producing activities. |
| | |
| | The Data Source, temporal context, and provenance associated with the state of a Twin Realization support reproducibility and interpretation of Test Execution results. |
| |
| ===== Delivery Phase ===== | ===== Delivery Phase ===== |
| The explicit child links under Contents remain while the subordinate requirement pages are being created and reviewed. After all child pages exist, you may remove the explicit links because the ''indexmenu'' automatically discovers them. | The explicit child links under Contents remain while the subordinate requirement pages are being created and reviewed. After all child pages exist, you may remove the explicit links because the ''indexmenu'' automatically discovers them. |
| |
| The displayed title has been changed from //Acquire Twin State// to //Access Twin State// because //access// better describes the technology-neutral architectural capability. The existing namespace ''twin-005-acquire-twin-state'' remains unchanged to preserve the stable URI. | The displayed title is //Access Twin Realization State//. The existing namespace ''twin-005-acquire-twin-state'' remains unchanged to preserve the stable URI. |
| | |
| | The architecture does not define //Twin State// as a separate controlled term. State is treated as a characteristic of a Twin Realization, consistent with how the Node requirements treat state. |
| | |
| | The decomposition intentionally distinguishes: |
| | |
| | * establishment of the initial state of a Twin Realization; |
| | * determination of its current state; |
| | * access to the values constituting that state; |
| | * identification of the originating Data Source; |
| | * temporal association; |
| | * provenance; and |
| | * detection of an invalid or unknown state. |
| |
| Do not treat successful receipt of data as sufficient evidence that the data represents valid Twin State. Eligibility, Source Selection, Twin Data Mapping, provenance, and other governing Configuration remain separate concerns. | Do not treat successful receipt of data as sufficient evidence that the data establishes the state of a Twin Realization. Twin Data Mapping, Data Source eligibility, Source Selection, temporal context, provenance, and governing Configuration remain separate architectural concerns. |
| |
| ---- | ---- |