PI Web Service Benefits

Security

In 2004 a well-publicised incident occurred where an industrial control system experienced a loss-of-view when the control system interfaces were attacked by a fast-replicating worm coming in via the intranet. Whilst a firewall had been put in place to protect the user stations from such an incident, it had been weakened over time by numerous holes configured to provide engineers with access to process data, typically for spreadsheets. The worm exploited one of those after infecting an engineer’s machine.

A more effective and intrinsically-safe architecture would have had a single machine acting as a proxy for all data requests.  The PI Service works in this way as all data requests are made to a web server which is normally heavily-secured under the control of an IT infrastructure group. The firewall can then be locked down so that only this one machine can access the historian directly.

Accessibility

People and applications can obtain data from a web service via TCP port 80, rather than the native PI port 5450 which is unlikely to be open all the way from an arbitrary user desktop to a centralised historian in a global intranet.

In addition, the tools required to access current and historical PI data via the PI Service are already present on every Windows desktop. No extra client-side software or licences are required. Internet Explorer can be used for ad-hoc, interactive queries, and the standard operating system tools can provide easy, programmatic access from Excel, Visual Basic, even shell scripts.

Speed

The PI Service is optimised for blistering performance in a demanding environment. Requests are serviced in parallel over cached connections for minimum latency. Snapshot requests typically return in under 10 milliseconds and sustained loads of 300 requests per second are quite normal even on 2001/2002 hardware.

Developers can further boost the perceived speed of their applications by virtue of moving to a web-service-based data-access tool. Using web services, developers can use asynchronous requests with ease. So even if a lengthy history request takes 1000ms or more, a developer can run it in the background while servicing the user interface instantaneously, for even snappier-feeling applications.

Real industrial-strength: If your applications typically require many megabytes of historical data in a single request then streaming is crucial. Simply put, this allows the server to emit data onto the wire whilst the remainder of the document is still being constructed. It is subtly different from asynchronicity discussed above, but very important to industrial-scale applications.  It is principally important to the server, as it avoids buffering up many megabytes of data in server memory, causing performance problems or even memory exhaustion. Of course client side applications can also take advantage of streaming, as they don’t have to wait for a large document to arrive in it’s entirety before they start work on it.

Manageability

The desktop software manifest can be simplified as no client software (e.g. DataLink) needs to be installed. Support issues are centralised. Upgrades are simplified, as only one piece of software needs to be touched instead of having to plan costly, pan-enterprise rollouts.

Generalist IT skills are sufficient to administer the PI Service at one central location. There is one web-based management interface, one log file, and one set of real-time debugging flags for troubleshooting.

Re-usability

While a dedicated application developer can usually get data out of PI with a one-off application, this effort is usually duplicated on the second and subsequent applications. However, attempts at moving to a re-usable architecture frequently founder on real-world issues of performance, connection management and multi-threading, to name but a few.

In addition, a heavily-automated environment will frequently require PI connectivity from applications such as Oracle (PL/SQL), bespoke web applications (ASP, ASP.NET, Java) or standalone applications (C#, Delphi, C++, VB). Such a variety of technologies frequently involves a multiplicity of developers and developer preferences.  This is an obstacle to re-use - an Oracle PL/SQL object written to encapsulate PI requests is not usefully re-usable in Excel

With the PI Service, making a request is as simple as invoking a URL. Data is returned as an easily-comprehensible XML document in a consistent, unchanging format. All platforms (Oracle PL/SQL, Excel VBA, .NET, etc) have native mechanisms to request and parse XML, and the format doesn’t change from one platform to another.

This last point is important: the move away from re-use of executable objects (e.g. COM, CORBA) toward re-usable documents and document formats. This fundamental insight is one of the key drivers of the web service revolution around the world.