01 / Define the experiment
Agree permitted traffic, equipment, approved SPAN/TAP point and the evidence to evaluate. Begin with synthetic or explicitly authorised lab data.
ACADEMIC / RESEARCH / INDUSTRIAL TESTBEDS
Academic and testbed evaluation.
A starting point for universities, research groups and industrial testbed teams exploring passive OT visibility and practical evidence workflows.
Seeking evaluation partners. No university affiliation, endorsement, active collaboration or grant award is implied.
CONTROLLED EVALUATION
Start with a simulation rig and an agreed scope.
02 / Observe the copy
Evaluate local asset and communication visibility from a mirrored feed. The monitoring path is designed not to probe controllers or issue control commands; configuration still needs validation.
03 / Review the output
Compare inventory, relationships, freshness warnings and report examples against the testbed’s known ground truth. Record coverage gaps and agreed next actions.
SUPPORTING DETAIL
Evaluation detail, on demand.
Choose the topics relevant to your site, scope and review.
Traffic and evaluation scenariosChoose the agreed protocols and reference conditions.
PROTOCOL COVERAGE / SCOPE TO AGREE
Choose the traffic you want to evaluate.
| Protocol family | Evaluation focus | Boundary to validate |
|---|---|---|
| Modbus TCP | Observed client/server communication and available protocol metadata | Cleartext TCP capture and supported message types |
| EtherNet/IP (ENIP) | Observed industrial endpoints and recorded communication relationships | Available ENIP/CIP traffic and decoder coverage |
| Siemens S7 | Engineering-station/controller communication context | Captured variants and supported exchanges |
| OPC UA | Observed endpoint and connection context | Encryption limits payload visibility; no decryption bypass is implied |
| MQTT | Observed broker/client connections and available metadata | TLS and capture scope can limit message visibility |
These are evaluation topics, not promises of every protocol version, field or encrypted payload being parsed. Confirm support against the selected release and an authorised test capture before agreeing acceptance criteria.
Collection architectureInspect the approved copy path and its limitations.
ILLUSTRATIVE ARCHITECTURE / APPROVED MONITOR FEED
Observe a copy. Keep control with the plant.
Select a layer or the appliance to explore the deployment boundary. This simplified Purdue view is a discussion aid, not a validated zone-and-conduit design.
Local appliance boundary
The monitoring interface receives an approved traffic copy for local analysis. It is not inline. Management access, updates and evidence exports follow separately agreed controls.
Passive monitoring is designed not to inject discovery probes or machinery commands. A SPAN/TAP copy alone does not prove air-gap isolation, safe configuration, complete coverage or zero operational risk. Validate switch/TAP settings, capture direction, management separation, retention and change control before connecting a plant or testbed. Purdue levels are illustrative; actual zones depend on your architecture and risk assessment.
Data handling and research boundariesReview what can leave the testbed and who controls it.
DATA GOVERNANCE / CONTROLLED TRANSFER
Your team controls what leaves the testbed.
Local by design
Day-to-day analysis is designed to run on the local appliance without a continuous public-cloud service. Capture and payload retention depend on the agreed collection configuration.
No routine cloud upload
The proposed evaluation does not require raw packet captures or proprietary payloads to be uploaded to OTCogniShield. Any export or support transfer requires an explicit, agreed method and scope.
Agree governance first
Confirm data owner, permitted processing, access roles, retention, deletion, anonymisation and publication permissions before collection. Validate isolation and management connections as part of the test plan.
Use the website form only for a short project description. Do not attach captures, credentials, controller configurations or proprietary payloads. The internet-connected website is separate from the local industrial platform.