How to run an OPC UA pilot on three machines

Three machines provide enough variation to expose weak points while still allowing the team to check every signal by hand. I usually choose one typical machine, one older or unusual machine, and the machine with the most complex operation. The pilot then tests the boundaries of the future system instead of one polished special case.

The result should be an acceptance package: recorded versions, a node map, test logs, an access matrix, certificate files, and a connection test report. The phrase "data is flowing" means nothing in an acceptance certificate. The process below lets an engineer on another shift repeat the test and reach the same conclusion.

How to choose three machines and set the pilot boundary

Choose machines for the differences that could break scaling, not for easy access to their cabinets. Include the most common configuration, the oldest supported configuration, and the machine with the richest data set. If the shop uses different CNC generations, OPC UA server versions, or network gateways, three identical new machines test almost nothing.

First, state the objective in production terms. For example: determine machine state, automatic cycle duration, downtime reasons, and the good-part count with no more than five seconds of delay. Each objective needs an owner who understands the physical process and approves the signal's meaning. An integrator should not decide alone whether Running means spindle rotation, program execution, or automatic mode.

Record the pilot scope before connecting:

• machine identifier, CNC model, and software version;
• OPC UA publication method: embedded server, gateway, or industrial computer;
• selected metrics and the list of source signals;
• expected change rate and acceptable delay;
• acceptance conditions and the person who signs the result.

Limit the first set to roughly 20-40 nodes per machine, but do not choose only quiet counters. Include a fast-changing signal, a state with rare transitions, a cumulative counter, a text reason, an alarm, and at least one value that sometimes becomes unavailable. This set tests subscriptions, queues, quality, and time. Once the mechanism passes, you can expand the model without changing the test method.

List what the pilot does not cover. Writing control parameters, remote start, and method calls belong in a separate project with a risk assessment. Read access is enough for production data collection. Combining collection and control complicates approval and encourages teams to give an integration client unnecessary rights.

Check the namespace after every restart

Bind the integration to a namespace URI and a stable node identifier, not to ns=2 alone. OPC UA Part 3 defines a NodeId as the combination of a NamespaceIndex, identifier type, and identifier. The numeric index points to the URI's position in the NamespaceArray, so a server may assign the same URI a different index after a configuration update.

This is not an academic detail. A client saves ns=3;s=Machine/State; after a new information model is installed, the server puts the same URI in position 4, while index 3 now belongs to another vendor. A poor client reads the wrong node or fails. A sound client reads the NamespaceArray at connection time, finds the required URI, and rebuilds the NodeId.

For each signal, record more than its display name in the pilot report. A minimal map row looks like this:

asset_id,namespace_uri,identifier_type,identifier,browse_path,data_type,engineering_unit
LATHE-01,urn:plant:cnc,String,Machine/State,Objects/Machine/State,Int32,1
LATHE-01,urn:plant:cnc,String,Production/PartCount,Objects/Machine/Production/PartCount,UInt32,pcs

DisplayName is intended for people and can be localized. BrowseName helps construct a path, but OPC UA Part 3 explicitly warns that it need not identify a node uniquely across the server. Store the original NodeId with its URI, and use the browse path for discovery and troubleshooting, not as an unquestioned primary key.

Run the check in four passes. Capture the complete NamespaceArray and the selected node map. Restart only the OPC UA server, then restart the whole machine or gateway. Browse again and compare URIs, data types, array ranks, and engineering units. If the server configuration allows it, temporarily add or remove a third-party namespace and confirm that the client does not depend on an index number.

The acceptance rule is strict: after every restart, all selected signals resolve to the same logical tags, and an index change requires no manual configuration edit. Document every exception as a lasting limitation of that machine model instead of hiding it in code named special_case_2.

Source time matters more than receipt time

Use sourceTimestamp for cycle analysis when the server creates it at the source, and keep serverTimestamp as a diagnostic mark. OPC UA Part 4 separates them deliberately: the first describes a time associated with the value's source, while the second says when the server received the value or knew it was current. Substituting one for the other makes network delay part of the production cycle.

Perform a controlled transition on each machine. Change a mode or run a short test program, note the actual time in the CNC log, and compare it with both OPC UA timestamps and the collector's receipt time. Repeat at least ten transitions on a quiet network, then introduce an acceptable level of network load. Do not expect millisecond agreement if the controller updates the variable once a second. Look for a bounded difference that you can explain.

Before the test, synchronize the server, gateway, and collector to an approved time source. Save synchronization state and clock offset in the report. A sudden timestamp difference usually points to unsynchronized clocks, an application-level time-zone error, or a gateway adding time after the fact. OPC UA uses UTC; conversion to local time should happen only for display.

Do not silently accept an empty sourceTimestamp. The standard allows an empty value when the source cannot assign a timestamp. The fallback must be explicit: the metric uses receipt time, receives a wider tolerance, and carries a lower-accuracy mark. For events that establish the order of alarms, a missing source timestamp can justify rejecting the tag.

Test three more situations: a server clock restart, a value transition without a quality change, and the same value repeated with a new timestamp. If the client subscribes only to value changes, a new timestamp may not trigger a notification. The OPC UA trigger setting STATUS_VALUE_TIMESTAMP considers quality, value, and sourceTimestamp, but you must test filter support and the source's actual behavior.

Write a numeric acceptance condition for each signal class. For example, a state transition reaches storage no later than five seconds after its source timestamp, and clock offset stays below an agreed threshold. A single tolerance for spindle speed, alarms, and a daily counter usually hides a problem instead of containing it.

A value without StatusCode is not data

The collector must store the value, StatusCode, and both timestamps in one record. OPC UA Part 4 requires a client to check status before using a result: Good means usable, Uncertain calls for care, and Bad makes the value unusable. A database that keeps only the number erases the server's most important warning.

Build a quality test table. For every selected node, safely disconnect or simulate the loss of its actual source: break the gateway's connection to the controller, remove permission to read a test node, or stop a test driver. Record the code, whether the last value remained present, and how analytics treated it. Do not disconnect a production sensor for the sake of a neat report.

The correct policy depends on the metric. Bad_NoCommunication for machine state does not mean "machine stopped." It means knowledge is missing, so the interval must become unknown. Uncertain_LastUsableValue may be shown to an operator with its age, but it should not enter a cycle-duration calculation without qualification. A good value with the Overflow bit says the queue lost changes even though the latest number looks plausible.

For acceptance, a simple stored record is useful:

{
  "assetId": "LATHE-01",
  "tag": "Machine/State",
  "value": 3,
  "statusCode": "Good",
  "sourceTimestamp": "2026-07-26T08:14:31.420Z",
  "serverTimestamp": "2026-07-26T08:14:31.428Z",
  "receivedAt": "2026-07-26T08:14:31.451Z"
}

Force the report to display an unknown interval. If a chart draws a straight line between a good value before an outage and a good value after it, the user sees invented continuity. If the system inserts zero automatically, it turns a communication failure into machine downtime. This semantic defect is expensive because an ordinary dashboard rarely exposes it.

This stage passes when storage, calculation, and display behavior are defined for every bad and uncertain status. Keeping an unhandled code is acceptable in the first phase if it is preserved exactly and never converted to good by default.

Subscription rate is not machine update rate

A requested sampling interval does not make the controller update data faster. OPC UA Part 4 describes the sampling interval as the server's best-effort cycle and separately notes that the underlying source may update more slowly. The client must read the returned revisedSamplingInterval, revisedPublishingInterval, and revisedQueueSize rather than treating a request as a promise.

For every tag, record four figures: expected physical change rate, requested sampling interval, server-revised interval, and subscription publishing interval. Then change a test signal faster and slower than those boundaries. Count notifications, sequence numbers, and the intervals between them. This reveals whether the server collects every change, only the latest state, or periodic snapshots.

A queue of 1 works for current temperature or current mode when the latest snapshot is enough. It does not work for short counter pulses or transition sequences where one lost change alters the meaning. OPC UA Part 4 says that when a queue larger than 1 overflows, the server sets the Overflow bit. The client must store it and raise a diagnostic event.

Apply a deadband only to analog values where small movement has no production meaning. Do not put a percentage deadband on counters, states, or alarm codes. Verify the engineering unit and range before setting a percentage: a wrong range turns a sensible threshold into a filter that hides real changes.

The pilot load test should be limited but honest. Subscribe to the full selected set on all three machines, use the typical publishing rate, and keep the connection for a full production cycle plus a mode change, not for a few minutes. Watch CNC, gateway, and collector load, late publications, overflows, and disconnects. The pilot must not impair the machine.

Acceptance requires a proven adequate rate, not the maximum rate. For every metric, document which transitions could be missed under the selected settings and why that is acceptable. If no pulse may be lost, a normal subscription to a current value may be the wrong source; use a cumulative counter, a queued event, or another controller mechanism.

Test certificates in both directions

A protected connection begins with mutual application trust, not a checked SignAndEncrypt box. OPC UA Part 4 describes separate lists for trusted certificates and issuer certificates. The client validates the server, the server validates the client, and a valid chain alone creates no trust until an administrator puts the required certificate or certificate authority in the TrustList.

Issue a separate application certificate to the collector during the pilot. Do not copy one private key to an engineer's laptop, the server, and the future industrial collector. Record the ApplicationUri, DNS names or IP addresses, validity period, fingerprint, issuer, private-key location, and renewal owner. Never put the private key in the report or a shared network folder.

Test both success and failure. Establish trust on both sides and connect with the selected security policy. Then remove the client certificate from the trusted list on one test server: the connection should fail with a controlled error instead of silently falling back to None. Restore trust, change the host name in the connection address, and confirm server name validation.

The specification calls for checking validity period, host name, application URI, key usage, signature, and chain of trust. Save the outcome of every check in the pilot report. Certificates created before DNS was configured and machine clocks far enough behind to make a new certificate appear not yet valid are especially common findings.

Do not leave automatic acceptance of every certificate enabled after commissioning. The mode is popular because it is convenient in a lab, but it destroys application identity verification. Proper automation distributes preapproved trust or uses a managed certificate authority. It does not treat the rejected folder as an endless supply of automatically accepted files.

Before scaling, rehearse certificate renewal on one machine. Old and new certificates may need a short overlap. Measure downtime, test rollback, and schedule a warning before expiration. A certificate that works today does not prove that its lifecycle is managed.

Access roles must prohibit excess rights

Give the integration client a separate account or identity with read rights only on approved nodes. Anonymous access offers no individual accountability, while a shared engineering account makes it impossible to revoke one client without stopping others. Excess rights remain excess rights even over a protected channel.

OPC UA Part 18 separates authentication from authorization: the server first identifies the client and user, then role permissions determine available nodes and operations. A server may implement only part of the role model, however. A role with a reassuring name does not prove that restrictions work.

Create a test matrix for at least three identities: integration reader, commissioning engineer, and unknown or anonymous user. For each, test Browse, Read, Write, Call, and access to diagnostic nodes. The integration reader should browse and read its approved set but receive Bad_UserAccessDenied for writes and method calls. An unknown client should not receive production data merely because it knows the endpoint.

One awkward case deserves attention: the server permits Browse across the whole tree but denies Read for values. That can reveal program, recipe, and tool names as well as the equipment structure. Decide with the production owner whether that visibility is acceptable. Test permission to see the structure separately from permission to read a value.

Do not keep credentials in a plain configuration file or a project copy on a laptop. The pilot only needs to prove that the collector retrieves its secret from protected storage, supports replacement without recompilation, and does not log the secret. Then change the password or user certificate and confirm that the old credential no longer works.

Acceptance passes when the matrix is repeatable and an actual status code confirms every denial. Testing successful reads alone is insufficient. Protection becomes visible when a prohibited operation reliably fails.

Break the connection on purpose

Test recovery with controlled outages of different lengths because a brief cable interruption and a server restart affect different OPC UA layers. The client should first open a new SecureChannel and activate the previous Session. If the session is gone, it creates a new one and attempts to transfer subscriptions, then recreates them when transfer is unavailable.

OPC UA Part 4 recommends monitoring a connection through subscription keep-alives. After recovery, the client uses sequence numbers and Republish to request missed messages. If the messages have left the queue, the client must record a gap explicitly, read current values, and stop claiming complete history.

Run this sequence:

1. Block the network for 5-10 seconds without stopping the server, then restore access.
2. Repeat for longer than the session lifetime but within the subscription lifetime if the server supports that behavior.
3. Restart the OPC UA server while the machine continues running.
4. Restart the gateway or machine under an approved procedure.
5. Stop the collector, change several test values, and start it again.

For every experiment, save the last message time before the outage, the first message after it, sequence numbers, the Republish result, the number of recreated subscriptions, and the unknown interval length. Look for the Overflow bit if a queue filled. If the client misses a number without raising an event, the test fails even if current values return.

Do not demand the impossible. A normal subscription does not guarantee indefinite history storage during a day-long outage. Reliable delivery depends on subscription lifetime and queue sizes, as Part 4 explicitly states. The business must choose a boundary: short outages might recover without loss, while longer ones create a registered gap and trigger reconciliation against cumulative counters.

Test a recovery storm. The simultaneous return of three machines must not make the client recreate subscriptions forever or overload the server with rapid retries. The retry interval should grow to a set ceiling with slight jitter and reset after a successful connection. Exact values depend on the network and server, so establish them during the pilot.

Verify tag meaning at the machine

A correct NodeId does not prove the correct production meaning. A signal named CycleActive may turn on in manual mode, remain active during a pause, or disappear when a door opens. The protocol cannot reveal that semantic behavior; observation and the CNC log can.

For every calculated metric, run a short scenario with a process engineer or commissioning engineer. Start an automatic cycle, pause it, create an approved test alarm, reset it, produce a part, and change the program. Compare physical events, the CNC display, raw OPC UA values, and the resulting system state. Record the time and responsible person.

Definitions must be explicit. "Running" might mean executing a control program, axis movement, spindle rotation, or production of a part. Choose one definition for a given metric and list its source conditions. If a CNC model supplies only an approximation, call it an approximation and do not promise unavailable accuracy.

Pay particular attention to counters. Find out when they increment, who can reset them, whether they survive a restart, whether the data type can overflow, and whether rejected parts count. Compare the increase over a controlled batch with the physical quantity. If a counter resets with a program change, storage must recognize a reset rather than reporting negative production.

Test alarm and text fields for encoding, language, and stable codes. Message text is useful to an operator, but a vendor may change the wording after an update. For analytics, prefer a stable code plus localized text when the server publishes both. Do not derive your own code from a text hash: a small translation edit would turn the same alarm into a new type.

Production, automation, and data owners should accept the pilot together. One confirms physical meaning, another confirms acquisition stability, and the third confirms storage and calculation rules. Their joint approval prevents an argument a month later when a polished report disagrees with the shift log.

Base the scaling decision on defects

Scale only when every criterion has evidence and each open defect has a known impact and owner. The percentage of successfully read tags is useless by itself: one missing quality signal can corrupt every calculation more than ten absent decorative parameters.

Bring results into one acceptance sheet. For each requirement, record machine, version, test, expected outcome, actual outcome, a reference to the local evidence file, status, and defect owner. Useful decision classes are simple: accepted, accepted with a limitation, retest required, and blocks scaling. Do not hide uncertainty behind "almost ready."

Unstable identifiers, indistinguishable bad data, unproven recovery from short outages, automatic certificate trust, and write permission for the collector account must block scaling. An inaccurate description of an optional diagnostic tag can wait. Separate architecture defects from catalog defects.

Plan shop deployment in waves grouped by CNC and server configuration. Connect a small group first, repeat a shortened acceptance set, and compare it with the pilot. Then expand the wave. Even identical machine models may carry different software versions, licenses, or local configuration, so inventory before connection is mandatory.

The pilot package must let the team recreate trust, the account, subscriptions, and the node map without relying on one integrator's memory. EAST CNC supplies machines and supports selection, commissioning, and service; on a new project, it makes sense to record telemetry requirements during equipment configuration and acceptance.

Assign retest rules before rollout. A CNC, gateway, or client software update, certificate replacement, information-model edit, or network-name change should trigger the relevant part of the test suite. You need not repeat the whole pilot each time, but a namespace change requires a node-map check, a new server version requires subscription and recovery tests, and a security-policy change requires trust and role tests. Put those links in the acceptance sheet or the package will become obsolete after the first service visit.

Evidence needs discipline too. A screenshot shows one successful moment but poorly proves an event sequence. Save a machine-readable UTC log with sequence numbers and statuses for timing and recovery; save the request, identity, and denial code for access; save public certificate details and validation results without the private key. Name files by machine, test, and time so someone other than the author can find them.

Before the first wave, agree on who can stop a connection attempt after a deviation. The automation engineer must be able to stop a test if controller load rises, the process engineer chooses a safe intervention time, the network engineer controls segment changes, and the data owner decides whether a gap is acceptable. This order prevents technically successful collection from disrupting production or a convenient report from being accepted despite poor source quality.

The last check does not happen on an OPC UA client screen. Stop the test report, restore it from the saved configuration in a clean environment, and repeat collection from the three machines. If undocumented human actions are required, the pilot is unfinished. Scale only a process that the team can repeat and whose failures it can recognize.