SCADA Software for Oil and Gas
Wells, pipelines, terminals and offshore platforms, from one platform that reaches every one of them.
Request an Evaluation See the RFP checklist, answeredFrameworX is a SCADA and IIoT platform for oil and gas operations, used upstream, midstream and downstream. It monitors and controls wells, gathering systems, pipelines, compressor and pump stations, terminals and offshore platforms, reaching remote sites over cellular, satellite, licensed radio and fibre. It includes a store-and-forward historian so a site's record is complete after a communications outage, alarm handling with a full audit trail, and reporting for production and custody transfer. It runs on a server, at the edge, or inside an industrial router at the wellhead. Local tags are unlimited in every edition, and more than 120 connectors are included in the license.
A distributed problem, and now two different buyers
Oil and gas is distributed before it is anything else. A single operator can run hundreds of wellheads across a basin, a gathering system feeding a compressor station, pipeline segments crossing three states, a terminal with custody transfer metering, and a platform offshore. Almost none of it is staffed. The communications are whatever the terrain and the budget allow, which usually means cellular where there is coverage, licensed radio where there is not, and satellite offshore.
That shapes what the supervisory software has to do. It has to keep collecting when the link drops and fill the record in when it returns, because a gap in a production record is a gap in an allocation or a custody transfer. It has to raise an alarm that reaches a person who is not in a control room. And it has to do it across equipment installed over thirty years, because nobody replaces a working RTU to suit a software purchase.
What changed recently is who buys it. On the largest deployment of the last year, the software was installed and managed by the customer's networking group rather than by the automation group.
That is a different buyer with a different budget, a different regulatory frame and a different purchase process. It happens because the supervisory software now runs inside the industrial router that was already going to be installed at the site, so the edge in question is the IT edge rather than the traditional automation edge. It is worth naming because it changes what a site rollout costs: no separate edge computer, no separate cabinet, no second device to secure and patch.
What FrameworX does for an oil and gas operator
Remote sites over the links you actually have
FrameworX polls remote stations over cellular routers, licensed radio, satellite, wireless Ethernet and fibre, and the polling rate is set per device rather than globally, so a satellite-linked platform and a fibre-connected terminal sit in the same project without the slow link holding the rest back. Each node carries a primary and a backup station with a configurable failover timeout, so a site with two paths uses both.
How a distributed FrameworX system is put together.Supervisory software inside the router
FrameworX runs natively inside Cisco IOx-enabled industrial routers, fully embedded rather than merely connected to them. At a remote site that removes the separate edge computer and the cabinet it lives in, and it puts collection, local alarming, C# normalisation and MQTT Sparkplug B publishing on the device that was already being installed for connectivity. The IR1101 is validated and production-proven; other IOx-capable models are validated on request. The router deployment is documented here.
A complete record after an outage
The historian stores and forwards. When a site loses its link, data continues to be collected locally and is backfilled when the connection returns, so the archive does not carry a hole where the outage was. For production allocation and for custody transfer, that gap is the whole problem rather than an inconvenience.
Crossing the boundary between field and business networks
Application Gateway carries data across the DMZ between the process control network and the business network without opening a hole in the firewall for each application that wants access. Traffic is directed through a single controlled path under defined business rules, authenticated and authorised, with an audit trail of what was fed through and who changed it. Where a regulatory framework requires that the field network not connect directly to the business network, this is the mechanism that satisfies it.
Custody transfer, allocation and the calculations behind them
C#, VB.NET and Python 3 run natively in the runtime, so meter factor calculations, LACT logic, allocation and flow computer reconciliation live in the platform rather than in a spreadsheet or a service somebody maintains beside it. Results are historised, alarmed, trended and reported like any other value.
Alarms that reach a person, and a record of what happened
Alarm items, groups and areas, with acknowledgement workflows, shelving and a full audit trail. Notification by email and text message to an operator who can then open the same system from a browser or a phone without installing anything. The audit trail records who acknowledged what and when, which is what an incident review reads.
One project, control room to field
The control room, the field office and a phone at the wellhead see the same application. The HTML5 client runs in a browser with no installation, on desktop and mobile, and map-based asset views including ESRI put a distributed field on one screen.
Unlimited local tags
Local tags are unlimited in every edition. The paid scaling axis is external I/O points, meaning the physical signals coming from the field, so adding a calculated value, a trend or a screen costs nothing and an operator can model assets properly rather than economising on tag names.
Connectivity for oil and gas
An oil and gas estate is rarely one generation of equipment. Flow computers and RTUs stay in service for decades, and the platform has to speak to what is installed rather than to what is current.
FrameworX includes more than 120 native connectors. The ones this sector reaches for:
- DNP3, for pipeline and production telemetry and RTUs
- Modbus TCP and RTU, including serial over radio, cellular and satellite
- WITSML, for drilling and completion data
- OPC UA, client and server
- MQTT and Sparkplug B, both directions, with a built-in broker, for bandwidth-efficient reporting over metered links
- Allen-Bradley (ControlLogix, MicroLogix, SLC, PLC5, DF1), Modicon, Siemens S7, Omron
- Historians, native to the platform, with connectors for AVEVA PI and for Canary where a site already runs one
- SQL databases and cloud endpoints, including Microsoft Azure, for analytics and back-office integration
Connectors are included in the license rather than sold per protocol, which is what stops a single new flow computer from starting a procurement cycle.
The RFP checklist, answered
What an oil and gas operator should require of a SCADA platform, and where FrameworX stands on each line.
| What an oil and gas RFP asks for | FrameworX |
|---|---|
| Redundant SCADA servers | Hot-standby redundancy with automatic failover, licensed as an option |
| Local control continues if SCADA is down | Control stays in the PLC, RTU or flow computer. FrameworX is the supervisory layer, not the control loop |
| Store-and-forward and backfill for remote sites | Built into the historian |
| Redundant communication paths per site | Primary and backup station per node, with configurable failover timeout |
| DNP3 for pipeline and production telemetry | Native |
| Substation and electrical infrastructure integration | IEC 61850 and IEC 60870-5, alongside DNP3 |
| Modbus TCP and RTU, including serial | Native |
| OPC UA | Client and server |
| WITSML for drilling data | Supported, alongside OPC UA and MQTT |
| MQTT with Sparkplug B for metered links | Both directions, with a built-in broker |
| Edge deployment at unmanned sites | Runs on a server, on edge hardware, or embedded inside a Cisco IOx industrial router |
| Historian with configurable retention | Built in, with configurable retention and unlimited retention at the Enterprise tier |
| Integration with an existing historian | Read and write to an established historian, including AVEVA PI and Canary, so the archive stays in place |
| Custody transfer and LACT calculations | C#, VB.NET and Python 3 native in the runtime, historised and reported like any other value |
| Production allocation and reporting | Scheduled and on-demand reports in PDF, CSV and XML from historian and operator-entered values |
| Alarm management, shelving and audit trail | Items, groups and areas, acknowledgement workflows, shelving, full audit trail |
| Alarm notification to field staff | Email and text message built in |
| Web and mobile operator access | HTML5 client, zero install, desktop and mobile |
| Map-based view of a distributed field | Map displays including ESRI, with asset status and alarms |
| Role-based security and audit trails | Role-based access control, secrets vault, full operator audit trail |
| Separation between process control and business networks | Application Gateway across the DMZ, single controlled path, no per-application firewall exceptions |
| Critical-infrastructure cybersecurity controls | Role-based access, TLS, secure gateway, secrets vault, audit trail, and published hardening and standards-compliance guides |
| NERC CIP | Compliance is assessed for the installed solution, not for a software product. Applications built on FrameworX have been validated under NERC CIP in production, including offshore. The platform supplies the technical controls and the configuration guides |
| Backup, restore and disaster recovery | Project export and import, and Git-friendly JSON for version control |
| No internet dependency for field operation | Sites run on premises. Cloud and remote access are optional |
| Unlimited tags for modelling assets | Local tags unlimited in every edition. External I/O points are the paid axis |
In production
Apache, Permian Basin
Apache needed a way to improve well performance in the Permian Basin from real-time operational data, with secure remote access so decisions did not wait for someone to drive to a site.
FrameworX was selected as the IIoT and integration engine to aggregate, process and visualise real-time data. Open standards and native interfaces to the existing SCADA and historian systems let Apache stream well data to analytics dashboards reachable from the office or the field, without replacing what was already collecting it.
Router-embedded production monitoring, more than 300 sites
A large United States oil and gas operator runs FrameworX inside Cisco industrial routers at more than 300 production sites, onshore and offshore, collecting from the PLCs and RTUs at each location. The edge nodes normalise data in C#, publish over MQTT Sparkplug B, and manage failover across redundant northbound paths so a site keeps reporting when one route is unavailable.
The deployment is notable for who ran it as much as for its size. It was installed and managed by the customer's networking group rather than by the automation group, using infrastructure and a change process that already existed on the IT side.
Chevron, California, across the DMZ
Application Gateway routes data across the DMZ between the field network and the business network, following the requirement that the field network not connect directly to business systems. Applications on the business side receive the data they need through one authenticated and audited path rather than through a firewall exception each.
Deep-sea drilling, high-frequency visualisation
FrameworX drives the operator interface for a deep-sea drilling project running about forty displays, with real-time collaboration through trend annotations and sustained high-frequency data processing: roughly 5,000 channels per second, and about 500 channels every 100 milliseconds. It integrates with the existing National Instruments and historian systems on the rig.
Secure supervisory access for a distributed operator
Multiple business applications needed access to the process control network, each of which would otherwise have required its own firewall exception. A control dashboard now directs that traffic through the secure gateway under defined business rules, with data authenticated and authorised and an audit trail of what was fed through and who modified it.
RigDAP, real-time drilling data aggregation
Tatsoft's drilling data aggregation solution, built with partner Intellicess and their Sentinel RT streaming-analytics engine, which applies a Bayesian network to distinguish sensor faults from process faults in real time. More on the partner solution
AI, and what it actually does here
FrameworX is AI-Native by architecture. Model Context Protocol servers for the Designer, the Console and the Runtime, all released and supported today, connect an AI model of your choosing to the live engineering project, so an engineer can describe a screen, a report or an alarm set and have it built, reviewing and approving every change before it runs. In the runtime, the same access lets an operator query live operational data in plain language rather than writing a report.
The model runs where you decide. FrameworX ships no model. It connects over an OpenAI-compatible endpoint to a model you run, on a separate networked machine of your own, or to a hosted one. The model host is deliberately not the FrameworX server: the two are separate machines, which keeps model workload off the supervisory server and keeps the boundary between them explicit. Once the model is on that host it needs no internet connection, so an operator who will not send production data outside its own network can run the whole thing inside it.
Statistical models are not placed in the process control loop. The control stays in the PLC, the RTU and the flow computer, where it has always been.
Common questions
What does SCADA do in oil and gas operations?
SCADA in oil and gas monitors and controls geographically distributed assets: wells, gathering systems, pipelines, compressor and pump stations, and terminals. It brings remote measurements into a central view, raises alarms on abnormal conditions, historises production data for reporting, and lets operators act on distant equipment without travelling to it.
How does SCADA work at remote sites with unreliable networks?
Remote SCADA relies on autonomous operation at the site. A FrameworX edge deployment keeps collecting, alarming and logging locally when a satellite or cellular link fails, buffers the data, and forwards it once the connection returns. The central historian then holds a complete record rather than one with gaps during outages.
Can SCADA run inside an industrial router at a remote site?
Yes. FrameworX runs natively inside Cisco IOx-enabled industrial routers, embedded on the device rather than connected to it, and the Cisco IR1101 is validated and production-proven for this. At an unmanned site that removes the separate edge computer and its cabinet, and puts data acquisition, local alarming, C# normalisation and MQTT Sparkplug B publishing on the router already being installed for connectivity. More than 300 production sites at one United States operator run this way, onshore and offshore. It also changes who owns the rollout: on that deployment the installation was managed by the customer's networking group rather than by the automation group.
How does SCADA data cross from the field network to the business network?
Through a gateway rather than through firewall exceptions. Each business application that wants process data would otherwise need its own opening in the firewall, and enough of those openings defeat the segmentation they sit in. FrameworX Application Gateway carries the traffic across the DMZ on one controlled path, with the data authenticated and authorised under defined business rules and an audit trail of what was passed and who changed it. Where a regulatory framework requires that the field network not connect directly to business systems, this is the mechanism that satisfies it.
Is FrameworX certified for NERC CIP?
No, and no SCADA platform is. NERC CIP compliance is assessed for an installed system in a specific environment, running a specific configuration under specific procedures, and it belongs to the operator. What a platform can provide is the technical controls the standard asks for, the documentation showing how to configure them, and evidence that it has been used this way. Applications built on FrameworX have been validated under NERC CIP in production, including on offshore platforms. Tatsoft publishes standards-compliance and hardening guides for the controls themselves. Treat any software product advertised as certified or approved under a framework of this kind with caution, because the certification does not exist at the product level.
What is WITSML?
WITSML is the Wellsite Information Transfer Standard Markup Language, an open standard for exchanging drilling and completion data between wellsite systems and operators. It defines a common structure for well, wellbore, log and trajectory data. FrameworX supports WITSML alongside OPC UA and MQTT with Sparkplug B.
Can FrameworX work alongside an existing historian?
Yes. FrameworX integrates with existing historians, SCADA systems and databases rather than requiring them to be replaced. Data can be read from and written to an established historian, which lets a site modernise the supervisory and visualisation layer while the historical archive and its reporting stay in place.
Can SCADA be modernized without replacing the whole system?
Yes. A common path is to add a modern layer alongside the existing system, connecting to the same controllers and the current historian, then migrate applications area by area. FrameworX is built for this, with native connectivity to legacy automation as well as to modern IIoT architectures.
Which protocols does oil and gas SCADA need?
Field connectivity typically needs Modbus and the major PLC and RTU protocols, plus DNP3 for pipeline and production telemetry, OPC UA for interoperability with other systems, and MQTT with Sparkplug B for bandwidth-efficient reporting over cellular and satellite links. FrameworX includes all of these in the license, among its 120+ connectors. Drilling operations add WITSML, and sites with their own electrical substation add IEC 61850 and IEC 60870-5. FrameworX supports all three, and these drivers are priced separately.
How is oil and gas SCADA licensed, and what drives the cost?
FrameworX licenses are perpetual. Every module, feature and 120+ connectors are included in each license, so there is no separate protocol or reporting module to budget for. The IEC 61850, IEC 60870-5 and WITSML drivers are priced separately. Local tags are unlimited in every edition, and the axis that scales the cost is external I/O points, meaning the physical signals coming from the field rather than the number of tag names in the project. Annual support and maintenance is 20 percent, or 16 percent on a three-year term and 14 percent on a five-year term. Hot-standby redundancy is a licensed option that adds 50 percent. Moving between editions costs the difference in price.