IN Brief:
- More than 500 embedded engineering decision-makers were surveyed across several regulated industries.
- Ada, SPARK, and Rust ranked strongly for safety, security, and reported lifecycle performance.
- Project maturity, certification requirements, and team experience remain important when interpreting the cost results.
VDC Strategy has examined the relationship between programming-language selection, embedded software cost, security, delivery schedules, and maintenance through a study involving more than 500 engineering decision-makers.
Automotive, aerospace, defence, energy, industrial, and medical programmes are represented in the research. More than 70% of the projects were subject to safety standards, while 55% included real-time requirements, placing language decisions within environments where predictable execution and verifiable behaviour carry substantial weight.
Around 85% of respondents identified programming-language choice as a factor in system safety or security. Ada, SPARK, and Rust ranked strongly among the 26 languages considered, reflecting their ability to prevent or expose classes of error that can remain difficult to identify in less constrained development environments.
Median development costs for some memory-safe language projects were reported at between half and one quarter of comparable C or C++ programmes. Ada projects recorded a higher proportion of schedules completed ahead of plan, while SPARK users reported strong delivery performance alongside lower defect-related expenditure.
Differences continued after release, with some memory-safe projects recording patching and remediation savings approaching or exceeding 60% over seven years. Teams using those languages were also more likely to direct engineering time towards new analytics or artificial-intelligence functions instead of corrective maintenance.
Memory safety restricts faults such as invalid pointer use, out-of-bounds access, use-after-free errors, and uncontrolled memory corruption. Within embedded equipment, those defects can produce intermittent resets, corrupted control data, exploitable vulnerabilities, or unsafe behaviour that appears only under unusual timing and load conditions.
Language choice sits within a wider engineering system
Although the study identifies substantial differences between language groups, it does not isolate language as the only cause. Teams selecting Ada or SPARK may already operate with stronger requirements management, formal verification, experienced safety engineers, and development processes shaped by regulated markets.
Programme characteristics also vary markedly. A long-life flight controller, a medical instrument, and a connected industrial gateway differ in certification effort, hardware constraints, software complexity, update frequency, and acceptable risk, even when each is described broadly as an embedded system.
The results nevertheless support a well-established cost pattern: defects prevented during design are generally less expensive than faults discovered during integration, certification, deployment, or field service. A language that makes invalid states harder to express can reduce the effort spent locating routine memory errors and allow verification resources to concentrate on system behaviour.
Rust has gained attention because it brings memory safety to systems programming without requiring garbage collection. Ada and SPARK provide longer experience in high-assurance development, including strong typing, contract-based programming, and formal proof techniques suited to programmes where implementation evidence must accompany the software.
Migration remains difficult because established embedded platforms contain extensive C and C++ codebases, qualified compilers, proven libraries, proprietary drivers, and engineering teams familiar with existing toolchains. Rewriting a mature product can introduce more risk than it removes, making mixed-language architectures and controlled adoption more credible than wholesale replacement.
Secure development also depends on the surrounding lifecycle. Panasonic’s certified industrial development process illustrates the combination of vulnerability management, controlled engineering evidence, and repeatable procedures now expected around connected products.
Compiler qualification, static analysis, coding rules, architecture, test coverage, update mechanisms, and developer competence remain essential regardless of language. Memory-safe software can still contain incorrect requirements, numerical faults, race conditions, timing failures, and unsafe interactions between otherwise valid subsystems.
New communications stacks, parsers, update services, and externally exposed interfaces provide practical starting points for adoption because they process untrusted data and are frequent sources of exploitable defects. Their boundaries can often be defined clearly enough to introduce a different language without rewriting the complete application.
Longer-term evidence will become more useful as additional Rust and mixed-language systems enter service. Security incidents, emergency patches, certification delays, and redesigns avoided over the operating life will provide a stronger measure than the number of defects found during initial development.
