This is a spin-off of this thread. The thread got offtopic from the original question, so that thread is locked and we should continue discussion in this thread.
In this case some Service Oriented Architecture would be preferred I guess. You have to do some custom development, but that would allow you to solve the caching and security issues.
I understand that we can develop web-service and so on. But I think that we can expect some infrastyructure from OSIsoft. For example, PI Web Services currently haven't deal with AF -- with PI tags only. ACE isn't AF-oriented (it's still need MDB ). OLEDB Enterprise has some performance issues (I expect next version with great hope).
I also think that PI Notfication can be used as calculation host like ACE (custom "notification" channel can also perform various tasks, such as calculations and so on). Notifiations are AF-oriented and ready to use.
Michael @ OSIsoftI understand that we can develop web-service and so on. But I think that we can expect some infrastyructure from OSIsoft.
I can definitly get that. OSIsoft is aware of this though. I don't have any concrete on this, but we are definitly considering this.
For example, PI Web Services currently haven't deal with AF
I'm not sure you mean that you can't use AF from PI Webservices, because you can! You can retrieve values from AFAttributes with PI Webservices. If you are talking about accessing data from AF through PI Webservices then no, there is nothing 'out of the box'. But then I wonder about the advantages over using the PIPoint DataReference?
OLEDB Enterprise has some performance issues (I expect next version with great hope).
I just talked to one of the developers, and he says there are a lot of performance enhancements. There is no release date set yet, but from what I can tell it's in the final stages of development.
Lots of different discussions in one thread here...so here is one more for the mix.
This type of spiking from faulty equipment is, to me, a classic case for StreamInsight for those scenarios where you can't control the data storage through exception/compression alone. You need a bit more intelligence to detect when the signal is not behaving "normally" and then filter, quicker than you can with ACE or Abacus. Whenever filtering is applied to the raw data I would probably be tempted to create corresponding event frames that easily depict when data has been filtered, may be even raise a notification that the measurement is misbehaving.
Zev Arnold @ Wipro
Great thoughts Rhys. Applying event frames to periods of data quality filtering is a really neat idea. Would StreamInsight really react more quickly than Abacus though? They would both have to sign up with the PI server for updates (StreamInsight doesn't read directly from interfaces yet, does it?)