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

In our previous blog post we talked about the CTP release of PI OPC UA Server.  We also had a vCampus webinar dedicated to OPC UA.  During that webinar we showed a simple OPC UA client that can be built with only several lines of code.  In this blog post, we will go through that code and explain how it works.  The client uses OPC UA assemblies (Opc.Ua.Core.dll and Opc.Ua.Client.dll) that implement OPC UA communication stack, client API classes, and helper classes.  Since it’s a simple client, it’s built to do very basic things, such as connecting to the OPC UA server, reading the value of a known node (e.g. PI point) and disconnecting from the server.  We will use the PI OPC UA Server as a target server.  A Visual Studio 2008 solution for this client is attached. 

  • Connecting to PI OPC UA Server

To establish a connection between an OPC UA client and an OPC UA server, we must create a secure channel in the communication layer. This is a logical channel that is needed to ensure confidentiality and integrity of a message exchange between two applications.  Once the secure channel has been established, we need to create and activate a session between client and server.  The session allows us to call services provided by an OPC UA server.  In Step 1, we pass the URL of the PI OPC UA Server to the CreateSession() helper method to establish the secure channel, and then create and activate the session.


// Step 1 -- Connect to UA server


string discoveryUrl = "";




Session mySession = ClientUtils.CreateSession(discoveryUrl, "OSIsoft.UA.ConsoleClientDemo"); 

  • Read Value

After the session is created, we can try calling different OPC UA services provided by PI OPC UA Server.  One of the basic services is Read Service.  It can be used to read values of OPC UA nodes.  Step 2 shows how the service can be called using Session object.  In order to make this call we have to pass a NodeId.  NodeIds are represented by a string containing a browse path of AF element or attribute.  The PI OPC UA Server has several nodes that are mapped to PI points.  Let’s choose one of them.   


// Step 2 -- Read the value of a node representing a PI Point data under the hood

NodeId nodeToRead = new NodeId(@"\\jmaytumwin2k8\intense3000\osisoft\piservers\jmaytumwin2k8\intense0001|value", 3);

DataValue value = mySession.ReadValue(nodeToRead); 


Console.WriteLine("\nRead: Current value of intense0001 = {0}, status = {1} \n", value.Value, value.StatusCode); 



  • Clean Up

Step  3 - Close the current session


// Step 3 -- Clean up

mySession.Close ();

Okay, we showed you how to write a simple OPC UA client in three easy steps.  It's important to note that by using OPC UA assemblies, we didn't have to implement complex web service communication mechanism.  All of that has been abstracted from us by the client API.  In the upcoming blog posts we will show you how to use other OPC UA services and implement more advanced functionality. Please let us know if you have any questions and we will be happy to provide you with more details.  Thanks for reading and happy coding!

As you may have read already, we are going to have Technology Roundtables at our OSIsoft vCampus Live! event (San Francisco, December 1-2). This is a unique opportunity to share with peers and meet in-person with the OSIsoft development taskforce (Product Managers, Developers, etc.).


Now the question is: what do YOU want to talk about? Simply take a few moments to complete this survey to make sure we cover the topics you'd like to discuss at these roundtables.


Make sure check out the exciting agenda lined up for the event (and obviously don't forget to register for the event)


New on OSIsoft vCampus Team

Posted by hanyong Employee Oct 20, 2009

I am new on the OSIsoft vCampus Team, based out of OSIsoft Asia, in the small island city of Singapore.


This is my 4th year with OSIsoft, where I spent my last 3 years in Field Service and Tech Support in the AsiaPac region, mostly China. What I enjoyed in these years is working customers/integrators and helping them to find means and ways to fulfill their requirements as much as possible. I joined OSIsoft fresh out of college, graduating as a Computer Engineer.


In my own experiences, I would say that OSIsoft Techsupport structure is doing a great job in providing users information and assistance about PI products and technologies, but given the nature of a technical support team, transfer of knowledge does not necessary spread out among the users. I like the concept of OSIsoft vCampus for encouraging more information sharing not just from OSIsoft to users and among users, and I am happy to be part of this initiative.   


I'll be using this space to share some of my thoughts and learnings about PI development and integration, and you will probably see more of my postings in the forum as well =)







Writing a custom delivery channel is the most popular way of programmatically extending PI Notifications; but debugging these plug-ins can be a bit tricky.  Two common problems are 1) not running the same version of the plug-in that is loaded in Visual Studio and 2) not having remote debugging configured.


To ensure you are running the correct version, it is important to understand how the plug-ins are loaded.  When a process using the AFSDK requires a plug-in, the AFSDK downloads the version registered on the current AF server.  This version of the plug-in is loaded for the life of the process.  So if a new plug-in (or new version of a plug-in) is registered on the AF server, any running process will need to be restarted to load & use it.  Thus a running PI Notifications Service or PI System Explorer will need to be restarted to get the new plug-in.


In the early stages of developing a delivery channel, most debugging can be done with a simple test harness.  This might be a command line tool that accesses properties or a simple form that loads a UI control.  The Test() method can be tested and debugged this way, too.  When you are further along, you can test the UI elements in the PI System Explorer (PSE) by registering your plug-in with AF and (re)starting PSE.  Then you can use the Visual Studio "Attach to Process" feature (under the Debug menu) and select the "AFExplorer.exe" process.  If you don't have PSE installed on your development machine, you will need to use remote debugging.


If the PI Notifications Service runs locally on the development machine, simply set the service to run under your user account, then attach to it as described previously for PSE.  If you are running remotely, you will need to install the Visual Studio Remote Debugger on the machine running PI Notifications Service.  When you have a new build of your delivery channel, you will need to:


1.       register the new plug-in dll on the AF Server with regplugin


2.       copy the debug symbols (the pdb file generated with the dll) into C:\WINDOWS\Symbols\dll on the PI Notifications machine


3.       (re)start the PI Notifications service


I use a batch file that performs these steps to save time.  When all that is done and you want to debug the Send() method:


On the machine running the PI Notifications Service:


1.       run the Visual Studio Remote Debugger (you might need to delegate permissions to the account running Visual Studio depending on your security setup)


On the development machine:


2.       run "Attach to Process" in Visual Studio in the Debug menu


3.       in the "Qualifier" field, select Browse


4.       in the pop-up you should find the PI Notifications Service machine running the Remote Debugger


5.       select OK, then find "PIAnalyticsProcessor.exe" in the Process list and click Attach


If all goes well, the debugging symbols will be loaded and you will be able to set breakpoints that will be hit when a notification is triggered.


PI OLEDB 4.0 beta is available

Posted by jlakumb Oct 14, 2009


Give it a test drive and let us know what you think.  Looking forward to your feedback...


Big value in "Littleware"

Posted by mmiller Oct 10, 2009

Many OSIsoft customers get frustrated by the fact that we do not provide vertical applications.  We talk about all the great thigs that can be done with PI, like Condition-based monitoring and predictive metrics, with little more than slideware from those who have done it and all the money they made or saved.  These applications provide lots of value off the shelf and we rely on our partners and customers to produce and deliver these applications.  vCampus was designed to be the way we help you deliver on these challenges.  But what about smaller applications?  What about the projects that are easy to build on top of PI that could do some neat things for PI users?


One of our close friends at OSIsoft, Phil Ryder used to talk about "littleware".  I like the idea of Littleware.  Littleware are software applications that were more than snipets and functions, but not really full scale "applications".  These are the numerous programs that get written to extend the vlaue of PI in everyday use.  I bet you have some.  Many of these were bantered about over the years and eventually updated and posted on DEVNET.  DEVNET was pretty useful in its day and promoted some ideas that are now standard features (like playback in ProcessBook). But there were problems with it too.  Without a supporting mechanism these "littleware" applications became out of date and did not use the ever advancing capabilities of the PI system.  The support and management of it became significant.  Mostly it didn't address the real issue of providing assistance and guidence to  those who needed to develop on PI.  But the idea of littleware still exists and it is as important as ever.


Most of us would like the idea of a PI littleware share.  Having lead many development teams I see a problem with lttleware sharing between non-developers.  It has to do with relationship between users and devlopers.  For littleware to be valueable you need to use it as part of a work process.  Although generic littleware can be used, integrating it can provide profound value.  The problem I see is, how do users get this integration?  Or any changes for that matter?  Users are accustomed to presenting these changes back to developers.  In a lttleware share the users and developer most likely work for different companies with different ideas about its use.  Code share between developers relieves this becuase the relationship is different.  As a pier developers can modify for thier own use and repost for other users.  Several versions could then be selected for best fit and rated.  That's what communities do righ?


 So, my question is, should the vCampus Community become involved in a PI Littleware Share?  This seems like something that would benefit the users we all serve and this community.  I think we could do it if we keep the code share within vCmapus, i.e.  developer to developer.  Any user suggestions would be posed to the community who could accomodate the changes for thier benefit and the benefit of others and repost. The vCampus team would be available, as always, to provide guidance and direction for completing these gems.

Filter Blog

By date: By tag: