Origins & History

HCDF (Hardware Configuration Descriptive Format) has been in development since 2020, emerging from real-world experience building autonomous systems where existing robot description formats did not capture all of the system information needed by the project. The resulting format describes physical structure alongside functional interfaces, physical connections, network topology, power and material transfer, software identity, and device discovery metadata.

Motivation

Formats such as URDF and SDF provide established representations for physical structure and simulation. HCDF retains that structural scope while adding typed descriptions for the interfaces and resources that connect a real system: network topology, wired and wireless carriers, connector positions, routed assemblies, deterministic network configuration, power distribution, fluid transfer, software identity, sensor behavior, actuator behavior, and human-machine interfaces.

Configuration tools, visualization systems, planners, and runtime software can use the same typed document to answer both structural and connectivity questions. Conversion profiles and loss manifests make the boundary between HCDF and narrower formats explicit.

Keep physical structure and connection semantics in one document model
Represent communication, power delivery, and material transfer with one purpose-and-carrier vocabulary
Separate functional ports from physical connectors, then bind them at an explicit fidelity
Represent visible connector positions, antennas, cables, hoses, and routes with primitives, models, model parts, or derived geometry
Compose reusable modules and optionally pin external resources by SHA-256 digest

Key Features & Innovations

Unified physical and connectivity schema. HCDF puts kinematics, component capabilities, physical interfaces, topology, network configuration, and software identity into one typed document.
Optional content pinning. Includes, model resources, and stream-profile resources can carry SHA-256 digests for integrity checks and cache identity. Unpinned resources remain valid.
Stream profiles separate application-level data flows from hardware topology. A .streams.xml file defines streams, endpoints, QoS requirements, paths, forwarding, and FRER behavior without restating the physical topology.
Rust-canonical implementation. The schema model, validation, conversion, bundling, and WebAssembly-compatible core are implemented in Rust. Python access uses compiled PyO3 and maturin bindings.
Extensible through domain-versioned extension containers. The reverse-DNS extension mechanism (org.ros2, org.gazebosim, org.ros2.control, org.ieee.1722) allows typed domain content without adding it to the core vocabulary.

Ecosystem

hcdformat: The Rust library and hcdf CLI for validation, conversion, profiles, bundling, Xacro expansion, baking, and schema-derived artifacts.
HCDViz: A browser-based HCDF viewer that renders system geometry and exposes structural and connectivity information.
Dendrite Build: A browser-based builder that composes HCDF systems and uses HCDViz for visualization.
xacro-pure: A Rust Xacro implementation used by the conversion and browser workflows without requiring a Python runtime.
Modules and bundles: <include> composes reusable descriptions, while .hcdfz bundles can package a model and its referenced local assets.

Acknowledgments

HCDF development has been supported by and inspired by collaborations with:

DARPA: Research programs advancing autonomous systems
NXP Semiconductors: Automotive Ethernet, TSN, S32 platform
Purdue University: Robotics research
AFRL: Air Force Research Laboratory
Infineon Technologies
The Zephyr RTOS community
And the broader CogniPilot open-source community