The Peripheral Detection Protocol (PDP) is an open wire protocol designed to enable any sensing peripheral — from a simple thermocouple to a multi-axis inertial measurement unit — to securely authenticate, self-describe, and stream calibrated data through any PDP-compatible gateway without manual configuration. PDP defines a five-phase lifecycle covering physical attachment, mutual ECDSA-P256 authentication, configuration via TEDS EEPROM, continuous streaming using the MNEMOS Binary Protocol, and platform binding via the Vigil API. This paper specifies each phase in sufficient detail to enable independent implementation, describes the security threat model and mitigations, documents the TEDS EEPROM memory map, defines the complete MBP frame structure, and outlines the developer programme for submitting new peripheral type descriptors.
The industrial sensing landscape in 2026 is characterised by deep fragmentation. A typical manufacturing facility operates sensors from dozens of vendors, each communicating over proprietary buses — 4–20 mA, HART, IO-Link, Modbus RTU, CAN, Profibus, EtherCAT, and countless bespoke serial protocols — with incompatible data representations, calibration formats, and authentication models. The result is that integrating a new sensor type requires weeks of engineering effort: custom firmware, one-off data normalisation code, and fragile point-to-point wiring between sensor, gateway, and historian.
This fragmentation compounds as sensing requirements expand beyond traditional manufacturing. Modern facilities now deploy not only temperature and pressure transducers but vibration analysers, ultrasonic flowmeters, gas chromatographs, machine vision cameras, and environmental monitors — all requiring custom integration. The emerging class of collaborative robots and autonomous mobile platforms introduces yet more proprietary sensor buses, each requiring its own integration layer.
PDP addresses this problem at the protocol level. Rather than building adapters for every proprietary bus, PDP defines a single, open, secure protocol that any sensor manufacturer can implement. A PDP-compliant probe carries its own identity, calibration data, and channel descriptions in on-device EEPROM — sufficient for a gateway to enumerate, authenticate, configure, and stream the probe's data with no prior knowledge of the probe type and no manual configuration by the installer.
This paper specifies PDP revision 0.9. The protocol is intentionally conservative in its hardware requirements: the only mandatory components beyond the probe's existing circuitry are a 2 KB AT24C16 EEPROM (unit cost < $0.20 at volume), a hardware secure element (such as the ATECC608B, ~$0.50 at volume), and a 32-bit microcontroller with SHA-256 and ECDSA-P256 acceleration — present in essentially every modern sensor SoC.
PDP defines five sequential phases that a probe traverses from physical insertion to steady-state data streaming. The phases are designed to be resumable: if a probe is momentarily disconnected, it re-enters the protocol at the earliest phase for which its state is no longer valid, rather than restarting from scratch.
| Phase | Name | Duration (typical) | Outcome |
|---|---|---|---|
| 1Attachment | Physical attachment and enumeration | < 100 ms | Bus presence confirmed; probe addressed |
| 2Auth | Mutual ECDSA authentication | < 500 ms | Both parties have verified each other's identity |
| 3Config | TEDS EEPROM read and JOIN_REQUEST | < 1 s | Probe type, channels, and calibration known to gateway |
| 4Stream | MBP DATA frame streaming | Continuous | Calibrated measurements flowing at declared sample rate |
| 5Platform | Platform binding via Vigil API | < 2 s (one-shot) | Binding IDs assigned; data routed to TimescaleDB |
PDP is bus-agnostic at the physical layer. The reference implementation uses a single RS-485 half-duplex link with auto-addressing, but implementations over I²C, SPI, CAN, USB CDC, and Ethernet are all conformant provided the higher-layer MBP framing is preserved.
On attachment, the gateway drives a PROBE_ENUM broadcast. Each newly-attached probe responds with its hardware_id (a 16-byte globally unique identifier burned into the secure element at manufacture) and its PDP revision level. The gateway assigns a session address (1–254) used for the remainder of the connection.
Authentication is a two-pass challenge-response exchange using ECDSA-P256 signatures over the NIST P-256 elliptic curve. Each probe carries a device certificate signed by the manufacturer's CA, which is in turn signed by the PDP Root CA maintained by Continuis Labs. Gateways carry the PDP Root CA public key in firmware, enabling offline certificate chain verification.
The authentication sequence proceeds as follows:
Authentication failure at this phase results in immediate disconnection and an AUTH_FAILED event logged to the platform. The probe is not permitted to proceed to configuration until authentication succeeds. This prevents any unsigned or counterfeit probe from injecting measurements into the platform.
After authentication, the gateway reads the probe's TEDS (Transducer Electronic Data Sheet) EEPROM in full. The complete memory map is specified in Section 3. The TEDS contains sufficient information for the gateway to: identify the probe's PDP type ID for registry lookup; enumerate all measurement channels and their physical quantities; apply calibration coefficients to convert raw ADC counts to calibrated engineering units; and verify the EEPROM's integrity via an embedded ECDSA signature covering the entire data region.
The gateway then sends a JOIN_REQUEST to the Vigil platform, forwarding the parsed TEDS data. The platform creates or updates the probe's Device record, resolves each channel's quantity binding, and returns an array of binding IDs — one UUID per channel — which the gateway stores in NVRAM for use in all subsequent streaming frames.
In the streaming phase, the probe sends MBP DATA frames at the rate declared in its TEDS channel table. Each frame carries: the source address assigned in Phase 1; the binding ID for the channel (received in Phase 3 response); a 32-bit monotonic sequence number for drop detection; raw sensor counts; and a CRC-16/CCITT-FALSE checksum over the entire frame. The gateway applies the calibration polynomial from TEDS and forwards calibrated values to the Vigil ingest API in batch payloads of up to 5,000 measurements.
The gateway is responsible for rate adaptation: if the probe samples at 10 kHz but the upstream connection can only sustain 1 kHz, the gateway must downsample or buffer before forwarding. Ultra-high-frequency waveform capture (the ULTRA tier) bundles raw sample arrays into a single MeasurementUltra record with accompanying sample rate metadata.
Phase 5 is a one-shot operation that occurs once per probe, on first connection to a given Vigil organisation. The gateway POSTs the probe's hardware_id, PDP type ID, and channel descriptors to POST /api/v1/pdp/probe/. The platform resolves each quantity_slug against its quantity registry, creates DeviceBinding records, and returns the full binding map. Subsequent reconnections skip Phase 5 (binding IDs are already assigned and stored in NVRAM).
The TEDS EEPROM is a 2,048-byte (2 KB) AT24C16 I²C device soldered to the probe PCB. The memory is structured into six fixed-size regions. The total allocated size of these regions is 1,168 bytes; the remaining 880 bytes are reserved for future revisions. The entire data region (bytes 0–1983) is covered by an ECDSA-P256 signature stored in bytes 1984–2047, ensuring EEPROM integrity and preventing field modification.
| Offset (hex) | Size (bytes) | Region | Description |
|---|---|---|---|
| 0x0000 | 16 | Header | Magic (0x4E4D4544 'NMED'), PDP version, revision, flags |
| 0x0010 | 48 | Probe Info | hardware_id (16B), pdp_type_id (24B), serial number (8B) |
| 0x0040 | 368 | Channel Table | Up to 8 channels × 46 bytes: quantity code, unit, range, sample rate tier, ADC resolution, channel flags |
| 0x01B0 | 128 | Calibration | Up to 8 channels × 16 bytes: polynomial coefficients (c0, c1, c2) as IEEE-754 float32, valid range |
| 0x0230 | 512 | Certificate Chain | DER-encoded device certificate (up to 384B) + manufacturer intermediate CA cert (up to 128B) |
| 0x0430 | 64 | Signature | ECDSA-P256 signature over bytes 0x0000–0x042F using device private key |
| 0x0470 | 16 | Reserved | Must be 0xFF; reserved for future use |
| 0x0480 | 896 | User Area | Unstructured; available to the probe manufacturer for custom data |
Each entry in the channel table describes one independent sensing channel on the probe. Unused entries are filled with 0xFF. The quantity code is a 16-bit value cross-referenced against the PDP quantity registry (a superset of the SI base quantities, extended for common industrial measurements).
After reading the full EEPROM, the gateway computes the SHA-256 digest of bytes 0x0000–0x042F and verifies the ECDSA-P256 signature stored at offset 0x0430 using the device public key extracted from the certificate at offset 0x0230. If verification fails, the probe is rejected and a TEDS_INTEGRITY_FAILURE event is logged. This check prevents EEPROM tampering or data corruption from allowing malformed calibration data to reach the platform.
MBP is the binary wire protocol used for all PDP communication after Phase 1 enumeration. It is designed for efficient transmission over low-bandwidth buses (RS-485 at 115200 baud, I²C at 400 kHz) while remaining fully parseable on 32-bit microcontrollers with minimal memory overhead.
The eight-byte header is fixed. Magic is the ASCII encoding of 'MN' (0x4D 0x4E), used for frame synchronisation on byte-stream buses. VER|TYP packs the protocol version (upper 4 bits, currently 0x1) and frame type (lower 4 bits). Defined frame types are:
0x0 — PROBE_ENUM (broadcast, no payload)0x1 — AUTH_CHALLENGE (32-byte nonce payload)0x2 — AUTH_RESPONSE (signature + certificate chain payload)0x3 — TEDS_READ (offset + length request)0x4 — TEDS_DATA (EEPROM block payload)0x5 — JOIN_REQUEST (forwarded TEDS summary)0x6 — DATA (measurement payload)0x7 — ACK / NACK0x8 — CMD (gateway-to-probe command)0xF — ERROR (with error code payload)SRC and DST are single-byte session addresses (0x00 = gateway, 0xFF = broadcast). SEQ is a 16-bit monotonic counter per (SRC, frame type) pair, allowing receivers to detect dropped frames. FLAGS carries bit fields for: encrypted payload (bit 0), compressed payload (bit 1), acknowledgement requested (bit 2).
The DATA payload carries one or more measurement samples. Each sample is 16 bytes: 8-byte binding_id reference (lower 8 bytes of the UUID), 4-byte raw ADC count as int32, 2-byte sequence sub-counter for burst captures, 1-byte quality code, and 1-byte channel index. The gateway collects DATA frames across the sample window, applies TEDS calibration, and batches the results into ingest API calls.
PDP's security model is built around the principle that physical access to a probe does not grant access to the platform. An attacker who physically obtains a probe — even with full read access to its EEPROM — cannot inject malicious measurements, impersonate a legitimate probe, or replay captured traffic, due to the following controls.
The ECDSA-P256 private key is generated inside the probe's secure element (e.g. Microchip ATECC608B or Infineon SLE 97) at manufacture and never exported. The key resides in a zone protected by hardware access controls that prevent read-out even under physical fault injection attacks. The device certificate binding this public key to the probe's hardware_id and manufacturer identity is signed by the manufacturer's intermediate CA, which is in turn signed by the PDP Root CA.
Compromised device certificates can be revoked via the PDP Certificate Revocation List (CRL) distributed to gateways on each MQTT connection. Gateways cache the CRL and check it on every Phase 2 authentication. In offline operation, the cached CRL is used; gateways that have been offline for more than 72 hours must refresh the CRL before accepting new probe connections.
The MBP SEQ counter and the random nonce in AUTH_CHALLENGE prevent replay attacks. A captured AUTH_RESPONSE frame cannot be replayed because the nonce changes on every authentication attempt. Replay of DATA frames is detected by the monotonic SEQ counter and results in those frames being discarded and logged.
Gateway-to-platform authentication uses a separate bearer token mechanism (SHA-256 hashed, never stored in plaintext) described fully in CLR-003. PDP authentication and platform authentication are deliberately decoupled: compromise of a gateway token does not expose probe private keys, and vice versa.
PDP defines two platform-facing API calls that complete the end-to-end flow: the gateway join endpoint and the probe register endpoint. These are REST calls made by the gateway firmware to the Vigil API using the gateway's bearer token.
POST /api/v1/pdp/gateway/join/ — called at boot and on every reconnect. The gateway reports its hardware_id, firmware version, hardware revision, and optional location coordinates. The platform creates or updates the Device record (node_type=GATEWAY) and binds the hardware_id to the calling token if not already set. A 201 response indicates new registration; 200 indicates reconnect.
POST /api/v1/pdp/probe/ — called once per probe, on first attachment. The gateway forwards the probe's hardware_id, PDP type ID, parsed channel descriptors (quantity slugs, roles, sample rate tiers), and EEPROM descriptor blob. The platform validates the descriptor against the registered PeripheralType schema (if the type is known), creates the probe Device and Peripheral records, and creates one DeviceBinding per channel. The response contains binding IDs that the gateway stores in NVRAM.
review_status=pending and performs no EEPROM descriptor validation. Channels with valid quantity_slug values are still bound; channels with unknown slugs are logged as skipped. This allows deployment to proceed without blocking on registry approval.
Any hardware manufacturer or software developer may submit a new peripheral type for inclusion in the PDP registry. The registry maps a human-readable pdp_type_id (e.g. acme.vibration.3axis.v2) to a PeripheralType record containing the TEDS EEPROM descriptor schema, supported quantities, and an optional platform handler binary.
POST /api/v1/pdp/developer/ and obtain a signing certificate.POST /api/v1/pdp/types/submit/, including the EEPROM schema, supported quantities, and optionally a platform handler binary signed with your developer certificate.For probe types requiring non-standard data transformation (e.g. spectral analysis, FFT preprocessing, multi-channel fusion), developers may submit a platform handler binary — a WASM module that runs in a sandboxed environment on the Vigil server. The binary must be signed with the developer's RSA-SHA256 certificate and is verified before execution. This enables probe manufacturers to ship first-class platform integration without requiring changes to the Vigil core codebase.
A PDP-compliant probe implementation must pass the following conformance tests, which can be run using the open-source pdp-conformance test suite available in the Vigil repository:
Gateway implementations must additionally pass GW-001 through GW-012, which test the full five-phase lifecycle including error recovery, CRL refresh, and platform API interaction against a conformance test server.
The Peripheral Detection Protocol provides a complete, secure, and open foundation for universal sensor interoperability. By encoding identity, calibration, and channel metadata directly in on-device EEPROM and enforcing hardware-bound authentication, PDP eliminates the manual configuration burden that has historically made sensor integration slow and error-prone.
The protocol is designed to be implementable on commodity hardware at marginal cost — an AT24C16 EEPROM and an ATECC608B secure element add less than $0.80 to a probe's bill of materials. The resulting interoperability benefit — that any PDP probe works with any PDP gateway without configuration — is a qualitative shift in how sensing infrastructure is built and maintained.
Continuis Labs invites hardware manufacturers, systems integrators, and standards bodies to review this specification, submit peripheral types to the PDP registry, and contribute to the conformance test suite. PDP will advance to stable release (v1.0) following a 90-day public comment period. Feedback and implementation reports can be submitted via GitHub Issues on the Vigil repository.