What crossed the network?
Anchor observed endpoints, timestamps, directions, decoded fields, retries, errors, and transport behavior to exact frames.
Enterprise packet investigation · Industrial and OT → Robotics
When the machine stops, prove what the network saw.
Investigate the network-visible path around robot and automation failures, then separate exact packet evidence from controller logic, safety state, and physical outcomes the capture cannot prove.
NETWORK EVIDENCE RECEIPTOBSERVED ≠ PHYSICAL PROOF
01 · REQUESTAgent service
captured09:41:18.20802 · EXCHANGEOPC UA node
outside viewframes 4812–482703 · OUTCOMEMachine state
corroborate- Packet record
- Endpoints · time · decoded fields · response · retransmission
- Coverage
- One vantage · both directions · payload visibility · supplied mapping
- Conclusion
- Network exchange observed. Motion, authorization, and safety state unproven.
A neutral incident record
Move the argument from vendor opinion to bounded evidence.
PacketSafari investigates supplied PCAPs. It is not a robot controller, continuous monitor, safety system, or source of physical truth.
Where did the exchange diverge?
Compare the failing window with expected peers and successful traffic, while preserving missing directions and capture gaps.
Which team owns the next check?
Give controls, robotics, middleware, network, OEM, and integrator teams one reviewable chronology instead of another blame loop.
What remains outside the capture?
Keep local agent logic, shared memory, USB, serial, controller internals, interlocks, mechanics, and physical outcomes explicitly unproven.
Current capability, not roadmap
Know which layer is supported before the capture is interpreted.
Current OPC UA analysis is real but bounded. Robotics-specific DDS/RTPS depth, companion-model interpretation, MHS compatibility, and physical attribution are not presented as implemented capabilities.
LayerStatusEvidence availableExplicit boundary
OPC UA in the current OT workflow
Available, mapping-gatedDetected OPC UA traffic, endpoints, mapped NodeIds, transport and security-policy fields, overflow and semantics-changed flags, coverage, and packet pivots when exposed by the capture.
Not a complete generic service chronology, session reconstruction, request/response pairing, or OPC UA Robotics companion-model interpretation.
DDS / RTPS / ROS 2
Qualification requiredPacket-level investigation can use decoder-visible network facts and the surrounding IP, UDP, timing, loss, and infrastructure evidence.
PacketSafari does not currently claim qualified robotics-specific discovery, topic, QoS, sequence, or repair triage. Serialized samples do not establish physical meaning.
Agent-to-device control paths
Network-visible segments onlyA capture may preserve supported HTTP, TLS, OPC UA, or other network exchanges around an agent-driven workflow.
No current MHS compatibility claim. Local stdio, shared memory, USB, serial, device-internal control, and uncaptured hops are outside the packet record.
Machine and safety state
Corroboration requiredNetwork-visible values, status fields, timing, and errors can support a bounded operational hypothesis.
Packet evidence is not a safety certification and cannot by itself prove motion, mechanical cause, safe state, or authorization.
Capture-led investigation
Design the evidence path before the next stop.
A useful capture is positioned at a decision boundary and paired with a precise operational question. One PCAP rarely sees agent intent, middleware, controller response, safety logic, and motion together.
- 01
Write the acceptance question: the stop, missed update, discovery failure, timing symptom, unexpected peer, or disputed command window.
- 02
Record topology, capture point, interfaces, clock source, filters, snap length, drops, protocol variants, encryption, and expected traffic.
- 03
Capture where trust or ownership changes: agent service, cell network, robot controller, OPC UA client/server boundary, DDS participant network, or remote-access path.
- 04
Bring an expected peer or signal mapping and, where possible, a successful comparison run. Treat site semantics as supplied context, not inferred truth.
- 05
Verify the packet chronology against controller, robot, safety, application, and operator records before assigning physical cause or authority.
A conclusion another team can review
End with ownership direction, not a dramatic guess.
Each outcome depends on the reported symptom, chosen capture point, protocol visibility, and successful comparison evidence.
Network evidence supports a cause
The capture contains a reproducible network sequence that explains the observed communication failure.
Network evidence supports a contribution
Loss, timing, discovery, reachability, or protocol behavior plausibly contributed, but another subsystem remains involved.
No captured network fault
The relevant exchange completed within the observed boundary, so the next check moves to controller, software, safety, or physical evidence.
Inconclusive
The decisive direction, payload, time window, mapping, or capture point is missing, encrypted, unsupported, or outside view.
Evidence boundary
Network packets can prove an observed exchange at the capture point. They cannot alone prove that an AI agent intended an action, that a mechanism moved, that the movement was safe, or that a physical component caused the incident.
Qualify with the incident you already know
Bring a failing capture, a successful comparison, and the question the packet record must answer.
We will confirm protocol fields, capture coverage, workflow fit, and explicit unsupported scope before treating the case as a valid evaluation.