by Alexander Walter (ERNI Switzerland)
Industrial machines are becoming increasingly software-driven. Sensors provide continuous data, edge devices process information close to the machine, cloud platforms connect equipment with business systems, and artificial intelligence is finding its way into quality inspection, maintenance and robotics. This creates new possibilities for manufacturers. Functions that once required a hardware redesign can increasingly be added or improved through software.
But there is another side to this development. More software means more testing, more interfaces, more dependencies and more responsibility after the product has been delivered. A defect that reaches hundreds or thousands of installed machines can become a costly field-service, cybersecurity or compliance issue. For C-level executives and programme leaders, this makes software architecture increasingly relevant to Total Cost of Ownership.
Rust is one technology worth considering in this context. It combines the native execution and low-level hardware access of C with strong memory and concurrency safety, plus a modern type system. More importantly for established manufacturers, it can be introduced alongside existing C and C++ software rather than requiring a complete rewrite. For selected components, this can help reduce the cost and risk of developing and maintaining the next generation of industrial products.
Software complexity is a cost driver
In the past, a traditional industrial product often had relatively clear technical boundaries. Embedded software controlled a device, programmable logic controllers handled automation, and higher-level IT systems dealt with data and business processes. Those boundaries are now becoming less distinct. A modern robot or machine may combine embedded firmware, perception, industrial communication, cybersecurity, edge applications, device management, AI and cloud connectivity. Products are updated more frequently and remain connected to the manufacturer throughout their operating life. Each new capability adds value, but also creates engineering work.
This is where Rust can provide value. Rust does not eliminate testing or careful engineering. Its compiler does, however, reject broad classes of memory and concurrency errors before software reaches system testing. In a complex programme, this matters because defects caught earlier are generally less expensive to resolve than those discovered during integration or after deployment. The potential value therefore extends beyond runtime performance. It can affect the amount of engineering effort spent finding problems later.
The supporting ecosystem is also maturing. STMicroelectronics, for example, now provides platform-independent Rust drivers for a growing range of MEMS sensors alongside its established C offering. Espressif provides official hardware support for Rust for its ESP32 products. For manufacturers, this type of vendor support reduces one of the practical barriers to introducing Rust into embedded products.
An automated quality gate for distributed development
This advantage becomes particularly relevant when development is distributed across internal, nearshore and offshore teams. Programme leaders often have to manage different experience levels, suppliers and development practices while still maintaining consistent product quality. Reviews, static analysis tools, coding guidelines and integration testing are used to create that consistency. Many important architectural rules and assumptions still exist only in documentation or in the minds of software architects.
Rust adds another mechanism. Its ownership and type systems force developers to make many assumptions about memory, resource access and concurrency explicit. When those assumptions are inconsistent, the software often does not compile. This does not replace code review, architecture governance or testing. Nor does it prevent logical errors. But it can act as an additional automated quality gate before software is handed from one team to another.
That is especially interesting where a company relies heavily on external engineering capacity. Quality does not have to depend entirely on every developer remembering every rule in a coding standard. Part of the rule set is enforced by the language and compiler. For programme leaders, the value is less about the compiler mechanics and more about shorter feedback loops, fewer integration defects and more consistent engineering across organisational boundaries.
Volvo Cars provides a useful example from the automotive sector. Its engineers have described onboarding as easier because developers can change and refactor code while the compiler checks that important assumptions still hold. What began as a bounded embedded initiative has since reached production: Volvo Cars has shipped its first ECU fully written in Rust as part of its SPA2 electric vehicle platform.
AI will increase the importance of software
Artificial intelligence is likely to accelerate the development further. Industrial robots are becoming better at interpreting their surroundings, recognising objects and adapting their behaviour. More of this processing is also moving onto the machine itself. The AI model is only one part of the system. The surrounding software still has to collect sensor data, manage communication, coordinate concurrent processes and translate decisions into physical actions. This becomes increasingly important as robots gain more autonomy.
Matic, for example, develops autonomous cleaning robots that perform much of their processing locally. The company chose Rust partly to combine efficient execution with reliable concurrency on constrained onboard hardware. Matic also points to the value of the compiler when changing a complex architecture: incompatible assumptions elsewhere in the software become visible while the code is being changed rather than later during operation.
Scythe Robotics has taken a similarly broad approach. The company states that it writes its on-robot software in Rust wherever feasible, citing safety, reliability, performance and development pace as reasons for the decision. Its autonomous machines have been operating outside the laboratory, where software has to deal with changing environments, sensors and hardware rather than controlled test cases.
Fusion Engineering provides another example from autonomous flight control. The Fusion Reflex flight controller is written in Rust and uses a control approach developed with TU Delft to react to disturbances such as wind gusts while maintaining stable flight. Its software is split into isolated processes so that a failure in an auxiliary component, such as GPS or communication software, does not bring down the rest of the flight control system.
Cybersecurity changes the economics after delivery
Another major change is taking place after machines leave the factory. Under the EU Cyber Resilience Act, manufacturers of products with digital elements face new obligations for cybersecurity and vulnerability handling. Reporting obligations apply from September 2026, while the main requirements apply from December 2027. The EU Machinery Regulation, applicable from January 2027, also places greater attention on software, cybersecurity and safety-related control systems.
In systems software, memory-safety defects remain a major source of serious security vulnerabilities. This makes preventing such defects particularly relevant for connected products that may remain deployed for many years.
Google’s experience with Android gives an indication of the possible scale of this effect. Google introduced Rust for new systems-level code that would otherwise have been written in C or C++. In 2025 it reported a more than 1,000-fold lower memory-safety vulnerability density in its Rust code compared with the historical density of its C and C++ code. Rust changes also spent around 25% less time in code review, while medium and large changes had about one quarter of the rollback rate.
The lesson is that some defect classes that otherwise require testing, debugging and patching can be prevented in Rust before the software runs. Across a large installed product base, this can affect both cybersecurity risk and lifecycle cost. Figure 2 illustrates the underlying TCO effect. Rust moves selected checks into development, where issues are generally easier to resolve, reducing the number of problems that can progress into integration, deployment and field support.
Safety is becoming a software engineering question
As robots and machines become more autonomous, software increasingly influences functions that can affect people and physical equipment. Functional safety is therefore becoming more closely connected to software architecture.
Rust does not make a system functionally safe, nor does it remove the need for a safety architecture, verification or certification. Its relevance is more specific. Preventing certain memory and concurrency errors by design can reduce the number of low-level failure modes that engineers need to manage. Strong typing can make invalid states and interfaces more explicit.
Qualified Rust toolchains are now making this approach possible in safety-related industrial applications. Ferrocene, for example, provides a Rust toolchain qualified for development under standards including ISO 26262 and IEC 61508, with the exact qualification scope depending on the target and libraries being used.
Sonair provides a particularly relevant example from industrial robotics. Its ADAR One ultrasonic safety sensor achieved SIL 2 and PL d certification in 2026, with the safety functionality implemented in Rust using Ferrocene. The product is now in series production and shipping on deployed industrial robots.
The architecture is also instructive. Sonair did not insist on using Rust everywhere. Non-safety functionality still runs on FreeRTOS and C, while Rust was selected for the safety domain. Processor support, dependency selection and certification still require substantial engineering work. This mixed architecture is likely to be more representative of industrial Rust adoption than an end-to-end rewrite. Rust can be introduced where its characteristics create value while proven components remain unchanged.
Where Rust is most likely to pay off
A stable controller application that has operated reliably for years may offer little reason for change. Mature C and C++ components with low maintenance costs can remain exactly where they are. Python will continue to be well suited to AI and data science work.
Rust becomes most interesting when defects are expensive to find, expensive to repair or expensive to distribute across an installed product base.
Stable and proven control logic sits on the left-hand side. If it changes rarely and has operated reliably for years, introducing a new technology may create more cost than value. There is usually little reason to rewrite it.
The case becomes more interesting towards the right. Communication gateways, networking components and update services change more frequently and are exposed to external data. New embedded and edge components combine frequent development with constrained hardware resources. These are stronger candidates because Rust’s memory safety, concurrency model and native execution address several requirements at the same time.
Safety-related functionality is shown separately because criticality alone is not sufficient reason to use Rust. The hardware platform, qualified toolchain, safety architecture and certification strategy must also support the choice. The practical starting point is where frequent change, technical exposure and the cost of failure come together.
Start with one measurable business problem
For programme leaders, a Rust initiative should therefore begin with a concrete cost or risk rather than with a language decision. A practical first step is a bounded pilot of approximately six to eight weeks. Identify a component with visible cost or risk: frequent defects, recurring concurrency issues, high QA effort, security exposure or high maintenance cost. Communication gateways, protocol parsers and new edge modules are often suitable candidates.
Implement one isolated component in Rust under realistic conditions. Use the actual hardware, development process, interfaces and deployment environment rather than an artificial benchmark. A first project can be as small as a single library. Rust compiles to native code and can expose C-compatible interfaces, allowing a Rust component to be linked into an existing C or C++ application while much of the surrounding architecture and development process remains unchanged.
Compare more than runtime performance. Measure implementation effort, QA and debugging hours, defects found during integration, CPU and memory use, onboarding effort and the ease with which internal and external teams can maintain the result. Only after this comparison should the organisation decide whether Rust deserves a larger role.
Conclusion
Manufacturing will continue to become more software-intensive. Robots will become more autonomous. More intelligence will move to the edge. Products will remain connected after delivery, while cybersecurity and regulatory obligations will increase. For manufacturers, this makes software quality increasingly part of product economics. Rust is not a universal answer to this development. It adds another option for the parts of a system where security, hardware efficiency, maintainability and frequent change come together.
These are no longer isolated experiments. Matic and Scythe use Rust inside autonomous machines, Volvo has shipped a production ECU written in Rust, STMicroelectronics provides first-party embedded drivers, and Sonair has incorporated Rust into a certified industrial safety product.
Its ability to coexist with existing C and C++ software makes that option particularly relevant for established manufacturers: adoption can be incremental and focused on areas where the current approach is already creating measurable cost. The right starting point is therefore not a broad migration programme. It is one component where the existing engineering trade-off is already visible – and where the result can be measured before deciding what comes next.
