Skip navigation
All Places > PI Developers Club > Blog > 2009 > September

Early registration means big savings. Don't miss it. Register now to save $250 on your registration and hotel—and members of OSIsoft vCampus take off $425!


New in 2009, OSIsoft vCampus Live! gives you a chance to get maximum benefit from the technical resources and developer support the online OSIsoft Virtual Campus (vCampus) by meeting your peers and colleagues face to face.


Join us December 1-2, 2009 at the beautiful Palace Hotel in the heart of San Francisco for two full days of an interactive technical experience designed for and shaped by the PI System development community:

  • An under-the-hood look at the PI System and how PI developers work
  • Live, in-person technology roundtables
  • Code reviews and best development practices
  • Networking with peers and OSIsoft developers
  • Deep dives in current and forthcoming technologies
  • Optional hands-on learning labs

Click Here to Register NOW!


Do some specific topics specially interest you? The OSIsoft vCampus technical community can now help shape and define the content of this event. Got an idea? Drop us an email at or just comment online at the OSIsoft vCampus Live blog. We want this to be precisely the event you need it to be.


And…because community input will continue to shape the content, be sure to visit the registration website to check the agenda as it evolves. Also make sure you follow us on twitter for up-to-the-minute news on the event.


So register today and see you in San Francisco in December!

Some of you may have noticed I've been out for a few weeks... well I'm back


As you can imagine, I had (and still have) to catch up on emails and stuff, but you should see me active on the forums and others from now on. As a matter of fact, I just posted the PI ProcessBook 3.2 and PI Server 3.4.380 (WIS) setup kits on the vCampus Download Center. Enjoy!


I'd also like to take this opportunity to remind you 2 things:

  1. We're really hoping to see all technical folks in San Francisco on December 1-3 for the OSIsoft vCampus Live! event - don't forget to visit the related blog and registration website for more information. Also make sure you follow the event team on Twitter and contact them at in case you need more info.
  2. Remember we launched the Community Technology Preview (CTP) for the PI Web Services and PI OPC UA Server products - an exclusive opportunity for vCampus members to try these products out and provide feedback on their design/roadmap. Make sure you visit their respective blogs for more information: here for Web Services and here for OPC UA.


PI ProcessBook 3.2 represents a transitional version of display relativity, where you can build one display and choose the equipment of interest dynamically. New tools for automating the migration of Module Database content to AF are in progress, but have not been released yet. As you consider migrating from existing Module Database-based ProcessBook displays to AF-based ProcessBook displays, note that both the existing Module Relative Display (MRD) add-in as well as the new Element Relative Display (ERD) add-in are provided with version 3.2 of PI ProcessBook. Because both add-ins are installed by default, you may have some questions about how and when to use each add-in. This article is intended to address those anticipated questions.

Use MRD if…

If you have not migrated your existing Module Database to AF, if you have existing displays that you continue to use that were built with the MRD provided with earlier versions of PI ProcessBook, if you use BatchView and want to create new displays with relativity, if you use the DataSheet Control, or if you use IT Overview, then you should use the MRD add-in to select a module of interest for the display or to create or edit new displays.
Note that there are some limitations to creating new MRD displays. If a Module database has been migrated to an AF database, then a new display no longer lists this Module database when selecting Available Modules for a new MRD display. There are no limitations for updating existing MRD displays.

Use ERD if…

If you do not have an existing Module Database or have already migrated it to AF, and have started to use and configure AF, you should (1) remove the MRD add-in using the Add/Remove Programs entry and (2) use the ERD add-in to create, edit and use displays that are element relative (different data appears when a different element is selected from the Elements of Interest list).
Note that the MRD add-in is installed with a separate MSI, so automated software deployment systems can be used to automatically remove it. In addition, the setup.ini file shipped with PI ProcessBook 3.2 specifies that the MRD.msi is included in the installation. If you use automated software deployment systems, you can customize the setup.ini or silent.ini to remove this item from the installation.


Migrating an existing Module Database to AF can be accomplished once the PI Server 3.5 EAM release is available (projected for 2010). This release schedule has an impact on how to decide whether to use the MRD add-in or the ERD add-in. When the Module Database to AF migration tools are released, there will be additional information about how best to implement them.
If you have both existing MRD displays and an AF database you want to use, you should use the MRD add-in to navigate existing MRD displays and you should use the ERD add-in to create new displays. Once you have migrated your Module database using the Asset subsystem in PI Server 3.5, you should (1) remove the MRD add-in using the Add/Remove Programs entry and (2) use the ERD add-in to upgrade the existing MRD displays to use their AF equivalents.


After you migrate a Module Database to AF, that Module Database tree is no longer visible in the user interface for selecting modules in the MRD add-in for new displays as described above. Existing MRD displays continue to work, but there is no user interface to build new ones. For most customers, this is not an issue, since you can remove the MRD add-in, automatically upgrade the existing displays to use ERD and continue building new displays with that way.

Limitations on migrating your Module Database to an AF database

If you use BatchView or the Datasheet Control or the IT Overview add-in for PI ProcessBook, there is an existing dependency on the MRD add-in for creating symbols with relativity that will be addressed in a later PI ProcessBook release. For those customers, migrating the module database to AF will have limitations until the updated BatchView, IT Overview and Datasheet Control functionality is in place. Until then, use the earlier version of PI ProcessBook (3.1) to create new MRD displays once the Module database is migrated. If the module database isn’t migrated, you can continue using the MRD as before.

Migration Validation

You may want to use the existence of the MRD and ERD add-ins to check the status of and verify your Module Database to AF migration (once that is available in PI Server 3.5). This is best accomplished by comparing two displays: one created with the MRD and one created with the ERD, looking at the same assets.

Important Note

Combining ERD and MDB references on the same display is NOT supported, even though there is no mechanism to prevent this. If a display contains both ERD and MRD references and the MRD add-in is removed from the computer, the ERD add-in attempts to convert the MRD references, with potential consequences for the existing ERD references. We strongly advise customers not to combine references on a single display. The PI ProcessBook 3.2 Release Notes explain that this is an unsupported feature.

VBA Implications

Many users have VBA code in displays behind buttons that change the context. An example of this would be code like:


Sub SwitchContexts()
     Dim mrd as ContextHandler


     Set mrd = ThisDisplay.Application.ContextHandlers.Item("Alias")


     mrd.CurrentContext(ThisDisplay) = "\\trenton\MyAssets"
End Sub


PI ProcessBook 3.2 (specifically, the ERD add-in) interprets calls to set the current context for MRD displays and handles them to make at least the simple displays work by providing an AF-equivalent path. This handling is provided when the MRD add-in is no longer present on the system.
More complex VBA scripts that do more than set the current context need to be rewritten to use the new AF-focused ERD add-in.

Make no mistake the folks at NITSL (Nuclear IT Strategic Leadership) are focused on a new renaissance for nuclear energy in the US. Perhaps only the smart grid has more buzz going on right now.


Indeed nuclear energy generation is on the rise. Digital instrumentation, controls and information systems are enabling higher capacity factors and frequently part of reactor power up-rate projects.  Funding to build a new reactor in the US has been secured. With 40% of carbon emissions attributed to power generation, nuclear energy is also benefiting from carbon footprint reduction initiatives.


Security regulations are however a concern.  Physical security solutions alone represent 7-9% of operational budgets.  How much more will it cost to implement and maintain cyber security programs?


In fact, the industry is now faced with dual regulation on cyber security: the NERC CIP standards to protect bulk electric system and new NRC orders that essentially mandate implementation of NIST 800-53 and 800-82 security framework. 


Folks attending the NITSL workshop are well prepared for the road ahead. After all, there really is no margin for error – many in attendance remember where they were for 3 Mile Island (it’s not just the plants are aging ) and fully understand how much is at stake. Perhaps it’s these familiar faces and belief in common goals that, IMHO, makes NITSL one of the most productive industry working groups on cyber security.


NIST 800-82 describes several architectures. The most common and most secure deployment pattern for PI uses replication technology between two or more PI servers.  The idea is to restrict access into the security perimeter while still providing authorized access to plant information on servers located outside the perimeter. Customers in many industries are already doing this today, with PItoPI streaming data into central servers and driving fleet management applications.


The nuclear spin, although not final, involves regulatory guidelines that are expected to prohibit communication inbound to critical networks.  Implementation strategies discussed at NITSL include OSI network layer 1 enforcement devices. 


The approach is an old trick commonly used in the days of RS232. Remember when we would snip the TX lead on the PI end of a Y-cable? This would enable communication eavesdropping but avoid potential glitch of serial handshake (btw…PI-UFL still provides an option for listening to serial com ports).


Of course, Ethernet really changed the world and with it TCP/IP claimed a spot as a reliable protocol fit for industrial service. There lies the rub, the 3 way TCP handshake is fundamental and simply not readily compatible with mechanisms blocking acknowledgement. Furthermore, systems may be highly integrated and depend on bidirectional data flows.


Engineering for uni-directional communication is a hot topic. Bridging plant and corporate PI Servers with such a link is definitely interesting. In addition, the NIST cyber security coordination task group for smart grid standards has already started to characterize interfaces appropriate for uni-directional enforcement.  So there you have it, you might not be able to teach old dogs new tricks… but the young pup can quickly learn those good old tricks!



Posted by jlakumb Sep 10, 2009

If you're monitoring the Engineering Plan on the Tech Support site, you may have noticed that we just announced a new major release - PI OLEDB 4.0. You might have also seen that we removed PI System OLEDB Provider 1.0. It turns out that all we did is combine the existing PI OLEDB 3.3 and the new PI System OLEDB 1.0 into one release called PI OLEDB 4.0.


We are doing this for several reasons:


1. PI OLEDB and PI System OLEDB Providers are complementary and will likely be used together in apps
2. Encourage current PI OLEDB customers to upgrade and use the AF functionality in PI System OLEDB
3. Simplify our product offering (this is a general strategy we are using across the PI infrastructure)


We hope this reduces the activation energy to allow your OLEDB apps to leverage both time-series data in PI with context metadata in AF.


More on aggregates

Posted by smohr Sep 8, 2009

If we added a new method for the return of aggregates, we would not be stuffing the returned values into a series of time series types as we do presently.  Instead, each path requested would receive a rowset consisting of one row per timestamp, and one column for each aggregate requested.  You'll note that would let you retrieve one set of columns for one path and a different set for another path, e.g., min, max, average, and stddev for sinusoid and range and total for cdep158.  You'd have to make a separate roundtrip for aggregates, but you could fine-tune what you get back.


Getting Summaries

Posted by ray Sep 6, 2009

We call these both summaries and aggregates interchangeably. I am talking about the classic OSIsoft set of summaries that you can request for any PI point: average, minimum, maximum, total, range, standard deviation (both types) and mean. To get any of them, you must time interval instead of a single time. When you retrieve any of these summaries, we also give you a "percent good" value which indicates what fraction of the time interval had good data in it.


The current CTP design for getting summaries is admittedly a bit odd. We accept a "columns" argument which is a list of summaries you want. What you get back is a "cross-product" of this list and the Paths. For example, if you request "Average" and "Total" from Paths "sinusoid" and "cdt158," you get 4 summaries back: sinusoid(Average), sinusoid(Total), cdt158(Average) and cdt158(Total). If you've tried it, you will see these "pseudo-Path" strings in the returned data set.


This is less than ideal. We need a better design. One option on the table is to create a separate service for summaries which would return them as a Table instead of  a Timeseries. This way, each column would contain one summary. Each row would contain the summary's timestamp (which in our case is the timestamp at the end of each time interval) and the "percent good" value. The service would return a collection of tables, one for each passed Path.


Let us know what you think.


What about Annotations?

Posted by ray Sep 6, 2009

All events stored by a PI Server can have an annotation associated with them. They are usually strings with some kind of relevant comment about the event, but they can also contain structured data. The majority of events stored in PI Servers have no annotations. Even when they are present, most of our applications don't actually retrieve them unless you ask.


We are struggling with the best way to expose annotations through the PI Web Services. In the current CTP, there is no support for them at all. We are considering these options:

  • Create a separate web service to retrieve annotations. It would likely take the same Context argument as the normal data call. We would have to return timestamp and value as well so you know with which event the annotation is associated. This makes it pretty much the same as the regular data service.
  • Add a nullable annotation object to the TimedValue. This means that any event returned by the normal data call could hold an annotation. We would add an "option code" to the parameter list so that you can tell the service whether you want annotations returned or not.

Whatever choice we make, we will add support for the "status flags" associated with each event. This is a set of booleans that tell you if an event is Questionable, has been Substituted or is Annotated. The last flag means you can find out if an annotation is present without retrieving it.


More on Paths

Posted by smohr Sep 3, 2009

Right now, we have path-context-manner-column as the tuple that locates an item of data.  Let's focus on the first and last (path and column).  To be frank, column grew out of the columns that PI tags return.  Other data sources may not have anything like this.  Would it make more sense to fold "column" into the path syntax for PI points?


Right now, if you provide a list of points (n in number) and a list of columns (m in number), you get n x m results, helpfully labelled "pi:\\server\tag(column)".  If we make the input look like the output, you would no longer have to provide the columns separately and the scheme shrinks to path-context-manner.


The benefits are that you could have a ragged array (e.g., value, max, min, and average for one path and value for another), and future, non-PI sources wouldn't be burdened with a PI-centric concept.  The downside is longer paths.


What do you think?  How would you use the web service?




OSIsoft vCampus Live! Agenda

Posted by JON Sep 1, 2009

Earlier this year I wrote a blog entry explaining our upcoming OSIsoft vCampus Live! 2009 event. Several of you responded with questions about what it will include.  My answer is simple: this is a community event, so if you want to get the most out of it, don’t just attend the event—participate in it! One way to participate is by providing your input on topics. 


It’s only a few months away, so it’s time to start locking in the agenda.  At this time, here are some session topics we’re proposing:

  • In the 'Configuration' Track
    1. Business Value of Software
    2. New Security Model of PI
    3. HA and Virtualization
    4. PI ProcessBook, PI DataLink and PI WebParts
    5. INL Security
  • In the 'Programming' Track
    1. OSIsoft SDKs
    2. PI Web Services Programming
    3. OLEDB/JDBC Data Access
    4. Microsoft Office 2010
    5. Microsoft Silverlight

In addition to creating rich topic sessions we are bringing together for the first time expert-staffed Technology Roundtables and holding extreme code reviews. Both types of sessions will be completely directed by your requests.


The Technology Roundtables will be live, in-person sessions with lead developers, industry experts and product managers on topics most important to you. We think this is a great way to cover a lot of important ground efficiently.


The "Extreme Code Reviews" are explained here. They are an awesome way to help you write great code; every participant benefits from these reviews.  OSIsoft will be contributing to this segment as well—I think we can start by doing an Extreme Review of some of our own code. Plus, we need your participation here as well—this is an opportunity to get a review of your code. You will hear more about how to get us your ideas in very soon.


Please let us know your thoughts and ideas on session topics, roundtables and extreme code reviews. You can email the team directly at: or just comment on this post.


Also, don't forget to follow us on twitter for the latest news and visit the registration site to learn everything about event logistics and to register.

Filter Blog

By date: By tag: