During one of the presentations at DevCon 2007, Jim Luth mentioned the significance of the Server Object as part of the Information Model.  One of the things people have been wanting in the current OPC offerings is a standard way to get status, diagnostic, capability and configuration information for a given server.  This is a key requirement when putting together an enterprise wide monitoring or management strategy for your OPC architecture.   OPC UA addresses this using the standard, yet extensible, ServerType object.

I’ve posted before on the OPC UA Information model, and said that it is expected that every OPC UA server will expose at least one ServerType object in the address space.  If you want the nitty, gritty details they are all found in OPC UA – Part 5 Information Model  (or better yet join the Early Adopter Program and help implement some of this stuff ).  For everyone else, here’s the 10,000 ft view on things.  So what sort of stuff does this thing tell you about a server?  Let’s ask some questions and find out.

Where do I find things?  The ServerType object has properties that tell a server where it can get to from here.

List of Other UA Servers: One of the design intentions of OPC UA was to support chaining and federation of OPC UA servers in the enterprise, so one of the things the ServerType object has is a list of other OPC UA servers it is aware of.

Namespace Table: Each OPC UA server has it’s own namespace that is used as part of the NodeIds in a server.  The ServerType object provides a convenient index mapping to the longer name URIs.

How am I feeling?   The server usually knows the most about it’s backend connections.  The OPC UA client goes to the ServerType object to get that sort of information.

Service Level: This property is also used to support OPC UA server federation and reliability.  There will be cases in a given system where an OPC UA client may be able to access the same data from two different servers or paths (i.e. in a redundant server configuration).  The Service Level is a number between 0-255, that indicates the relative ‘health’ or ‘ability to serve data’ of a server. 255 would mean everything is A-OK.  A Service Level of 0 would indicate the OPC UA server is disconnected from it’s back end data source.   A number somewhere in between might be used to indicate periods of network slow down, servers in a timeout or reconnect mode or some other questionable state.

Status Information:  The standard start time, current time, version information and the familiar Running / Failed / No Configuration / Shutdown / etc  states are here as well.

Diagnostics: This is actually another whole object type, which in turn nests other objects.  It would contains a vast amount of diagnostic statistics such as numbers of views, sessions, timeouts, sampling and publishing rates and rejects due to security constraints.  It also has additional information on a per session, per subscription and per sampling rate granularity.

What can I do?  Ever wonder what a particular OPC server can do?

Server Capabilities:  This is another object type that contains specifics on what a particular server supports.  Rather than just checking to see if interfaces exist, OPC UA clients can now find out which specific OPC UA Profiles a server supports.  The base Server Capabilities object also has information on support node types, local information and minimum sample rates.  Clients would also start at this object to find additional capabilities objects such as Historical capability or vendor defined information .

Redundancy: The OPC UA specification defines the way clients and servers handle redundancy.  Redundancy can be a many headed beast dealing with client vs. server redundancy, transparent vs. non-transparent failover and Hot, Warm or Cold fail over scenarios.  The Server Capabilities object is where the details are found on what a server supports.

What did I do?   Almost as important as what a server can do, is what it did do.  In today’s world of Sarbanes-Oxley type legislation, process audit trails are becoming an necessity.  

Audit Events: The ServerType object also has information on what Audit events a server supports.  This contains data such as who did what when in terms of configuration, security or data updates.

In addition to providing standardized access to a wealth of knowledge about a server, the ServerType object is also a great example of how UA allows extending the standard ObjectTypes by adding additional components (with some restrictions in order to maintain interoperability of course).  I’m looking forward to seeing what types of powerful client applications will be developed to leverage these features of the OPC UA Information Model.  Aren’t you?