The allure of the Industrial Internet of Things is the promise of making systems work better based on connected data through the internet. Data can come from a sensor, a web server, a web service, another device, such as a mobile phone. Really any electronic device which can receive/send data through the internet is a possible source of data.
In industrial automation applications, web services are often used to interface to external systems like databases or other electronic systems and services. A simple example of a web service might be one that exposes the current temperature for a given zip code. To make the web service work, a SCADA or HMI programmer would have typically (in the past) written code in such a way as to “ask” the web service what the temperature was by calling the correct part of the code and sending a zip code to the web service. This is often accomplished in an Applications Programming Interface (API) or a sort of blue print as to how to use the web service. The web service would respond with what the temperature was – much like if you were to ask someone “what is the temperature in Miami today”, but the web service would do so by responding in an electronic format. A manufacturing example of that same web service comes to mind. What if the quality standards for certain products require strict environmental control? You could use this web service to raise or lower the temperature in your production or warehouse environment based on the external temperature or humidity.
Imagine an alternative energy provider that makes money by co-generating electricity. They would want to know the optimal times to run their equipment when the price of electricity was at its peak – a web service could be used to answer that question.
There are many “buzz” words around how programmers can interact with web services such as : XML, JSON, REST, SOAP, etc. They all require programming knowledge and must be maintained over time (sometimes the web service itself may be updated or changed – which would require your code to be modified). The simple problem is that, let’s face it, we are not all web programmers – our job is to get product out the door in a reliable, consistent, and profitable manner. Why spend a bunch of time and energy writing and maintaining custom code just to call a web service? The answer is, you don’t have too.
Wonderware’s NEW Web Services Gateway (OI Server) eliminates the need to write custom code to interact with web services. This product was developed with the process engineer, not the coder, in mind. The driver communicates using standard Wonderware (Suitelink) protocols to users wishing to access data from a web service – almost as if it were a PLC. Imagine instead of writing custom code you would be configuring a driver to communicate to a PLC, but instead of it being a PLC, it is a web service. The Web Services Gateway is configured just like any other Wonderware communications driver, and instead of custom code, it is doing the heavy lifting to communicate to the web service – the driver does all the work! This lowers the barrier of entry to an organization wishing to utilize all the IIOT web services that are available out there for a variety of needs.
A simple google search reveals lots of free and useful web services that can be utilized for doing things like sending email or SMS, statistical tools for analyzing data sets, databases, pricing and inventory management applications or even as simple as the get the temperature app.
Now the power of IIOT and Webservices are truly in our hands.
To see how to configure the Wonderware Web Services gateway in a matter of minutes, click here.