Standard · ISO 17978-3
SOVD for ROS 2: the open diagnostic API standard
SOVD - Service-Oriented Vehicle Diagnostics, standardised as ISO 17978-3 - is a modern REST/HTTP diagnostic API. It came out of automotive, where a fleet of mixed ECUs needed one way to be diagnosed. The same problem now lives in robotics: every robot, PLC, and vehicle speaks something different.
SOVD gives all of them one diagnostic interface - faults, live values, operations, and configuration over plain HTTP, that any tool or AI agent can call.
What SOVD gives you
One REST surface
Faults, live data, operations, and configuration of every component behind one HTTP API - no bespoke protocol per system.
Structured faults
Faults carry a code, severity, status, and a freeze-frame of the state around them, instead of a wall of log text.
Entity model
Robots, subsystems, PLCs, and ECUs are addressable as a tree of components and apps, so tools and agents navigate them the same way.
Tool and agent ready
Because it is just REST, a web UI, a dashboard, your own scripts, or an AI agent over MCP all read the same diagnostic plane.
GET /api/v1/components/motor_ctrl/faults
HTTP/1.1 200 OK
{
"items": [{
"code": "MOTOR_STALL",
"severity": "CRITICAL",
"status": { "aggregatedStatus": "CONFIRMED" },
"snapshot": {
"commanded_velocity": 0.42,
"measured_velocity": 0.0,
"driver_temp_c": 87.3
}
}]
}One standard across the stack
SOVD is not ROS-specific. A production line is rarely one technology: ROS 2 robots over DDS, PLCs over OPC-UA, classic ECUs over UDS/DoIP. SOVD sits in front of all of them and normalises each into the same entity-and-fault model, so the PLC fault and the robot it stranded land in one place.
That is the difference from observability. Observability tells you a metric moved. SOVD is built to act on it: trigger an operation, read a freeze-frame, push a configuration, gate an update on device health.
How selfpatch implements SOVD
ros2_medkit is the open-source (Apache 2.0) SOVD gateway for ROS 2. Point it at your graph and it discovers every node and exposes them as a SOVD API, with a web UI and an MCP adapter, shipped in the official ROS 2 distribution for Jazzy and Humble. Medkit Pro and the Diagnostics Box extend the same gateway to PLCs, ECUs, fleets, and safe OTA.
Explore Medkit ->Go deeper
Your ROS 2 Robot Deserves Real Diagnostics (SOVD)
Your robot stops. You SSH in and get a wall of text. SOVD replaces this with a REST API, structured faults, and diagnostic snapshots.
Unified PLC and ROS 2 Diagnostics with ros2_medkit
Bridge PLCs into ros2_medkit via OPC-UA. PLC faults trigger the same SOVD lifecycle as ROS 2 nodes - with AI diagnosis in 30 seconds.
Multi-ECU OTA Through SOVD: One Endpoint, Every Update Backend
Three ECUs, three firmware stacks, one REST call. How the SOVD plugin pattern coordinates updates across heterogeneous controllers with a single /updates lifecycle.
VDA 5050 + SOVD: Fleet Coordination Meets Deep Diagnostics
VDA 5050 tells the fleet manager the robot stopped. SOVD tells the engineer why. How we bridged both standards on one robot.
Frequently asked questions
SOVD, ROS 2 diagnostics, OTA, and how selfpatch fits.
SOVD (Service-Oriented Vehicle Diagnostics, ISO 17978-3) is a modern REST/HTTP diagnostic standard. Instead of low-level legacy protocols, it exposes faults, live data, operations, and configuration as one uniform web API that any tool, dashboard, or AI agent can call.
ros2_medkit is the open-source (Apache 2.0) diagnostic gateway from selfpatch for ROS 2. It discovers your node graph and exposes every entity behind one SOVD REST API, with a web UI and an MCP adapter, and ships in the official ROS 2 distribution for Jazzy and Humble.
It runs as a gateway in front of your ROS 2 graph, pinpoints the failing node, captures a freeze-frame of the state around the fault, and ranks likely root causes against past incidents - no SSH sessions or log archaeology.
Yes. The open core bridges PLCs over OPC-UA into the same API, and Medkit Pro adds UDS/DoIP ECUs and custom protocol bridges, so robots, PLCs, and vehicles read through one diagnostic interface.
Both - that is the point. Brownfield plants run robots and PLCs from different vendors side by side, with separate teams and separate tools. selfpatch is one diagnostic layer across both: ROS 2 robots and PLCs read through the same SOVD API, land in one fault tree, and share one incident history.
Updates are cryptographically signed, gated on live device health from the diagnostic layer, staged across the fleet, and rolled back automatically if the health gate fails - so a bad update cannot take a shift of robots down.
The core, ros2_medkit, is open source under Apache 2.0 and free to use. Medkit Pro and the Diagnostics Box are commercial layers that add more protocols, secure OTA, fleet view, and guided triage on top of the same core.
Only if you choose the cloud deployment. On-prem or air-gapped, diagnostic data, faults, and the knowledge base stay on your infrastructure, with role-based access control and no external model calls.
You choose the deployment: fully air-gapped on-prem, or cloud-hosted. Air-gapped, the entire loop - diagnosis, technician verdicts, knowledge base - stays inside your network. In the cloud deployment the same loop runs there instead, and the knowledge base is still yours. Across customers, knowledge travels the way automotive fault codes always have: as a curated catalog of fault patterns and proven fixes shipped with product updates. Patterns travel; your data does not.
Software on a standard industrial platform. The box ships as our software image on the Revolution Pi Connect 5, an off-the-shelf DIN-rail industrial computer - no custom electronics, no proprietary supply chain. The value is the software and the fault knowledge it builds; the hardware is a catalog part.
No. It talks to PLCs over their native protocols the same way an HMI does - reading identity, data, and alarms. It never modifies the PLC program, and writes to tags are off by default, opt-in per install, and audit-logged.
Plug it into the OT switch and it discovers the plant itself - PLCs, drives, robots - typically within minutes. Commissioning covers naming, thresholds, and network specifics, not months of tag mapping.
The box speaks the native protocols too - S7comm for Siemens, ADS for Beckhoff TwinCAT, EtherNet/IP for Rockwell - so it reads controllers that were never opened up for OPC-UA.
Only if you decide. The box runs fully on-premise; you can connect the assistant your team uses - context is shared per your consent - or run an on-premise model so nothing ever leaves the plant. The diagnostic core underneath stays deterministic either way.
The box raises a communications-lost fault for that device - timestamped and debounced, so a flaky cable does not spam you - and clears it automatically when the device returns. The outage lands on the audit timeline like any other fault.
See selfpatch on your fleet
Tell us your stack - we'll show which of your recurring faults it could already resolve.