I like your "challenge for vCampus community" approach
As for your other questions, I did connect with the Product Management for ProcessBook and I'll them answer that one!
Hi, Moh. Thanks for raising this question about SilverLight (and the nice compliment as well).
Currently, the OSIsoft plans for SilverLight are to use the existing SVG-formatted files emitted by PI ProcessBook and transform them on the fly within RtWebParts (the RtGraphic web part, in particular). The way in which SilverLight comes to be used in the web application will drive any plans or designs for replacing the SVG add-in in ProcessBook with one that emits or converts the SilverLight XML grammar used by WebParts. For the time being, there isn't a compelling reason to do this work.
Having said that, both file formats use XML, so it is really only a matter of transforming the SVG grammar.
The other part of your question/comment has to do with what would be difficult to replicate in SilverLight. The current limitations in the SVG add-in should give you some pointers there. There really is no way to "translate" ActiveX controls that may be on a display into an XML format and there is no XML equivalent for VBA scripting. In addition, I would add that faithfully reproducing what a symbol looks like (and where it is located) within a display is fairly easy using ProcessBook's automation model. The more challenging part is understanding how to store information for dynamic symbols like trends and XY plots so that the resulting XML file can be used somewhere else and get updated data, as it does in RtGraphic, for example. This need to replicate the symbol behavior and data manipulation has been one reason that the SQC symbol has not yet been included in the SVG export, for example (there is significant client-side processing that has to take place for ad hoc SQC symbols).
The web-based implementation is far more challenging than translating the ProcessBook format to XML. Not only is there the visual component, but there are interaction behaviors users expect to have available no matter where they see our symbols (e.g., trend zooming, etc.). And also, there must be updating data, of course.
I hope that addresses your general question. I'm happy to continue this conversation if others find it useful.
OSIsoft Product Manager
I have been working on an 'implementation' of ProcessBook in Silverlight.
My approach has been to strictly observe a strict Model - View - ModelView architectural pattern. The basis of my approach is that the Silverlight (XAML) Controls only act as a View layer for the underlying Model. The Model only uses basic Silverlight types: so serializing the Model object graph is easy with the standard DataContractSerializer. The serialized information is not in XAML/SVG/... format. It is serialized XML by the DataContractSerializer.
I have implemented a 'Editor' View-ViewModel and a 'Viewer' View-ViewModel. In this way, I can edit the Model visually using the 'Editor', and view it using the 'Viewer'. I can just Serialize and Deserialize the Model object graph, and load it into either the Editor or the Viewer - no problems there.
Values from the Pi Server (or any datasource - like OleDB - for instance) are retreived using WCF. For communication between the local Silverlight 'Viewer'/'Editor' and Pi i am using my new Linq-To-Pi and WCF.
In your Workbook (and Page) you can create one or multiple datasources. These datasources contain DataSets. A dataset can be an SQL Query (for the OleDB DataSource) or a Pi Point (with start and end times etc). A table, chart series (line, scatter, pie etc.), gauge or label register with a dataset. The datasource provides the updates (polling or event based). These datasources and datasets are serialized with the object graph.
This approach eliminates the problem that there is no XML equivalent of VBA. A Workbook / Page can hold a string of C# Code. This C# code is compiled on the fly (on the server, using .NET's CSharpCodeCompiler object). References to the objects in the Workbook/Page are included in the compiled assemblypart. This assemblypart is loaded with the 'Viewer'. The C# Code can then reference the objects on the page (charts, gauges, labels, datasources etc).
The current approach is based on that users can create and modify workbooks on their local space (at the moment this is the Isolated Storage, provided with Silverlight), and then 'Publish' their Workbooks to an intranet/internet service.
So, I think that creating a 'light' processbook version for the web is certainly possible. Taking advantage of Silverlights outstanding databinding model, I think this can be done with reasonable amount of resources. The advantages of such a product are huge in my opinion.
In the near future I will hope to provide some screenshots and additional information, if anyone is interested!
It will take me some time to digest the two replies, as each sentence in the replies sounds important.
In the mean time, you might be interested to checkout the Status product from www.mobiform.com (I have no relation with them!). I love their concept, but I am not sure about their implementation.
At this point, I understand from Laurie's response that PB will remain the main authoring tool for displays, but RtGraphic will incorporate some sort of XML transformation so as to render XAML on the fly. If my understanding is correct (i.e., that PB will remain the main authoring tool for displays) then I may conclude that the functionality of the obtained displays will be based on what you can do with PB.
I have been at a customer's site recently and, in order to make his point, the manager logged into a hotel reservation website, and asked me why cannot he get PI screens with similar interactive functionality. It would not be hard to get the same behavior with PB+VBA, ASP.NET, or with Silverlight. But I have no idea if a XAML-aware RtGraphic will ever be able to give him what he wants unless the VBA functionality in PB is not "lost".
I look forward to your progress updates, Moh.
Thank you so much for pointing to that link. The real funny thing is, that their product looks a lot like what i'm trying to build. With some really important exceptions. Their concept is really great!
From what I see, their screens are build as XAML pages. From the screenshots it looks like it is a Silverlight IDE optimized for creating process displays. This is not the way I think it 'should' be. From what I see, you are just building Silverlight Projects, with another IDE... It almost looks like Expression Blend for the web...
In your post you said:
I love their concept, but I am not sure about their implementation.
Can you explain this a little further? What are you not sure about?
Can you tell me how far you have got with this development and whether you are willing to share any of it with the Virtual Campus community (me!)?
I have a "working" silverlight application where you can add trends from a PIpoint. It also includes tables, and I'm working on gauges. I have also made it (quite) generic, so it can also handle odbc datasources.
It is not really user friendly at the moment, and I haven't had the time to work on it any further. I'm planning on working on it this summer.
I am not entiirely sure if want to share it. Not at the moment I guess, because it isn't (at all) finished and still a bit prototype. It still has some bad prototype code, that I want to refactor before making anything public.
Like any programmer, my attention quickly shifted when I found a new challenge (Windows Azure in this case :) )
I will keep you informed of any updates!
I have been working on the Process Display a lot the past time. It is still in a prototype/proof of concept state, but I think it really shows promise.
I am very excited about participating in the Extreme Code Review on the OSIsoft vCampus Live! event in December. I'm really curious what the opinion of the community is.
Michael @ Atos Origin
Can you explain this a little further? What are you not sure about?
The Status documentation says that "Status has a plug-in architecture and full object model", but I am not sure why should one invest in extending Status when Visual Studio itself can be extended? Imagine a product like Status that consists of an extension to Visual Studio, where the extension simplifies the UI (like Status does) for casual end-users, but provides the full power of Visual Studio and Expression for power users.
So my comment is not because I found any limitation that is worth mentioning about Status, but I must say that I have used it only in Trial mode, and I went only over some parts of its documentation. Perhaps more experience with the product will alleviate my doubts.
But Mobiform seems to be putting great effort in their graphic design. But had the Microsoft effort described in this ppt led to anything, the graphical part would be freely available: