Digitising Industrial Sites: LoRaWAN& WirelessHART

When we take the time to consider which direction industrial sites in the future are moving towards, most people would agree: Facilities, planned around a firm technological foundation, harvesting increasing amounts of data, to create safer and more efficient work environments.

Accordingly, the oil and gas industry realises that they must take their lead from the day-to-day technology that society is increasingly favouring. For years now, people and businesses have been moving from traditionally wired interfaces, preferring the wireless world that has now come to dominate our everyday lives.

Particularly when considering IIoT technology, with increasingly less infrastructure, wireless technology has dramatically reduced the facility’s cost per measuring point. Consequently, increased functionality and limitless applications combined with these reduced costs have seen the tide begin to turn in favour of new technologies as the logical choice. New business cases are becoming almost unarguable even for the most ardent traditionalists.

However, rolling out new wireless networks in such a hazardous and regulated environment requires much expertise and strategy. This white paper will focus on the decision process and considerations when picking the right tool for the right job. And in particular, which wireless protocol to settle on for the digitisation of assets.

When an IT architect plans any new industrial network, particularly in the oil and gas sector, at the top of their priority list will always be reliability and security. Very swiftly following is cost, functionality, and future flexibility. Getting the balance right between these typical determinables is always different depending on a company’s demands and ambitions.

A company must weigh up immediate needs and future ambitions against what’s currently available on the market and then evaluate what these solutions promise for the future. They know a decision has implications possibly for decades into the future.

Increasingly, we see architects forced to decide between the two most prominent wireless protocol technologies that excel in this environment. Both do the same job in simple terms, yet both are born from very different approaches and backgrounds. The two choices being:

WirelessHART: The wireless evolution of HART, the undisputed champion within the sector, having supported Industrial wireless networks since the mid-eighties.

It’s super reliable and essentially bulletproof, but the wireless version lacks the modern demands for scalability and agility. Lastly, it is incredibly costly.

LoRaWAN: A relatively new technology that is slowly becoming the natural choice for wireless networks. LoRaWAN is lightweight, meaning it has low computational complexity. It is scalable and budget friendly, but the methodology makes it less suitable for the small percentage of critical assets.

LoRaWAN is the wireless network embraced by global Network and cloud providers such as IBM, Cisco, and Amazon but, until recently, relatively new to the petrochemical industry. LoRaWAN is agile, has almost unlimited scalability and functionality and serves as the obvious-choice protocol when planning towards a data-driven future. The truth is, neither ideology is wrong, and when employed correctly, both can be highly effective, and at times a combination of methodology serves as the best solution.

So the bigger question is, which system is best suitable for which purpose? How do they differ? And as a facility operator, what questions should one ask when planning facilities for the future?

Two Protocols - A Look behind the Ideologies

At first consideration, LoRaWAN or WirelessHART have much in common. They both appear to have a mutual purpose: To communicate wirelessly to service an industrial network. But delve a little deeper into the conception of each, and you will see the DNA is much different.

HART, initially developed in the mid-eighties, as a multi-vendor and interoperable protocol meaning that any manufacturer can use it for their products should they choose. Since then, HART has established itself as one of the most popular industrial protocols. Today, it operates as the primary, hard-wired, industrial network of many oil and gas facilities worldwide. To widen the wired protocol’s capabilities, in 2004, HART was adapted to work wireless, and accordingly, WirelessHART was introduced to the market.

WirelessHART’s primary purpose was to serve as a convenience to engineers who needed to add network connectivity to assets that sat at an inconvenient position from the network’s primary cabling. With the same level of reliability and protocol as used with the regular wired version of the protocol, HART.

In total contrast, LoRaWAN is a child of IoT, and was always devised to be wireless. It hasn’t been adapted to be so. It was created by IBM in 2015 and specifically designed to serve as the global network architecture to connect battery operated ‘Things’ over a wide area. This is what LoRaWAN signifies – Low Power, Wide Area. The primary purpose of LoRaWAN is to be the backbone of any future Industrial IoT network. It, too, is an open protocol and free for any manufacturer to use.

Understanding Vendor Lock-in

WirelessHART is interoperable, and as such, an open protocol is free for any manufacturer to use, but unfortunately, should you decide to add third-party assets and functionality, this is not easy and very often prohibited.

It is essential to understand that not all HART solutions are compatible. Whilst devices may share a network communication protocol, often we see manufacturers, suppliers, and integrators limit the possible integration of products outside of their family. Physical connection compatibility, network access and DCS control mean a facility is bound by the original vendor when adding smart assets and functionality to a network.

With LoRaWAN, we see the conceptual ideology playing a defining part in the applicational possibilities. The absolute wireless nature of the protocol ensures no vendor lock-in. There is no hardwiring, no specific plugs for connectivity. If your network operates on LoRaWAN, then communication with any third-party device is possible, meaning the only limitation to your network’s functionalities are the devices available on the market.

This ideological freedom is tailor-made towards the conceptual expansion of networks, leaving engineers free to explore limitless IoT possibilities.  Any other certified LoRaWAN developed products are free to integrate, further advancing possible IoT functionality, capability, and overview.

When we narrow our vision to the oil, gas, and chemical industries, it means that a single LoRaWAN network can support IoT strategy long into the future. A facility can potentially have thousands of sensors monitoring every aspect of possible variables in the plant infrastructure.

Moreover, companies can also utilise the network for other purposes, such as equipment location and identification, an onsite vehicles’ battery status, or maybe coordinating of assets.

Technological Comparisons

Frequencies
Similar to Bluetooth and WiFi, WirelessHART operates in the 2.4GHz spectrum, which has some significant advantages. First, it’s great for high bandwidth and capable of transmitting vast amounts of data. Secondly, this communication technology can operate anywhere in the world without any restrictions. This is crucial if your assets are mobile or if an asset with an integrated sensor needs to relocate to another global location.

LoRaWAN relies on ISM bands, which are free to use sub-GHz frequencies. The difficulty is, this can differ depending on which region in the world you need the device to operate. These frequencies are built directly into the firmware of the sensors, so you need to buy the correct sensor for the region. e.g. US / EU / Asia.

A primary advantage of the LoRaWAN band is its enormous range and capacity, with a single gateway able to receive data from up to a couple of kilometres from potentially thousands of sensors. To replicate a similar level of capacity, a WirelessHART network would have to have a hard-wired repeater every 100sq metres or so.

Putting these figures into perspective, to provide adequate wireless coverage to a typical sized oil terminal, say approximately 5sq kilometres, a LoRaWAN network would require only five gateways. Those five gateways account for double redundancy, meaning each location on site has two gateways within range.

WirelessHART works differently. A rollout starts with identifying the sensors’ location and creating a “path” to the nearest gateway. This is achieved by either with sensors working together or adding separate repeaters.

This means that any change or the addition of a new sensor would require a new radio plan. Whereas, LoRaWAN covers the complete site once and is ready for all sensors in the future.

One other significant consideration is how frequencies interact with their physical environment, particularly metal and water. Scientific study shows that these materials work to dampen 2.4 frequency signals, causing a significant performance loss, similar to WIFI in households. Whereas Sub-GHz frequencies, such as LoRaWAN, actually reflect from large metal surfaces resulting in much less signal loss in industrial surroundings.

Understanding the Relevant Topologies
For topology purposes, WirelessHART uses a Mesh network. Clearly put, this means all nodes in the network have the job of both listening to other nearby nodes and then repeating that message, passing it further up the chain until it reaches a master node. Once the master node receives the message, it connects to a server and relays the data.

The upside to this technique is that a message usually is heard and then repeated by more than one node, creating redundancy in the network. And the more nodes you have in the network, the better it works.

The downside to the method is that all nodes act as a repeater and wake to repeat a message throughout the complete network, although a node has nothing new to relay regarding its status. This repetition generates immense overhead in the network as the message scales up at an exponential rate. The limiting factor in volume takes up all available bandwidth and is, at the same extremely power-hungry. Crucially for WirelessHART, this bandwidth limitation constricts the number of devices per gateway.

In contrast, LoRaWAN employs a Star topology,  where all sensors talk with gateways directly and only when it has a new message to send. Traditionally, the downside to Star topology is that each sensor needs to be in direct reach of a gateway, but great leaps of gateway development and sophistication have introduced long-range gateways. As these gateways have a range of over two kilometres, this is not seen as a problem anymore.

A significant upside to Star topology is no overhead or dependancy in the network, ensuring all available bandwidth goes toward functional application data. This means the number of devices and sensors associated with a single gateway is almost unlimited.

Additionally, a sensor only wakes when a state change occurs or for a scheduled heartbeat. The heartbeat is to indicate the device is in good health. Should the heartbeat not happen, the system will notify an operator that there is a sensor down. This limited communication is how LoRaWAN devices achieve such low-power usage.

Reliability
Topology plays a vital role in creating redundancy in a network. While there are downsides to using a Mesh as a network set-up concerning power usage and device limitations, there are certainly upsides to creating near full redundancy.

Firstly, a WirelessHART device has a regular heartbeat, confirming that it is still operational to the DCS. Should the heartbeat not be received, then an alert is immediately triggered. To reinforce the high level of redundancy, the Mesh topology’s repeating nature ensures that this message will find its way home to the DCS.

Low-power usage is crucial in a LoRaWAN setup. To this end, LoRaWAn uses a Star topology; however, this focus on low-power usage has a direct effect on redundancy.

When a device sends a message concerning a change of status, the message is only transmitted once, and if not received by the gateway, then, in theory, you would never know the device sent it.

There are ways of mitigating this. This is done by configuring sensors to stay awake for confirmation. Also, you should always install gateways to overlap. This way, should one gateway miss a message for any reason – maybe interference, then a second gateway should, in theory, catch the message.

Because there is no permanent connection, LoRaWAN devices send a heartbeat to notify the gateway it is still functioning. To keep power usage at a minimum, how often this occurs depends on the device’s importance, and an engineer would set the frequency. Sometimes it’s every few hours, sometimes only once a week. Should the device miss its scheduled heartbeat then an alert is activated.

When a message is missed altogether by all nearby gateways, an alert will be triggered when comparing logs during the scheduled heartbeat. If the device fails to meet the heartbeat – possibly due to a device failure – then any missing logs are reviewed when the device is re-initiated.

It may seem counter-intuitive that a solution based on processing mass data should only require occasional communication. But in this instance, no message is, in fact, an actual message, and as such, data telling the system that all is well. For example, that temperature is within acceptable limits, or that a valve is still closed.

The system operates like any good parent. It doesn’t require a child to keep shouting, “Hello. I’m ok”. It presumes they are well until they say otherwise and only worries when they don’t make contact when they are supposed to.

DCS Integration
The ease of integrating new devices or data streams into an existing DCS is a common topic of debate. When a company has invested in a particular technology in the past, there is a natural want to see it utilised in their future plans. There is often discussion about the difficulties of integration and whether integration issues affect one protocol more than another because of these concerns.

Firstly, WirelessHART integration with an associated DCS should be relatively easy since the vendor would have supplied it. If you want to add the data from WirelessHART sensors to a LoRAWAN based solution, you can simply output the data from the DCS.

LoRaWAN is not quite so simple but almost. If you want to feed LoRaWAN data into a DCS, you can achieve this by simply adding a connector. So the true answer is that DCS cross-integration is a non-issue.

But, looking to the future, the bigger question is, why would a facility want to do that?

Neither solution comes with a default DCS solution because it’s simply not an effective tool to deal with the amount of possible data that a sophisticated network is capable of producing. A DCS effectively monitors a traditional set-up with remote monitoring of essential equipment but is not developed to do analytics.

As the oil and gas industry becomes increasingly sophisticated in data analytics and science, we increasingly see organisations aspiring to have their own data lakes and data platforms with all the tools to crunch and interrogate the information received from all sensors in the field.

A fully operational LoRaWAN network would typically be harvesting data from thousands of sensors.  To perform the powerful data analytics required to achieve machine-learning, data filtering or automate decisions, a facility would have to utilise a purpose-built cloud-based solution or locally host a platform capable of such processing power.

And this is the essence of this white paper. If the previous paragraph sums up a company’s future ambitions, they will require a network capable of hosting many thousands of sensors and devices.  At present, LoRaWAN is the only realistic option available for capability, flexibility and affordability.

Security
As with any network, increased digitisation can raise exposure to new, digital threats. With an oil or gas facility, it’s not only the daily peril of losing valuable and confidential data but also the added danger of losing control of your vital infrastructure, which could result in a potentially catastrophic event.

Thankfully, the addition of most wireless technology will do little to weaken your overall network security. Connection for both LoRaWAN and WirelessHART is fully encrypted and only contains binary data formats that are difficult to de-code.

LoRaWAN messages are at a higher risk of being intercepted due to the much longer signal range. But in reality, the binary data would make little sense to the interceptor, and as such, they could do little with it.  Importantly, firstly it’s crucial to note that a LoRaWAN signal generally travels in one direction  –  from the device to the gateway. Secondly, the LoRaWAN device only records and sends data. They don’t receive commands and, as such, interception would have no control or effect on functionality.

WirelessHART differs from LoRaWAN in that it has communications travelling both to and from the device. Also, some WirelessHART equipment not only records data but also can control the equipment, which does infer a slightly higher risk of someone attempting to maliciously interfere with the apparatus. This risk is low as the relatively short wireless signal range, which would usually mean a hacker would have to be on-site to stand any chance of gaining control of the device.

To protect against the danger of a hacker attempting to replicate the identity of a device in an attempt to send misinformation, then both LoRAWAN and WirelessHART have fully encrypted unique identifiers and date-stamps.

Lastly, for both protocols, there is a possibility that a signal could be meticulously jammed, but if this happens, the gateways would recognise this immediately and an alarm would be triggered.

IoT Fulfilment: Scalability, Planning for the future
When WirelessHART was developed as an extension of the HART network functionality, a fundamental principle at the heart of the protocol was Iceberg automation. That is, you only need to monitor the top 10% of assets – namely, the ones you use the most and those that are most critical.

Twenty years ago, that made sense. It was an equation that covered most safety and efficiency concerns. It was then, and still is, a sound principle that should ensure that no major incidents occur. However, to put that in context, the development of WirelessHART occurred ten years before “IoT” had gone mainstream. Concepts, such as Machine Learning and Data Analytics were still a long way from the boardroom table.

Nowadays, when planning an intelligent facility for the future, having only the first 10% of assets connected doesn’t come remotely close to achieving a sufficient data overview.

Simply put, a WirelessHART network cannot, both practically or economically, achieve a sufficient data overview to use for IoT data analytics; unless a wired HART solution supports the bulk of the network.

Most will agree that it is only a matter of time before all assets will be automated or remotely monitored. Add to these other additional measuring points that can contribute valuable data. These will be sensors based at never-before thought positions that sit well outside the definition of the traditional network.

An excellent example of this would be retrofitting sensors to all manually operated valves on a site. At a large facility, the number of sensors harvesting data could potentially be tens of thousands. Certainly far, far more than 10% of assets.

This is not new news, IT architects have increasingly contemplated integrating these type of super-intelligent systems over the last decade, but financially it was never before viable. The technology was too expensive to justify the expenditure.

Today, things are different; tremendous technological advances coupled with a vastly reduced cost point has brought these systems into the budget. Additionally, the CTO and accountants are now far more aware of the benefits of an advanced I-IoT network that can add to a facility’s efficiency. – Physically and Financially.

Financial Comparison

Previously in this white paper, we have compared the technical merits of LoRaWAN and WirelessHART. This is a relatively straightforward thing to do when comparing like-for-like technological attributes in areas such as functionality, performance, and capacity. However, making financial comparisons is not so easy.

The first thing to note is that they are literally very different solutions. It’s only at the ends of their functional spectrum do they attempt to plug the same hole in terms of applicability.

And while it’s true to say there are particular scenarios that both could be installed to fulfil specific use-cases, the fact is this potential overlap is minimal.

Outside of this, it’s about buying the right tool for the job. And this makes it very different to make financial comparisons.

An excellent example of this ‘overlap’ could be a facility with an existing HART network that wants to add functionality to a further tens of assets – Assets previously considered out of reach. Both solutions would serve to satisfy the need. Both would provide the required connectivity. And both would cost a similar amount to install after you factor in the installation cost of the new LoRaWAN network against the higher price-point of the WirelessHART devices.

So, in this example, we have a dead heat. There is very little to choose between the two solutions, although it would probably be more logical to stick with the HART-based solution.

However, if we consider the economies of scale and begin to factor in any additional devices, WirelessHART will rapidly reach a tipping point where convenience is far outweighed by financial outlay. With the cost of LoRaWAN devices being a tenth of a WirelessHART, this mounting cost quickly escalates.

So, again it must come down to future intentions and ambitions. If the intention was to stop network expansion after the initial ten new devices, then installing a new LoRaWAN network, gateways and sensors would be pointless.

Alternatively, if this was just the beginning of a larger IoT vision, expanding the existing HART network with increasingly WirelessHART devices would seem not only illogical but financially unviable.

Should a facility have no pre-existing HART network in place and aspires to create a network to incorporate only tens of assets initially, but with the potential to add hundreds or even thousands of assets, this can be attained most cost-efficiently setting up a LoRaWAN solution.

Square

Conclusion

Technological advances change what is possible
Over a couple of decades, we have seen an increasing amount of wireless equipment become available for use in the oil and gas industry. Those designed before the conception of IoT were primarily developed to support hardwired systems. They offered additional capability or better accessibility, but at a high cost.

Not only are these costly to purchase and install, but they also lock the customer into that technology choice. Functionality and flexibility are limited by vendor lock-in, which prohibits engineers from integrating any 3rd party equipment.

Over the last couple of years, significant advances have meant that wireless has to be viewed seriously, no longer in a supporting role, but as the base protocol technology behind future industrial networks.

Past methodology and ideology limits insight
Traditionally, the industry has believed that efficient and safe monitoring can be maintained by focusing on the first 10% of assets. That is, the first 10% of infrastructure deemed most critical or essential. This ethos has guided technical development over the past half-century, with successive roll-outs of increasingly advanced solutions that still only focused on this 10%.

But these systems only view the device singularly, not as a part of a larger ecosystem. On a single piece of equipment, the micro-level of sophistication can be high. But at a macro-level, the pure understanding of the facility as a single entity is very low.

Most industry professionals agree that future facilities will lean towards achieving a high level of IoT awareness and capability. We already see new facilities designed and existing ones adapted to incorporate a vast array of devices and sensors to monitor every aspect of a refinery. Achieving closer to the 90% – not the 10%.

If we were to imagine and extrapolate the full potential of a LoRAWAN network at a facility. It would consist of tens of thousands of sensors, each designed to satisfy a specific need or supply a particular data point. When combined with an engineer’s experience and knowledge, this provides them with a complete neural overview and acts as a tool to see the facility as a living, breathing entity.

In our Opinion
Ultimately, the decision on which protocol to choose depends on the IT architects and CTO involved. They need to think about not only the immediate goals and the imminent needs of the facility but also any ambitions and visions for the future.

Should they decide to monitor only the top 10% of assets, then being honest, most solutions, including either WirelessHART or LoRaWAN, could adequately fulfil this role.

However, should our IT Architect and CTO have aspirations to create a more comprehensive and flexible network that leans towards an I-IoT orientated future, they will have to venture far beyond the 10% indeed. And, at present, to fulfil these ambitions, LoRaWAN is the only realistic choice; with increasingly more IECEx / ATEX certified sensors and devices available, it has the scalability to include every possible measuring point across an entire site.

There is an excellent argument to operate two networks in parallel for those existing facilities that have already invested in solutions to monitor the first 10% or plan new facilities with a slower transition of technology and methodology.

The first network, possibly HART or similar, ensures the first 10% are hardwired, fed to a visual control room, and managed traditionally. The second network, being LoRaWAN, provides connectivity to the remaining 90% and incorporates the first 10% harvested data from the primary network. A more costly solution but one that would satisfy even the most passionate progressives and traditionalists.

The above scenario is an excellent example of how an IT architect, CEO, or Engineer should view LoRaWAN. It’s a new tool in the toolbox. It’s not developed to replace any other tool.

For the CTO and IT Architect, it’s a tool to plan for the future while making existing systems more intelligent and efficient.

For the CFO and Accountants, it’s a tool to make a facility more productive, save costs, explore new revenue opportunities, and be viewed by their customers as effective and future thinking.

For the Engineer, it’s a tool to give unparalleled insight and ultimately make their job easier.

And for the CEO, it’s all of the above and, lastly, a tool to help ensure that their company is relevant and positioned for the future.

Square