Interpret a process value together with its StatusCode and source/server time instead of assuming a received number is fresh and valid.
Treat the value as structured evidence
OPC UA DataValue includes more than a numeric payload. The OPC Foundation defines a StatusCode and distinguishes a source timestamp from a server timestamp. The quality state and time fields carry information that can change how the number should be used. A client that displays only the number can hide uncertain quality or old source information. Receiving a message now is not, by itself, proof that the underlying measurement was updated now.
OPC Foundation: DataValue supports the technical principle above.
Define what freshness means in the application
Make a data-consumer worksheet with tag identity, value type, expected quality states, source-time meaning, server-time meaning and the maximum useful age for the stated purpose. Note whether a timestamp is present rather than inventing a default. Record the relevant clock basis and how clock synchronization is managed. Apparent age becomes ambiguous if the clocks being subtracted are not comparable.
Keep two decisions separate: whether the quality permits use and whether the value is sufficiently recent. A good-quality value may still be too old for a time-sensitive use. Conversely, a recent message can carry a bad-quality value. Define the display, logging and downstream behavior for each agreed combination rather than letting a numeric conversion discard the metadata.
Hypothetical freshness worksheet
Imagine a fictional record received at 10:00:05 with source time 10:00:00 and server time 10:00:04, all on an assumed synchronized clock basis. Its apparent source age at receipt is five seconds; the server timestamp does not erase those five seconds. Now compare a second invented record received at the same time with a Bad StatusCode and a current source timestamp. It is recent but invalid for a use that requires Good quality. Write separate columns for apparent age and permitted quality. These made-up records describe no HM controller, available OPC interface or installed monitoring capability.
Specify the consumer contract explicitly
The project output should state which fields the client preserves and how it responds to missing time, stale data and each relevant quality state. Preserve representative expected records as part of an interface acceptance plan. Do not assume a logging platform retains every field merely because it supports OPC UA. When discussing machine-data integration, first confirm that the proposed interface exists and identify its semantics. This article supplies a supplier-agnostic interpretation method; it does not promise that any current HM product exposes OPC UA or a particular data tag.
Customer Questions
Is server time the same as measurement source time?
No. OPC UA gives those fields distinct meanings.
Can a recent value have bad quality?
Yes. Freshness and quality are separate conditions and should be evaluated separately.
Does this article confirm OPC UA on an HM machine?
No. The availability and scope of any interface must be confirmed for the proposed configuration.
Related Equipment References
Review the actual offered equipment and application separately from this educational example.
Primary References
These references support the technical principles discussed in this guide. The worked examples and review questions are educational.
Discuss Your Machine Requirement
Share your product, container, required output and the evidence needed for your technical review.
Request a Technical Review