UNIVIP

UNIVIP Roadmap

On this page

Status: Proposed, 2026-10-14; Phase 1 progress updated 2026-10-15 (all Phase 1 build items done; exit criterion — a recorded public demonstration with two adapters — not yet met). Dates are planning targets, not commitments.

Guiding rule

Ship a working demonstrator before seeking broad endorsement. Every phase ends with something that runs.

Phase 0 — Foundation (now → 2026-12)

  • [x] White paper, prior-art scan, governance draft, decision records.
  • [x] Draft specification parts 01–14, JSON Schemas, OpenAPI description, validator.
  • [ ] Formal prior-art review per docs/prior-art.md §5 (ONVIF, MISB, STANAG, BSI Flex 335, vendor APIs).
  • [ ] Trademark and patent landscape searches.
  • [ ] Recruit an initial technical working group: at least one drone vendor or autopilot project, one VMS vendor, one integrator.

Exit criterion: working group constituted; spec 0.1 published for comment.

Phase 1 — Reference gateway and demonstrator (2027-Q1 → Q2)

  • [x] Reference UNIVIP gateway (open source) with a MAVLink/PX4 adapter: Profiles S, C and N on the simulator (gateway/). MAVLink validated against PX4 1.17.0 SITL (SIH quadrotor with gimbal) and ArduCopter 4.7.2 SITL (servo gimbal and camera): discovery, telemetry, every vehicle command, gimbal, pilot override, low-battery and link-loss failsafes and vehicle silence pass end to end (docs/sitl-validation.md); 19 adapter bugs fixed; opt-in SITL tests in gateway/tests/test_sitl.py. Real hardware (Phase 2) not yet.
  • [x] Reference UNIVIP client library: .NET SDK (dotnet/src/Univip.Client), plus a console viewer sample.
  • [x] A minimal standalone "UNIVIP viewer" that shows video, map position, telemetry overlay and events (dotnet/src/Univip.Viewer.Web), with optional leased camera control and hold / return home; tested end to end against the reference gateway in a headless browser. H.264 decoding is validated in Google Chrome; browser builds without an H.264 decoder cannot play the mandatory stream. The software validation workflow records both protocol adapters through TURN.
  • [x] .NET port of the gateway (dotnet/src/Univip.Gateway), simulator adapter. Its WebRTC stack has had an internal security review (docs/security/webrtc-review-2026-10.md: 17 of 22 findings fixed in the original review, WR-18 and WR-19 addressed in the software follow-up); it still needs the Phase 2 independent review and penetration test before operational use.
  • [x] Implementation findings recorded for spec 0.2 (docs/implementation-findings.md).
  • [x] Second adapter: DJI Cloud API (DJI Dock / Dock 2 over the dock-to-cloud MQTT protocol): telemetry, take-off, goto, hold, return home, camera control and live push; mapping in Annex A.4. Verified against a fake dock built from the public documentation; validation on a real dock is pending a partner.
  • [x] Recording test: replay of the flight path alongside recorded video from in-band ST 0601 and from out-of-band telemetry (gateway/tests/test_recording.py, docs/recording-test.md). Alignment is checked against the 100 ms budget, with independent frame-counter continuity and deliberate clock-error checks in the software follow-up; the two sources agree within ST 0601 quantisation.
  • [x] Spec 0.2.0-draft incorporating implementation experience: findings A–H and most of I–S resolved (docs/implementation-findings.md); both gateways, the .NET SDK and the viewer implement it. The remaining open findings are input to 0.3.

Exit criterion: the "first demonstration" in README.md performed end to end with two adapters and one client, recorded on video and published.

Phase 2 — Profile N and security hardening (2027-Q3 → Q4)

  • [x] Control-lease model implemented in gateway and client; software tests cover pilot override and lease expiry. The real-aircraft demonstration remains the Phase 2 exit criterion.
  • [ ] Safety review by at least one party with vehicle-controller expertise.
  • [ ] Threat model and penetration test of the reference implementations (input: the 2026-10 internal WebRTC review and its open findings WR-18 to WR-22).
  • [ ] mTLS and OAuth 2.0 device onboarding profiles tested with at least one commercial identity provider.
  • [ ] Spec 0.3 → 1.0 Release Candidate.

Exit criterion: Profile N demonstrated with a real aircraft in a controlled environment under an operator's authority.

Phase 3 — Conformance program (2028-H1)

  • [ ] Conformance test suite for Profiles S and C (device and client sides), derived from spec/14-conformance-testing.md.
  • [ ] Conformance policy and claim rules; logo and naming guidance.
  • [ ] Two independent device implementations and two independent client implementations pass.
  • [ ] Spec 1.0 Stable.

Exit criterion: first conformance claims published.

Phase 4 — Standards-body engagement (parallel from Phase 1)

  • [ ] Open dialogue with ONVIF; present the demonstrator; understand the profile proposal process and membership requirements.
  • [ ] Present to the Dronecode Foundation regarding MAVLink mappings and a possible MAVLink-to-UNIVIP reference adapter under their umbrella.
  • [ ] Engage MISB regarding the ST 0601 mapping table.
  • [ ] Decide, as a Steering Group decision, whether to contribute UNIVIP as an ONVIF profile proposal, keep it independent, or both.

Risks and mitigations

Risk Mitigation
Largest drone vendors decline to participate Gateway mode makes adoption possible from the VMS side alone; integrators can ship adapters
ONVIF launches its own drone profile Engage early; design for contribution; worst case UNIVIP becomes the implementation experience that shapes it
Profile N creates liability concerns Keep it optional; require operator authority and vehicle-controller enforcement; publish the safety model openly
Scope creep into C2 / UTM Keep UNIVIP a VMS-facing profile; define extension points instead of absorbing adjacent domains
Vendor capture of governance Governance rules in GOVERNANCE.md; no majority seats for one organization

Generated from docs/roadmap.md.