Rethink runtime discovery entity mapping to align with SOVD entity model

[bburda]

Summary

Runtime discovery maps ROS 2 namespaces to the wrong SOVD entity types. Namespaces become Areas and Components, but per the SOVD spec (ISO 17978-3, Clause 5) they should map to Functions.

Problem

Current mapping:

• ROS 2 namespace -> Area (wrong - Area = logical grouping like domains/zones, deployment-specific)
• ROS 2 namespace -> Component (wrong - Component = HW or SW platform like ECU, HPC, OS)
• ROS 2 node -> App (correct)
• Topic prefix -> Area/Component (wrong - same issue)

Correct SOVD semantics:

• Area - deployment topology (domains, zones, SDV architecture). Not inferrable from ROS 2 graph. For small robots with 1-3 ECUs, areas are just noise. Areas make sense at fleet/building level (e.g., floor_1, zone_a) not per-device.
• Component - execution platform. Should be extracted from the actual host system (OS, hostname, architecture), not from namespace groupings. A single-device deployment has one Component (the OS) with all Apps running on it. Multi-ECU setups define Components in manifest.
• Function - "Functional view spanning multiple components." THIS is where namespace grouping fits: /diagnostics/gateway + /diagnostics/fault_manager -> Function "diagnostics".
• App - ROS 2 node from graph introspection (not topic-based discovery).

Proposed changes

1. Deprecate synthetic areas - create_synthetic_areas defaults to false, eventually removed. Areas only from manifest. Empty areas collection is valid for single-device deployments.

2. Change Component discovery - instead of per-namespace synthetic components, extract actual host info (OS, hostname). Single default Component for runtime_only mode. Manifest defines Component hierarchy for multi-ECU setups. Subcomponents model SW-on-HW (e.g., Component: Nvidia Orin -> Subcomponent: Ubuntu 24.04 -> Apps).

3. Map namespaces to Functions - repurpose existing namespace grouping logic to create Functions. /sensors/* nodes -> Function "sensors". Works in both runtime_only and hybrid modes.

4. Remove topic-based entity creation - topic_only_policy should not create Areas or Components from topic prefixes. Apps come from ROS 2 node graph only.

5. Simplify config - most gap-fill flags (allow_heuristic_areas, allow_heuristic_components, create_synthetic_areas, topic_only_policy) become unnecessary. Currently 5+ flags needed to suppress noise in hybrid mode with a complete manifest.

Context

Found during selfpatch_demos smoke test work (issues #307, #311, #312) where synthetic entities leaked into API responses. The root cause is incorrect entity mapping, not suppression logic.

[mfaferek93]

Review notes (revised)

Original review pushed back on most proposals. After discussion with @bburda and reconsidering the SOVD spec, revising position significantly.

What the issue gets right

Namespace-to-Area/Component mapping doesn't scale to multi-ECU. If ECU1 and ECU2 both have /sensors namespace, runtime discovery produces duplicate sensors area with mixed components from both ECUs. No amount of merge pipeline fixes solves this - runtime discovery simply lacks the physical topology information needed to disambiguate. Prefixing (ecu1__sensors) is ugly and breaks the user-facing API.

SOVD spec: Areas and Functions are logical groupings WITHOUT resource endpoints. Per the spec, only Components and Apps should have data, configurations, operations, faults, logs, bulk-data endpoints. The current implementation gives full resource endpoints to all 4 entity types. This means synthetic areas are noise - users click on them and get... what? Forwarded resources from child entities that they could access directly.

Too heavy for typical robots. A TurtleBot3 with 8 nodes doesn't need a 4-level hierarchy. The natural model is 2-3 Components (compute board, sensor module) + Apps. Areas add nothing on a single-device robot.

Revised position

Proposal	Previous	Revised
Deprecate synthetic areas	Reject	Accept - no resource endpoints per spec, doesn't scale to multi-ECU
Component = host system	Defer	Accept direction - 2-3 components per robot is the right scale
Namespace -> Function	Addition only	Accept as default - best semantic fit, also no resource endpoints per spec
Remove topic-based entities	Partial	Accept - simplifies significantly
Simplify config flags	Reject	Accept - if entity model is simpler, most gap-fill flags become unnecessary

What to preserve

• runtime_only mode must still produce useful output. Flat tree (Apps only + optional host-level Component) is better than fake hierarchy with non-functional Areas. But it needs to be a good UX, not just "here's 50 unsorted apps."
• Manifests remain the source of truth for multi-ECU. Runtime cannot infer physical topology. This is a feature, not a limitation.
• The merge pipeline suppression work ([BUG] Hybrid discovery merge pipeline does not suppress runtime entities linked to manifest entities #307-fix: suppress root-namespace heuristic entities and orphan apps #312) isn't wasted. It fixed real bugs. But the underlying model should be simplified so less suppression is needed.