Oil & Gas Ideas

We use all brands.

We monitor basically everything. Flowmeter’s, PLC’s, Rod Pump’s, VSD’s, Plunger Lift, etc.

Yes, a few different methods on recording data. In some instances we store daily production in a database table. In some systems I have worked on we export it daily to a production accounting system and don’t store it. Just depends on what the customer wants.

One of the coolest things I have done is create a route alarm scheduling tool using the equipment schedule component to allow the Foremans the ability to plot out alarm scheduling for a whole month, or more. Basically they make entries into the database and Ignition takes care of moving people into and out of rosters and make sure that they are set to receive alarms at the correct time.

Are you using “Load Cell” to measure plunger life? I would like to know what you are using and what you are actually looking for when doing that.

In the best Ignition tradition we started work on one system to monitor production data for an oil & gas customer and have since added multiple other projects to help run just about every part of the company.

These include:

  • Wellhead monitoring
  • Production monitoring, including lots of reporting
  • On-site generation monitoring
  • User interface for the on-site fuel station
  • Monitoring of water supply and SWD, including RFID identification for drivers
  • Control of access to rest facilities
  • Central information store used to hold asset and maintenance data

The more we put in the more ideas the customer has to add something else. All these systems run on a redundant pair of Ignition servers running Ubuntu Linux, with a pair of MySQL servers providing data storage. For new installations we use Debian Linux and MariaDB.

1 Like

As anyone ever heard of ignition being deployed on the Drilling Rig side of things?

I used to work on an oil rig as a deckhand throwing chains years ago when it was booming… We often had our rigs fitted with really expensive solutions from companies called Pason and NOV. At the expense of the Oil company you drilled for. They charged like 1200$ or more a day for these systems. They were so simple too. Like count rpm of top drive, monitor tanks, connect to Detroit motors, monitor BOP and so on.

I think some of the bigger guys have their own solution nowadays. Like Nomac, H&P and Patterson. All they did back then was talk to the company mans trailer on site and to the rig on site. The company man used the data in his daily report back to wherever they were out of. Usually Houston.

I don’t work in O&G anymore this was before I went to school. Just curious more or less. Good Thread!

Thanks for the reply, give me some Ideas already.

I also work in oil and gas. The machines we have move around a lot from project to project, offshore to land and back and forth etc.

Im monitoring the machines, no control via ignition but I do have means of remote parameter viewing and adjusting etc. I monitor pressures, temps, component run hours, filter hours, motor start stops and lots more stuff trying to build trends. Somewhat of a crude ML to ultimately replace parts before history tells us a part will fail.

Biggest challenge was keeping it all connected either via site WiFi or cell modems. So every machine is connected via MQTT back to a cloud based ignition server and a VPN network. Same VPN network also lets me remote access the machine / PLC’s, apply updates etc.

As I mainly monitor everything In hours run the messages are sent every hour, just the basic stuff. But I also programmed ignition to be able to send a MQTT message to the machine on a button push, to have the machine send a more in-depth MQTT transmission when requested. This was the biggest factor in keeping data overhead low. Perspective was a game changer as the operator can now open the app, scan the QR code on the machine, view past data or request more information if they are having any problems with the machine etc.

As with every project it starts with a simple idea and it quickly grows arms and legs.

A good and recent example of the benefits to this. I recently had a hydraulic pump motor fail after 400 hrs, only a small 5hp motor. We typically change it every 2k hours so this one caught us off guard. Closer inspection we seen that it had been stopped and started way more then usual, the operator was stopping and starting the motor every few minutes, over a span of days. Turns out they didn’t like the noise so they would stop the pump every chance they had. That’s a brief summary but benefits of capturing data that at the time seems irrelevant, is valuable later on.

1 Like

That's an AI use case!

What was the incremental cost involved in such remote monitoring configuration (the edge devices used, the MQTT modules used etc,) and what was the ROI?

We NOW can see this type of activity and then get on top of the problems.

We had pumpers (Contract) that would not show up for days, but fill out the report as if they was
there everyday. Didn’t take long to catch this type of abuse.

1 Like

ROI??

Over the weekend we had a main flow line break, now this is from a field that makes 3600 barrels of water a day, as soon as the pressure drop below our setpoint the fieldkill was triggered and alarms sent out to all needed personnel.

We probably prevented a $150,000.00 clean up!!!

All of the location/wells that have our pump controller installed we know the instant belt’s break, rod part, electrical problems, so these problems get taken care of then not day’s later when pumper finally see’s
a problem (And all the lost production - ROI??)

We have paid for our scada system many times over already!!

2 Likes

Its hard to put a figure on costs, and ROI’s. As a figure that probably doesn’t mean much with out the full facts our down time went from 16% to 0.6%. That’s downtime vs project hours which run in to the 10’s of thousands over the year, over multiple projects and locations.

But then again, we are throwing away parts that are ‘working’ so machine costs go up, downtime goes down and some locations run into hundreds of thousands a day in operating costs that could be held up.

Initial costs is also hard to put a figure on. You could say our system is as dumb as it gets. No redundant servers, sometimes no internet connection. No fancy MQTT messaging queuing system. If we loose one message, we will get the next one a hour later, a week later etc. But, that’s because the bulk of the work is done at machine PLC level. That’s what does most of the calculations, logging, conversions and averages etc. That PLC is there anyway controlling the machine, so really that’s no extra cost. Once I program the data blocks in the PLC I can copy them over and over. So the only hardware cost besides modems and routers is a MQTT device at machine level sending the messages.

2 Likes

Indeed the return is not always tangible. Building more transparency, visibility , observability , instant response , remote monitoring at central location , more and more operational data helps in doing an analysis in real time or as a postmortem analysis to draw actionable insights and inferences . So the incremental cost of such a solution is mostly that of MQTT modules and hardware I guess ?

We developed our own “Remote Units” they are “SMART” meaning they actually manage the location, so if any problems come up they are taken care by the site unit. This way if for some reason we do drop communication to Ignition all site decisions will still be preformed.

We build this box for $1750.00 (USD) and then add what ever sensors we want for monitoring various points.

This box includes PLC, HMI, Cellular Modem, MQTT Gateway, PS/With battery Backup, Antenna.

I am sure that will a great learning for the O&G community! Obviously they will need to go into more details of the individual components inside the box, such as what PLC, what HMI (is it Ignition Edge?), which modules of MQTT etc . But its a great learning experience for the community as a whole.

Are you using the Ignition Edge for the HMI and MQTT for telemetry and PLC for connection to sensors and other io?

We do not use Ignition Edge! This is really because our unit needs to manage the location even if there is no communication with server.

This is why we developed our own remote unit for this.

Right now we just show, record all the tags from each location with scada. We query this data in various ways to show Pie Charts, Trends, Daily Totals, Weekly, Monthly.

We have our own “Cellular Private Network” so any supervisor can connect to any location with his/her phone/laptop and make needed changes.

This works for us as of now, but we make changes to the infrastructure all the time.

Learning whats works best for us & the oil patch.

1 Like

Thanks for reply . So it’s your own custom solution based on your needs . Perhaps Ignition edge may be overkill if you have very few sensors to monitor .

Edge is better suited to larger installs that can justify the hardware outlay of, e.g. GroovEPIC.

If you need a headless site with low IO, but still MQTT then there are cheaper alternatives that are still reliable.

Disclaimer; I don’t work in O&G industries.

1 Like

A while ago I added some info on this post on how I go about it.

Took a bit of time to set it up with the pi having 3 ip addresses and writing the IP tables and modifying the various code. Now I have the pi image saved it’s simple to create a new device.

It may help someone, as above my system is effective but basic. I have no unmanned stations etc.

Kevin, what other ‘collectives’ exist for Ignition? I’m in manufacturing (i.e., inherited a collection of machines & systems originally delivered without connectivity and/or scada of any sort that I’m gluing together into a cohesive structure, often very much against their will :slight_smile: and am curious what else is out there. I didn’t see any links back to the mother-ship from the link you provided.

Thank you.