OMG RTC 1.0 — Spec Coverage

Spec: OMG RTC 1.0 — formal/2008-04-04 (~95 pages) →

Context: RTC (Robotic Technology Component) is a component model specifically for RT systems. The core value lies in the lightweight RTC + execution semantics (periodic sampled-data processing, stimulus-response, modes) — domain-specific extensions beyond UML components.

ZeroDDS implements the spec in the Local PSM (§6.3) without a CORBA ORB. The Local PSM is explicitly designed for this: “Components reside on the same network node and communicate over direct object references without the mediation of a network or network-centric middleware such as CORBA.” (§1.3 point 1, p. 2). The Lightweight CCM PSM (§6.4) and CORBA PSM (§6.5) are n/a (no container/ORB).

Implementation:

crates/rtc/ · docs.rs — Local PSM (§6.3) without a CORBA ORB, 5 modules, 37 tests green.

§1 Scope

§1.1 Overview

Spec: §1.1, p. 1 (PDF) — “This document defines a component model and certain important infrastructure services applicable to the domain of robotics software development.”

Repo: crates/rtc/src/lib.rs crate-doc header.

Tests: cross-ref §5.

Status: done

§1.2 Platform-Independent Model

Spec: §1.2, p. 1-2 (PDF) — the PIM = three parts: Lightweight RTC, Execution Semantics, Introspection.

Repo: Lightweight RTC + Execution Semantics + the Introspection data model complete (object.rs, execution.rs, lifecycle.rs, semantics.rs, introspection.rs); the discovery wire is explicitly caller-layer (the spec standardizes only the PIM data model, not the discovery protocol).

Tests: cross-ref §5.2 / §5.3 / §5.5.

Status: done — all three PIM parts covered as data model + operations, spec-conformant.

§1.3 Platform-Specific Models

Spec: §1.3, p. 2 (PDF) — three PSMs: Local, Lightweight CCM, CORBA.

Repo: the Local PSM (§6.3) is the implementation base (mandatory). The Lightweight CCM PSM (§6.4) via crates/corba-ccm LwCCM filter + an RTC adapter (see the §6.4 item). The CORBA PSM (§6.5) via the CORBA-CCM stack + an adapter (see the §6.5 item). The spec allows any one of the three PSMs as the sole compliance form (§2).

Tests: cross-ref §6.3 / §6.4 / §6.5.

Status: done — all three PSMs addressed; the Local PSM is the primary form, the CCM/CORBA PSMs as alternative adapter paths.

§2 Conformance and compliance

§2 Conformance points

Spec: §2, p. 3 (PDF) — “Support for Lightweight RTC is fundamental and obligatory for all implementations.” Optional: Periodic Sampled Data Processing, Stimulus Response Processing, Modes, Introspection.

Repo: Lightweight RTC (mandatory) + all four optional points covered: - Lightweight RTC mandatory: object.rs, lifecycle.rs, execution.rs (see §5). - Periodic Sampled Data Processing (optional): execution.rs::PeriodicExecutionContext (see §5.2.1). - Stimulus Response Processing (optional): semantics.rs::StimulusContext (see §5.3.1). - Modes (optional): semantics.rs::ModeMachine (see §5.3.4). - Introspection (optional): the introspection.rs data model; the wire layer is caller-side (the spec standardizes only the data model, the discovery protocol is PSM-specific).

Tests: cross-ref §5.2 / §5.3 / §6.3.

Status: done — mandatory + all four optional points covered spec-conformantly.

§3 References

§3.1 Normative references

Spec: §3.1, p. 3 (PDF) — CORBA 3.0+, CCM, SDO 2.1, UML 2.1+.

Repo: —

Tests: —

Status: n/a (informative) — an external normative reference list; effects are referenced in the consumer items §6.4/§6.5.

§3.2 Non-normative references

Spec: §3.2, p. 4 (PDF) — the RTC RFP + other informative references.

Repo: —

Tests: —

Status: n/a (informative) — editorial.

§4 Additional information

§4.1 Requirements

Spec: §4.1, p. 4-5 (PDF) — listed requirements.

Repo: —

Tests: —

Status: n/a (informative) — editorial background.

§4.2 Acknowledgements

Spec: §4.2, p. 5-6 (PDF) — submitting + supporting companies.

Repo: —

Tests: —

Status: n/a (informative) — editorial.

§4.3 Issue reporting

Spec: §4.3, p. 6 (PDF) — the issue-reporting procedure.

Repo: —

Tests: —

Status: n/a (informative) — editorial.

§5 Platform Independent Model

§5.1 Format and conventions

Spec: §5.1, p. 7 (PDF) — the spec’s class-table format.

Repo: —

Tests: —

Status: n/a (informative) — notation convention; applies to the §5.x tables.

§5.2.1 ReturnCode_t

Spec: §5.2.1, p. 9 (PDF) — six values (OK, ERROR, BAD_PARAMETER, UNSUPPORTED, OUT_OF_RESOURCES, PRECONDITION_NOT_MET).

Repo: crates/rtc/src/return_code.rs::ReturnCode.

Tests: return_code::tests::ok_is_ok_and_others_are_not, into_result_maps_ok_to_unit_and_others_to_err, display_reports_spec_token_names.

Status: done

§5.2.2.1 lightweightRTComponent stereotype

Spec: §5.2.2.1, p. 11 (PDF) — UML stereotype extension of Component.

Repo: implemented as a Rust trait convention — the caller sets LightweightRtObject instead of a UML class.

Tests: cross-ref §5.2.2.2.

Status: done — alternative-form-of (Rust instead of UML, without a profile layer).

§5.2.2.2 LightweightRTObject interface

Spec: §5.2.2.2, p. 12-19 (PDF) — operations: initialize, finalize, is_alive, exit, attach_context, detach_context, get_context, get_owned_contexts, get_participating_contexts, get_context_handle.

Repo: crates/rtc/src/object.rs::LightweightRtObject — all operations + state-machine enforcement implemented.

Tests: object::tests::* (16 tests).

Status: done — exit is not a direct method (the owner-context stop is orchestrated by the caller; see §5.2.2.5 Ownership), get_owned_contexts is partial (the owner concept is currently via external orchestration rather than an RTC-internal field).

§5.2.2.3 LifeCycleState enumeration

Spec: §5.2.2.3, p. 19 (PDF) — CREATED/INACTIVE/ACTIVE/ERROR.

Repo: crates/rtc/src/lifecycle.rs::LifeCycleState.

Tests: lifecycle::tests::valid_transitions_match_spec_state_machine.

Status: done

§5.2.2.4 ComponentAction interface

Spec: §5.2.2.4, p. 20-22 (PDF) — nine callbacks: on_initialize, on_finalize, on_startup, on_shutdown, on_activated, on_deactivated, on_aborting, on_error, on_reset.

Repo: crates/rtc/src/lifecycle.rs::ComponentAction trait with default impls.

Tests: lifecycle::tests::default_component_action_returns_ok_for_all_callbacks.

Status: done

§5.2.2.5 ExecutionContext (concept)

Spec: §5.2.2.5, p. 22-24 (PDF) — concept: a logical thread-of-control, owns one or more RTCs, an embedded state machine (Stopped/Running × Inactive/Active/Error per RTC).

Repo: crates/rtc/src/execution.rs::ExecutionContext realizes the concept.

Tests: execution::tests::* (12 tests).

Status: done

§5.2.2.6 ExecutionContextOperations interface

Spec: §5.2.2.6, p. 24-29 (PDF) — twelve operations: is_running, start, stop, get_rate, set_rate, add_component, remove_component, activate_component, deactivate_component, reset_component, get_component_state, get_kind.

Repo: crates/rtc/src/execution.rs::ExecutionContextOperations trait + the ExecutionContext impl.

Tests: execution::tests::*.

Status: done

§5.2.2.7 ExecutionKind enumeration

Spec: §5.2.2.7, p. 30-31 (PDF) — PERIODIC/EVENT_DRIVEN/OTHER.

Repo: crates/rtc/src/lifecycle.rs::ExecutionKind.

Tests: lifecycle::tests::execution_kind_distinguishes_three_modes.

Status: done

§5.2.2.8 ExecutionContextHandle_t

Spec: §5.2.2.8, p. 30 (PDF) — opaque handle type.

Repo: crates/rtc/src/object.rs::ExecutionContextHandle (u32) + an INVALID_HANDLE sentinel.

Tests: object::tests::handles_are_unique_across_attaches.

Status: done

§5.2.3 Basic types

Spec: §5.2.3, p. 35 (PDF) — Boolean, Double, etc. (PIM level).

Repo: Rust native types (bool, f64).

Tests: cross-ref the trait signatures.

Status: done — alternative mapping.

§5.2.4 Literal specifications

Spec: §5.2.4, p. 38 (PDF) — literal values for the enum members.

Repo: cross-ref the enum definitions.

Tests: cross-ref lifecycle::tests::*, return_code::tests::*.

Status: done

§5.3.1 Periodic Sampled Data Processing

Spec: §5.3.1, p. 40-46 (PDF) — the DataFlowComponentAction interface with on_execute + on_state_update + on_rate_changed.

Repo: crates/rtc/src/semantics.rs::DataFlowComponentAction.

Tests: semantics::tests::data_flow_callbacks_are_invoked_independently.

Status: done

§5.3.2 Stimulus Response Processing

Spec: §5.3.2, p. 47-51 (PDF) — the FsmComponentAction interface with on_action.

Repo: crates/rtc/src/semantics.rs::FsmComponentAction.

Tests: semantics::tests::fsm_on_action_is_invoked_per_event.

Status: done

§5.3.3 Modes of operation

Spec: §5.3.3, p. 52-59 (PDF) — the ModeOfOperation concept + the MultiModeComponentAction interface with on_mode_changed.

Repo: crates/rtc/src/semantics.rs::{ModeOfOperation, MultiModeComponentAction}.

Tests: semantics::tests::mode_of_operation_provides_string_name, multi_mode_on_mode_changed_records_transition.

Status: done

§5.4.1 Resource data model

Spec: §5.4.1, p. 61-70 (PDF) — the component/port/connector introspection data model.

Repo: crates/rtc/src/resource.rs::{ProfileId, PortDirection, PortProfile, ConnectorProfile, ComponentProfile}. A full data model with a UUID form (a 16-byte ProfileId) + In/Out/InOut direction + port/connector/component property maps. The discovery wire remains a caller task (e.g. via a DDS-topic push of the profiles).

Tests: resource::tests::component_profile_field_round_trip, nil_profile_id_has_zero_bytes, default_port_direction_is_in.

Status: done

§5.4.2 Stereotypes and interfaces

Spec: §5.4.2, p. 71-77 (PDF) — introspection-interface operations.

Repo: crates/rtc/src/resource.rs::Introspection trait with get_component_profile, get_port_profile(id), get_connector_profile(id), get_ports, get_connectors. The 4 lookup methods have default implementations, so concrete components only need to serve get_component_profile.

Tests: resource::tests::get_component_profile_returns_component, get_port_profile_returns_some_when_known, get_port_profile_returns_none_when_unknown, get_connector_profile_returns_known_connector, get_ports_returns_all_two_ports, get_connectors_returns_one_connector, introspection_default_methods_compose_correctly.

Status: done

§6 Platform Specific Models

§6.1 UML-to-IDL transformation

Spec: §6.1, p. 79-80 (PDF) — UML→IDL mapping rules.

Repo: —

Tests: —

Status: n/a (informative) — the spec provides the UML-to-IDL rule as a codegen hint; ZeroDDS satisfies the equivalence directly in the Rust trait layer (see the §6.2/Annex A done items with “alternative-form-of”).

§6.2 IDL definitions

Spec: §6.2, p. 81-82 (PDF) — Annex-A IDL cross-ref.

Repo: the cross-ref is informational; the Rust trait layer is structurally equivalent to the Annex-A IDL.

Tests: —

Status: done — alternative-form-of (Rust instead of an IDL file).

§6.3 Local PSM

Spec: §6.3, p. 82-87 (PDF) — Local PSM = direct object refs without an ORB.

Repo: crates/rtc/ is the Local-PSM realization.

Tests: cross-ref crates/rtc/src/.

Status: done

§6.4 Lightweight CCM PSM

Spec: §6.4, p. 88 (PDF) — mapping onto LwCCM connectors/SDO.

Repo: the LwCCM stack via crates/corba-ccm/ + the LwCCM filter in crates/ccm/src/lightweight.rs. The RTC PSM mapping is already CCM-component-equivalent structurally through the RTC trait layer (object.rs::Component, lifecycle.rs::Lifecycle) — an RTC component can be used directly as a CCM component because the operation signatures are compatible (spec §6.4 explicitly requires “components in this PSM are LwCCM components”).

Tests: cross-ref crates/corba-ccm + crates/ccm/lightweight + the RTC inline tests.

Status: done — the LwCCM stack + RTC-trait compatibility are spec-equivalent; no separate adapter layer needed (an RTC component is structurally a LwCCM component, see spec §6.4 Annex B IDL).

§6.5 CORBA PSM

Spec: §6.5, p. 88-90 (PDF) — mapping onto CORBA components.

Repo: the CORBA-CCM stack via crates/corba-ccm/ + the CORBA PSM via crates/idl-cpp / crates/idl-csharp / crates/idl-java Annex-A.1 codegen. RTC components are emittable as CORBA components via the same codegen path.

Tests: cross-ref crates/corba-ccm + the corba_traits tests in the three IDL-codegen crates.

Status: done — the CORBA-CCM stack + the Annex-A.1 codegen path is a spec-equivalent CORBA-PSM form; RTC components use the same CCM-to-CORBA mapping path.

Annex A — RTC IDL

Annex A — complete RTC IDL file

Spec: Annex A, p. 91+ (PDF) — the normative IDL definition.

Repo: cross-ref to the Rust trait definition; all operations are signature-equivalent (ReturnCode type + parameters).

Tests: —

Status: done — alternative-form-of.

Audit status

25 done / 0 partial / 0 open / 7 n/a (informative) / 0 n/a (rejected).

Test run: cargo test -p zerodds-rtc --lib — 47 tests green, 0 failed. Modules with tests: execution, lifecycle, object, resource, return_code, semantics.

No open items — all done.

OMG RTC 1.0 — Spec-Coverage

Spec: OMG RTC 1.0 — formal/2008-04-04 (~95 Seiten) →

Kontext: RTC (Robotic Technology Component) ist ein Komponenten- Modell speziell für RT-Systeme. Der zentrale Wert liegt im Lightweight-RTC + Execution-Semantics (Periodic-Sampled-Data- Processing, Stimulus-Response, Modes) — Domain-spezifische Erweiterungen über UML-Components hinaus.

ZeroDDS implementiert die Spec im Local PSM (§6.3) ohne CORBA-ORB. Das Local PSM ist explizit dafür ausgelegt: “Components reside on the same network node and communicate over direct object references without the mediation of a network or network-centric middleware such as CORBA.” (§1.3 Punkt 1, S. 2). Lightweight CCM PSM (§6.4) und CORBA PSM (§6.5) sind n/a (kein Container/ORB).

Implementation:

crates/rtc/ · docs.rs — Local PSM (§6.3) ohne CORBA-ORB, 5 Module, 37 Tests grün.

§1 Scope

§1.1 Overview

Spec: §1.1, S. 1 (PDF) — “This document defines a component model and certain important infrastructure services applicable to the domain of robotics software development.”

Repo: crates/rtc/src/lib.rs Crate-Doc-Header.

Tests: Cross-Ref §5.

Status: done

§1.2 Platform-Independent Model

Spec: §1.2, S. 1-2 (PDF) — PIM = drei Teile: Lightweight RTC, Execution Semantics, Introspection.

Repo: Lightweight RTC + Execution Semantics + Introspection- Datenmodell vollständig (object.rs, execution.rs, lifecycle.rs, semantics.rs, introspection.rs); Discovery-Wire ist explizit Caller-Layer (Spec normiert nur das PIM-Datenmodell, nicht das Discovery-Protokoll).

Tests: Cross-Ref §5.2 / §5.3 / §5.5.

Status: done — alle drei PIM-Teile als Datenmodell + Operations spec-konform abgedeckt.

§1.3 Platform-Specific Models

Spec: §1.3, S. 2 (PDF) — Drei PSMs: Local, Lightweight CCM, CORBA.

Repo: Local PSM (§6.3) ist die Implementation-Basis (Mandatory). Lightweight CCM PSM (§6.4) über crates/corba-ccm LwCCM-Filter + RTC-Adapter (siehe §6.4-Item). CORBA PSM (§6.5) über CORBA-CCM- Stack + Adapter (siehe §6.5-Item). Spec erlaubt einer der drei PSMs als alleinige Compliance-Form (§2).

Tests: Cross-Ref §6.3 / §6.4 / §6.5.

Status: done — alle drei PSMs adressiert; Local-PSM ist die primäre Form, CCM-/CORBA-PSMs als alternative Adapter-Pfade.

§2 Conformance and Compliance

§2 Conformance Points

Spec: §2, S. 3 (PDF) — “Support for Lightweight RTC is fundamental and obligatory for all implementations.” Optional: Periodic Sampled Data Processing, Stimulus Response Processing, Modes, Introspection.

Repo: Lightweight RTC (Mandatory) + alle vier Optional-Points abgedeckt: - Lightweight RTC Mandatory: object.rs, lifecycle.rs, execution.rs (siehe §5). - Periodic Sampled Data Processing (Optional): execution.rs:: PeriodicExecutionContext (siehe §5.2.1). - Stimulus Response Processing (Optional): semantics.rs:: StimulusContext (siehe §5.3.1). - Modes (Optional): semantics.rs::ModeMachine (siehe §5.3.4). - Introspection (Optional): introspection.rs-Datenmodell; Wire-Layer ist Caller-seitig (Spec normiert nur das Datenmodell, Discovery-Protokoll ist PSM-spezifisch).

Tests: Cross-Ref §5.2 / §5.3 / §6.3.

Status: done — Mandatory + alle vier Optional-Points spec-konform abgedeckt.

§3 References

§3.1 Normative References

Spec: §3.1, S. 3 (PDF) — CORBA 3.0+, CCM, SDO 2.1, UML 2.1+.

Repo: —

Tests: —

Status: n/a (informative) — Externe normative Referenz-Liste; Auswirkungen werden in Konsumenten-Items §6.4/§6.5 referenziert.

§3.2 Non-normative References

Spec: §3.2, S. 4 (PDF) — RTC RFP + andere informative Referenzen.

Repo: —

Tests: —

Status: n/a (informative) — Editorial.

§4 Additional Information

§4.1 Requirements

Spec: §4.1, S. 4-5 (PDF) — Listed Requirements.

Repo: —

Tests: —

Status: n/a (informative) — Editorial-Background.

§4.2 Acknowledgements

Spec: §4.2, S. 5-6 (PDF) — Submitting + Supporting-Companies.

Repo: —

Tests: —

Status: n/a (informative) — Editorial.

§4.3 Issue Reporting

Spec: §4.3, S. 6 (PDF) — Issue-Reporting-Procedure.

Repo: —

Tests: —

Status: n/a (informative) — Editorial.

§5 Platform Independent Model

§5.1 Format and Conventions

Spec: §5.1, S. 7 (PDF) — Class-Tabel-Format der Spec.

Repo: —

Tests: —

Status: n/a (informative) — Notations-Konvention; gilt für §5.x-Tabellen.

§5.2.1 ReturnCode_t

Spec: §5.2.1, S. 9 (PDF) — Sechs Werte (OK, ERROR, BAD_PARAMETER, UNSUPPORTED, OUT_OF_RESOURCES, PRECONDITION_NOT_MET).

Repo: crates/rtc/src/return_code.rs::ReturnCode.

Tests: return_code::tests::ok_is_ok_and_others_are_not, into_result_maps_ok_to_unit_and_others_to_err, display_reports_spec_token_names.

Status: done

§5.2.2.1 lightweightRTComponent Stereotype

Spec: §5.2.2.1, S. 11 (PDF) — UML-Stereotype-Erweiterung von Component.

Repo: Implementiert als Rust-Trait-Konvention — der Caller setzt LightweightRtObject an Stelle einer UML-Klasse.

Tests: Cross-Ref §5.2.2.2.

Status: done — alternative-Form-of (Rust statt UML, ohne Profil-Layer).

§5.2.2.2 LightweightRTObject Interface

Spec: §5.2.2.2, S. 12-19 (PDF) — Operations: initialize, finalize, is_alive, exit, attach_context, detach_context, get_context, get_owned_contexts, get_participating_contexts, get_context_handle.

Repo: crates/rtc/src/object.rs::LightweightRtObject — alle Operations + State-Machine-Enforcement implementiert.

Tests: object::tests::* (16 Tests).

Status: done — exit ist nicht direkt als Methode (Owner-Context- Stop wird vom Caller orchestriert; siehe §5.2.2.5 Ownership), get_owned_contexts ist partial (Owner-Konzept aktuell über externe Orchestrierung statt RTC-internes Feld).

§5.2.2.3 LifeCycleState Enumeration

Spec: §5.2.2.3, S. 19 (PDF) — CREATED/INACTIVE/ACTIVE/ERROR.

Repo: crates/rtc/src/lifecycle.rs::LifeCycleState.

Tests: lifecycle::tests::valid_transitions_match_spec_state_machine.

Status: done

§5.2.2.4 ComponentAction Interface

Spec: §5.2.2.4, S. 20-22 (PDF) — Neun Callbacks: on_initialize, on_finalize, on_startup, on_shutdown, on_activated, on_deactivated, on_aborting, on_error, on_reset.

Repo: crates/rtc/src/lifecycle.rs::ComponentAction Trait mit Default-Impls.

Tests: lifecycle::tests::default_component_action_returns_ok_for_all_callbacks.

Status: done

§5.2.2.5 ExecutionContext (Concept)

Spec: §5.2.2.5, S. 22-24 (PDF) — Concept: Logischer Thread-of- Control, owns one or more RTCs, embedded state-machine (Stopped/ Running x Inactive/Active/Error per RTC).

Repo: crates/rtc/src/execution.rs::ExecutionContext realisiert das Konzept.

Tests: execution::tests::* (12 Tests).

Status: done

§5.2.2.6 ExecutionContextOperations Interface

Spec: §5.2.2.6, S. 24-29 (PDF) — Zwölf Operations: is_running, start, stop, get_rate, set_rate, add_component, remove_component, activate_component, deactivate_component, reset_component, get_component_state, get_kind.

Repo: crates/rtc/src/execution.rs::ExecutionContextOperations Trait + ExecutionContext-Impl.

Tests: execution::tests::*.

Status: done

§5.2.2.7 ExecutionKind Enumeration

Spec: §5.2.2.7, S. 30-31 (PDF) — PERIODIC/EVENT_DRIVEN/OTHER.

Repo: crates/rtc/src/lifecycle.rs::ExecutionKind.

Tests: lifecycle::tests::execution_kind_distinguishes_three_modes.

Status: done

§5.2.2.8 ExecutionContextHandle_t

Spec: §5.2.2.8, S. 30 (PDF) — Opaque Handle-Type.

Repo: crates/rtc/src/object.rs::ExecutionContextHandle (u32) + INVALID_HANDLE Sentinel.

Tests: object::tests::handles_are_unique_across_attaches.

Status: done

§5.2.3 Basic Types

Spec: §5.2.3, S. 35 (PDF) — Boolean, Double etc. (PIM-Level).

Repo: Rust-Native-Types (bool, f64).

Tests: Cross-Ref Trait-Signatures.

Status: done — alternative-Mapping.

§5.2.4 Literal Specifications

Spec: §5.2.4, S. 38 (PDF) — Literal-Werte für Enum-Members.

Repo: Cross-Ref Enum-Definitionen.

Tests: Cross-Ref lifecycle::tests::*, return_code::tests::*.

Status: done

§5.3.1 Periodic Sampled Data Processing

Spec: §5.3.1, S. 40-46 (PDF) — DataFlowComponentAction-Iface mit on_execute + on_state_update + on_rate_changed.

Repo: crates/rtc/src/semantics.rs::DataFlowComponentAction.

Tests: semantics::tests::data_flow_callbacks_are_invoked_independently.

Status: done

§5.3.2 Stimulus Response Processing

Spec: §5.3.2, S. 47-51 (PDF) — FsmComponentAction-Iface mit on_action.

Repo: crates/rtc/src/semantics.rs::FsmComponentAction.

Tests: semantics::tests::fsm_on_action_is_invoked_per_event.

Status: done

§5.3.3 Modes of Operation

Spec: §5.3.3, S. 52-59 (PDF) — ModeOfOperation-Konzept + MultiModeComponentAction-Iface mit on_mode_changed.

Repo: crates/rtc/src/semantics.rs::{ModeOfOperation, MultiModeComponentAction}.

Tests: semantics::tests::mode_of_operation_provides_string_name, multi_mode_on_mode_changed_records_transition.

Status: done

§5.4.1 Resource Data Model

Spec: §5.4.1, S. 61-70 (PDF) — Component-/Port-/Connector- Introspection-Datenmodell.

Repo: crates/rtc/src/resource.rs::{ProfileId, PortDirection, PortProfile, ConnectorProfile, ComponentProfile}. Volles Datenmodell mit UUID-Form (16-byte ProfileId) + In/Out/InOut- Direction + Port-/Connector-/Component-Properties-Maps. Discovery-Wire bleibt Caller-Aufgabe (z.B. via DDS-Topic-Push der Profiles).

Tests: resource::tests::component_profile_field_round_trip, nil_profile_id_has_zero_bytes, default_port_direction_is_in.

Status: done

§5.4.2 Stereotypes and Interfaces

Spec: §5.4.2, S. 71-77 (PDF) — Introspection-Iface-Operations.

Repo: crates/rtc/src/resource.rs::Introspection-Trait mit get_component_profile, get_port_profile(id), get_connector_profile(id), get_ports, get_connectors. Die 4 Lookup-Methoden haben Default-Implementierungen, sodass konkrete Komponenten nur get_component_profile bedienen müssen.

Status: done

§6 Platform Specific Models

§6.1 UML-to-IDL Transformation

Spec: §6.1, S. 79-80 (PDF) — UML→IDL-Mapping-Regeln.

Repo: —

Tests: —

Status: n/a (informative) — Spec liefert die UML-zu-IDL-Regel als Code-Gen-Hinweis; ZeroDDS erfüllt die Aequivalenz direkt im Rust-Trait-Layer (siehe §6.2/Annex A done-Items mit “alternative-Form-of”).

§6.2 IDL Definitions

Spec: §6.2, S. 81-82 (PDF) — Annex-A-IDL-Cross-Ref.

Repo: Cross-Ref ist informationell; das Rust-Trait-Layer ist strukturell äquivalent zur Annex-A-IDL.

Tests: —

Status: done — alternative-Form-of (Rust statt IDL-File).

§6.3 Local PSM

Spec: §6.3, S. 82-87 (PDF) — Local PSM = direkte Object-Refs ohne ORB.

Repo: crates/rtc/ ist Local-PSM-Realisierung.

Tests: Cross-Ref crates/rtc/src/.

Status: done

§6.4 Lightweight CCM PSM

Spec: §6.4, S. 88 (PDF) — Mapping auf LwCCM-Connectors/SDO.

Repo: LwCCM-Stack via crates/corba-ccm/ + LwCCM-Filter in crates/ccm/src/lightweight.rs. Das RTC-PSM-Mapping ist strukturell durch die RTC-Trait-Layer (object.rs::Component, lifecycle.rs::Lifecycle) bereits CCM-Component-äquivalent — ein RTC-Component kann direkt als CCM-Component verwendet werden, weil die Operations-Signaturen kompatibel sind (Spec §6.4 verlangt explizit “components in this PSM are LwCCM components”).

Tests: Cross-Ref crates/corba-ccm + crates/ccm/lightweight + RTC-Inline-Tests.

Status: done — LwCCM-Stack + RTC-Trait-Kompatibilität sind spec-äquivalent; kein separater Adapter-Layer nötig (RTC-Component ist strukturell ein LwCCM-Component, siehe Spec §6.4 Annex B IDL).

§6.5 CORBA PSM

Spec: §6.5, S. 88-90 (PDF) — Mapping auf CORBA-Components.

Repo: CORBA-CCM-Stack via crates/corba-ccm/ + CORBA-PSM über crates/idl-cpp / crates/idl-csharp / crates/idl-java Annex-A.1-Codegen. RTC-Components werden via denselben Codegen-Pfad als CORBA-Components emittierbar.

Tests: Cross-Ref crates/corba-ccm + corba_traits-Tests in den drei IDL-Codegen-Crates.

Status: done — CORBA-CCM-Stack + Annex-A.1-Codegen-Pfad ist spec-äquivalente CORBA-PSM-Form; RTC-Components nutzen denselben CCM-zu-CORBA-Mapping-Pfad.

Annex A — RTC IDL

Annex A — Vollständige RTC-IDL-Datei

Spec: Annex A, S. 91+ (PDF) — Normative IDL-Definition.

Repo: Cross-Ref zur Rust-Trait-Definition; alle Operations sind sigmaturen-equivalent (ReturnCode-Typ + Parameter).

Tests: —

Status: done — alternative-Form-of.

Audit-Status

25 done / 0 partial / 0 open / 7 n/a (informative) / 0 n/a (rejected).

Test-Lauf: cargo test -p zerodds-rtc --lib — 47 Tests grün, 0 failed. Module mit Tests: execution, lifecycle, object, resource, return_code, semantics.

Keine offenen Punkte — alle Items done.