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).

Before connecting to the OPC Classic (COM Server) it is necessary to create and configure the Server object in the Server Model.

Connecting to the OPC Classic Server

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 for example) to connect to the inmation OPC Server and browse the namespace of the I/O Model.

Connecting to the system OPC Classic Server with Matrikon OPC Explorer
Figure 1. 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 property.

Add Virtual OPC Classic (COM) Servers
Figure 2. 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.
In the Model Access subsection, the system Models to be exposed by the server can be specified. By default, only the I/O Model is exposed.

Unlike the OPC UA Server, the Virtual OPC Classic server does not need to have I/O Model Access enabled to expose events.

Create two different Virtual OPC Classic (COM) servers and give them different Prog IDs. Click Apply.

Adding 2 Separate Virtual OPC Classic (COM) Server Instances
Figure 3. 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.

Virtual OPC Classic (COM) server instances in external client
Figure 4. 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. Then, open the Server filter dialog.

Server Filter Options
Figure 5. Server Filter Options

This will open a Table Properties Grid dialog 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 expose 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.

Adding a Server Filter using Drag and Drop
Figure 6. 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.

Server Filters in Object Properties Panel
Figure 7. 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.

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

Browse filters

The OPC DA 2.05, DA 3.00, and HDA 1.20 COM interfaces related to browsing the server’s namespace support filtering on the object tag name. For all interfaces the supported filter syntax is the same.

Filter Syntax

The pattern-matching features allow you to use wildcard characters, character lists, or character ranges, in any combination, to match strings. A character here is equivalent to a Unicode code point. Pattern-match is case-insensitive.

The following table shows the characters allowed in pattern and what they match:

Characters in pattern Matches in string


Any single character.


Zero or more characters.


Any single ASCII digit (0-9).


Any single character in charlist.


Any single character not in charlist.

Single characters are Uniocde code points and not user-perceived characters. The latter is Unicode parlance, also called grapheme clusters, to denote printed symbols which are perceived as a single character but requiring multiple Unicode code points to be represented. Such grapheme clusters are not matched by a single ? or an element in charlist.

A group of one or more characters (charlist) enclosed in brackets ([]) can be used to match any single character in string and can include almost any charcter code, including digits.

To match the special characters left bracket ([), question mark (?), number sign (#), and asterisk (*), enclose them in brackets. The right bracket (]) can’t be used within a group to match itself, but it can be used outside a group as an individual character.

By using a hyphen (-) to separate the upper and lower bounds of the range, charlist can specify a range of characters. The character ordering is binary, based on the Unicode code point value. For example, [A-Z] results in a match if the corresponding character position in string contains any uppercase letters in the range A-Z. Multiple ranges are included within the brackets without delimiters.

Other important rules for pattern matching include the following:

  • An exclamation point (!) at the beginning of charlist means that a match is made if any character except the characters in charlist is found in string. When used outside brackets, the exclamation point matches itself.

  • A hyphen (-) can appear either at the beginning (after an exclamation point if one is used) or at the end of charlist to match itself. In any other location, the hyphen is used to identify a range of characters.

  • When a range of characters is specified, they must appear in ascending sort order (from lowest to highest). [A-Z] is a valid pattern, but [Z-A] is not.

  • The character sequence [] is considered a zero-length string ("").

  • The pattern [!] is equivalent to ? and matches a single character.

HDA Filter Attributes

The HDA CreateBrowse method supports filtering on the following attributes:

OPC HDA Attribute

Mapped Property

Operator Codes


ServerAccessRights (IoItem), otherwise defaults to VT_VARIANT

All (numeric comparison)



OPCHDA_EQUAL (supports pattern matching)

User Identity 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.

Profile Properties
Figure 9. Profile Properties

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.

User Properties
Figure 10. User Properties

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:

Applying the [.property]#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.