During last European IOP at Nuremberg,Germany
OPC foundation launched this tool.
So far there are compliant test
tools(CTT) for servers.
Foundation published many advantages
for client certification. My personal observation is after testing with Analyser,
client becomes robust enough to guard against any buggy server.
Let me describe with a real case
scenario. The case I would like consider here
is "OnDataChange" call. And this is based on an observation made at
IOP.
All those clients that I observed so
far never bothered to filter information received from OnDataChange callback.
Probable reason being this call is made by server and clients assume data to be
authentic. So what is the problem here?
Just to recap from specification
here goes first two paragraphs under comments sub-section of section 4.6.1.1
IOPCDataCallback::OnDataChange
"For any S_xxx pErrors code the client should assume the
curresponding Value, Quality and Timestamp are well defined although the
Quality may be UNCERTAIN or BAD. It is recommended (but not required) that
server vendors provide additional information here regarding UNCERTAIN or BAD
items.
For any FAILED ppError code the client should assume the curresponding
Value, Quality and Timestamp are undefined. In fact the Server must set the
corresponding Value VARIANT to VT_EMPTY so that it can be marshalled
properly."
Client developers need to emphasize
on this kind of statements so that operational safety ensured. Both these
statements say that VTQ (Value Timestamp and Quality) should be assumed as
undefined in respective cases.
Here the
important point to be noted is about precedence. Considering the fact that
server is OPC compliant, thus hrMastererror and hrMasterquality are updated as specified
in spec, pErrors for an item should be S_OK for that VTQ to be updated on User
Interface. This means that pErrors should take precedence over pwQualities,
The reason for this stands by safety
and design of transmitters. Transmitters are designed to send Value and state
of the transmitter upon query. And some modern transmitters can Time stamp the
value as well. But considering the cache, dead band and on-change attributes of
OPC items, Quality is a value which is always built in firmware at server
level. Thus value of Quality is not raw information received from transmitter.
When transmitter fails or freezes,
the value may or may not be held at failsafe value. This depends on
configuration available at transmitter. What ever could be the configuration,
there could be a chance for freeze at last good/bad value. Ideally such a
scenario should be detected and an alarm should be generated for transmitter
fault. And values from then onwards should be considered as undefined.
OPC spec mandates this from these
paragraphs and even goes one step further by recommending servers to set the
VARIANT field to VT_EMPTY. This to ensure that value can not marshaled though
it has a valid server handle and client handles
A simple test case to verify this
scenario is
-- return a failure error code for
any one item
-- set/leave quality good
-- client must not use this value
and should indicate an error
OPC Analyzer helps in testing many
scenarios like this. Analyzer can be downloaded from foundation site
www.opcfoundation.org by Corporate Members.
Latest version available is
1.00.1004. Now you can guard your clients from crashing against buggy servers…