Jemmac Software
OPCNetView logo. Philosophy of OPCNetView

OPC environments are typically safety and business critical and it is of paramount importance that OPC processes are kept running and not compromised in any way.

OPC Servers are available from a vast range of software vendors. Most adhere to the OPC specification but there are many different ways in which those standards have been interpreted and implemented. In particular, there is nothing in the OPC specification which specifies what logging or traceability information has to be provided by the OPC Server, if any. Some vendors do provide a vendor specific mechanism by which a System Administrator can find out how many clients are connected to an OPC Server but many do not. Even when information can be obtained, it is possible for an OPC Client to fail to provide the OPC Server with information about its identity when it makes an OPC connection request.

Similarly, there is a vast range of OPC Clients available, ranging from in-house developments to complex applications from software vendors.

Typically, these OPC Servers and OPC Clients are run on a complex distributed network of nodes. When problems arise, the System Administrator currently has no easy way to work out what OPC Clients are remotely connected to which OPC Servers. He can only use a number of different operating system and vendor specific tools and it is almost impossible to run them on the different nodes at the same time and get a view of the running processes at the same timestamp.

OPCNetView has been developed to quickly provide the System Administrator with visibility of connectivity between his remote OPC processes, regardless of which vendor developed them. It has been deliberately designed to be passive so as not to compromise security or performance. No packet sniffing is involved and there is no message interception or proxying taking place. OPC processes are totally unaware of the existence of OPCNetView and are untouched by it.

OPCNetView gathers information about running processes and the operating system and uses it to work out which processes running on a node are OPC related and if they have any network connections to other remote OPC processes. OPCNetView is then able to interrogate or query those remote nodes on demand to provide detailed process information about the remotely connected OPC processes.

Remaining passive has its limitations however and not peering at packets makes it impossible to report exactly how many active OPC connections an OPC Server currently thinks it has. OPCNetView instead reports the number of active network connections between the OPC processes which are created and maintained by the Windows operating system. In the vast majority of circumstances, the number of Windows network connections is the same as the number of OPC connections between 2 remote OPC processes - a large number of network connections reflect a large number of concurrent OPC connections.