1. PI Data Archive Server COM Points Richard Beeson

2. What’s in a Name So what is this thing called anyway? “Magic Points” Surrogate Points COM Points PI 3 rd Party Historian

3. What’s in a Name Server COM Points We envision there may be extensions or modifications to the specification which will place “COM Points” on the middle and client tiers – “Its not just for servers anymore.”

4. Design Objectives Support the mapping of multiple external data sources to a Data Archive. Allow SCOMP to coexist with “normal” PI points, interfaces, etc. In fact they are just that, normal PI points. Use as much of the existing PI Data Archive for NT as possible without sacrificing performance. Preserve a single code base = no special builds.

5. Design Objectives Using SCOMP should feel like “PI”. Take advantage of existing NT / WIN32 technology. Hence COM Provide a gradual migration path to PI 3.x for customers who have legacy historians. Eventually allow for a complete migration if desired.

6. How will it be Used? Down level historians RDB Access Simulator Integration Redirection to other PI Systems Projection/Target Integration Hmmm?

7. PI COM Point Resolver PI COM Point Dispatch Architecture PI-DAAPI/SDK Client App.

8. SCOMP Definition COM points must derive from a point class containing the pi3ph attribute set. COM points get their archive data from an external system. COM points get their snapshot either from the local PI snapshot or from the external system. All remaining features of the points are native PI 3.x behavior.

9. User Experience Install/Validate PI Data Archive 3.2 SR2 or later. Install one or more SCOMP Add-in. enables the pi3phss subsystem and PI-SDK installs the in process COM server - pi3phxxx.dll and/or the out of process COM server - pi3phxxx.exe Adds any third party specific support systems such as vendor API's.

10. User Experience Installs pi3ph attribute set and a default pi3ph point class in the point database. Installs additional attribute sets or point classes depending on mapping needs. The monitor may also support automatic point synchronization creating points in PI as needed.

11. User Experience Specific digital state tables created. Automatic synchronization with digital state tables and any other needed tables.

12. User Experience Users then create points mapping to the external data source. These points may be used in client applications just like any other point. Snapshot data and historical data will be retrieved from the external data source. Some implementations may choose to support one or more of the put/edit/delete calls.

13. Legacy System Support PI 2.x from OSI ??? From people like you

14. Migration Yes

15. External Data Sources OSI will provide resolvers for vendor independent data sources, such as: PI-API OLEDB OPC (?) More as they become obvious to us…

16. Design Details Pi3phss is an out of process server/service which dispatches calls between PI Data Archive and the resolving system. All points which have the necessary attributes are registered in pi3phss. Pi3phss dynamically maintains a table of 3ph points as well as a fast dispatch table into the associated pi3phxxx.dll/exe Multiple external data sources are supported on any PI Data Archive.

17. Mapping Parameters The pi3ph attribute set must be used as a basis for any point class that will be used to create a SCOMP point. The pi3ph attribute set consists of three attribute pi3ph_desc pi3ph_strmap pi3ph_lmap Generates a unique id between dispatch and resolver at runtime.

18. pi3ph_desc The pi3ph_desc is a string attribute Identifies the external data source resolver. Maps to the name used to identify the resolving COM server in the registry. This name is defined by the implementer of the resolver. The PI-API resolver for the PI 2.x data source is registered with the name "pi3ph_piapi". All SCOMP points which will be mapped to a PI 2.x data source should have this value for pi3ph_desc.

19. pi3ph_lmap/strmap pi3ph_strmap is a resolver specific string attribute. pi3ph_lmap is a resolver specific integer (4 byte) attribute. Either or both attributes may be required by the resolver to properly map the external data stream.

20. PI-API for Example Stores server node id in pi3ph_lmap. The pi3ph_piapi resolver uses the pi3ph_lmap for the server node id of the server (as specified in the pilogin.ini file.) If this field is empty, the default server defined in the pilogin.ini is used. Stores the tag name in pi3ph_strmap contains the tag name which is mapped for the specified server when the point is defined.

21. Dispatch A “pi3ph” flag is kept internally to signal an external data point. If this flag is set, the snapshot and archive dispatch to the appropriate pi3phxxx interface to resolve snapshot and archive retrievals.

22. Dispatch Requires only approx. 5 calls for most functionality. All remaining functionality is layered on these few calls. Expected archive functionality is preserved such as calculated expressions, filters, etc. Subsystems such as pitotal, pisqlss, pipeschd, etc. continue to function normally even when SCOMP points are referenced.

23. Local Flag System defaults to “remote” snapshot. On a point by point basis the resolver may identify points as using the “local” snapshot. The resolver/monitor is responsible for updating the snapshot in PI. Data will not go to the archive.

24. Updates Updates are handled by PI through the standard PI Update Manager mechanism. Since SCOMP points are native PI points, changes to these points are reflected accordingly. Since the data is not native to PI, EVM exceptions are only provided if the local flag is set; in other words, current data updates are only available if the resolver is able to keep the snapshot in synch.

25. Resolver Design The resolver must implement the Ipicompt COM interface. Beyond this the resolver may implement local data support, point synchronization and full or partial migration support. Installation/Setup

26. Ipicompt Interface See Visual Developer…

27. Data Types DATE Expected normalized to UTC – will be coerced to proper PItimestamp. VARIANT All standard types will be coerced to the proper PIvalue type if possible. PI-SDK The PI-SDK will specify objects and collections for handling event passing. Once, available, these data types will supercede the current implementation. This will not be available in the first release.

28. PI Local Data Uses standard API calls to keep the snapshot synchronized. Will see a special SDK interface for management in future.

29. Point Synchronization Use standard SDK interface.

30. Migration Yes.

31. Information Next week, preliminary information and support for SCOMP will be provided at http://irn.osisoft.com/pi3ph http://irn.osisoft.com/pi3ph A very early version of PI 3.2 SR2 will be available for developers wishing to start working on external data source resolvers. All documentation will be made available via the WEB and through HTML Help format.

32. Schedule The development tools and documentation will be available in beta form at the beginning of April 1999. The first release of SCOMP will accompany PI 3.2 SR2 – Summer/Fall 1999.

33. Questions?