Wednesday, July 22, 2020

Universal I/O LoRa node from VolleyBoast

You've seen me post about LoRaWAN and how it's creating and delivering relevant data to the enterprise without navigating the traditional bureaucratic processes and costs, right? If not, take a minute and get caught up eyeballing this illustration from the bottom up, or click here for a deeper dive. 

If you're going to play in the LoRaWAN game you can either find a sensor that is fully integrated with battery, LoRa RF, power management, etc, or you can opt for an off the shelf LoRa end device/node/bridge that can pretty much handle any sensor you want to throw at it. 
The latter method is just what Volley Boast has released to serve the industrial market, and it's proven to provide a few immeasurable benefits: 
  • you can use sensors your team has grown to know and trust
  • you can use sensors that might be in your own inventory, or provided locally by your favorite fisherman, hunter, hockey player, skeet shooter, or beer drinker.
  • it provides a connectivity solution for just about anything you want to hang out on the edge. 
Volley Boast new GP-1 LoRaWAN End Node is well equipped to handle most of your applications, and will soon have a Class I Div.2 sibling. 

The GP-1 uses the mDot LoRa module from MultiTech Systems, which is LoRa Alliance Certified.  This assures the user that the GP-1 can easily be adopted by any LoRaWAN compliant Gateway/Network, such as MultiTech's IP67 or Conduit Gateway, and many others. 

The GP-1 is packaged in a NEMA4X enclosure (~3"x6"), IP67 for outdoors, and rated -40 to 176degF (80C).  It has 3 cable entries that are sized nicely to accommodate the I/O count.  There's also an internal magnetic switch that allows the user to locally force a sample/transmit without opening the enclosure.

The GP-1 is powered by a single 3.6Vdc D-Cell battery offering 13Ahrs of autonomy, and the ability to power sensors up to 24Vdc. 
The I/O compliment assures that outside of RTD/TC, this might be the only node you need to LoRa enable others peoples sensors (OPS).  That might become a new thing! "Who's down with OPS!"; yeah, I'm that old.
Here's what you get: 
  • 3 Analog Inputs - Individually Selectable (0-5Vdc / 0-10Vdc / 4-20ma) 
    • Ideal for Pressure sensors like Wika E-10, Foxboro IGP-10, ABB 266
  • 4 Discrete Inputs - 3 - Rated 1A@24Vdc, also Pulse Counters (0-10KHz) / 1 - Interrupt Input
  • 1 Serial Port - RS485 Modbus Master
    • for things like Electrolab tank sticks and Foxboro/SE's Modbus Transmitters.

These guys are doing a good job facilitating the needs of all segments oil & gas, petrochemical, water/wastewater, and other industrial segments.

They are Houston based, including manufacturing, and can be reached at www.volleyboast.com, info@volleyboast.com, and also at 250-412-5679. 

Let's hear it for Made in the USA!!!

Monday, July 6, 2020

Ethernet Connectivity in Hazardous Locations

We hear many times,  "I'll just drop a Cat5 cable to my Hazardous Area Rated Tablet or Laptop to tweak my VFD, Analyzer, or reprogram a PLC". 

Really? You're going to shut down the PLC, make the Ethernet connection, then fire it back up?  
If you don't, you're about to make a potentially dangerous connection, according to the NEC. 

People don't commonly think of Ethernet as having enough energy to create a spark, but it does.  There are a couple of alternatives to de-risk that connection: 
1) use rigid conduit with a poured seal, with Ethernet cable into a safe area. 
2) use an Intrinsically Safe Ethernet Barrier. 
The latter seems so much simpler, because it is. 

There are two versions in Solexy's offer that help this effort. 
  • The BAF is for use in a safe area; which could inside a purged panel in a hazardous area, or a legit safe area on its own. 
  • The BXF is for use in an unsafe area, and is installed into a conduit entry of an explosion proof enclosure.  
The connections are always made in pairs as there is energy being applied on both ends, going to the other.  Each barrier assures the signal leaving is compliant to I.S. energy limits.   When using a purged panel, it is common to have a power disconnect so that the panel is de-energized upon pressure loss. Without a barrier such as the BAF, the user would be forced to have a remote disconnect on the other end of the ethernet switch to prevent energy from being sent into the purge-failed panel.   

This is probably a good place to mention that these cannot be used with POE (power over ethernet)

The units are IP66/68, made of aluminum or stainless steel,  and well suited for permanent outdoor installations where an ad-hoc connection needs made.  For example,  a new analyzer house, or a skid, without the time or costs impacts associated with a rigid installation (engineering, electrical/mechanical techs, poured seals, etc.) 
For machine to machine installations, there is potential for use of a BAF to another BAF, or BAF to BXF, etc.  It all depends on the area and housing type.
The BAF and BXF are available for Class 1 Div.1, AEx Zone1, as well as ATEX/IECex Zone1.
The field connectors for the Cat5 are standard M12 D-Code industrial connectors. 

You can learn more about these by visiting Solexy 

Feel free to hit me up on applications challenges associated with Ethernet in Hazardous Areas!

Wednesday, June 10, 2020

Deploying WiFi in Class I Div.1/Zone1 ExplosionProof Hazardous Area

All the cool kids are pursuing "the Connected Operator" so they can make use of the goggles, cameras, tablets, and handhelds; and that's no big step for most applications.

But what about the ones that live in hazardous areas, and I don't mean CID2, but the ones like Class I Div. 1, or Zone 1 where an explosive environment is always a real threat?
Those folks have historically had very few options, which were quite expensive, really heavy, and required several runs of rigid conduit and seals for power, signals, etc, and use costly, low gain, fixed mount antennas XP antennas.

If you had your choice of installing, with the help of another person, and maybe a lift, the one just described, or one that's about the size and weight of a bowling ball? Cost being somewhat proportional, which one would you pick?  Yeah, me too.

When speaking with Giovanni Soldo, founder and President of Solexy Wireless, he expressed his desire to bring to market something that will promote the proliferation of connectivity in most any environment, and just about any budget.

His new solution series comes in 3 connectivity varieties: 
Each of the units are available in Aluminum or Stainless Steel, weighing in at 9-15lbs, and range between $1,400 and $3,000USD.

One of the challenges with such communication solutions is how to go about getting the RF out of the box. These units use Solexys RX/SX Intrinsically Safe and ExplosionProof RF Barrier fitting to allow the RF signal to safely exit the enclosure. This barrier consumes no space inside the unit, and allows the user several advantages:
  • use any off the shelf passive antenna, Yagi or Omni, and higher gain; respecting EIRP... 
  • allows locating the antenna locally or remotely, optimizing the RF topology.
  • allows the use of any off the shelf coax cable, with out conduit, or costly ratings. 
With todays cost constraints it is great to see Solexy contributing to the affordability of Connecting  the Operator, providing increased operational effectiveness, and operator safety. 

Now, what will you connect next?

I look forward to your questions or comments below.

Thursday, May 28, 2020

Converting Modbus to MQTT, with no programming

It seems all the cool kids are MQTT’ing these days; pub’ing this, and sub’ing that.  
But what about the kid that geeks from across the room, because he isn’t a Python or C++ programmer? 
You know the one, the kid that just wants to git ‘r done.  
Well kid, meet SCADADroid by Reonix. 

Based in Calgary, they've got a decade of history in autonomous alarm notifications using text-to-voice synthesis, SMS and email; think Win911 in a cell modem.  The past few years have brought about a few tweaks, continually responding to "Hey, have you thought about ...?". 

As a result, the SCADADroid, while maintaining a ton of other notable capabilities, has become a sweet piece of hardware that can MQTT-enable any device that speaks Modbus. You really don't even need a Modbus device, you can just use any of the Discrete or Analog Inputs. The big significance however, is "no programming required". 

Did you understand the part about "no programming"? This unit requires zero programming, the user simply configures the functions using a browser interface to the devices internal web server.

For simplicity, and relevance to MQTT, some of the functions have been greyed out in the below illustration.  Basically all you do is: 
  • Create your list of Tags (Onboard I/O, or Modbus)
  • If Modbus, configure each with address, data type, registers, formats, tag names, scaling, trigger, units (psi, gpm, etc)
  • If Onboard, configure each with Input Number, tag names, scaling, trigger, units (psi, gpm, etc)  
  • Configure MQTT publishing trigger; can be time or process variable change
  • Enter your MQTT Broker credentials

Congratulations, you just virtually MQTT'd!

As they say on late night TV ad's "but that's not all!" 
The SCADADroid also: 
  • OpenVPN client; secure connections for remotely programming PLC's, etc.
  • Routing and Port Forwarding
  • Alarm notification - voice, SMS and email
  • Notification phone book with groups and shift changes, and holidays
  • Alarm escalation policies
  • Remote acknowledgement with audit trail
  • Process variable trend window
  • Alarm history dashboard
  • Use your existing radio network with the cellular as redundancy
  • Generate reports as pdf, csv or json
  • Distribute reports via email
  • Onboard historization of all process variable changes (datalogging)
  • Remote control of Discrete Output, and/or condition based.
  • Create conditional logic with Event Composer
  • Live Tag Viewer

Coming soon! 

  • Class I Div.2 Certification (is currently pending)
  • Dual SIM option to host a Verizon SIM and an AT&T/other SIM at the same time.

This unit really is a non-coders dream to MQTT'ing, I can't imagine it being much simpler. 

You can learn more about the SCADADroid at www.scadadroid.com

Hit me up with any questions! 

Friday, May 15, 2020

LPWAN considerations for a newbie (a short series) - Part 1 of 3

You guys know I enjoy the heck out of talking about all sorts of wireless sensor networks and many of the things that impact selection and overall performance.

This post was made active, but was quite long, so has been segmented for ease of consumption into these parts which will be posted in coming days:
1) LPWAN - what it is, what it consists of, and why it exists
2) Sensor/Node Considerations
3) Public vs Private

1) LPWAN - what it is, what it consists of, and why it exists

LPWAN (Low Power Wide Area Network) is a family of technologies that provide a relatively broad topology for deploying battery power low powered sensors and machine connections.  Some connect directly to the cloud, and some to the cloud via gateway.

In North American the dominate participant is LoRaWAN, with LTE-M and NB-IoT rapidly gaining ground.   It is estimated that ~2022 the number of LTE-M chipsets deployed will surpass those of LoRaWAN.  That does not mean that LoRaWAN is expected to decline.  On the contrary both are expected to grow and the technology, and associated costs will enable more and more device to earn their place in connectivity.  There are a few other players in the space, but those listed above pretty much cover todays incumbents.

The LPWAN market evolved from necessity due to the fact that the cellular carriers ignored the space for low data rate plans at a low cost for M2M applications. Of the carriers polled, who offered M2M data plans, 75% of those devices had utilization under <1MB per month.  With those plans being near $29/mo just a couple years ago, it's easy to see why an adjacent market segment was created.

There's really not a one size fits all technology when it comes to M2M connectivity.  Some of the considerations that help decide which is best range from frequency/interval of communication, range/distance of the wireless link, the size of the payload, access to power, field accessibility to data, mobility requirements or not, existing infrastructure or not, and public or private network access.

Some LPWAN's have limitations that vary by region and carrier, such as messages per day, payload size, and range.

For example LoRaWAN has regional limitations set by the FCC in the USA which only limit dwell time.  In Europe however, ETSI limits the on-air time.   For North America a user needs to balance throughput and range.  To do that the application is evaluated against the performance attributes of the available 11 Data Rate plans and 6 Spread Factors which allow the user to balance data payload and distance requirements. You can speed up the comms but sacrifice the range.  Other LPWAN's offer much more speed like LTE-M/CatM1 @~375kbps and NB-IoT @ ~100kbps, but you give up low cost, and low power.

Bi-directional communications is another consideration depending on the needs of the remote asset.  Some of the reasons you might consider bi-directional communications are:
- FoTA, firmware over the air
- writing control outputs, such as locking a gate, closing a valve, turning on street lights.
- writing configuration changes such as re-ranging a transmitter or changing the device interval
Different LPWAN's have different limitations around bi-directional utilization, read up before deciding which is best for you.

Mobility is an interesting aspect of LPWAN and is well accommodated by LTE-M, somewhat by LoRa, but not well at all by NB-IoT or Sigfox.  NB-IoT and Sigfox are built around specific infrastructure, which there is very little of in todays rural North America.
LTE-M however, is supported most everywhere LTE exist today, and supports roaming from one tower to another.
LoRaWAN is the only LPWAN focused here that requires a gateway. As such, mobility is largely determined by the network being Private or Public.  If on public LoRa network, you can roam anywhere a packet forwarding gateway exist.  On a private LoRa network you are limited to accessibility of your own gateways, which could anywhere in the world, as long as they are on the same network.

Between legacy Wireless Sensor Networks like WiHART and 900MHz proprietary versions (Americas) and the increasing applications of LPWAN's and PWANs (BLE/NFC), it's not hard to fathom the billions of devices being connected in the next few years.

 Coming soon are the follow ups to this short series:
         2) Sensor/Node Considerations
         3) Public vs Private

Have fun with your LPWAN endeavor and I look forward to your questions or comments!

Friday, May 8, 2020

Content vs Context

This morning over coffee I was catching Dan and Joe on 10XTalk podcast as the focused on their Impact Filter method of not just doing things right, but doing the right things.

One of their points was about communicating during this period of lockdown, where we're not face2face, and how our emails have content, but not context.   The content is what we're communicating, and the context is why we're communicating it.  When we're together we get used to people having awareness of the context around the content and assume the same holds true when not together; which is not true, and we also miss out on body language, expressions, tone, etc.

On the previous blog a dear friend who's now retired (Dan Turner) reached out to suggest that he wasn't able to capture the value of LoRa deployment which I was trying to convey as it relates to creating data without the complexities of traditional SCADA.  We spoke a bit and he helped me understand that his retirement came just before LoRa and while he understood the context of the SCADA component, he didn't the LoRa, and that my lack of context around the content made the blog a bad read for him.  That said, people that understand LoRa can better understand O&G, but for an O&G person, i didn't help understand LoRa.  Dan's comments led to a re-write of everything before the illustration.  Thanks Dan!

Now, how does all this related to data?  How many times have you seen data look like this?
30264  26356 that means nothing unless you know that the first number is a Modbus register and the second is a raw count.  But if you don't know if it's a 12 or 16 A/D, you still can resolve it.  Even then you'd just have a number, and without an engineering unit of some sort you won't know what it means, even with a unit such as psi, degF, inches, mmcfd,  you'll only know if it is a temperature, pressure, level, flow rate, etc.
You need to know the process variable name at the root level, all the way up to the asset before it can be interpreted and used to make a decision or feed a control loop or analytic application.  Today it might end up looking like bigoilco.scoop.route3.joebob121.gaslift.inputs.flowrate, so that someone can recognize the asset lineage of that point and have some realization of the context around the value.

That is the foundation of our lack of context around SCADA data, especially in a legacy Modbus world.  Luckily technology has evolved us beyond that with some of the proprietary protocols out there as well as things like OPC, and SparkPlugB for those moving into MQTT land.  These cool new toys (or tools) are not only creating context for the data (content), but also providing a strong thread of consistency which lends itself well to massive scalability, and potentially adoption of legacy assets.  By the way, MQTT/SPB is far more efficient with legacy field telemetry networks; more on that subject another day.

But even with this context, there is still more that can be provided through what I can only term metadata, or maybe keywords.  An example I use is around tank level.   If a production tank level goes high, an operator might interpret that as "I'm about to have a mess".  However a production engineer might interpret as "Hmmm, that well never makes that much water, I wonder what changed?".  Same point, but different discipline = different meaning.

I see Walker Reynolds put out some great content on name unification in the process controls space and how they are managing content around this in more of a Industry 4.0 environment. Be sure and check out some of his video content.  He's not only knowledgable, but fairly entertaining as well.

What tools have you found that help provide an intrinsic level of context to content, or application/domain awareness to data so that multiple disciplines can experience maximum utilization?

I look forward to your comments on how you've addressed "contextualization of data",  or any other thoughts/ideas you have on the matter.

This blogs 'about' statement contains "a place to ramble".  It won't disappoint!

Tuesday, May 5, 2020

Mitigating the cost of traditional sensor SCADA data

After interviewing a number of people, across several disciplines, within an O&G operating company as to why they use 3rd parties to deploy process monitoring systems in the field as opposed to using their own SCADA network, the results were hyper-consistent  and astounding.  
This might be a little paraphrased, but not by much..."It's just too much effort to fight my way through the system when I can just pay someone to get it to the cloud, and tell me where to find it".
You'd think there'd be an equivalent of the old easy button, and accomplish this with their existing resources.  Remember those buttons? 

It was about a year after learning that operators, with fantastic SCADA systems we're contracting others to deploy sensors for easily accessible data, that I gained exposure to LoRaWAN, and other LPWAN's for that matter, that would prove to me that there might just be an easy button after all.   
LPWAN is a family of technologies that make up Low Power Wide Area Networks.  LoRa is just one of several, and the LoRA stands for Long Range.  These technologies are being deployed with traditional process transmitters, to get their data to the cloud; could be your cloud, or someone else's cloud.  They can last years on a battery(s) and though the spec says 3-10 miles, we're seeing 18 miles commonly is the flatlands, and 50+ where there is significant elevation change. 

Granted LoRa is not for high speed or super critical data, but more for what you'd consider data of low consequence, yet quite high relevance.  Relevance varies by discipline.  For example, one operator has thousands of chemical tanks that cost a fortune to monitor. Another wanted to monitor gates so that while eating dinner with his family he can have peace knowing that he's not going to be chasing cattle in the morning with a ticked off land owner over his shoulder.  

So what was so bad about getting a data point through SCADA that caused these guys to seek a 3rd party alternative? For the record, I'm not suggesting LPWAN is a replacement for all that's going on below here, its simply an alternate for creating data availability when all that other stuff isn't adding any real value.

To better understand we will step through the traditional data creation model and just quickly identify a few of the realized pain points. 
Here we go...

You see, there is a lot of work, by a lot of people, to create sometimes a point or two of data that is highly relevant to one or two people.  It's almost true to suggest that it is as painful to create one point as it is thirty, and if not super critical, and there's and easier way, why not give it a look?  

Starting at the sensor, someone has to determine what is best, how it'll be powered, what's going to read it, and does it need data-logged.  Then another someone will likely design the panel for an RTU/PLC, regardless of how small, create a design or drawing, send it for fabrication, cables marked, loop checked, scaled, and readied for installation.  The device selected to read that sensor will need programmed or configured at some point.  The communication person will need to be engaged to advise if using radio or cellular, and how it should be addressed.  The SCADA person will need engaged to specify the device network ID, as well as the protocol, or registers, or mapping or whatever so that it can be polled.  Then where it should be displayed in SCADA or made part of the alarm management system. That data will be put into a data-lake or historian of some sort where it can be made available, then connected to business applications where decisions can be made, and finally some value extracted from this very common and painful process.

Edit: much of the above is being mitigated by MQTT and SparkplugB, but that is still SCADA data.  This post is about creating data at the sensor and getting it to the cloud as quickly as possible, generally using MQTT & SPB as the final hop.

Let's now take a look at LPWAN's (low power wide area networks), specifically LoRaWAN (long range).  LoRa operates in the sub-gigahertz bands and provides crazy range (4-10miles LoS, with occasional 13-18mi) with proportionally crazy low power utilization. 
LoRaWAN can be deployed as a public or private network, and the nodes (up to thousands) use a gateway as their cloud connector.  Think of it as a star topology, involving a cloud (could be your cloud, or AWS, Azure, etc.)

The LoRa chipsets that you'd find in a sensor or node, that I'm most familiar with, are from MultiTech and have a ton of onboard connectability for most any type sensor ranging from analog inputs (voltage or current), discrete I/O, serial, I2C, and SPI.  With such flexibility there are battery powered nodes available for connecting almost any device you might encounter, and as mentioned are ridiculously low powered, allowing several years on a battery pack.  
(There's more to power management, battery life, and range/distance of connectivity, but will save that for another day.)

The real save of the LoRa connectivity is that the data can be created at the sensor and communicated to the cloud by way of a gateway where it is made available for consumption.  This could be pumped into a historian or made available by subscription within a broker via MQTT and/or SparkPlugB.

At the end of the day, LoRa is providing sensor based data creation and cloud connectivity that can be deployed at huge cost reduction, potentially even more of a benefit as it could bypass multiple steps of "how quick do you need it?" at each of those impact layers.

We'll dig into some of the specifics in future posts.  Feel free to comment if there's a particular component you'd like to dig into. 

- Ciao! 

Be sure and subscribe for future posts on: 
- LPWAN battery optimization considerations
- M2M via LTE-M and NB-IoT
- Deploying WiFi in Class I Div 1 / Zone1 Explosion Proof locations
- Converting ModbusRTU data points to MQTT with no programming required
- New Class I Div 2 Cellular Router with WiFi, and Serial/Ethernet port server
- Deploying Cellular Routers in Class I Div 1 / Zone1 Explosion Proof locations
- Wireless enabling Serial instrument networks with Bluetooth in CID1 areas
- Considerations for deploying Cisco and Aruba WiFi in Hazardous Locations

Note: LoRaWAN is an open standard owned by Semtech and managed by the LoRa-Alliance.