Configure PCS PI Data provider Galaxy service

This section describes how to configure and deploy PCS PI Data provider as a Galaxy service.

When a PCS PI Data provider is installed in a Galaxy Repository, a new service "AVEVA PCS PI Provider" is available in the galaxy.

In the System Platform IDE, navigate to Galaxy>Configure>System>Services. In the Configure Services utility, verify the installed PCS PI Provider is added to the services list.

To configure PCS PI Data provider Galaxy service:

1. After installing PCS PI Data provider, restart the IDE.

2. From the IDE ribbon, navigate to Galaxy>Configure>System>Services. A new service AVEVA.PCS.Provider.1.0 is available.

3. In the Configure Services utility, expand the items on the left pane and go to AVEVA PCS PI Provider 1.0 service.

   

4. Right-click on the AVEVA PCS PI Provider 1.0 service and select Create. The new instance of the service appears on the tree structure. By default, it is named as PCS.PI_Provider_001.

   

5. Right-click on the new instance and select Check-out to modify the configuration.

6. The following are the important parameters:

   • Provider

     • Namespace: Prefix used for the references. The namespace to be used in item references. For example, if namespace value is ns, then to reference data from this provider, use ns:\\PIServer\PIDatabase\Element|Attribute.
       In this example we have considered pi as reference.

   • PI Web API

     • Server: The address used to access PI Web API server, for example: https://piserver/piwebapi. Make sure PI Web API server certificate is valid and the user running the AVEVA PCS PI Provider Windows Service has access to the required resources (both on Asset Framework and Data Archive). When using the default Virtual Service Account, the identity used to access these resources will be the machine account: DOMAIN\Computer$.

   • Browse

     • Databases: An array with the Asset Framework databases you want to use.
       Enter the database name in the form of ServerName1\DatabaseName1, ServerName2\DatabaseName2, etc., You can provide multiple databases separated by comma.
       If empty, all Asset Framework servers and databases connected to PI Web API will be shown. In case we only want to show relevant databases, we can pass a comma-separated list of databases in the form AFServer\AFDatabase. This configuration does not prevent accessing data from other databases, it only hides them when browsing.

   • Runtime Data

     • Update time (ms): Refresh time for the data (by default. 5000 ms). Interval between consecutive update checks. Data will not be updated faster than this.

     • Static Value Update Time(ms): Interval between updates for static values. Static values are attributes that don’t support subscribing for updates, for example, attributes with Table Lookup data references.

     • Reconnect Time(ms): Interval between reconnection attempts when provider disconnects from PI Web API server.

     • Updates Per Request: Requests for updates are not send all together in one request, instead they are sent in chunks, and this value establish how many attributes are updated per each request. If you are getting ‘URL too long’ errors, you need to lower this value.

     • Updates Concurrent Requests: Controls how many chunked update requests are sent concurrently (simultaneously). This is to prevent too many requests being sent at the same time, increasing the CPU usage of the PI Web API process. If you are experiencing high CPU load on PI Web API process, you can lower this value.

     • Attributes Per Request: Similar to Updates per Request property, this controls how many attributes are checked per request. If you are getting ‘URL too long’ errors, you need to lower this value.

     • Attributes Concurrent Requests: Similar to Updates Concurrent Requests property, this controls how many chunked attribute requests are sent at the same time.

   • Web Access

     • Enables: Select the checkbox to accept connections from the web client. This configuration enables browse methods through a web browser, using gRPC-Web. This is needed only if you use PCSNavigation on OMI Web, since default browse access is done using a protocol not supported on browsers.

     • CORS Origins: Comma-separated list of origins allowed to get data from Web Access service. This needs to be configure if the PCS Provider service is running on a node different from the OMI Web server node (WebViewEngine). For example, if we access OMI Web with the address https://omiserver/omi, but the PCS Provider is not running on OMISERVER node, then we need to configure CORS Origins to include https://omiserver (we remove everything after the first slash) as an allowed origin.

     • Identity Manager: Web Access uses AVEVA Identity Manager to authenticate the requests (it uses the same identity connected to OMI Web). This value controls the JWT issuer that is going to be used to validate the token. If the value is left empty, the default Identity Manager will be used.

7. Verify the details about the parameters for Provider, PI Web API, Browse, and Runtime Data.