Run safer, more reliable operations on data you can defend.

Operational technology is the equipment and software that controls physical processes: PLCs, SCADA, distributed control systems, and safety systems. IT is the business side: ERP, email, reporting. OT is engineered for availability and safety over a long lifecycle, and most operators segment it from IT with firewalled zones and a DMZ, often following models such as the Purdue reference architecture and standards such as IEC 62443. A well-built operational platform lives on the IT side and reads from the control network through a historian or a one-way channel rather than connecting to controllers directly.

A historian is a time-series database that records tag values from SCADA and control systems at high frequency, with compression, quality flags, and long retention. It is the natural place for business software to read operational data, because it already sits at the boundary and never writes back to equipment. A well-built platform reads from the historian through its API or OPC interface, maps tags to assets with units and time zones handled explicitly, and treats quality flags as data rather than ignoring them.

Crews on a lease, a platform, or an exploration camp often work for hours or days without a usable link, so a field app has to store readings, inspections, photos, and signatures on the device and sync when a satellite or cellular connection returns. The hard parts are conflict handling when two people edit the same record, clock drift on devices, and knowing which form version was in use. A well-built app is offline-first, versions its forms, preserves both sides of a conflict for review, and stamps every record with its capture time and location.

Permit-to-work is the formal process that authorizes hazardous work such as hot work, confined-space entry, or work on isolated equipment, with gas tests, isolations, approvals, time limits, and checks for conflicting simultaneous operations. Paper permits still dominate because they must be visible at the work site and survive a lost connection. A well-built system models the permit lifecycle with approvals and isolation registers, checks for conflicts across the site, prints or displays the permit at the job, and keeps an unalterable history that an investigator can reconstruct after an incident.

It depends on the activity and jurisdiction: federally regulated pipelines and offshore projects in Canada answer to bodies such as the Canada Energy Regulator and the offshore petroleum boards, provincial regulators such as the Alberta Energy Regulator cover most upstream activity, and in the United States agencies such as OSHA, EPA, BSEE for offshore, and PHMSA for pipelines set their own record and reporting rules. The common thread is that incidents, inspections, emissions, spills, and training must be recorded with evidence and retained for years. Your compliance team should confirm the exact obligations; a well-built platform treats record types, retention periods, and submission formats as configuration so they can be adjusted without a release.

Production accounting takes measured volumes from meters and tanks, allocates them to wells, facilities, and working-interest partners, and adjusts them when estimates are replaced by actuals at month-end. Field readings, historian values, and the ERP rarely agree on the first pass because of unit conversions, late corrections, and manual estimates. A well-built system keeps the provenance of every number, versions each allocation run, and shows finance exactly which field inputs produced the volume on the invoice.

OPC UA is the current standard for reading tags from PLCs and SCADA servers, with OPC DA still common on older installations. Modbus TCP and RTU remain widespread on field devices, DNP3 is common in utilities and pipeline SCADA, and MQTT, often with the Sparkplug B payload specification, is used by IoT gateways and newer sensors. Modbus has no authentication, so it must never be exposed beyond the control network; a well-built platform reads these protocols through a gateway or historian inside the OT zone and only forwards normalized data across the boundary.

A computerized maintenance management system holds the equipment register, preventive maintenance plans, work orders, and spare parts, while the ERP holds procurement, inventory valuation, and cost accounting, and larger ERPs include their own asset management modules. Running maintenance in both without a clear system of record is how duplicated work orders and unposted costs happen. A well-built architecture picks one system of record for work orders, integrates parts and costs with the ERP, and lets condition data from the historian raise work orders automatically.

Most upstream assets are owned by several working-interest partners who are entitled to production, cost, and HSE data under the joint operating agreement, and contractors on site need permits, training records, and inspections but nothing else. Access therefore has to be scoped per site, per partner, and per record type rather than per company. A well-built system enforces that scoping in the data layer and logs every access, which satisfies both the partners and the auditors.

An investigator or regulator will want to know who recorded it, when, on which version of the form, what evidence was attached, and whether anyone changed it afterward. Records that live in editable spreadsheets or in a vendor system with no change history fail that test. A well-built platform keeps immutable history with time-synced stamps, stores evidence alongside the record, applies retention schedules, and can export a record exactly as it stood on any past date.

Greenhouse gas and methane reporting draws on operational inputs such as fuel use, flaring and venting volumes, equipment counts, and leak detection surveys, and regimes such as the federal Greenhouse Gas Reporting Program in Canada, provincial programs, and the EPA program in the United States each prescribe their own methods and emission factors. Factors and methods change over time, so a report must record which version it used. A well-built system keeps calculation methods and factors versioned and preserves lineage from each reported figure back to the field data behind it.

A list of sites with their connectivity, the control system and historian vendors at each, your OT security policy and the boundary your OT team will allow data to cross, the regulators and record types you report to, and the spreadsheets and forms your crews use today. From that we write an integration inventory and propose a first phase that replaces the record or form causing the most pain at one site.