All projects 06 / V1.1
Case study

Detection Stream Simulator

Purpose-built tooling that decouples client-side integration from pipeline readiness, so both workstreams run in parallel and integration risk is resolved before the real system arrives.

NDA / V1.1 NDA

What it is

When we build a real-time perception pipeline, the systems that consume it (control loops, dashboards, embedded devices) cannot wait for the full pipeline to be production-ready before starting their own integration work. This simulator removes that dependency: a lightweight server that speaks the same wire contract as the production detection pipeline, at a configurable frame rate, so the consumer side can begin immediately.

Why it matters for delivery

Real-time perception projects have two parallel workstreams: the pipeline that produces detections, and the systems that consume them. Without a simulation layer, those workstreams are sequential: consumers are blocked until the pipeline is done. With it, both sides run in parallel, and integration is already validated by the time the production system ships.

This is the kind of supporting infrastructure that compresses overall project timelines and removes a common source of late-stage integration risk.

Technical approach

Architecture
Detection Stream Simulator architecture: a Proto Contract defines the shared wire schema; the Mock Server emits synthetic protobuf frames at a configurable FPS over two transports: gRPC to a full-stack Integration Client and length-prefixed TCP to a resource-constrained Embedded Client.
Proto Contract → Mock Server → Protobuf Frames → gRPC Transport → Integration Client; Mock Server → Protobuf Frames → TCP Transport → Embedded Client
  • Wire format: Protocol Buffers. Compact, schema-enforced, and language-agnostic. The same .proto file that defines the simulator’s output is the contract the production pipeline will honour, so the wire is honest from the first day of integration.
  • Transport 1: gRPC. For full-stack consumers — services, dashboards, and cloud backends.
  • Transport 2: Length-prefixed TCP. For resource-constrained embedded systems that cannot carry a full gRPC stack. Both transports speak the same schema; the transport is just a delivery mechanism.

These are implementation choices, not constraints. The wire format, transport layer, and frame schema can be adapted to fit any existing stack.