OSisoft webinar slides

Editor's Notes

• #5: Data is critical to understand what it takes to deliver operational efficiency Through data we can deliver continuous improvement and grow the organization Along with people, data is one of your most value assets to deliver on operations and business objectives When we think about some of the primary goals in an organization, data is key to delivering Process efficiency Energy and resource efficiency Asset health, maintenance and reliability Safety and security Quality Regulatory compliance and enablement Barriers to meeting these goals is typically data: Lack data insights for continual process improvements Lack data insights into historical and real-time data for asset management Lack data insights into resource consumption, loss and waste management Lack data insights for product quality issues and improvements Silo’d, inconsistent data and manual reporting challenges Lack real-time insight into health, safety and security risk areas
• #9: Intention of the Slide: To set up the ‘agenda’ of the following slides The audience gets that even though the various PI products the speaker is about to cover have distinct responsibilities, they all operate as part of one system. Narration: Okay so now will get into the individual pieces of the PI System - the individual pieces of software that have names that you might've heard like ‘PI Server’ or ‘PI Coresight’. The three layers I mentioned: there is a layer that collects information, there's a layer that manages that information, stores and enhances it, and there's an layer that is responsible for delivering that information. Any of our products falls into one of these three categories - and they all are part of one system and they all work together
• #11: Intention of this slide Leave the audience trusting the PI System can connect to THEIR operational data, The audience values choosing a software vendor that has no preference for what data is brought in (like OSIsoft) Why? We’ve been at it for over thirty years (thus we have a long library of interfaces, including old technologies no one would write new interfaces for today) We’re agnostic (We are enthusiastic about reading ANY data you use. we have no preferences for what data you bring in, unlike historians that come with control systems) We’re global-sized (We are big enough to support the engineering group required to develop and support this many interfaces) Narration: (start with referencing the homework you did) So in talking to you earlier I asked what source of data you connect with, and how you connect with X and Y systems. One of the main strengths of the PI System is that it connects to any source of data out there – and it's built to natively read from over 300 industrial automation standards and systems. (note: we’re using the 300 figure here to align with the number of active interfaces we have. 450+ is often quoted, that number refers to the total number of interfaces OSIsoft has ever written. Some of those are inactive) Often our customers have one control system and maybe a secondary control system somewhere else, then a different plant or simply some data that they have to manually get to that is in a difficult to get to takes a lot of time. [first animation] What if you could take all the data and automatically pull it into one system? Even if that equipment was installed decades ago, or you still needed to manually record it, it could immediately go into that one system. Then looked at side-by-side with all the other data without having to deal with going over here to this system to get data, then going over here to that system to get data? Data set is all in one place. OSIsoft produces a whole family of ‘PI Interfaces’ as we call them: a PI Interface is a piece of software that connects to a specific source of data. This could be a control system, it could be a certain industrial automation standard, it could be another type of historian for data! We've written interfaces to connect to many, many, many of them so whatever data you have out there can be put into the PI System. In the end the PI System and provides pervasive conductivity. Like how the roots of the tree can pervasively go through the ground and get everywhere, the roots of the PI System can reach to any source of data and get it back to the PI System. Notes to the account manager: What you say is really going to be customized to the type of data that this customer is dealing with. Interfaces can take data that is a slow drip, all the way up to performance that is needed to monitor the stability of the electric grid. That’s 60 reads a sec – over a wide distributed geography. Most customers never will use that – yet it gives you a sense of the quality of these interfaces. Some customers are really concerned with the rate at which data can be read - maybe phasor data or some other really high rate data – and they're concerned if your system can keep up with it. In that case, during the section you should highlight the performance of our interfaces. That they can really take high speed data. Some customers are concerned that can you collect the number of data streams that I need to consume? In which case, highlight that we have interfaces that collect data for utility customers that span over wide geographies with millions of data points coming in nonstop. Or maybe this customer has just one source of data, coming at a moderate speed. In which case maybe want to highlight that ‘we have you covered on that one source - and when you get new source of data in the future, you can trust the PI System will bring it in without an expensive custom integration project.
• #15: Here is an architecture for the systems that are typically found inside a datacenter. These systems include the: BMS for mechanical data EPMS for electrical power data DCIM for IT data Facility Systems (Environment, weather station, Utility meters, Security Systems) The PI System has over 400 interfaces to talk to a wide range of equipment and devices. These interfaces include the standard interface protocols that are commonly used inside the datacenter. Such as: BACnet SNMP Modbus DNP IPMI Relation database interface XML and a REST interface to communicate to web services If you have an electrical or mechanical system that does not support providing data to a third party systems, in most cases we can configure the system to talk directly to the devices such as CRAC’s, switchgear, metering, RPP’s and even PDU strips. We also have experience working with systems that are not on a common network. For these situations we will work directly with your networking team to develop an architecture that will provide not only the data the we need, but also maintain the security that you demand. Another common issue that we see is when there are devices that have been added to the facility such as RPP’s or additional racks with PDU strips, but they were never tied back into EPMS. For these situations we can communicate directly to the device and again make it look like it was integrated into the main system again as a single pane of glass. The trickier devices to bring into this solution are devices that do not have a communication adapter to provide data remotely. Sometimes this is done on purpose to save upfront costs by purchasing equipment with out a communication adapter then only to find out down the road that yeah it would be really helpful I you could get information from the set of gear or device. We have relationships with many of the key vendors that supply data center equipment and can find out exactly what it will take to monitor it. We even work with data centers that may not have a BMS and or EPMS, for these systems again we go directly to the devices to collect the data.
• #16: Now that we know all of the equipment and devices that are being monitored, the focus shifts to the analytics. Analytics start at the device level. Each type of device has a predefined list of analytics that are associated with it. Of course these analytics can be expanded at anytime. You can see here on the left a sampling of the analytics based on the device type. Alaytics are also performed at the facility level where the analytics are defined based on the system for example electrical system Mechanical system level analytics. If you look at the sample mechanical analytics, these are defined for a data center that utilizes a central chilled water system. If the DC did not have a central chilled water system the analytics would be focused on the rolled up calculations based on the CRAC units such as Total Thermal load.
• #17: Template Based KPI’s Facility Level Power Mechanical Facility Environment Device CRACH PDU’s Rack …. Alarming: Monitor of Monitors (MoM) approach Configure alarms that have affects at the facility level Duplicate only critical system level alarms Alarms can be complex (if temp >80 & fan is on for 15 minutes) then alarm
• #18: Now let me describe how a single device, this PDU Strip, becomes integrated into the single pane of glass. Here we are looking at a smart PDU strip whether the source of this data is from the electrical system or by a direct connection, that doesn’t matter anymore because it is now part of the single pane of glass solution. Here we are collecting real-time data at the strip level and also down to each individual outlet. As shown in the demo this information can be complimented with rack asset specific data from a DCIM product or any other source that contains the asset information about the servers or devices that is connected to each outlet. The system takes all of this information and applies the analytics to the PDU Strip, a Rack and rolls the analytics up to an group of racks in an aisle or in the case of a colo a group of racks. Finally these results are rolled up to the facility level. All of this information is then delivered to the user through the state of the art visualization showing executive, Operations with device level real-time displays and on the IT side rack distribution displays for power optimization and thermal displays including rack details displays showing servers that are over utilized or have stranded capacity. Alarming: Monitor of Monitors (MoM) approach Configure alarms that have affects at the facility level Duplicate only critical system level alarms Alarms can be complex (if temp >80 & fan is on for 15 minutes) then alarm