Remote Diagnostics for Equipment You Ship
How machine builders diagnose equipment already on customer sites: connection model, industrial network limits, and why the operator matters.
Updated
You shipped a machine. It is on a customer’s shop floor running your software, and the customer is on the phone saying it has stopped.
Sending an engineer costs a day or two, and the machine is down for that day or two. That is the plain case for remote diagnostics. Building it properly means working around constraints that have little in common with supporting an office PC.
Three things that are different here
The machine is your product, not the customer’s asset. You know better than they do what state it should be in, where the logs live, which parameter is wrong. What you need is not “see the screen” — it is “reach everything the diagnosis requires”.
The person on site is not an engineer. In an office you can say “click the icon in the bottom right”. On a shop floor you may be talking to a machine operator or whoever happened to answer. Expecting them to follow a sequence of steps is not realistic, and that single fact decides the connection model.
The network is often isolated. Production segments frequently have no outbound route, or a tightly restricted one. This is not a detail to work around later; it is the first thing to establish.
Connection model: unattended is the default here
| Customer support | Equipment diagnostics | |
|---|---|---|
| Default mode | Attended (they accept) | Unattended |
| Why | The customer is at the machine and must see each session | There may be nobody near it at all |
This is the sharpest divergence from customer-facing remote support. There, attended is the right default because the customer should see every session. A machine that throws an alarm at 2am cannot wait for someone to click Accept.
Unattended moves the entire risk onto credentials and audit. With nobody on site to approve, “who connected to which machine, when, and what they did” has to be recorded by the system. That is not an optional extra — it is what makes unattended acceptable at all. See security and audit.
Network: establish it before you promise anything
Production networks come in roughly three shapes:
- Outbound access works — install the client and move on; NAT traversal handles private addressing
- Restricted egress — the customer’s IT needs to allow specific hosts and ports. That is one conversation, but it only has to happen once
- Fully isolated — remote diagnostics does not apply. Do not promise it. What you can do here is have the machine export logs to removable media, or work through the customer’s own jump host
Say the third one early. Promising it during the sale and discovering it during deployment is far more expensive than the awkward conversation up front.
Building the controlled end into the machine
Shipping every unit with a separate remote control tool to install is an extra step at the worst moment — installation rates drop, and the customer is already out of patience by the time it matters.
The client SDK embeds controlled-end capability into your own software, so a machine running your product can be connected to with nothing else installed. The SDK is cross-platform — Windows, Linux and macOS — which matters here, because plenty of HMIs and industrial PCs are not running a standard Windows desktop.
A Web SDK (start sessions from your own service portal) and a REST API (write session records back to the ticket) complete the picture. The differences are in embedding remote control in your own product.
⚠️ One limit worth stating plainly: the standalone WorksLink client ships for Windows and macOS only. If your equipment runs Linux, SDK integration is the viable path; installing the packaged client is not.
A workable rollout order
- Establish the network shape first. Which of the three it is determines everything after it
- Start with the model that generates the most service calls, not with the whole catalogue at once
- Turn on unattended and audit together. Doing unattended first and leaving audit for later means the sessions in between leave no record, and you cannot reconstruct them afterwards
- Integrate once volume justifies it. Installing the client by hand on a dozen machines is fine; at several hundred, or when units should ship with remote capability built in, the SDK starts paying for itself
One thing about how this is priced
WorksLink charges per concurrent channel, not per device.
That distinction is large in this scenario. You might have thousands of machines reachable while only a handful of sessions run at any moment. Paying for concurrency rather than installed base is a different cost curve from per-endpoint pricing — worth modelling before you compare quotes.