Being Cloud Ready

I just spent the last two days participating in an IoT and Data Analytics Hand-on-Lab at Microsoft Canada in Calgary. It was awesome to see what they are doing with their cloud product offering and how it can be used to enable business intelligence and possibility for new applications. Here is a screenshot of a PowerBI dashboard showing probability of being delayed due to weather at US airports (decent working example!).

Out of all this learning it is becoming incredibly clear that field techs and programmers must, must, MUST make sure they do their due diligence on site when setting up RTU and PLC programs. These jobs are no longer just about setting up shut down logic and measurement configuration. Industrial field programmers and field techs ARE the front-line staff in preparing the industry for all this cloud analytics. At least according to me.

In order to make your programs cloud ready:

  • Make sure you talk to the client about what data needs to be sent up to corporate or the cloud for data analytics. Ensure the client gets a spreadsheet with information about those data points (tags), where/how to get them, and what they are used for.
  • Make sure you setup proper history and logging on location. In Floboss/ROC RTUs this means setting up the history with the right algorithm (linear avg., current value, etc.). In SCADAPack RTUs, might mean setting up DLOGs and some averaging logic. In PLCs you might have to build or use some averaging logic blocks to produce minute, hourly or daily averages on important information.
  • Commission well. Make sure that pressure is linked up properly. Make sure your transmitters are scaled right. Do not rush this. If you get the data hooked up wrong (mis-categorized) you might mis-lead someone further down the line (for example if tubing and casing are mixed up).
  • Understand that a transmitter is installed for a valid and real reason, outside of process control. That pressure, or flow, or tank level is now almost or more important than the sensor used for safety control. Treat it with the same due diligence.
  • Organize your program in a way that will make it easier for the next programmer to work on or for someone else to find the information they need. Leave a copy of the program with tags behind. Be willing to share that information because that is going to make the entire industry better.
  • Setup communication paths that make sense for our modern data needs. If you are using a cell modem; bump up that baud rate. If you are installing a new radio network; consider an architecture that allows for higher bandwidth (avoid 400MHz Ethernet unless you need it to get past trees or hills). Cell modems are insanely cheap now ($10CAD/month for 500MB or more), and can be secured with VPN’s, or private cell networks managed by major telecom companies. Do not be afraid to use them.
  • Document what you have done. Ensure there is some context around how/why transmitters are installed and communicate the importance of them.

These are some added value pieces that can set your programs apart from another integrator or programmer. Make sure you quote/charge for them, I know we have been beat down pretty hard the last couple years, but start adding this into your process and quotes. Clients will truly appreciate the opportunities that come out of having access to valid, accurate data with context.

I have not done an RTU program in a while. I am kind of missing it. I think people assume because I focus primarily on the SCADA host side I am not as good or do not like the RTU or PLC programming side. Not true. This whole process starts in the field and I love getting that piece absolutely right. Getting the RTU program right saves everyone downstream (SCADA host, production accounting, marketing, etc.) so much time and effort.

I will have more to post next week! Off to Kentucky! Mmmm…. Bourbon…