Over the last twelve months, we have consulted on many IIoT projects for industrial companies across the U.S. These companies have varied from value-added distributors to systems integrators to end users. During the discussions it has been interesting to note the reactions to the inclusion of IIoT in the application. One of the most common reactions forms the basis of this article. It goes something like this.
After discussing specific needs there would come a point in the conversation where we would mention remote monitoring and control of assets, to which the typical response would be: “But we’re already doing this with our scada systems, what’s the difference?”
This is an excellent question and the best way to answer is by comparing the two approaches.*
Wastewater application in Florida
For our comparison, let’s use a recent application in the wastewater industry which includes the remote monitoring and control of a large water filtering station for irrigation in the Florida region.
An RTU has been programmed to monitor and control the filtration system and by measuring the differential pressure across the filters, the RTU automatically performs a backflush of the filters when required. The RTU also monitors the flow rate and total flow of water, and from this information one can determine the general health of the system.
Occasionally, the unit in the field will trip and stop working. The customer then has to send a technician to the site – a drive of around three hours. When the technician arrives, quite often the only action required is to reset the system, as most of the time this clears the fault.
But what the customer really wants to know is why the system tripped in the first place, and how necessary was it to dispatch a technician to the site. If a technician was not required, could the system be reset remotely?
These questions can be only answered by looking at the data from the sensors before and after the trip event.
Comparison of approaches
Using a traditional approach, a scada system would be installed to receive this data. As the system is usually deployed on hardware at the customer’s premises, the following would be considered:
• What level of reliability is required?
• Should it be running on server grade devices?
• Should a backup power system also be installed?
• How much will this cost in capital and maintenance?
• Who will manage this system?
Once these questions have been answered, the scada application can be built. It will of course require a data historian, the setting up of a mimic, and possibly an add-on package to deal with the telemetry aspect.
During the building of the system, security must also be addressed. The industry standard approach to this is to add a VPN connection between the scada computer and the RTU in the field. This requires using a cellular router that has the capability to both perform the VPN function and to open a port in firewalls and connect to a DNS. Once the VPN is set up, the scada can be set to run mode and will begin polling the RTU in the field.
In the IIoT approach, the first consideration is the choice of cloud platform provider. This is an important first step as not all cloud providers are created equal – it should be considered as important as selecting the correct hardware.
In this example let us choose the Xively platform as it has a powerful CPM (connected product management) feature that allows organisation of products in domains and sub domains. The importance of this will become clear later.
A typical IIoT system uses a broker in the cloud. I have chosen to use an MQTT broker as it is available in most cloud systems. Coupled with this is the Define Instruments Zen IoT RTU. The difference between this and the traditional RTU is that it is set up to deliver messages to thecloud broker using MQTT. It uses a publish and subscribe model: the Zen IoT RTU will publish information like pressure and flow rate to the broker, and subscribe to a control topic. Control topics are used to perform tasks such as turning on a relay in the RTU.
The other major difference is that the Zen IoT RTU itself makes the connection to the broker and it does so in a secure mode using TLS and certificates. This eliminates all the issues related to setting up VPNs, DNS and firewalls. The only information that has to be provisioned in the IIoT RTU is the username and password associated with the cloud account.
The information is now sitting in the cloud and in this location it is available to the humans and devices that have permission to access it. The cloud platform enables this by providing a rich set of APIs, rules-based engines and standard interfaces to CRMs and ERPs.
For this application a dashboard is required to visualise the data. There are third-party dashboards available, but in this instance a webpage was created to visualise the data using the REST API. This is akin to setting up the mimic in the traditional scada system.
So at this stage in our comparison, the IIoT approach is the simpler of the two to setup for a secure application, and one it also avoids the headaches of server-side hardware. You do however have to pay a monthly subscription to the cloud provider (around $1 per month for this application).
The post-installation scenario
After a few months of using the system the customer comes back and says: “Operation is great! So great in fact that I want to roll it out to monitor the 400+ filtration systems I have throughout the country. And I have some changes…”
The customer explains his clients would like to:
• See how much water they have been using.
• See how much wastewater was lost.
• Manually turn the system on and off by logging in to a website.
• Know when the pump has completed 1000 working hours to schedule maintenance, and be alerted via CRM at the 800 working hours mark.
Lastly, he leaves this juicy tidbit: “I was recently speaking to a pump manufacturer and he asked if we could share with him some of the pump data so he could use it to improve his product. I don’t see any reason why not…”
The IIoT solution provider can confidently accommodate these requests. He knows that his cloud partner already provides CRM alerts as a feature; he also knows the CPM system is another feature already in place to provide different permissions to different users.
All the IIoT solution provider has to do is:
• Make two new dashboards.
• Create accounts for the new users.
• Provision these credentials into the Zen IoT RTUs.
But where does the engineer come in? In actuality, an engineer isn’t required at all in the commissioning of the sites as an electrician can wire up the units in the field.
After wiring, the electrician isn’t required to do much more, just turn them on, run through an automated test setup and ensure any issues are sent as alerts directly to their cellphone (the last part requires a little more work – but just a little).
Employing the IIoT approach, the customer’s requests are easy to implement and it is smiles all round.
In the case of the scada system supplier faced with these requests from the customer, questions like the following arise:
• Will the server require an upgrade?
• If so, how much will that cost?
• With 400+ VPNs concurrently talking to the field devices, can the scada system handle it?
• How will all the permissions be managed to allow 400+ users to get information on the site.
In this case, the IIoT system wins hands down when faced with such scaling issue. Not only that, but the capital and development costs for IIoT are less; as are the costs of expert professional help from engineers and IT specialists.
Conclusion
This application could just be the start of this customer’s IIoT journey. For example, the information obtained from the systems over time could be useful for improving the design, as well as determining the real maintenance and running costs associated with such a system.
Armed with this knowledge, a new business model could be evolved: offering a maintenance agreement based on the water pumped, for example, or partnering with a finance company to offer a pay-as-you-go service so clients are only billed for the actual water pumped.
In this scenario, the benefits of implementing an IIoT solution over a traditional scada system go beyond the immediate wins of cost, timeline and required expertise. It is also highly scalable and adaptable to customer needs in the future. Anything that gives such a level of security, peace of mind and readiness for what might be over the horizon is an undeniable asset to business.
* The assumption is that both approaches require a highly secure solution.
For more information contact Charlene Oroschin, Define Instruments, +27 (0)83 384 9186, charlene@defineinstruments.co.za, www.defineinstruments.co.za
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version