13 Replies Latest reply on Apr 7, 2011 10:57 AM by wpurrer

    One year osisoft pi, lessons learned...


      I'm working now about a year with osisoft. Attached is a small pdf what my team and i did with osisoft from system perspective (challanges, solutions,...)


      Maybe someone can share some feedback.


      Maybe also some product managers can comment and in future i don't have to "create" this workarrounds anymore.







        • Re: One year osisoft pi, lessons learned...

          ps: please mind I'm not a native english speaker ... and only got a 3 (C) in english...

            • Re: One year osisoft pi, lessons learned...
              Lonnie Bowling

              I got a kick out out of the "they open some 'fancy command line tools' like buf.. -ss", and "then we clearly see the problem".


              I can identify with that. I keep telling myself I need to really learn about those tools, but the truth is, I don't use them enough to remember all the tricks.  This is an area that could be improved by providing some simple UI's that would provide that level of access.


              Thanks for sharing this document, I think it should spark some good discussion.

              • Re: One year osisoft pi, lessons learned...



                Good stuff, it's a good read.  Will take some effort to digest and extrapolate as you took great pain to obfuscate your customer and the application :-).  Without knowing the specific application, I would say many of the problems you described are really a result of manageability of the PI system.  Am I correct?

                  • Re: One year osisoft pi, lessons learned...

                    @Steve, i like to step on layer up .. in my opinion (and I seen it proven many times - also on last years userconfernce) that with osisoft the user & administrator aren't the priority.



                    • PI Calculation Processbook - i think nobody every used this at osisoft in a real live environment.
                      (a very small text box for entering a formular, and the "task" has to be very easy otherwise not working)
                    • Support Calls
                      Everytime you make an support calls you have to gather the same data, answer the same questions.
                    • Support Policy
                      Notification Bugs, SDK Bugs that you just can't use features which are broken open for month (years)...



                    I hope I understand the term managability correctly. Form my point of view the size isn't the some problem. I wan't to be informed if one  "interface fails" the same as if 80 interface fails.My focus is more usablity. With size only comes a bigger probability that some issue accure and  there is also a bigger leverage.



                      • Re: One year osisoft pi, lessons learned...
                        Ahmad Fattahi

                        This is really very interesting Wolfgang; thanks for sharing.


                        When you say anyone with access to the tags can hijack the system on slide 20, what do you mean by that? Would you like to give someone the ability to create new tags but not be able to touch certain existing tags? Also, I didn't quite catch why such users can hijack the DCS systems as well; don't they have the security of their own? Could you elaborate?

                          • Re: One year osisoft pi, lessons learned...

                            When you can create tags, you can also create tags that Write to the dcs, and Change values

                              • Re: One year osisoft pi, lessons learned...

                                Hi Wolfgang,


                                Once again thanks for sharing your feedback. Being part of the Product Management group, I can re-assure you the user is a priority. You are not without knowing the PI System has come a long way (30+ years) and has belonged to the process engineering world for most of its lifetime – this obviously affects what the system does, how it is architected and how it behaves. With the new areas and the new types of customers that use the PI System and, especially, the ever-growing size and complexity of the systems, a few fundamental changes are taking (and will continue to take) place in the system. One of those is manageability, as you pointed out several times.


                                As you already understand (and sometimes decry ), the long history of the PI System and the diversity of industries in which it is used have made it a rather broad and complex system, and it has a lot of legacy to take into account. Consequently, eventual efforts to simplify, abstract and expose core concepts/elements in a different, more manageable way, are generally more complex than they look like. We'll get there eventually, but you have to bear with us and continue providing feedback and ideas on how to improve – it's users like you who help us do our job better, and our job is to make the product more relevant and valuable to you all.


                                By the way, are you going to be at the San Francisco Users Conference at the end of this month? If not, I think it might be worth trying to find some time between you and some of my colleagues, to chat about these issues/ideas. Feel free to email me to start looking into this.


                                Thanks again for the feedback!

                            • Re: One year osisoft pi, lessons learned...

                              hi Wolfgang,


                              Thanks for sharing. Also thanks for detailing your solutions and approaches, that's super useful.


                              I had a note. On slide 27 onwards (Maintenance & System) you mention command-line tools like -ss. It turns out the corresponding metrics reported by many of these (piartool -qs, pibufss -ss, piartool -ss, etc.) are also exposed as perfmon counters. UniIint interfaces too do it for a subset of stats you so that don't really have to monitor the logs or call cmdline tools.


                              There is a nice whitepaper on Performance monitoring on our techsupport website. It presents many of these. The UniInt manual also presents some and then the pibufss manual (%PIHOME%\help\pibufss.chm particularly: mk:@MSITStore:%PIHOME%\help\pibufss.chm::/27950.htm) shows its set of counters. I haven't gone in a detailed fashion over each but I think most of the ones I normally check as a TSE when someone calls the TS line are exposed through it.