inmation OPC Classic (COM) Server

The Server service, once installed, creates an active connection to the Core host specified at the time of installation. If you install system:inmation using a default setup (using the Windows Installer), a local Server service will be installed (connecting to the local Core service) and will be visible in the Server model as a Server object with the same name as the host machine of the Core.

Figure 1. Server Model with Local Server Object

The Server object is created automatically but is not enabled automatically. To enable the Server, select it in the Server Model, right click and select Admin > Enable > Object (shortcut F9).

Figure 2. Enabled Server Object

You can use an external OPC Classic client to connect to the Server and browse the namespace. Before that though, it is necessary to add a User Account to a Profile in the Access model that matches the Windows account on the computer you are using. For instance, if you are using the Administrator account you need to Create a User underneath a Profile with the authenticating domain for the host machine and a matching "Administrator" Account Name. Once a corresponding User is created, use an external OPC Classic client (Matrikon’s OPC Explorer or example) to connect to the inmation OPC Server and browse the namespace of the I/O Model.

Figure 3. Connecting to the system OPC Classic Server with Matrikon OPC Explorer

Creating Virtual OPC Classic (COM) Servers

It is possible to create separate virtual OPC Classic (COM) server instances for the Server that will be visible as endpoints to connecting clients. These separate OPC server instances can be configured separately to have different namespace filters to only allow parts of the namespace to be visible to clients. To create new virtual OPC Classic (COM) server instances, select the Server object in the Server Model and in the Object Properties panel, click the "plus" sign next to OPC COM Servers.

Figure 4. Add Virtual OPC Classic (COM) Servers

From here you can add as many different Virtual OPC Classic server instances as you like. Each instance should have a different Version Independent Prog ID so the client can distinguish between the instances. Create two different Virtual OPC Classic (COM) servers and give them different Prog IDs. Click Apply.

Figure 5. Adding 2 Separate Virtual OPC Classic (COM) Server Instances

Creating the 2 new instances will restart the Server service, disconnecting any connected clients. Once the Server has restarted, the two instances will be visible in the client and available for connection.

Figure 6. Virtual OPC Classic (COM) server instances in external client

Server Filters on OPC Classic (COM) endpoints

Once you have created some virtual OPC Classic (COM) server instances, it is possible to add a filter so only certain parts of the I/O model namespace are browsable. To do this, select the Server object in the Server Model and expand the endpoint settings that were created in the last example and open the Server filter dialog.

Figure 7. Server Filter Options

This will open a Table Properties dialog box where the filter for browsing can be configured by selecting the level in the I/O Model that you wish to be browsable. You can drag and drop the object that you wish to be exposable to clients in the server endpoints into the path column of the table. Only this folder and the items below it in the hierarchical layout of the I/O Model will be exposed to connecting clients. Check the 'Active' checkbox in the column, then click Apply to set the Server filter.

Figure 8. Adding a Server Filter using Drag and Drop

Apply another different Server filter level to the other endpoint and click Apply. The Server Filters are now visible in the Object Properties panel and are stored as JSON strings.

Figure 9. Server Filters in Object Properties Panel

To see the filters in action, connect to each of the server instances in turn using your OPC Classic client and browse the namespace.

Figure 10. Server Filter Active when Connected using OPC Classic Client

User Indentity Override

Alternatively to the Server Filter, the Access Model can be used to control which data can be accessed via Virtual OPC Classic (COM) Servers.

Create a Profile dedicated to the communication between the OPC Server and the Core. For this Profile object set the General Authorization properties and Model Authorization properties according to your needs.

Underneath the Profile which you created in the previous step, create a dedicated User for the communication between Server and Core . Take a note of the value of the Account Name property of the User object.

Go back to the Server Model and tell the Virtual OPC COM Server to use the dedicated user by entering this value for the User Identity Override property in the OPC COM Servers property section of the corresponding server, following this schema:

<DOMAIN NAME>/<ACCOUNT NAME>

Applying the __Account Name__ value as __User Identity Override__

The User Identity Override configuration restricts which data the Core provides for the Server. It does not affect how the client and server interact.