Using PI Interface output points to directly manipulate control system end points is strongly discouraged and carries risks. Here are a few:
- There may be other architectural layers between the PI System and the control system, which all could have modes of failure that modify the way the data is sent to the control system. This poses risks to data integrity and security.
- Control systems are usually hardware-based, and therefore they have embedded code which is designed for a very different purpose than the PI System. One explicit example of this is that OSIsoft software does not guarantee delivery of the data (which is crucial). Furthermore, data must get to the control system within a specified amount of time, for example 40 milliseconds, which is at the risk of being delayed due to things like Issue 1.
- Having data written to a control system that does not originate from a system with its own embedded code could be considered a security breach. In general, you do not want external writing data that could affect crucial systems.
Ways to reduce risk
Having the control system "pull" from a dedicated PI Data Archive is a safer architecture. In this case, the control system should validate any inputs before use (for example: limit checks, validating timestamps, checking for out-of-order data, validating operator permissions).
If data exchange with a control system has business value, it is advisable to monitor the service level assurance of such a feature (for example: deterministic heartbeats, handshake, clock drift).
Most control systems support access to data from external sources in a number of ways. For example, the control system may include OEM versions of the PI System, interoperability with 3rd party OPC Servers, or drivers for SQL-compliant databases. PI System Data Access or other components may be required to implement a 'pull' solution.
OSIsoft is starting to offer "read-only" versions of interfaces in addition to the existing "full" read-write versions of interfaces with output PI Point functionality. Read-only versions can be implemented as an inherently safer technology that simplifies compliance with security policy. Read the FAQ about read-only and read-write interfaces
in the Interfaces and Connectors documentation.
OSIsoft also plans to enhance security capability of existing interfaces with output PI Point functionality. Specifically, newer versions of UNIINT 4.6-based interfaces can enforce a "white list" for interface output tags and values to control which tags are allowed to write outputs. The white list addresses some of the known threats in sending PI data to control systems; however, the white list is not a substitute for properly-constructed control system defenses.