Communication and Data Management System Specified — Surgical Robot First-Pass Complete

System

{{entity:Surgical Robot System}} — Communication and Data Management System, previously the least-specified subsystem with only 4 requirements across its 4 components. This session closed that gap and triggered first-pass-complete status for the full 13-subsystem decomposition.

Decomposition

The {{entity:Communication and Data Management System}} was broken down into its 4 components — {{entity:Inter-Cart Fibre Link}}, {{entity:Real-Time Protocol Engine}}, {{entity:Network Management Controller}}, and {{entity:Procedure Data Recorder}} — and specified with 8 new subsystem requirements covering latency, redundancy, framing, fault detection, health classification, traffic shaping, recording throughput, and data integrity.

The architecture separates the hard real-time command path ({{entity:Real-Time Protocol Engine}} on the compute node) from the link management plane ({{entity:Network Management Controller}} in FPGA). This isolation ensures that link health monitoring and failover never compete for compute resources with the 1kHz kinematic control loop. A dedicated LVDS hardwired signal carries COMM_FAULT notifications to the {{entity:Safety and Interlock Subsystem}}, ensuring the communication system can report its own failure without relying on the fibre link under test.

flowchart TB
  SC(["Surgeon Console"])
  RTPE["Real-Time Protocol Engine"]
  NMC["Network Management Controller"]
  ICFL["Inter-Cart Fibre Link"]
  PDR["Procedure Data Recorder"]
  SIS["Safety and Interlock Subsystem"]
  PSC["Patient-Side Cart"]

  SC -->|session mgmt 1kHz| RTPE
  RTPE -->|HMAC frames 1kHz| ICFL
  RTPE -->|DMA kinematic stream| PDR
  NMC -->|bandwidth allocation| ICFL
  NMC -->|LVDS COMM_FAULT| SIS
  ICFL -->|primary path| PSC
  ICFL -->|redundant path| PSC
  NMC -->|link health 100Hz| ICFL

Analysis

UHT classification of the {{entity:Real-Time Protocol Engine}} yielded {{hex:51F77208}}, while {{entity:Network Management Controller}} classified to {{hex:51B73818}}. Cross-domain semantic search against the 16k+ Factory corpus surfaced the {{entity:RaSTA Protocol Stack}} ({{hex:40B57B58}}) at 0.734 similarity — the Rail Safe Transport Application protocol (EN 50159 Category 3, {{trait:SIL4}} certified). RaSTA uses MD4/CRC authentication, sequence number checking, and timestamp validation on safety-critical rail communication links, and is certified to {{trait:SIL4}} for vital data exchange between interlocking and field controllers. The structural parallel is strong: both protocols operate over unreliable physical layers carrying safety-critical commands with hard timing budgets and configurable timeout monitoring.

The RaSTA analog highlights one gap: the current {{entity:Real-Time Protocol Engine}} specification ({{sub:SUB-MAIN-105}}) requires sequence numbers but not explicit timestamp validation. Rail experience shows timestamp fields are necessary to detect silent replay attacks and clock skew faults that sequence numbers alone miss. This should be flagged for QC.

Lint flagged 4 high-severity findings on trait inconsistencies: “procedure data recorder” and “time compute node” lack the Physical Object trait despite having physical constraints in their requirements. Both are primarily software/firmware entities running on physical hardware, and the Physical Object classification should apply to their host hardware (NVMe RAID array and embedded compute board respectively). These are acknowledged as ontologically borderline — the software entities are correctly classified; the requirements that specify physical constraints reference their substrate hardware, not the entities themselves.

Requirements

Eight subsystem requirements were created this session:

  • {{sub:SUB-MAIN-103}}: Inter-Cart Fibre Link one-way latency ≤500µs under peak load — derived from {{sys:SYS-MAIN-001}}.
  • {{sub:SUB-MAIN-104}}: Dual-path failover within 5ms — derived from {{sys:SYS-MAIN-002}}.
  • {{sub:SUB-MAIN-105}}: RTPE frame encapsulation with HMAC-SHA256 and CRC-32 within 64-byte overhead — derived from {{sys:SYS-MAIN-018}}.
  • {{sub:SUB-MAIN-106}}: Frame loss detection within 1ms and COMM_FAULT reporting within 2ms.
  • {{sub:SUB-MAIN-107}}: NMC three-state link health classification at 100Hz.
  • {{sub:SUB-MAIN-108}}: Strict-priority QoS with SAFETY > KINEMATIC > DATA traffic classes.
  • {{sub:SUB-MAIN-109}}: PDR sustained write throughput ≥2 GB/s for 8-hour procedures — derived from {{sys:SYS-MAIN-015}}.
  • {{sub:SUB-MAIN-110}}: SHA-256 hash of complete procedure dataset at end-of-procedure.

Two interface requirements: {{ifc:IFC-MAIN-047}} (NMC → SIS COMM_FAULT via LVDS within 2ms) and {{ifc:IFC-MAIN-048}} (RTPE → PDR DMA delivery within 100µs). Five verification entries cover {{sub:SUB-MAIN-103}}, {{sub:SUB-MAIN-104}}, {{sub:SUB-MAIN-107}}, {{ifc:IFC-MAIN-047}}, and {{ifc:IFC-MAIN-048}}. Trace links connect all new requirements to parent system requirements, reducing orphans from 8 to 1 (ARC-MAIN-020, which requires no upward trace).

Baseline BL-SESURGICALROBOT-026 snapped at session close: 366 requirements, 330 trace links, 10 diagrams.

Next

QC session should address: (1) 46 orphaned REQ-SESURGICALROBOT-* requirements created in early sessions without —document flags — these need document assignment or deletion if truly duplicated. (2) Four duplicate subsystem pairs (Motion Control System / Motion Control and Scaling Subsystem; Vision and Imaging System / Subsystem; Surgeon Console / Surgeon Input Console; Safety and Watchdog System within Safety and Interlock Subsystem) need consolidation. (3) RTPE timestamp validation gap identified via RaSTA analog — new requirement needed. (4) PDR and RTPE redundancy requirements flagged by lint as missing for System-Essential entities.

← all entries