UNIVIP White Paper: An ONVIF Equivalent for DronesLink to the section UNIVIP White Paper: An ONVIF Equivalent for Drones#

Version: 0.1.0-draft · Date: 2026-10-14 · Status: Working draft for discussion

Scope note (2026-10-14). This paper was written with aerial drones as the motivating case and keeps that language. The project has since adopted the name UNIVIP, Universal Vehicle Interoperability Protocol, and a domain-neutral data model that also covers uncrewed underwater, surface and ground vehicles (ADR-0007). Everything said here about drones applies to those vehicles with altitude read as depth where appropriate; aerial remains the first domain with conformance tests.

Executive summaryLink to the section Executive summary#

Video Management Systems (VMS) integrate thousands of fixed camera models through one vendor-neutral interface family, ONVIF. Drones, which are increasingly used as mobile surveillance sensors by police, critical-infrastructure operators, ports, utilities and private security, have no equivalent. Each drone platform reaches the VMS through a proprietary SDK or cloud API, and each VMS vendor writes a bespoke integration per manufacturer.

The research summarized in prior-art.md shows that several standards already solve parts of the problem, but no single, widely adopted, vendor-neutral interoperability profile brings drone video, synchronized GPS telemetry, health, events, camera control and optional flight navigation together for conventional VMS platforms.

UNIVIP, the Universal Vehicle Interoperability Protocol, is proposed as that profile. It is positioned as:

An open interoperability standard that enables any compatible drone to connect with any compatible Video Management System, stream live video and synchronized telemetry, publish operational events, and expose standardized camera and authorized vehicle-control capabilities.

This is a stronger proposition than an SDK. UNIVIP does not reinvent drone communications. It defines a common interoperability layer that makes drones usable by a VMS regardless of manufacturer, and it reuses ONVIF, MAVLink and MISB conventions wherever they fit.

1. The problemLink to the section 1. The problem#

A fixed camera has a relatively constant location and three familiar degrees of freedom: pan, tilt, zoom. A drone has:

• changing coordinates, altitude and attitude,
• velocity and heading,
• battery state and estimated endurance,
• a radio link whose quality varies with range and obstruction,
• an operating mode (idle, flying, hovering, returning home, emergency),
• often several payloads (visible, thermal, zoom, spotlight, speaker),
• two independent movable systems: the gimbal and the aircraft itself.

All of those properties are relevant to a VMS operator. Today, a VMS that wants to show a drone's position on a map next to its video, replay where the drone was at 10:32:15 in a recording, receive a low-battery alert, or move the gimbal, has to integrate against each manufacturer's API separately. The integration cost scales with (drone vendors × VMS vendors), the same quadratic problem ONVIF removed from the fixed-camera market.

2. What already existsLink to the section 2. What already exists#

Key observations from the research scan:

• ONVIF explicitly states that Profile M can apply to a video-based drone and that its clients include VMS software.
• MAVLink already standardizes camera streams, zoom, focus, gimbal control and flight commands, but its own camera documentation acknowledges limitations around frame-synchronized video metadata.
• STANAG 4586 defines interoperability levels from receiving UAV data through payload control to vehicle control, which is a useful precedent for UNIVIP's profile ladder.
• DJI and Skydio demonstrate that video-plus-telemetry integration is commercially proven, but only through their own APIs.

Conclusion: the opportunity is not to claim that no drone interoperability standard exists. It is to establish an open, VMS-native drone interoperability profile that combines and extends the useful pieces. That is both more defensible technically and more credible when approaching manufacturers, industry bodies and adopters.

3. The most important finding: ONVIF is already moving in this directionLink to the section 3. The most important finding: ONVIF is already moving in this direction#

Profile M recognizes video-based drones as devices and covers metadata and event handling for analytics and VMS clients. It does not define a drone flight-management model.

Profile V, at release-candidate stage at the time of research, specifies device-initiated secure connectivity, WebRTC streaming and event communication (with MQTT in its event model). This matches the requirement for drones to push data toward centralized infrastructure rather than wait on a LAN to be polled.

Implications for UNIVIP:

1. Interoperate, do not compete. UNIVIP adopts ONVIF-compatible concepts (device identity, capability discovery, event topics, PTZ semantics) and an outbound-uplink architecture aligned with Profile V, so that a UNIVIP gateway can also present itself as an ONVIF device where that is useful.
2. Keep a clearly different name until and unless ONVIF accepts a drone profile. Nobody can unilaterally declare a new official ONVIF profile.
3. Open the conversation early. ONVIF's Full and Contributing membership levels permit participation in standards development, and its profile policy describes the proposal and approval process.

4. Proposed architectureLink to the section 4. Proposed architecture#

Core principle: a drone is a mobile, intelligent, geospatial camera, not merely a flying IP camera.

┌──────────────────────────────────────────────────────────────────┐
│  Drone / Dock / Ground Controller                                 │
│  Video · GPS · Attitude · Health · Payload · Vehicle state         │
│  (native manufacturer SDK or MAVLink)                             │
└───────────────────────────┬──────────────────────────────────────┘
                            │
┌───────────────────────────▼──────────────────────────────────────┐
│  UNIVIP Adapter / Gateway                                           │
│  Normalizes manufacturer-specific capabilities into one standard  │
│  Discovery · Identity · Authentication · Capability negotiation   │
└───────────────────────────┬──────────────────────────────────────┘
                            │  standardized interfaces
┌───────────────────────────▼──────────────────────────────────────┐
│  Central VMS / Command & Control                                  │
│  Live video · Recording · Maps · Events · Camera control ·        │
│  Authorized movement                                              │
└──────────────────────────────────────────────────────────────────┘

The adapter layer is the pragmatic heart of the design. Many manufacturers will not install a new protocol in flight firmware quickly. UNIVIP therefore defines three implementation modes that are indistinguishable to the VMS:

• Native: the drone or dock implements UNIVIP directly.
• Controller-based: software on a ground controller, pilot app or dock provides UNIVIP connectivity.
• Gateway-based: a server translates MAVLink, DJI Cloud API, Skydio APIs or other interfaces into UNIVIP.

5. ProfilesLink to the section 5. Profiles#

UNIVIP follows ONVIF's approach of testable profiles rather than a monolithic specification.

• Profile S — Surveillance & Streaming. Device identity, live video, GPS position, altitude, basic telemetry, time synchronization, health status and critical events. A video-capable drone can support Profile S without allowing any remote control.
• Profile C — Camera & Payload Control. Profile S plus zoom, focus, gimbal pan/tilt, imaging settings, thermal palettes and other payload capabilities.
• Profile N — Navigation & Vehicle Control. Profile C plus optional navigation, flight actions, waypoint missions, return-to-home, flight-mode feedback, safety enforcement and control authorization.

Camera control and vehicle control are never the same permission. An operator may be allowed to zoom into a scene but not to move an aircraft toward restricted airspace. Profile N is a separately enabled control capability with independent permissions, leases, safety checks and audit records.

6. What the drone publishesLink to the section 6. What the drone publishes#

Three categories, deliberately kept distinct rather than folded into one video payload.

A. Continuous telemetryLink to the section A. Continuous telemetry#

Identity, position (WGS84, with explicit altitude references), motion (heading, velocity, attitude), power, connectivity, aircraft state, payload state and operational health, each with precise units and coordinate frames. Altitude above ground level is not interchangeable with altitude above mean sea level, and the schema makes that impossible to confuse.

B. Event-driven notificationsLink to the section B. Event-driven notifications#

State changes and meaningful occurrences: flight started or landed, battery low, link degraded, geofence warning, returning home, recording started, object detected, command rejected. Each carries a standardized severity, timestamp, source, event ID and structured payload.

C. Media with synchronized metadataLink to the section C. Media with synchronized metadata#

When an operator opens a recording at 10:32:15, the VMS should know where the drone was, its orientation, which way the camera faced and, where measurable, which ground area it observed. That requires time-synchronized video and telemetry, not two unrelated streams. UNIVIP supports both in-band timed metadata (KLV per MISB ST 0601 in a suitable transport) and out-of-band telemetry with shared timestamps, session IDs and sequence numbers, and it requires recordings to preserve enough to replay the flight path alongside the video.

7. TransportsLink to the section 7. Transports#

UNIVIP is transport-aware but not dependent on one proprietary transport. Version 1 defines a small mandatory baseline and precisely testable alternatives.

WebRTC serves interactive low-latency viewing. SRT is a strong candidate for contribution streaming over unreliable links because it provides packet-loss recovery and encryption.

8. The vehicle-control extensionLink to the section 8. The vehicle-control extension#

A drone camera has two separate movable systems:

• Payload movement: pan, tilt, roll, zoom, focus, pointing direction.
• Aircraft movement: forward/back, left/right, up/down, aircraft heading.

They must be independently addressable. An operator clicking "Pan Right" should rotate the gimbal when supported and must never unexpectedly rotate or translate the aircraft. UNIVIP therefore defines distinct camera.* and vehicle.* command families, capability discovery so a VMS knows which are supported, standardized rejection reasons, and a command lifecycle in which acceptance is never proof of completion.

For flight safety the specification requires: pilot/operator authority, expiring control leases with heartbeats, geofence checks, failsafe behavior, command audit records and enforcement by the manufacturer's vehicle controller. A VMS never bypasses the certified or approved vehicle-control system.

9. Geospatial video intelligenceLink to the section 9. Geospatial video intelligence#

A camera's position is not the position of what it observes. A drone at 80 m above ground looking down a road at 45° needs to convey its camera orientation, field of view and estimated ground footprint for the VMS to place the imagery on a map. UNIVIP's optional geospatial extension standardizes camera_footprint, target_geolocation, horizontal_fov_deg, vertical_fov_deg, position_uncertainty and target_confidence, enabling:

• a map showing each drone's live position and viewing direction,
• click-to-view live feed and recorded history,
• click-on-map to request camera pointing or authorized repositioning,
• correlation of drone video with nearby fixed CCTV,
• search of historical recordings by geographic area,
• mapping detected objects to coordinates with uncertainty.

10. Path to an official open standardLink to the section 10. Path to an official open standard#

Two routes exist.

Route A: Independent open standard (preferred initially). Publish UNIVIP as an open specification with a reference implementation, an independent governance process and an invitation to drone and VMS vendors. Momentum does not depend on an external body's approval, and the specification can later be submitted to one.

Route B: Propose a profile within ONVIF. Approach ONVIF with a concrete proposal supported by implementations and adopters. This reaches the established surveillance ecosystem but requires organizational support, technical review and the approved process.

UNIVIP pursues Route A first while opening conversations with ONVIF early. Legitimacy for an independent standard requires a public specification, transparent decision-making, an IPR policy, compatibility rules, a reference implementation and a conformance test suite. Publishing an SDK alone does not establish interoperability.

11. Who should be involvedLink to the section 11. Who should be involved#

Publish a demonstrator before seeking broad endorsement. The first target demonstration: a drone begins a mission; without any proprietary integration, the VMS recognizes the UNIVIP connection, shows video, plots the drone on a map, records GPS history, receives a low-battery event and, if authorized, adjusts the gimbal.

12. Foundational decisionsLink to the section 12. Foundational decisions#

Four decisions determine whether UNIVIP becomes broadly adoptable. Each is recorded as an ADR; the project sponsor confirmed all four on 2026-10-14.

13. One final distinctionLink to the section 13. One final distinction#

The protocol should be open, but vehicle-control authority must remain secure and independently governed. If that separation is right, UNIVIP can serve surveillance VMS platforms, command-and-control systems, drone operations software and future autonomous aircraft without forcing all of them to adopt one operational model. That is the opportunity to build around.

CaveatLink to the section Caveat#

This white paper reflects an initial research scan, not a conclusive patent search or an exhaustive international standards inventory. Before any claim that UNIVIP is the first standard of its type, the MISB documents, STANAG specifications, ONVIF draft specifications and existing commercial interoperability products listed in prior-art.md must be reviewed in detail.