Network and Data Security for a Production Vision System

A vision system occupies an awkward position in a plant. It captures images, and working areas contain people. It transmits process data, which is commercially sensitive. It usually carries a remote-access channel, opened so that a supplier could support it during commissioning and left in place afterwards. None of these is unusual and none needs an exotic answer, but all three need to be decided deliberately at design time, because the default outcome of not deciding is the least secure arrangement available: a device on the corporate network, with an old remote-access route, keeping images indefinitely. The three decisions are network placement, access control and retention.

Network placement

The practical approach is a dedicated segment for production equipment, with the vision system inside it and corporate traffic kept out. Reaching the vision system from the office then requires a defined route, typically through a gateway with rules, rather than being a side effect of both being plugged into the same switch. Equipment traffic also benefits: production devices behave predictably when office traffic and broadcast storms are not sharing the link. Where the vision system must reach MES or a data platform, agree which specific endpoints are allowed, and in which direction — a vision system that can reach anything is also a system that anything can reach. Where the segment boundary sits depends on what exists already, but the general shape is always the same, and it is discussed further in MES write-back field design.

Access control and remote support

Remote access is the weakest link in practice, and it is opened for the best of reasons: an equipment supplier needs to support the system, and travelling to site takes a day. What goes wrong is not the access itself but its permanence. A defensible arrangement gives each supplier a named account and closes the channel when the support window ends, with the reopening going through a quick approval. Two accompanying habits matter as much: log who accessed the system and when, and separate read access from parameter-changing access so that reviewing data does not require the ability to alter thresholds. The second is the more commonly skipped — engineers are given a single administrator credential because it is convenient, and the system then has no meaningful audit trail at all.

Retention: decide per data type

Keeping everything forever is expensive and risky, and deleting everything quickly makes the system useless for improvement. The workable approach differentiates by data type. Alarm images and verdict records should be kept long enough to support traceability, which generally follows the product's traceability requirement. A sample of conforming-part images is worth keeping for trend analysis at much lower volume. Full continuous video, where it exists at all, has the shortest justified life and is usually kept in days or weeks rather than months. What matters is that the policy is written down and implemented automatically, because a retention rule that depends on someone remembering to delete files will not be followed.

• Alarm records and images: per the product traceability requirement, commonly months to a few years.
• Sampled conforming images: a low-rate sample for trend analysis, typically months.
• Continuous video: only where a specific need justifies it, and then measured in days.
• Access and change logs: kept at least as long as the records they explain, since they are what makes the rest defensible.