Open Industrial Data Project (Valhall Compressor Live Data)

It is what happens when an operator streams a machine instead of publishing a brochure about it. The Open Industrial Data project is a joint effort by Aker BP and Cognite that publishes a live feed of genuine operational data from exactly one subsystem: the first-stage centrifugal compressor tagged 23-KA-9101 in the gas treatment train of the Valhall PH platform in the Norwegian sector of the North Sea. The machine is electrically driven and fixed-speed, receives gas from the separators at roughly 3 barg, and sits at stage one of a four-stage treatment train rated around 4.06 MSm3/d (143 MMscf/d) of export capacity. Aker BP picked it because its boundaries are clean and its instrumentation rich.

What arrives covers the full anatomy of one industrial subsystem. Continuous process and vibration time series, including alarm/warning/fault channels like externalId pi:160268. Maintenance history as structured events typed worktask or rule_broken. An asset hierarchy tying every signal to physical equipment. P&ID diagrams for the compressor, its first stage suction cooler and its suction scrubber. Plus 3D models and data models describing the same hardware spatially and semantically. Signals, paperwork and geometry all describe one machine.

Inside Datadory's oil & gas equipment services catalog of 14 datasets averaging 7.07/10, this record scores 8/10 and is one of only two in the slice that moves in realtime - the other answers at what price, while this one answers at what vibration. Get a sample of this dataset scoped to the tags you care about.

Three resource types, three shapes. As they arrive:

# time series datapoint - one sensor reading on the first-stage compressor
externalId : pi:160268          # source-prefixed signal id (alarm/warning/fault family)
timestamp  : 1755772800000      # UTC epoch milliseconds
value      : 3.42               # measured reading at that instant

# event - one maintenance record from the same subsystem
eventType  : worktask
description: First stage suction cooler inspection

# asset - one node in the equipment hierarchy
asset      : 23-KA-9101         # first-stage centrifugal compressor
metadata   : COMPRESSOR_STAGE=1

Read the shapes rather than the numbers. The datapoint row is the workhorse: millisecond timestamps joined to a single float and keyed back to a pi:-prefixed historian tag - exactly the join condition-monitoring and anomaly-detection code wants. The event row shows maintenance arriving structured rather than scanned, a typed work task with its description attached, alignable against vibration trends with no OCR step. The asset row is the graph in miniature: the compressor as one node, COMPRESSOR_STAGE=1 placing it among its siblings. Note that the example timestamp and value are schema-shaped placeholders from the research pass, not authenticated pulls - your sample swaps them for real readings on the tags you name, which is also where per-series history depth gets stated instead of implied.

Seven fields carry every observation, split between measurement and structure. On the measurement side, timestamp and value form the datapoint pair - epoch milliseconds against a number, high-frequency enough that a vibration signature survives sampling. On the structural side, externalId does the identity work, preserving source-system prefixes so historian tags stay distinguishable from platform-native ones at a glance; asset binds each series into the equipment tree rooted at the compressor; eventType keeps maintenance records queryable by class (worktask, rule_broken) rather than buried in prose; description carries the human layer; and metadata holds key-value context such as COMPRESSOR_STAGE=1.

Honesty clause, because this record earns one: definitions were written against the published resource schema during the August 2026 research pass rather than read off authenticated payloads, and the research log says so explicitly. The four items that vary by project configuration - file-to-asset bindings behind the P&ID diagrams, 3D scene nodes, per-series declaration details, and relationship records - fold under additional fields on request instead of being presented as universal columns. Name what your pipeline needs when you request the sample.

Geography: deliberately narrow. One location - the Valhall PH platform in the Norwegian sector of the North Sea - and within it one subsystem: compressor 23-KA-9101 plus its suction cooler and suction scrubber. This is depth-per-asset coverage, not basin-wide breadth; nothing here describes another platform, another field or another operator.

Temporal: a live stream described as continuous from project inception onward. Historical depth differs by tag - some signals reach further back than others - and overall archive bounds were not published at the August 2026 verification pass, so Datadory states each requested series' actual span in your sample rather than quoting a range nobody has seen.

Granularity: three grains under one field vocabulary. High-frequency sensor datapoints per time series, dense enough for spectral work on a rotating machine. Discrete maintenance events and work orders at record level. And document-level content, where P&IDs ship as drawings and equipment renders as navigable 3D scenes. Estimated size: one compressor subsystem with rich series and maintenance data - the exact series count has not been published, which is why the sample confirms it for your named tags before anything locks.

API, files, or your warehouse. Daily, weekly, or hourly.

Pick the channel your stack already speaks and set the cadence to match the decision being fed: streaming-shaped pulls suit a live condition-monitoring prototype, flat files sized for overnight loads suit a teaching environment, and rows landed directly beside your maintenance tables let a vibration trend join to its work order in one hop. The seven-field dictionary above travels unchanged across all three channels.

Every delivery ships the field dictionary, sample rows for validation, and per-series coverage mapped to the slice you asked for - so nothing arrives as an undocumented dump.

• Predictive-maintenance prototyping - vibration and process series aligned to typed worktask events give reliability engineers a labeled history for failure-mode models, with labels written by the crews who actually serviced the machine.
• Condition-monitoring pipeline hardening - integration teams rehearse historian-to-cloud flows against real signal shapes, including the awkward ones, before pointing them at production plant data.
• Industrial-IoT application development - a complete reference stack of time series, assets, events, documents and 3D exercises an end-to-end product without touching anyone's production infrastructure.
• Teaching and research - genuine platform telemetry makes digitalization lectures and papers concrete: the channel, the alarm and the drawing all describe one afternoon offshore, with an operator name attached for citation.
• Competitive intelligence - vendor and analyst teams benchmark how far operator-led data sharing reaches, using evidence from a running platform rather than marketing material.

Deeper persona guidance lives on the data scientists, developers & builders and investors & quants pages for oil & gas equipment & services.

Only four datasets in Datadory's whole 1,744-record catalog carry the compressor tag, and two sit in this industry slice - which makes the comparison unusually concrete. Refinery Centrifugal Compressor Sensor Data (One Year) is the frozen counterpart: 25 sensors on a Greek refinery train, 15-minute resolution, 35,036 readings per sensor across calendar 2022, one closed workbook. It offers more sensors over a finished window; Valhall offers fewer boundaries and no endpoint, because the machine is still running.

Elsewhere in the slice the contrast is starker. OGIM - Oil and Gas Infrastructure Mapping Database v2.5.1 maps ~6.7 million infrastructure features worldwide but describes facilities from the outside. NSTA National Data Repository (NDR) holds UK licence-level well and seismic depth beneath a different bit of the same North Sea. OilPriceAPI (Energy Commodity Price API) is the other realtime feed in the slice - it answers at what price while this answers at what vibration, and our side-by-side of the two covers the split in detail.

So the standard workflow stacks them: infrastructure context from OGIM, licence and well depth from NSTA, prices from OilPriceAPI, and this corpus whenever the question lives inside one machine.

Three things worth having in hand.

First, scope is one compressor subsystem - rich within its boundaries, silent outside them. Portfolio-scale or fleet questions need pairing with basin-wide company such as OGIM's infrastructure map or the NSTA repository rather than deeper filtering here; say so when you ask and we will point you at the right complement instead of overselling this one.

Second, archive depth varies by tag and was not published at the August 2026 verification pass. The stream runs continuously, but how far back each series reaches is confirmed per tag during sample preparation - state the span your design needs and the answer comes back evidenced, not implied.

Third, the seven-field dictionary is documented but marked inferred until confirmed against live rows - your sample doubles as that confirmation, which is why the schema ships alongside the data instead of ahead of it. Per-series attributes such as unit and step behaviour land in the same pass.