The purpose of the OPC Time Monitor is to provide a “time-in-condition” or “time-since-last-change” value for any OPC DA data tag. This give the user or integrator valuable information for process optimization or increased manufacturing output. In manufacturing, cycle time is of utmost importance. To be able to instantly know how long a machine or processing step has been “static” gives the plant engineer the information required to focus on the most time consuming phases of assembly. These time values can be viewed, plotted, logged or even used to trigger OPC A&E alarms (in case the process has been static too long and appropriate personnel need to be notified).

The OPC Time Monitor can be used in conjunction with other OPC-A&E servers to create an “alarm delay”. By using both the original OPC-DA tag AND the OPC-DA Time tag, the 3^rd party OPC-A&E server can effectively “delay” the creation of an OPC-A&E alarm until the static condition persists for more than a specified amount of time.

The OPC Time Server is an OPC-DA client that can connect to any OPC-DA 1.0 or 2.0 server. For each tag in the OPC-DA server, the user can establish an OPC-DA AND OPC-A&E tag that represents the “time since last change” in milliseconds, seconds, minutes or hours (configurable)

Other features of OPC Time Monitor include:

Maximum update time - Accept any OPC-DA tag and report accumulated time until the OPC DA tag changes value (whereby the time accumulation resets to 0.)

Deadbands, included and excluded values – Specify a range of values or a value difference that will (or will not) reset the time value. For example, while the value of the OPC-DA tag is between 50 and 100, keep counting time or until the value changes by more than 5, keep counting time.

Auto configuration – The OPC Time Monitor can “auto browse” your OPC-DA server’s database to automatically create it’s own time tag database. This database can then be modified as desired.

Dynamic discovery and browse through – An OPC-DA Client can “browse through” the OPC Time Monitor to find the actual OPC-DA tag from the primary server. What the user will get is the time value of this tag from the OPC Time Monitor instead of the original value.

Import/Export from .CSV – Create the time tags using a simple .CSV file that can be imported into the OPC Time Server directly.

Maximum time – This per-tag option gives the user the maximum time value that this tag has ever had (reset by another OPC-DA tag) so that someone can see the “worst case time” value. This is kind of like logging the maximum value over a given interval.

Other time characteristics - Cycle count, total and average time.

1.2 Required hardware and software

Software requirements

The OPC Time Monitor runs on any of these operating systems

- Microsoft Windows 95 with DCOM installed

- Microsoft Windows 98

- Microsoft Windows Me

- Microsoft Windows NT 4.0

- Microsoft Windows 2000

- Microsoft Windows XP

Version for Windows CE (including PocketPC platforms) is available upon request.

Hardware requirements

Use at least the recommended hardware for the operating system that you are running.

1.3 Installation

[under construction]

{OPC proxies, OPCEnum).

The installation also includes a setup of so-called MSXML3 components. These components are critical for the operation of the server; you should not abort their installation unless you are absolutely sure that this version is already installed on your computer. The version provided with the server is Service Pack 2 (SP2), which is the latest available. Note that the MSXML4 or other numbered releases of similar components are installed side-by-side with MSXML3. This means that installing MSXML3 does not negatively influence any other software, even if that software uses a different version of XML components.

OPC Labs Kit Server

The installation of OPC Time Monitor also includes OPC Labs Kit Server. This is a small OPC server with no user interface or configuration that provides a set of simulated values. The Kit Server can be used to verify the operation of OPC Time Monitor. Also, the sample configuration (Sample1.otm_xml) of the OPC Time Monitor refers to the Kit Server.

1.4 Demo version

Limitations: The demo version of OPC Time Monitor only supplies valid data for 1 hour since the server has been started. After this period, the OPC server state changes to OPC_STATUS_SUSPENDED, and quality of all items provided by the server becomes OPC_QUALITY_OUT_OF_SERVICE.

Alpha and Beta versions of the software are distributed as Demo version only.

Contact your distributor if you need to extend demo version limits for the evaluation purposes.

2. Functionality

2.1 Time measurement

This chapter describes the basic principles that the OPC Time Monitor uses to measure different time values.

Connections

The OPC Time Monitor does not have any physical interface to the plant. Instead, it uses other OPC Servers to obtain the data it needs. This makes it very generic tool.

In order to be able to obtain data from some other OPC server, the OPC Time Monitor must first establish a connection to it. The server can either be local, or it can be accessed via DCOM on remote machine.

Unless a full dynamic discovery (described later) is used, the user must first configure every connection that the OPC Time Monitor will be making. There are two basic pieces of information needed to establish a connection:

- Machine name (can be empty for local machine), and

- Server class (typically its ProgID).

The configuration tool (described in a separate chapters) allows you to browse for machines on your network, and for servers on them.

While the OPC Time Monitor is running, it tries to stay permanently connected to all the servers it needs for the time measurements. If the connection cannot be established, the server reports fatal error, stops responding or the connection to it is lost, the program disconnects from the server automatically. After certain time, it attempts to connect to the same server again. This time is called reconnect delay and is set to 60 seconds (1 minute) by default.

Time topics

Once we have connections, we can subscribe to certain items inside the connected OPC servers. OPC Time Monitor refers to the subscribed items as time topics. Every topic has a name that will be visible to OPC clients that use OPC Time Monitor.

When specifying the time topics, the primaery piece of information that is needed is the so-called ItemID of the item the we want to monitor. The ItemID is a string used to refer to certain data inside the source OPC server. The syntax of ItemID depends on the specific OPC server you are connecting to. The configuration tool (described in a separate chapters) allows you to browse for an ItemID inside a connected server, making it easy to enter ItemIDs correctly.

Besides ItemID, there are other entries that may be configured for every time topic:

- Access path

- Update rate

- Percent deadband

These entries are standard OPC qualifiers associated with the OPC item or OPC groups. It is outside scope of this document to provide complete descriptions of these entries.

Note, however, that the update rate and percent deadband values are of particular importance for time measurements. The update rate basically tell the source OPC server how often it should send the changed values to the client – in this case, the OPC Time Monitor. The source OPC server will also not send any value changes smaller than the percent deadband. As the OPC Time Monitor can only work with the data that it actually gets from the source, it is important to set the update rate and percent deadband so that the desired precision of tiem measurements can be achieved.

The OPC Time Monitor allows you to configure multiple time topics that refer to the same source OPC item, as long as you give the topics a different name or place them in different folders.. Although creating multiple topics referring to the same OPC item is not typical, it may be useful in situations where you want to perform several measurements (such as test for different conditions) on the same value.

Time folders

In a typical application, there may be hundreds or thousand of time topics. It would be impractical to list and access them in a flat manner, without further organization. Time folders allow you to organize time topics in any desired way. A time folder is a named placeholder that can contain time topics and even further (nested) time folders. The nesting levels are not limited by OPC Time Monitor.

The time folders are presented as address space branches when the OPC client browses into items of OPC Time Monitor.

For time measurements, the OPC Time Monitor itself does not interpret the organization of topics in folders. The time measurements are performed in the same way for all the topics, no matter how they are organized in folders. You can therefore choose any logical organization that suits your needs (or no organization at all). It is perfectly possible to put topics from different connections into one folder, for example.

For example, it is possible to mimic the address space of the source OPC servers, so that browsing OPC Time Monitor then resembles browsing the original (source) servers. In fact, this is how the folders will be set up if you import the source OPC server configuration (as described in the chapter about the configuration tool).

The other approach may be to use time folders to provide more logical (plant-wise) organization to the items that would otherwise appear scattered among different places inside source OPC server, or even among multiple source servers.

In addition, time folders can be used when you need to perform certain operation, such as manual, automatic or scheduled reset of aggregated values (explained later), for multiple time topics. Time folders provide functionality that allows resetting all of the topics that belong to them (and to folders below them as well) at once. By properly organizing topics into folders, thousands of topics can be easily manipulated together.

Measurement types

For every time topic, the OPC Time Monitor performs several measurements. It measures:

- for how long the topic value satisfies certain condition: this is called “in-condition” state,

- for how long the topic value does NOT satisfy the condition: this is called “out-of-condition” state,

- for how long the topic value has been (reasonably) stable.

The result of these measurements are available in separate branches under every time topic. The names of the corresponding branches are $InCondition, $OutOfCondition, and $Stable.

Engaged indicator

The OPC Time Monitor also provides a simple indication whether the topic value is in a state that corresponds to every measurement type. This indication is a logical value (true/false, or 1/0) that is called engaged indicator. The engaged indicator for every measurement type is accessible via OPC Item that has the same name as the measurement branch, i.e. $InCondition, $OutOfCondition, or $Stable.

For example, the engaged indicator $InCondition is 1 (true) if the topic value satisifes the given condition. At the same time, the engaged indicator $OutOfCondition will be 0 (false), and vice versa. The engaged indicator $Stable is always 1 (true) when the value is “in condition”, except for very short transitional periods.

Cycles

As the topic value changes, the measurement state becomes engaged and disengaged again. These state transitions are called cycles. The OPC Time Monitor keeps track of the number of (finished) cycles for every measurement, and provides it as an OPC item. The number of cycles is also used to compute the average time (see Aggregates later in this chapter).

The cycle count can tell you, for example, how many times certain topic value has been equal to 2 - in reality, this may be how many times the pump has been running during the day, or other important statistics that is otherwise difficult to obtain via traditional OPC servers.

Condition

The condition defines which values are eligible for time measurements. The condition works with the quality of the value (Bad, Uncertain or Good) and with the value data itself.

Definition of eligible value

In the configuration of the time topic, you can specify whether the data with Bad, Uncertain or Good quality satisfy the condition.

For the data with Uncertain and Good qualities, you can specify that either

- all values satisfy the condition,

- only values inside certain range satisfy the condition,

- only values outside of certain range satisfy the condition.

Stability

The stability measurement determines for how long the topic value has been constant, or at least did not change significantly. The stability measurement is only performed if the condition (described above) is satisfied.

Definition of significant change

The OPC Time Monitor considers a change in the value significant, if the quality had changed, or if the difference between a reference sample and this new sample is greater than the absolute deadband configured for the time topic. Note that the default for absolute deadband is 0.0.

The reference sample is the first value available for which the condition was satisfied in the current cycle. The comparison described above is performed on floating point numbers. If the reference sample or the new sample cannot be converted to a floating point value, a significant change is also triggered.

OPC quality handling

By default, the OPC Time Monitor does not measure times for items that have Bad quality. As long as the item has Bad quality, all “current measurements” returned by OPC Time Monitor also have Bad quality. The “previous measurements” and aggregated times are unaffected.

The quality handling, however, is controlled by the Condition settings. You can therefore change the way quality is treated to make it suit your needs.

By default, Uncertain qualities are also handled as Bad qualities by the OPC Time Monitor. You can easily change this by checking an appropriate checkbox in the Condition configuration.

Client and server times

The OPC Time monitor server measures every time interval in two ways, expressed in “client time” and “server time”. Depending on your application, you may need one of them, or both.

The client time measurements are based on the time when the client (in this case, OPC Time Monitor server) received the event. The server time measurements are based on the timestamp that the original server provided with the value.

The server time measurements are generally more precise, and can provide up to 100 nanoseconds resolution. The measurements based on server times are not influenced by the network delays between the server and OPC Time Monitor. The servers usually obtain the timestamps from the operating system. If somebody changes the current time on the server machine, either manually or by a time synchronization utility, the server time measurement may become extremely imprecise or even unusable at that particular moment. For example, if the actual time elapsed between two event is 30 seconds, but the user had adjusted the time on the server machine by 5 minutes in between the events, the computed difference between the timestamps may become 5 minutes and 30 seconds.

The client time measurements are, in contrast, based on the moments when the event (significant change) was noticed at the receiving end, i.e. in the OPC Time Monitor. The measurements may be influenced by network delays between the server and OPC Time Monitor and other processing on the machine. For computing the time values, the OPC Time Monitor uses the number of operating system ticks since the system startup. This mechanism is NOT influenced by any changes in the current time setting on either the server machine or OPC Time Monitor machine. The theoretical maximum possible resolution of client time measurements is 1 millisecond. However the actual resolution of the client time can never be better than the update rate for the measured item.

You should analyze the needs of your application and the strengths and weaknesses of these two measurement methods, and properly decide on using the server or client times, or their combination. The OPC Time Monitor provides both the server and client times as separate items, therefore you do not need to configure the OPC Time Monitor to provide the proper value – you just pick the right item from the server.

Current and previous measurements

As a primary result, the OPC Time Monitor provides the time how long the measured item satisfies certain condition, or how long it has been stable. This is called “time on current” in OPC Time Monitor. If the item value does not change significantly, the “time on current” keeps increasing. At the moment the item value significantly changes, the “time on current” measurement starts over again, i.e. the “time on current” becomes zero and starts increasing again.

Sometimes we call “time on current” measurements simply as “current measurements”. They are extremely well suitable for alarming purposes, as you can easily generate an alarm immediately at the moment when the OPC Time Monitor detects that the measured item kept certain cndition or value for too long. They may also be displayed on the screen of an HMI package and give the operator an immediate view of how long the item kept the value just now.

As a secondary result, the OPC Time Monitor provides the time how long the measured item had satisfied the condition recently, or had been stable before the last significant change. This is called “time on previous” in OPC Time Monitor. The “time on previous” is basically the value of “time on current” when it reached its maximum, just before it went back to zero.

Sometimes we call the “time on previous” measurements simply as “previous measurements”. They are extremely suitable for logging purposes, as you can store only the final time measurements into the log, not the transient values as the item has been monitored. Depending on the application, the “time on previous” measurements may also be well suited for trending screens or classical HMI screens as well.

At the moment the measurement cycle is finished, all “current” measurements are moved into the “previous” measurements, and the current times are reset (zeroed). Note that all “previous” measurements have a Bad quality until the first time is fully measured.

The OPC Time Monitor provides both the current and previous measurements as separate items, therefore you do not need to configure the OPC Time Monitor to provide the proper value – you just pick the right item from the server.

Note: Beware of “current server time” behavior. When the OPC Time Monitor is not getting updates from the source OPC Server (which may be perfectly OK because the value is not changing), the value of “current server time” stays constant, because the OPC Time Monitor is not getting any timestamps. This may give a false impression. To overcome this, use “current client time”, any form of the “previous time”, or force the source OPC server to send updates even if the value is not changing.

Aggregates

Besides the actual time measurements, described above, the OPC Time Monitor provides various aggregates, i.e. summary values based on individual measurements. This features makes it easy to use OCP Time Monitor without further processing its output by complicated scripting, expressions and additional computations.

Cycle count

Cycle count is an integer number equal to the number of measurement cycles finished (what the “cycle” is was described earlier in thich chapter). The counting starts at zero, and every time the cycle is finished the cycle count is incremented by one.

Maximum times

This aggregate holds the longest time for the given measurements. You can get maximum time the topic was in-condition, the maximum time the topic was out-of-condition, and the maximum time the topic value has been stable. Each maximum time is available either as time on server or time on client.

Writing any value into the item that expresses maximum stable time causes it to be reset (zeroed). For future compatibility, a value written should always be zero. You can use this feature to allow the user “acknowledge” that the maximum stable time has been noticed, e.g. by placing a pushbutton on the HMI screen and configuring it to store 0 (zero) into the corresponding item.

It is, however, recommended to use the $Reset item to perform similar operation. This item is described at other place in this documentation. Using $Reset, multiple aggregates can be reset at once, and their previous values can be kept for future reference.

Total times

This aggregate holds the total (sum) of the finished measurements of a given type. You can get the total time the topic was in-condition, the total time the topic was out-of-condition, and the total time the topic value has been stable (due to the way the stability is evaluated, this is usually equal to the total time the topic was in-condition).

Each total time is available either as time on server or time on client.

Average times

This aggregate holds the arithmetic average of the finished measurements of a given type. The average time is compited by diving the total time aggregate by the cycle count. You can get the average time the topic was in-condition, the average time the topic was out-of-condition, and the average time the topic value has been stable (due to the way the stability is evaluated, this is usually equal to the average total time the topic was in-condition).

Each average time is available either as time on server or time on client.

Note that the average time cannot be computed when the cycle count is zero (no cycle has been finished yet). For this reason, the OPC Time Monitor returns “Bad” quality for average times until at least one cycle was minished for the given time measurement.

Current and previous aggregates

Whenever the cycle finishes (and the current measurements are moved to previous measurements, as described earlier), the OPC Time Monitor updates the value of current aggregates. The current aggregates will kept aggregating the measurements until they are explicitly reset by any of the means described later below.

At the moment of the reset, the values of current aggregates are copied into a separate section of OPC Time Monitor data, called previous aggregates. After this, the values of current aggregates are set to zero. The previous aggregates are no longer updated and stay unchanged until the next reset.

Resetting the aggregates

The current aggregates can be reset in multiple ways: By writing into a $Reset item (“Manual reset”), by a value of certain OPC-DA item in another server (“Automatic reset”), or by the OPC Time Monitor according to a predefined schedule (“Scheduled reset”).

Any reset also causes the current aggregate values to be copied into previous aggregates. All ways of reset perform precisely the same operation: There is no difference whether the reset was invoked manually, automatically or via a schedule. You can even combine multiple was of invoking the reset.

Manual reset

Writing a logical one into a $Reset item provided by the OPC Time Monitor invokes a manual reset.

The $Reset item provided on every time topic, and writing a logical one into the $Reset on a topic level resets the aggregates only for that topic. In addition, the $Reset item is provided on every time folder, and also on a root of the OPC address space. Writing a logical one into one these $Reset items invokes a reset for all the time topics and folders on the given level and below, recursively. This way you can easily reset multiple (or all) aggregates in the OPC Time Monitor.

Note that in the current version of OPC Time Monitor, writing any value that can be converted to a True VT_BOOL into the $Reset item invokes the manual reset. The reset is performed only at the moment of the write; it is NOT repeated or held in reset state while the $Reset value stays True. For future compatibility, you should use logical one (True) followed immediately by logical zero (False).

Automatic reset

The OPC Time Monitor can watch the value of certain OPC item existing in some other OPC server. When this value becommes “triggered” (either zero or non-zero, depending on the configuration), the OPC Time Monitor invokes automatic reset.

The automatic reset feature can be configured on every time topic, and when used on this level, it resets the aggregates only for that topic. In addition, the automatic reset feature is provided on every time folder. When the associated OPC item becomes triggered, an automatic reset is invoked for all the time topics and folders on the given level and below, recursively. This way you can easily reset multiple aggregates in the OPC Time Monitor by watching a single OPC item in some other OPC server.

Scheduled reset

You can configure a scheduled reset for every time topic or time folder. The OPC Time Monitor will invoke the reset every minute, every hour or every day, based on the configuration settings. The reset can be performed at certain minute of an hour or at certain hour of a day.

The scheduled reset feature can be configured on every time topic, and when used on this level, it resets the aggregates only for that topic. In addition, the scheduled reset feature is provided on every time folder. When confgured on a folder, scheduled reset is invoked for all the time topics and folders on the given level and below, recursively. This way you can easily schedule a reset for multiple aggregates in the OPC Time Monitor.

Time formats

The OPC Time Monitor provides every time value in several formats. You can therefore select the format that is best for your application. The OPC Time Monitor provides separate items for every format of the time value, therefore you do not need to configure the OPC Time Monitor to provide the proper format – you just pick the right item from the server.

The most natural format to transfer time and date values via OPC is so-called VT_DATE, which is basically a floating point number containing the number of days in its integer part, and a fraction of a day in the part right to the decimal point. The OPC Time Monitor provides every time value as VT_DATE unless you choose a different format.

If you need a different format, of if your OPC clients does not handle VT_DATE well, you can choose from the range of various formats offered by OPC Time Monitor. You can find their full list in the Reference section. Items for different formats reside right under the “native” VT_DATE item. For example, the OPC Time Monitor item that provides the desired value as VT_DATE may be

     YourItem!$Stable!ClientTime

The same value provided as number of seconds is available as

     YourItem!$Stable!ClientTime!Seconds

and the same value provided as number of minutes is available as

     YourItem!$Stable!ClientTime!Minutes

Note that when the server provides the time in “seconds”, “minutes” and other units of time, it always returns the full time value converted to that unit of time. It does NOT return elements of time. For example, if the time measured is 93.1 seconds, it will return 93.1 when the “!Seconds” format is used, and it will return approximately 1.552 when the “!Minutes” format is used. It will NOT return 1 for minutes and 33 for seconds etc.

The OPC Time Monitor can also provide any time as formatted string, so if all you need to do is display the time measurement, the string format may be the safest choice.

Measurement start and stop

If the OPC Time Monitor is run as NT service, it starts time measuruments of all configured topics as soon as the NT service is started, and it stops the time measurements of all configured topics when the NT service is stopped. With NT service, you can therefore assure that the time measurements are performed and collected even when no OPC client is actually using the OPC Time Monitor server.

When the OPC Time Monitor runs as regular (out-of-process) server, it start time measurements of all configured topics as soon as the first OPC client connects to it, it stops the time measurements of all configured topics when the last OPC client disconnects from it. More technically, what actually matters is the number of OPCServer objects inside the OPC Time Monitor. The time measurements are performed whenever the count of OPCServers is not zero. This may be fine for many applications, but you should be aware of the fact the OPC Time Monitor may not be performing the time measurements until your OPC client connects to it. Note that it is NOT important which configured items the client actually requests. Either all configured topics are being measured, or none of them.

For dynamically discovered topics (no matter whether the server is run as NT service or as out-of-process server), the time measurements are started and stopped on per-topic basis.

2.2 Operations

Static configuration

[under construction]

Dynamic discovery

[under construction]

XXXX

(also describe the time-outs used to make the browse-through appear faster)

(describe problem with recursive browse-through and the measures taken against it)

When accessing the discovered item, the OPC Time monitor has no additional information available besides the server connection data and the item ID. This means that the OPC Time Monitor has to use default values for many properties that would otherwise be configured. The default values that are used for discovered items are:

Reconnect delay: 60 seconds

Access path: (empty)

Update rate: 100 milliseconds

Percent deadband: 0.0

Note: Unless necessary, you should limit the use of dynamically discovered items to minimum, ideally just for experiments and development purposes. Dynamically discovered items require significantly more processing overhead as compared to statically configured items. If you have to use the discovered items, try to stay away from storing item IDs chosen by selecting machines and items from the “Entire Network” branch. Depending on the computer and network configuration, the names of network containers may change in the future or may look differently on a different machine, rendering your stored item IDs unusable.

Client connections

[under construction]

XXXX

(describe how it connects to OPC server, detects a failure, and re-connects).

(Machine connections, OPCEnum)

2.3 Server management

Registration

[under construction]

(NT service …..)

Configuration

The OPC Time Monitor is configured via a XML document stored in a file. The default file extension is “.otm_xml”. The configuration contains a list of connections, and a hierarchy of time folders and time topics and their properties.

The configuration file can be generated by another program, or it can be created and modified by the configuration tool with intuitive user interface. The configuration tool is described in Chapter 3.

Server settings

[under construction]

Active configuration

Event logging

[under construction]

3. Configuration

[under construction]

4. Reference

4.1 OPC server instantiation

Depending on your OPC client, you may need the following information to connect to the OPC Time Monitor.

Version-Independent ProgID:	OPCLabs.TimeMonitor
Version-Dependent ProgID:	OPCLabs.TimeMonitor.2
Version-Dependent CLSID:	0258E5DF-C308-4E88-99CB-5C0670F7374D

4.2 Registry settings

[under construction]

HKLM\SOFTWARE\OPC Labs\Time Monitor

     ConfigurationFileName=

4.3 Address space structure

[under construction]

4.4 Syntax of item IDs

All OPC Time Monitor item IDs are case sensitive.

Separators and escape sequences

The OPC Time Monitor uses an exclamation mark (!) as a separator inside its OPC item IDs. The exclamation mark was chosen because it is used as a separator in other OPC servers quite rarely, and the OPC Time monitor needs to embed other server’s item IDs inside its own item IDs without causing conflicts.

If, in the rare circumstances, the exclamation mark itself needs to be a part of the item name, it has to be preceded by an escape character – tilde (~), like this: ~!. The tilde itself can be entered as double tildes, like this: ~~. The OPC Time Monitor takes care of this transformation automatically when presenting the statically configured or dynamically discovered item IDs via OPC browsing interfaces, and performs the opposite transformation (removing tildes) when properly formed item IDs are passed to it by OPC clients.

Item ID elements

The Item IDs consist of multiple parts. Later in the text, we refer to certain repeating parts as elements. The description of these elements is provided below.

Connection name

Connection name represents an alias used to refer to certain OPC server running on a given machine. You cannot rename the connections. The OPC Time Monitor creates connection names automatically, based on the machine name and OPC server class.

Syntax: \ServerClass

Example: \OPCLabs.KitServer.2

Syntax: \\MachineName\ServerClass

Example: \\MYPC\OPCLabs.KitServer.2

The ServerClass can be the server’s ProgID (version-dependent or version-independent), or its CLSID enclosed in curly braces, such as {3A5855D0-680F-5E88-81CB-9C0620F7375D}.

Folder name

You can use any combination of characters for folder names. For future compatibility, it is recommended that you limit the folder names only to characters allowed in file names, and do not begin the folder names with ‘\’ (backslash), ‘%’ (percent) or ‘$’ (dollar sign).

Example: Machine 1 measurements

Topic name

You can use any combination of characters for topic names. For future compatibility, it is recommended that you limit the topic names only to characters allowed in file names, and do not begin the topic names with ‘\’ (backslash), ‘%’ (percent) or ‘$’ (dollar sign).

Example: Valve37

Measurement name

Possible measurement names are:

Syntax: $InCondition

Syntax: $OutOfCondition

Syntax: $Stable

Time format

Possible time formats are:

Syntax: Days

Syntax: Hours

Syntax: Microseconds

Syntax: Milliseconds

Syntax: Minutes

Syntax: Seconds

Syntax: Str

Topic leaf path

The topic leaf path is the actual item of intereset under any time topic. Because there are many values provided by OPC Time Monitor for every time topic, the values are organized in a hierarchical structure again.

A short overview of all the items available is given here. You can find the detailed descriptions of every item available in the separate chapter below (“OPC Items and their meanings”).

Below is the list of items (leafs) available right under every topic.

Syntax: $CurrentValues

Syntax: $InCondition

Syntax: $OutOfCondition

Syntax: $Stable

Syntax: $Reset

$CurrentValue item is a pass-through value of the topic from the source OPC Server. The $InCondition, $OutOfCondition and $Stable items are engaged indicators (true/false). The $Reset item resets all the aggregates under this topic.

Besides the leafs, there are branches for every measurement type available uner the topic. You can therefore see following branches under every topic:

Syntax: $InCondition

Syntax: $OutOfCondition

Syntax: $Stable

(Do not mix the branch for the measurement with its engaged indicator). By browsing into one of these measurement branches, you will get further branches and leafs. They are all related to one of the measurements provided by OPC Time Monitor.

Following items (leafs) are available under every measurement:

Syntax: ClientTime

Syntax: PreviousClientTime

Syntax: ServerTime

Syntax: PreviousServerTime

Syntax: PreviousValue

The PreviousValue item provides the value that the topic had in the previous cycle. All other items are different time measurements (client and server times, in their current and previous state) provided directly as VT_DATE values.]

There are also branches with the same time as every time measurement (i.e. ClientTime, PreviousClientTime, ServerTime, and PreviousServerTime). These branches then contain the time measurements in different time formats. In other words, the time value provided under these branches is the same as the VT_DATE provided by the leaf with the same name, it is just represented in a different way or converted into a different type.

In addition to the leafs and branches for time measurements, there are also following two branches under every measurement type:

Syntax: Aggregates

Syntax: PreviousAggregates

These branches contain the current and previous aggregated values. They both have the same structure of leafs and branches underneath them.

Following items (leafs) are available under Aggregates and PreviousAggregates:

Syntax: CycleCount

Syntax: MaxClientTime

Syntax: MaxServerTime

Syntax: TotalClientTime

Syntax: TotalServerTime

Syntax: AverageClientTime

Syntax: AverageServerTime

With the exception of CycleCount, all of these items return time values in VT_DATE format. There also corresponding branches with the same names, and they contain items for times expressed in different formats.

[to be written] CHART (TREE) OF leafs

Syntax for specific kinds of items

Fully configured physical items

Not available in this version.

Discovered physical items under the configured connection

These items are denoted by ‘>>’ after the client name.

Syntax: ConnectionName!>>!ItemName!…! TopicLeafPath

Example: \OPCLabs.KitServer.2!>>!Simulate!Random!$Stable!PreviousValue

Note that the item ID of the measured item does NOT appear in the full form and syntax provided by the OPC server. Instead, it is separated into its constituents, and name of every node appears separated by the standard OPC Time Monitor separator (!).

Fully discovered physical items

These items are denoted by ‘>>’ right at the beginning of the item ID.

For items selected from “Local Machine! branch:

Syntax: >>!.!ServerClass! ItemName!…!TopicLeafPath

Example: >>!.!OPCLabs.KitServer.2!Simulate!Random!$Stable!PreviousValue

For items selected from „Network Neighborhood“ branch:

Syntax: >>!@!MachinePath!...!ServerClass!ItemName!…!TopicLeafPath

Example: >>!@!\\MYPC!Simulate!Random!$Stable!PreviousValue

For items selected from the „Entire Network“ branch:

Syntax: >>!*!MachinePath!...!ServerClass!ItemName!…!TopicLeafPath

Example: >>!*!Microsoft Windows Network!WORKGROUP!\\MYPC!OPCLabs.KitServer.2!Simulate!Random!$Stable!PreviousValue

Fully configured logical items

These are the items corresponding to the regular topics that you have defined in the configuration.

Syntax: TopicName!TopicLeafPath

Syntax: FolderName!…!TopicName!TopicLeafPath

4.5 OPC items and their meaning

Name	Access Rights		Canonical Data Type	Description
Name	Readable	Writeable	Canonical Data Type	Description
$CurrentValue	Yes	No	VT_EMPTY ^*	Passed-through current value of the measured (source) item.
$Reset	Yes	Yes	VT_BOOL	Writing True value into this item resets the aggregates under this level and below. Reading this item always returns False in this version.
PreviousValue	Yes	No	VT_EMPTY ^*	The value that the source item had at the beginning of the previous cycle. This item appears separately for every measurement type.
ClientTime	Yes	No	VT_DATE	Returns the measured time, as seen on the client (receiving) end and measured by operating system ticks.
ClientTime!TimeFormat	Yes	No	depends on TimeFormat	Same value as ClientTime, but expressed in a different way (converted), as given by TimeFormat.
PreviousClientTime	Yes	No	VT_DATE	The previous value of the client time, i.e. the client time value reached in previous cycle.
PreviousClientTime!TimeFormat	Yes	No	depends on TimeFormat	Same value as PreviousClientTime, but expressed in a different way (converted), as given by TimeFormat.
ServerTime	Yes	No	VT_DATE	Returns the measured time, as seen on the server (transmitting) end and measured by timestamps provided with the values.
ServerTime!TimeFormat	Yes	No	depends on TimeFormat	Same value as ServerTime, but expressed in a different way (converted), as given by TimeFormat.
PreviousServerTime	Yes	No	VT_DATE	The previous value of the server time, i.e. the server time value reached in previous cycle.
PreviousServerTime!TimeFormat	Yes	No	depends on TimeFormat	Same value as PreviousServerTime, but expressed in a different way (converted), as given by TimeFormat.
CycleCount	Yes	No	VT_I4	Number of finished cycles since the server started or the aggregates have been reset.
MaxClientTime	Yes	Yes	VT_DATE	The maximum value of PreviousClientTime since the server started or the aggregate has been reset. Can also be reset (zeroed) by writing any value into this item.
MaxClientTime!TimeFormat	Yes	Yes	depends on TimeFormat	Same value as MaxClientTime, but expressed in a different way (converted), as given by TimeFormat.
MaxServerTime	Yes	Yes	VT_DATE	The maximum value of PreviousServerTimesince the server started or the aggregate has been reset. Can also be reset (zeroed) by writing any value into this item.
MaxServerTime!TimeFormat	Yes	Yes	depends on TimeFormat	Same value as MaxServerTime, but expressed in a different way (converted), as given by TimeFormat.
TotalClientTime	Yes	Yes	VT_DATE	The total value of PreviousClientTime since the server started or the aggregate has been reset. Can also be reset (zeroed) by writing any value into this item.
TotalClientTime!TimeFormat	Yes	Yes	depends on TimeFormat	Same value as TotalClientTime, but expressed in a different way (converted), as given by TimeFormat.
TotalServerTime	Yes	Yes	VT_DATE	The total value of PreviousServerTimesince the server started or the aggregate has been reset. Can also be reset (zeroed) by writing any value into this item.
TotalServerTime!TimeFormat	Yes	Yes	depends on TimeFormat	Same value as TotalServerTime, but expressed in a different way (converted), as given by TimeFormat.
AverageClientTime	Yes	No	VT_DATE	The average value of PreviousClientTime since the server started or the aggregate has been reset.
AverageClientTime!TimeFormat	Yes	No	depends on TimeFormat	Same value as AverageClientTime, but expressed in a different way (converted), as given by TimeFormat.
AverageServerTime	Yes	No	VT_DATE	The average value of PreviousServerTimesince the server started or the aggregate has been reset.
AverageServerTime!TimeFormat	Yes	No	depends on TimeFormat	Same value as AverageServerTime, but expressed in a different way (converted), as given by TimeFormat.
TimeBranch!Days	Yes	same as TimeBranch	VT_R8	Time value, expressed in days and a fraction of a day.
TimeBranch!Hours	Yes	same as TimeBranch	VT_R8	Time value, expressed in hours and a fraction of an hour.
TimeBranch!Microseconds	Yes	same as TimeBranch	VT_R8	Time value, expressed in microseconds and a fraction of a microsecond.
TimeBranch!Milliseconds	Yes	same as TimeBranch	VT_R8	Time value, expressed in milliseconds and a fraction of a millisecond.
TimeBranch!Minutes	Yes	same as TimeBranch	VT_R8	Time value, expressed in minutes and a fraction of a minute.
TimeBranch!Seconds	Yes	same as TimeBranch	VT_R8	Time value, expressed in seconds and a fraction of a second.
TimeBranch!Str	Yes	same as TimeBranch	VT_BSTR	Time value converted to string, such as “01:45:58”. Uses the system default locale settings (not the custom locale settings). Note that the typical resolution of the converted string is up to seconds; no fraction of a second is provided.

^*Note: The server reports VT_EMPTY as a canonical data type for CurrentValue and PreviousValue items. This is a common OPC way to express that the canonical data type of a value is unknown at the moment. The actual values returned by the OPC Time Monitor server have the same data type as the underlying server that provides them. The OPC Time Monitor has no control over the data type and contents of these values.

4.6 OPC software tested for interoperability

OPC Servers

This list describes which OPC servers the OPC Time Monitor has been tested with. For this test, the OPC Time Monitor behaves as an OPC client, and the products listed below represent the servers for which the OPC Time Monitor does the time measurements.

Vendor	Product	Version	Result	Remarks
ICONICS
Matrikon	OPC Simulation Server	1.1.3.289	OK
OPC Labs	Kit Server	2.0	OK
[under construction]

OPC Clients

This list describes which OPC clients the OPC Time Monitor has been tested with. For this test, the OPC Time Monitor behaves as an OCP server, and the products listed below represent the clients that can consume the results provided by OPC Time Monitor.

Vendor	Product	Version	Result	Remarks
ICONICS
KEPware Products
Matrikon	OPC Explorer	3.1.0.57	OK
[under construction]

4.7 Specifications

OPC client part

[under construction]

OPC server part

[under construction]

=====