Secure Design for Long-Lived Machine Vision Systems

Author: Andreas Rittinger, Team Manager FAE Software & Processing, STEMMER IMAGING

Machine vision systems are often expected to remain operational for ten years or more. During that time, cameras are discontinued, processors become obsolete, software libraries evolve, and new regulatory requirements emerge. The long-term success of a system therefore often depends on architectural decisions made long before deployment.

A resilient machine vision system is one that can adapt to changing hardware and software without requiring extensive redesign. Achieving this requires reducing dependencies on individual manufacturers and designing interchangeable system components with clearly defined interfaces.

Andreas Rittinger, Team Manager FAE Software & Processing at STEMMER IMAGING

Supply chain disruptions caused by economic developments, geopolitical events or component shortages have demonstrated that hardware availability cannot be taken for granted. Having a qualified second source for critical components can significantly reduce these risks, but only if replacing a component is both technically and economically feasible.

One-stop shopping at a value-add supplier simplifies procurement. Direct sourcing of components from the individual manufacturers increases dependency.

For the camera selection, the sensor and interface are often more critical than the decision for a specific manufacturer. Multiple manufacturers offer products based on the same sensors and interfaces with comparable capabilities. However, taking advantage of this flexibility requires software that is largely independent of vendor-specific implementations.

This is where machine vision standards become essential. GenICam provides a common programming interface for industrial cameras, while GigE Vision and USB3 Vision define standardised transport protocols. Together with the Standard Feature Naming Convention (SFNC), these standards allow applications to configure cameras through standardised feature names instead of proprietary APIs. Applications designed around these standards can often integrate alternative cameras with only minor adjustments instead of significant software modifications.

The same modular approach applies to other hardware components. Separating cameras, lenses, illumination, frame grabbers and processing hardware allows each subsystem to evolve independently. In contrast, highly integrated smart cameras or vision sensors with proprietary programming environments may simplify initial development, but can create strong lock-in that becomes technically detrimental, or at least expensive, over the system lifetime.

Processing hardware deserves similar consideration. GPU product lifecycles are typically much shorter than those of industrial machines. A vision system designed around a specific accelerator or hardware generation may face costly redesigns when replacement hardware is no longer available.

Finally, a required operating system update may cause device drivers to stop working. In that case the hardware itself is not the problem: the dependency between hardware and software becomes the limiting factor once breaking OS changes are introduced.

Software introduces similar long-term challenges, which are often overlooked at the start of a project. Choosing actively maintained software components is often more important than whether they are open source or commercial. Both can provide excellent long-term value when backed by sustainable organisations and clear maintenance strategies.

When evaluating software, engineers should consider several factors:

• Is the project actively maintained, and by whom?
• Does the licensing model remain suitable for the intended product lifecycle?
• How quickly are security issues addressed?
• How many additional dependencies are introduced?

The last question is frequently underestimated. Modern software frameworks can introduce hundreds of transitive dependencies. Including an entire framework solely to support a single file format or utility function may unnecessarily increase maintenance effort, software size and long-term risk. By contrast, a careful modular design based on minimal packages pays off quickly.

Hardware abstraction deserves the same attention in software architecture. While proprietary programming frameworks such as CUDA can provide excellent performance on supported hardware, they also create dependencies on a single hardware ecosystem. Open standards such as OpenCL or SYCL may offer greater flexibility when long-term portability is a primary design objective, even if they require additional engineering effort or involve performance trade-offs.

Software transparency and the Cyber Resilience Act

The EU Cyber Resilience Act (CRA) further increases the importance of understanding software dependencies. Its vulnerability reporting obligations have applied since September 2026, and the main requirements for products with digital elements follow in December 2027. Software Bills of Materials (SBOMs) are becoming an essential tool for documenting the components contained within a product.

Although SBOMs are primarily discussed in the context of cybersecurity and vulnerability management, they also provide valuable insight into long-term maintainability. They reveal which libraries originate from small individual projects, which dependencies are no longer maintained, and which third-party components could become future liabilities. This visibility enables engineering teams to identify and reduce technical risks before they become operational problems.

Supplier dependencies cannot be eliminated entirely. Cameras will reach end-of-life, software projects will change direction, and hardware platforms will evolve. The objective is therefore not to remove dependencies, but to manage them deliberately.

A robust machine vision architecture separates hardware and software into well-defined modules with stable interfaces. Each module should expose only its intended contract while remaining tolerant of reasonable variations in the behaviour of connected components. Designing interfaces with interchangeability in mind enables individual components to be replaced with minimal impact on the surrounding system.

Ultimately, maintainability is achieved not through selecting a particular manufacturer or technology, but through architectural decisions that preserve freedom of choice. Systems built on open standards, modular interfaces, carefully selected dependencies and transparent software supply chains are better prepared to adapt to future technological, commercial and regulatory changes throughout their operational lifetime. However, even the best architecture cannot eliminate operational risk. Long-term resilience also depends on disciplined lifecycle management, regression testing, spare part strategies and continuous monitoring of component availability.

As an independent enabler, STEMMER IMAGING can support many of these operational aspects, for example by actively managing product lifecycles and identifying suitable replacements. On the software side, Common Vision Blox provides an SBOM in the standardised CycloneDX format, giving teams the visibility to monitor their dependencies over the system lifetime.

Why does a machine vision system need a long-term architecture strategy?

Machine vision systems are often expected to run for ten years or more, while cameras are discontinued, processors become obsolete and software libraries evolve. Architectural decisions made before deployment determine whether components can be replaced without extensive redesign.

How do GenICam, GigE Vision and USB3 Vision reduce dependence on a single camera manufacturer?

GenICam provides a common programming interface for industrial cameras, and GigE Vision and USB3 Vision define standardised transport protocols. Together with SFNC, they let applications configure cameras through standardised feature names, so alternative cameras can often be integrated with only minor adjustments.

What is an SBOM and why does it matter for machine vision software?

A Software Bill of Materials documents the components contained within a product. Beyond vulnerability management, it shows which dependencies are no longer maintained or could become future liabilities, which supports long-term maintainability.

What does the Cyber Resilience Act mean for machine vision systems?

The EU Cyber Resilience Act increases the importance of understanding the software dependencies within a product. Its vulnerability reporting obligations have applied since September 2026, with the main requirements following in December 2027.

Does Common Vision Blox provide an SBOM?

Yes. Common Vision Blox provides an SBOM in the standardised CycloneDX format, giving teams the visibility to monitor their dependencies over the system lifetime.