External Mode-Executor Registration

Summary

A runtime registration system allowing external components (offboard controllers, companion computers) to register custom navigation modes and arming checks, with hash-based persistent mode indexing and unresponsiveness monitoring.

Key insight

The system uses a hash-derived persistent index to map dynamically registered external modes to stable nav_state slots across reboots, combined with timeout-based unresponsiveness monitoring that blocks arming if registered safety checks fail to reply. This dual-registration pattern (mode executor + arming check in one flow) with hash-based stable indexing is unusual compared to typical plugin registries that assign ephemeral IDs or require explicit configuration.

Interface

register_ext_component_request_s message (mode name, component ID)
→ stable nav_state index (EXTERNAL1-8), arming check slot,
  unresponsiveness monitoring

Technical approach

ModeManagement handles register_ext_component_request_s messages: addExternalMode() computes a hash of the mode name, searches for a matching COM_MODE{i}_HASH parameter to assign a stable nav_state index (NAVIGATION_STATE_EXTERNAL1-8), and stores the mode in _modes[] array. ExternalChecks::addRegistration() creates an arming check slot, publishes arming_check_request_s, and monitors arming_check_reply_s. If no reply arrives within timeout, the check is marked unresponsive and blocks arming. Mode executors register via addExecutor() and can take control via _mode_executor_in_charge.

Components

• Hash-based mode indexer
• Parameter-backed persistent ID allocator
• Dual registration coordinator (mode + arming check)
• Timeout-based unresponsiveness detector
• Mode executor lifecycle manager
• Arming check request-reply monitor

Component interaction

When a register_ext_component_request_s arrives, the hash-based indexer computes a hash of the mode name and the parameter-backed allocator searches COM_MODE{i}_HASH parameters to find or assign a stable nav_state slot (EXTERNAL1-8). The dual registration coordinator then stores the mode in the _modes[] array and invokes ExternalChecks::addRegistration() to create an arming check slot. The arming check monitor publishes arming_check_request_s and starts the timeout-based unresponsiveness detector. If arming_check_reply_s does not arrive within the timeout window, the detector marks the check unresponsive and blocks arming. The mode executor lifecycle manager tracks registered executors via addExecutor() and allows them to take control via _mode_executor_in_charge.

Engineering characterization

Technical

Dimension	Result
Technical distinctiveness	62%
Implementation depth	68%
Problem specificity	72%
Generality	55%
Estimated commonness (lower means less common in comparable systems)	28%
Paradigm shift	1 / 3

Strategic

Dimension	Result
Product centrality	74%
Defensibility	58%

Distinctiveness mechanism

What makes this engineering approach unusual, named in the model's own words. An engineering observation only.

Hash-derived persistent slot allocation across reboots

cross_domain_transfer

Applies content-addressable storage (hash-to-index mapping) to runtime plugin registration, where most systems use ephemeral IDs or explicit configuration files. The hash of the mode name maps to a COM_MODE{i}_HASH parameter slot, ensuring the same external mode gets the same nav_state index (EXTERNAL1-8) across reboots without manual configuration.

Safety-critical unresponsiveness detection in registration flow

tradeoff_break

Combines plugin extensibility (allowing external components to register arbitrary modes) with safety enforcement (blocking arming if registered components become unresponsive). Most plugin systems either lack health monitoring or decouple it from registration; this integrates timeout-based liveness checks directly into the arming precondition logic.

Observability

Of the shipped product

Dimension	Result
Detectability	85%
Reverse-engineerability	72%

Observability reasoning

The mechanism is highly detectable: external components send register_ext_component_request_s MAVLink messages (observable on the wire), the system publishes arming_check_request_s and expects arming_check_reply_s (both visible in MAVLink logs), and the COM_MODE{i}_HASH parameters are readable via parameter protocol. The hash computation and timeout thresholds are visible in client-side behavior (repeated registration attempts yield the same nav_state index, arming failures correlate with missing replies). Reverse-engineering the hash algorithm and timeout logic is feasible from observing message sequences and parameter values, though the exact hash function and timeout constants require either source access or systematic probing.

Substrate discrimination

Dimension	Result
Substrate specificity	50%

Noun-swap reasoning

Replacing “navigation mode” with “behavior plugin” and “arming check” with “safety validator” preserves the hash-based indexing, timeout monitoring, and registration lifecycle. The mechanism is a generic plugin registry with persistent ID assignment. The aviation-specific parts are the nav_state enum range (EXTERNAL1-8) and the integration with failsafe/arming systems, but the core pattern (hash-to-index, unresponsiveness detection) is reusable.

Reviewer summary

ModeManagement implements a runtime registration system for external navigation modes (offboard controllers, companion computers) that combines hash-based persistent indexing with unresponsiveness monitoring. When an external component registers, the system computes a hash of the mode name, searches for a matching COM_MODE{i}_HASH parameter to assign a stable nav_state index (EXTERNAL1-8) that persists across reboots, and creates a corresponding arming check slot. If the registered component fails to reply to arming check requests within a timeout window, the system marks it unresponsive and blocks arming, ensuring safety-critical operations only proceed when all registered executors are alive.

Comparable techniques

Model-generated technical analogies that may help a qualified reviewer form search directions. These are not prior-art references, search results, or statements that any listed technique discloses this finding.

• Linux kernel module registration with major/minor number persistence
• ROS 2 lifecycle nodes with managed state transitions
• systemd service dependency tracking with timeout-based failure detection
• Eclipse plugin registry with extension point IDs
• Kubernetes custom resource definitions with webhook validation
• AUTOSAR adaptive platform service discovery with health monitoring

Source

Location: src/modules/commander/ModeManagement.cpp

Source code omitted for clarity.

Depends on

• ModeManagement::addExternalMode
• ModeManagement::removeExternalMode
• ExternalChecks::addRegistration
• ExternalChecks::checkAndReport
• Modes::addExternalMode
• ModeExecutors::addExecutor
• register_ext_component_request_s
• arming_check_request_s/reply_s

Confidence trace

Runtime registration system with hash-based persistent mode indexing (COM_MODE{i}_HASH), unresponsiveness monitoring, and arming check request/reply protocol is a distinct, grounded plugin registry.

• Characterization confidence: high
• Filter confidence: 75%

Back to the PX4 scan case study

Obviously Not is a technical analysis tool, not a law firm. Obviously Not does not provide legal advice, represent scan users or repository owners, determine patentability, or create an attorney-client relationship by analyzing code or generating a report. Strategic concepts are technical findings for further review, not legal conclusions or filing recommendations. Consult your own qualified patent attorney about your specific facts, potential rights, deadlines, jurisdictions, and any patent application.