How did the PI Historian start out?
Our initial goal was to put systems into refineries, paper mills—pretty well any industry. We spotted the need for ‘horizontal’ data management. Vertical applications are great at their specific task—like maintenance, reliability, etc. But data structures are horizontal. This is where PI provides a common base. The upstream has a very large number of suppliers, making it very compelling to have a single ‘discovery point’ for data users.
What exactly is a Historian?
You often hear that a Historian is for ‘real time’ data. I prefer to talk about ‘time series’ data. This could be a monthly meter or an urgent fire alarm—events that may trigger a complex chain of action. We don’t necessarily know what these are. In fact we stay away from applications. But our data capture experience goes back 30 years. In the 1980s an interface to a process control device cost $1 million to develop. Nobody wanted to do it except us! We developed interfaces for just about anything. Once this was done, our clients started getting incredible amounts of this type of data. Today, one turbine today may generate 50,000 points per revolution, with optical pyrometers looking through the walls onto every blade—very important in detecting blade failure. The same pattern can be seen in all industries with more and more data to monitor and historize.
Why can’t you use a RDBMS?
You can’t! Some applications require huge amounts of data for analysis, but you can’t feed SAP with a million events per second! Once data is historized, you can filter it to make it look like a RDBMS, to report aggregate information or feed to Excel. We expose our data with Microsoft’s WebParts so that data can be leveraged by Portals like SAP’s iView or Microsoft SharePoint.
How does this relate to the upstream?
It’s a great fit. Reliability engineering systems let you drill down through data without having to go offshore. BP uses the system to remotely monitor its wells on the Troika platform—PI fuels their modeling effort. In the end, it’s people, not apps, that need the data. Fuel them with the right data and let them do their jobs efficiently.
Do you see a cultural divide between upstream and process control?
There are two degrees of separation. One is between plant floor workers who know SCADA, PLC etc. and the consulting/engineering professionals who look at longer term solutions with reservoir and reliability engineering. The other divide is between IT and process—where convergence and security issues are interesting challenges.
Can you run the plant from a Historian?
Some transmission companies are run from the PI Screen but this is not without risk. It’s unlikely to happen in mission-critical fields like oil and gas but the method is OK for ‘supervisory control.’ It will not replace low level control systems.
What’s OSIsoft’s take on ProdML?
ProdML still needs some more work to make it a ‘maintainable’ standard. We are also very interested in the OPC Universal Architecture which is destined to become the standard for new process naming conventions. It should be possible to ‘pipe’ ProdML up to OPC UA.
Is this a Microsoft only play?
Microsoft has 95% penetration on the plant floor, less in the upstream. But service oriented architecture reduces the importance of the operating system. We work with Microsoft, Linux, Unix, whatever it takes.
More from cdugger@osisoft.com.
© Oil IT Journal - all rights reserved.