The production data layer for OT security

Train and validate OT security on real plant traffic.

Full-fidelity ICS network captures from operating industrial plants, time-aligned with process historian records. Commissioned to your specification by protocol, sector and Purdue level.

Request a dataset See a delivery

delivery-manifest — pharma / sterile injectables

architectureSiemens PCS7, redundant

capture_points7 simultaneous

packets_total12,412,880

ip_endpoints159 distinct

purdue_levelsL1 · L2 · L3

historian_window12 months

tag_definitions895,174

clock_synccapture ↔ historian

content_classbenign production baseline

integritySHA-256 per file

status: deliveredcompleteness verified

Live plant sectors

Industrial protocols

L1–L3

Purdue levels captured

Paired data families

2–4

Weeks to delivery

What this lets you build

Detection that holds up on a customer site.

Every OT security team hits the same wall: the model works in the lab and floods the console in production. The gap is the baseline, not the algorithm.

Tune against real operational noise

Rules and anomaly models calibrated on a plant that is genuinely running, so false-positive rates hold when the product reaches a customer estate rather than collapsing on first contact.

Validate parsers on messy estates

Protocol dissectors, DPI and device fingerprinting tested against legacy firmware, mixed-vendor networks, undocumented remote sessions and malformed frames that no simulator generates.

Correlate network to process state

Historian records from the same window as the capture, so behaviour can be read against what the plant was actually doing instead of inferred from packets alone.

Scope, stated plainly

What this data is, and what it is not.

A detection engineer asks this within the first minute. A vague answer costs more than a clear one, so here it is before you ask.

+What it is

A benign production baseline from a plant that is manufacturing product at the moment of capture.
Full-fidelity frames carrying legacy firmware, flat segments, duplicate MACs, malformed packets and vendor remote-access sessions.
Historian records time-aligned to the same operating window, so network behaviour reads against real process state.
Commissioned to a written specification by sector, protocol, Purdue level and operating condition.

−What it is not

Labelled attack traffic, injected intrusion or synthetic adversarial activity.
Testbed, replica-rig or vendor demo-network traffic dressed up as production.
Simulator output, however faithfully the protocol stack is modelled.
Enterprise IT traffic from Level 3.5 and above, which is excluded by design.

This is deliberate rather than a limitation. Generating attacks is the easy half of the problem, and public corpora such as ICS-NAD already cover labelled malicious ICS traffic well. What almost nobody can obtain is a realistic normal from an operating plant — the reference every detector is implicitly measured against. The two pair well: label your attacks from public sources, ground your baseline here.

What we deliver

Two data families, one operating window.

Captured together wherever the site architecture permits, so network behaviour and process behaviour can be read against each other. This pairing is the part most OT data cannot offer at all.

Family A

Production network captures

Raw packet capture from mirror ports on production switches, taken while the line runs.

Full-fidelity and unsampled, delivered as captured in PCAP or PCAPNG
Simultaneous multi-point capture across OS servers, batch servers, historian servers and field PLCs
Purdue Levels 1 to 3 within a single window
Remote-access sessions preserved rather than stripped
Asset-discovery material: LLDP and PROFINET DCP announcements, hostnames, name-service traffic

S7commPROFINETOMRON FINSOPC / DCERPCVNC / RDP

Family B

Historian & control records

The process side: what the plant was actually doing while those packets moved.

Process tag time-series, in native historian format and Parquet
Alarms, events and Sequence of Events logs
Operator audit trail, including recipe and setpoint changes
Batch and recipe records tied to production runs
Tag dictionaries and control-system configuration exports with address mapping

PCS7 Process HistorianWinCCAVEVA WonderwareParquetCSV

The shape of a delivery.

The raw capture, a columnar packet index built from it, and the historian export for the same window. Schema and manifest are identical across engagements. Rows below are illustrative, showing structure and typing rather than plant data.

packets.parquet — illustrative

Illustrative excerpt of the packet index
ts_utc	src	dst	proto	func
09:14:22.101893	10.20.4.11	10.20.4.60	S7comm	Read Var
09:14:22.104556	10.20.4.60	10.20.4.11	S7comm	Ack Data
09:14:22.118004	10.20.4.11	10.20.4.31	PROFINET	RT Cyclic
09:14:22.203441	10.20.7.14	10.20.4.60	OPC	Read

tags.parquet — illustrative

Illustrative excerpt of the historian export
tag	ts_utc	value	quality
R3.TIC_204.PV	09:14:22.000Z	148.62	Good
R3.TIC_204.SP	09:14:22.000Z	150.00	Good
R3.FIC_118.PV	09:14:22.000Z	12.043	Good
R3.PT_331.PV	09:14:22.000Z	3.118	Uncertain

delivery/manifest.json

pcapng_files62 · sha256 per file

protocol_hierarchytshark io,phs per window

tag_dictionarytag → unit, range, loop, asset

clock_synccapture and historian aligned

redaction_logevery field removed, with reason

completenesschecked against your spec

Built to a specification. Accepted against the same specification. If a capture missed something you asked for, you hear it from us before you are invoiced.

Our standing commitment

Where the data sits

Captured at the levels that carry process traffic.

Plants are segmented on the Purdue model, and most available ICS data is recorded at a single level on a testbed. We capture across Levels 1 to 3 of a running plant, so a model sees controller traffic, supervisory control and historian context from the same window.

L5–L4 Enterprise IT ERP, business planning, corporate network not captured

L3.5 Industrial DMZ Data diode, jump host, patch and AV relay boundary

OTTrace capture zone

L3 Site operations Process historian, MES, batch records, engineering shares OPC / DCERPC · historian export

L2 Supervisory control SCADA servers, operator HMI, engineering workstations S7comm · OPC · vendor RPC

L1 Basic control PLCs, DCS controllers, RTUs, safety instrumented systems S7comm · FINS · Modbus · PROFINET

L0 Field devices Transmitters, analysers, VFDs, valve positioners seen via L1 I/O

Level 3.5 and above is deliberately out of scope. Enterprise traffic is not what an OT detection model needs, and excluding it keeps a delivery free of corporate identifiers.

Against the public corpus

Public ICS data exists. Production ground truth is still scarce.

We are not going to tell you there is no public ICS data, because there is, and some of it is good. ICS-NAD carries real-world traffic with labelled attacks. SWaT, WADI and the Morris datasets remain useful benchmarks. But the published corpus is overwhelmingly testbed and simulation derived, and none of it can be commissioned to your requirements against a currently operating estate.

Comparison between public ICS datasets and OTTrace production-sourced data
	Public datasets	OTTrace
Production environment	Rare	Always
Currently operating estate	Sometimes	Yes
Commissioned to your spec	Not possible	Core offering
Multiple simultaneous capture points	Rare	Standard
Buyer-specified protocol and sector	No	Yes
Time-aligned historian and PCAP	Rare	Core offering
Specified operating conditions	No	Yes
Refresh cadence	No	Available
Labelled attack traffic	Yes, in some corpora	No, baseline only

Coverage

Nine live sectors. More sourced to order.

Live means an existing plant relationship in that sector, so a capture can be commissioned against your specification rather than hoping suitable data already exists. Anything outside these nine is reachable through the partner network on request.

Live

Pharmaceutical

Sterile injectables, multi-line parenteral filling, lyophilisation, ampoule and pre-filled syringe lines. Siemens PCS7 and OMRON estates.

Live

Steel

Melt shop and rolling operations with energy monitoring across roughly 200 machines.

Precision component held in a lathe chuck while a spindle tool cuts it under coolant

Live

Specialty industrial

Abrasives and precision component manufacturing, with year-round line access.

Industrial robotic arm working on a vehicle assembly line

Live

Automotive

Press shop, body-in-white, paint and final assembly. Robot cells, conveyor control and line-level PLC traffic.

Crane and storage silos at a cement production plant

Live

Cement & building materials

Kiln control, raw and finish mills, dispatch and quality loops across a continuous process.

Rolls of paper stacked in a paper production facility

Live

Pulp & paper

Pulp mill, paper machine drives and recovery boiler, with tight closed-loop quality control.

Workers in protective gear processing product in a dairy factory

Live

Dairy & cold chain

Pasteurisation, separation and clean-in-place cycles, with cold-chain monitoring across batch and continuous lines.

Live

Renewables, wind & solar

Turbine and inverter SCADA, substation telemetry and distributed sites on IEC 61850 and DNP3.

Live

Building management & data centres

BMS, chillers, UPS and power distribution across a large estate, largely BACnet and Modbus.

Sourced on request

Reachable through the plant partner network against a written specification. Lead time is longer than a live sector because access has to be arranged first, and we will tell you honestly which of these we can realistically reach.

Protocol catalogue

Industrial protocols available from OTTrace with Purdue level and availability
Protocol	Purdue level	Typical estate	Availability
S7comm	L1–L2	Siemens PCS7, S7-300 / 400 / 1500	Live
PROFINET IO / DCP / PTCP	L1	Siemens distributed I/O, PROFINET rings	Live
OMRON FINS	L1–L2	OMRON estates, packaging and filling lines	Live
OPC over DCERPC	L2–L3	PCS7 OS servers, classic OPC clients	Live
VNC / RDP remote access	L2–L3	Engineering stations, vendor remote support	Live
OPC UA	L2–L3	Modern SCADA, MES and edge gateways	On request
Modbus TCP	L1–L2	Mixed-vendor estates, utilities, packaged skids	On request
EtherNet/IP & CIP	L1–L2	Rockwell / Allen-Bradley estates	On request
DNP3	L1–L2	Electric utilities, water, pipeline SCADA	On request
IEC 61850 MMS / GOOSE	L1–L2	Substation automation, protection relays	On request
BACnet	L1–L2	Building management, HVAC, cleanroom utilities	On request

FAQ

Frequently asked questions.

Anything else, email founder@ottrace.com and you get a direct answer from the founder, not a sales sequence.

Is this actually production data?

Yes. Captures are taken on the live network of a plant that is manufacturing product at the time of capture, not on a testbed or a replica rig. That is the whole point of the company. It also means the data carries what testbeds do not reproduce: legacy firmware, flat network segments, duplicate MAC addresses, malformed frames, vendor remote-access sessions and long-tail operational noise.

Where does the data come from?

Captures come from operating industrial plants sourced through our partner network. Every engagement is covered by a mutual NDA, and sensitive identifiers such as addresses, hostnames, product names and batch codes are redacted to a policy agreed with you before delivery. Source facilities are not publicly identified.

Does the data contain attacks or labelled malicious traffic?

No. OTTrace supplies benign production baseline data. There is no labelled attack traffic and no synthetic intrusion. This is deliberate: generating attacks is the easy half of the problem, and public corpora such as ICS-NAD already cover labelled malicious ICS traffic. What almost nobody can obtain is a realistic normal from an operating plant, which is the reference every detector is measured against. Use public corpora for labelled attacks and OTTrace for the baseline underneath them.

What can I specify in a commissioned capture?

Sector and process type, target protocols, Purdue levels, number and placement of capture points, capture duration, the operating conditions you need represented such as a batch changeover or recipe change, which data families you want, and your anonymisation policy. We state up front what is sourceable and what is not, rather than accepting every specification and disappointing you later.

How is sensitive information anonymised?

Anonymisation is configurable to your risk posture and agreed before delivery rather than applied by default, because heavier redaction reduces forensic and asset-inventory value. Options range from full-fidelity delivery under NDA through to rewritten IP and MAC addressing, removed hostnames, and redacted product and batch identifiers. Every delivery includes a redaction log stating each field removed and the reason.

How long does a commissioned capture take?

For a sector where a plant relationship already exists, a commissioned capture runs roughly 2 to 4 weeks from specification sign-off to delivery, allowing for site scheduling around production windows. Sectors sourced from scratch take longer because access has to be arranged first. Datasets already held can move within days.

Get started

Tell us the plant traffic you wish you had.

Give us the sector, protocols, Purdue levels and operating conditions. We will tell you what already exists, what we can commission, and what is not realistically sourceable by anyone.

Sector and process type

Protocols and Purdue levels

Network capture, historian records, or both

Capture duration and refresh cadence

Your anonymisation requirements

Request a dataset

Goes straight to the founder. Reply within one business day.

or email founder@ottrace.com