Machine Design #75: Safe Remote Support — Connection Does Not Mean Permission to Control
Remote support cuts downtime. It also creates a convenient path along which a machine can be changed without anyone at the site knowing it happened. The design question is not whether the connection works, but who is allowed to do what through it, and what evidence remains afterwards.
Separate watching, diagnosing and controlling
The right to read a log should not carry the right to edit a PLC or issue a motion command. Treat these as three levels, each with its own authorisation, its own indication at the machine, and its own condition on the floor.
| Level | Typical action | What it must require |
|---|
| Observe | Read logs, trends, alarm history, screen view | Identified user, session record |
| Diagnose | Force a value in a test mode, read program state | Approval, a defined scope, an operator informed |
| Control | Write to the program, command motion, change configuration | Approval, a person present at the machine, zone control |
Write these decisions into the requirement, the architecture, the configuration or the test case that owns them. A rule that only exists in a PLC comment, or in one engineer's memory, is not a rule.
Connect by session, with approval
A session needs a requester, an approver, a purpose, a time limit and a ticket. A shared account or a tunnel that is always open destroys accountability: afterwards, nobody can say which of five people made the change, or why.
Practical consequences:
- Individual accounts, not a shared engineering login.
- A session that expires by itself rather than one that has to be remembered and closed.
- Access granted for a stated purpose and revoked when that purpose ends, including contractor access after commissioning.
Local control must know what remote is doing
The machine has to show the state of the session, who is connected and what they are allowed to do. Anything that can produce motion has to be coordinated with the procedure, the zone control and the person standing at the machine — not decided by whoever is at the far end of the link.
The practical test: someone standing at the machine should be able to answer "is anybody connected right now, and can they move this axis?" without opening a laptop.
Protect the update path
Package, checksum, signature, backup, rollback and a configuration baseline all have to exist before anything is changed. Remote access does not lower the requirement for validation; it only removes the person who would have noticed something looked wrong.
Before a remote change:
- take a backup of the running configuration and record its version;
- know how the change will be reversed, and how long that takes;
- decide who confirms the machine has returned to the baseline afterwards.
Log, and rehearse the failure
Record logins, commands, file transfers, changes and disconnects. Then test the cases that matter: the network dropping mid-session, a credential being revoked while a session is open, and the connection being isolated on purpose. In each case the machine must reach a state that was decided in advance, not a state that happens to result.
That rehearsal is what separates a documented remote-access policy from one that has been proven.
Review checklist
- The scope and the boundary of remote access are defined.
- Normal, abnormal and restart behaviour are all specified.
- The right to act, and the owner of each decision, are clear.
- Timeout, retry, reset and bypass are bounded and logged.
- Data carries identity, timestamp and version.
- Negative tests and fault injection exist, not only the happy path.
- A rollback plan and a criterion for "back to baseline" exist.
- Documents, code, HMI and procedure use the same vocabulary.
- Anything touching safety or security has been reviewed by the right specialist.
Conclusion
Safe remote support is a question of architecture and lifecycle, not a block of logic added at the end of a project. When state, identity, operating rights, data and recovery each have a clear contract, the machine is easier to run, to investigate and to change, without depending on the memory of whoever wrote the original program.
Public references
- IEC 62443-2-1, IEC 62443-3-3, IEC 62443-4-2
- NIST SP 800-82 Rev. 3
View all MINATA technical articles