AI adoption brings real pressures:

• Prove ROI on LLM initiatives.

• Protect data privacy & compliance when using open-source models.

• Scale responsibly without being derailed by hallucinations, talent gaps, or security risks.

That’s why we built TechLeader Voices by Packt — a newsletter that delivers real-world playbooks, frameworks, and lessons from frontline AI leaders.

Subscribe today and unlock the Executive Insights Pack — including 1 report, 1 case study, and 5 power talks — valid for the next 48 hours only.

Hi

Welcome to the sixteenth issue of Deep Engineering.

This edition was created in collaboration with Alexander Kushnir, principal software engineer at Johnson & Johnson MedTech. Kushnir specialises in electrophysiology systems and brings roughly two decades across medical devices, industrial controllers, and networked embedded platforms. He has worked on motion-control firmware, network switches, VoIP, and medical software; his core expertise spans embedded Linux, modern C++, cross-platform development, and HW/SW integration. He has also built and led a two-day workshop on CMake.

In today’s feature, we use Kushnir’s field experience to examine what it takes to design software that must survive regulatory cycles, hardware obsolescence, and engineering turnover. You’ll find practical, transferable habits: clear boundaries between certified and updatable code, disciplined OTA with rollback, modularity via HAL/RTOS, SoM-based hardware strategies, CI-gated changes, and a quality culture that resists bit-rot.

📢 Important: Deep Engineering is Moving to Substack

The shift to Substack is underway. Some of you may receive two emails today including one from[email protected]. Thank you for bearing with us during this transition and the inconvenience is regretted.

To ensure uninterrupted delivery, please whitelist [email protected]in your mail client. No other action is required.

Sign Up |Advertise

The FDA’s June 2025 guidance on medical device cybersecurity explicitly requires manufacturers to provide a “reasonable assurance” of ongoing security throughout a device’s lifecycle, including verifiable secure update mechanisms and a documented process for managing vulnerabilities over at least a decade. That means devices must support signed and authenticated firmware updates, with audit logs and the ability to rollback if needed, for 10+ years after release. Regulators now expect evidence in premarket submissions that companies have planned for ten-year supportability via patch management and cybersecurity monitoring. This shift, reinforced by new laws like the U.S. FD&C Act §524B, reinforces that designing for longevity is a fundamental safety requirement, not just a business choice.

As Alexander Kushnir observes:

“Any update that could affect safety or compliance still requires formal review and, if necessary, re-certification. In practice, we (can) minimize disruption by:

In this way, the need to keep embedded software up to date becomes operationally similar to maintaining conventional PC or cloud-based software, but with the extra discipline required for regulated environments.”

Meeting a 10+ year lifespan requires disciplined platform and toolchain management. Here are three strategies to achieve this:

Kushnir also recommends that teams:

“Use industry-standard and up-to-date tools: Even though it is not a hard requirement, tools keep evolving, and if you fall too far behind, then when you eventually need to investigate an issue in the field, you may find yourself forced to use newer tools you’ve never worked with—leaving you at a disadvantage.”

Long-lived projects should treat toolchain, OS, and library updates as part of the regular engineering cycle (with CI tests to catch issues early). It’s far easier to sustain a system when its underpinnings aren’t frozen in time.

Robust OTA (over-the-air) update capability is now a first-class feature of any long-lived system. In fact, the FDA’s new rules require manufacturers to implement secure update mechanisms and to have a postmarket vulnerability management plan. This aligns with the best practices many teams have already learned through hard experience.

A recent OTA checklist from Memfault highlights the critical elements of a sustainable update framework: signed and validated firmware images, explicit hardware/firmware compatibility checks before deployment, support for atomic rollback if an update fails, staged rollout mechanisms, and fleet monitoring to catch issues early. This means:

Implementing such an update system though is not trivial. Fortunately, tooling is rising to meet the challenge. Cloud IoT platforms and services can manage device cohorts and track update metrics. Even development tools are integrating quality gates to enforce update readiness: for example, GitHub in August 2025 made repository rulesets and merge queues generally available, allowing teams to require that all code passes tests and security checks before it’s merged and queued for release.

As Kushnir emphasizes

“CI tests are a must. I would even say that every pull request should be gated, i.e. only if the pull request passes all the tests, should it be merged. Many developers don’t like writing tests, but as a matter of fact, the tests protect them, and provide developers the confidence to make major changes without breaking things.”

Long-lived systems will face newfound vulnerabilities (e.g. a cryptographic library weakness discovered in 2028) and changing requirements, so shipping without a safe update path is simply not acceptable in 2025.

A recurring theme in longevity engineering is abstraction with discipline. Systems that endure tend to be built with clear hardware abstraction layers and modular components, so that sub-parts can be replaced or updated with minimal ripple effect. Two tactics to mitigate obselescence:

Using standardized RTOS and HAL can allow you to swap out one microcontroller for another years later if the original becomes obsolete, without rewriting the entire codebase. Kushnir recommends:

Abstract all you can. Whether one is taking the OOP approach… or a procedural one, abstraction and modularity must be applied. Hardware Abstraction Layer (HAL) is an excellent example of abstraction, as the application logic is not aware of the hardware (for example Linux paradigm took abstraction to the edge - everything is a file, whether it is a network connection, hardware device, or a real file - the user reads from and writes to a file).

Recently the Zephyr RTOS (an open-source, cross-platform RTOS) has gained massive adoption and ecosystem support. Zephyr’s latest 4.2 release (July 2025) was its largest ever, setting a contribution record with 810 developers contributing and adding support for 96 new boards and 22 shields in one release.

This kind of broad hardware support and vendor backing (Silicon Labs, NXP, Intel, etc. are all involved) means that a product built on Zephyr can more easily move to new hardware in the future – the OS abstracts the MCU details and already supports a wide range of CPUs from ARM Cortex-M to RISC-V and even Renesas RX. The modularity and community maintenance of such an RTOS reduce the burden on your team to support every low-level detail for years.

In fact, companies traditionally known for proprietary environments are embracing this: IAR Systems (known for their commercial compilers/IDEs) announced in 2025 full production-grade support for Zephyr RTOS in their toolchain, including optimized compilers, debugging, and even functional safety certification for using Zephyr in ISO 26262 or IEC 62304 contexts. This convergence of open-source OS with professional tools indicates that using open ecosystems no longer means forsaking quality or support. On the contrary, it can lower integration costs and prolong maintainability, since you benefit from upstream improvements and a larger talent pool familiar with the technology.

Another architectural tactic to fight obsolescence is to leverage system-on-modules (SoMs) or long-life silicon platforms. According to Kushnir:

“When designing a hardware platform, the engineer must ensure that the components he chooses have a “long-term support”. Having said that, I prefer to use off-the-shelf System-on-Module (SOM) integrated on a custom board, rather than developing a board with the same CPU (or FPGA) and having to address most basic interfaces such as memory or a flash storage during the board bring-up. This reduces the complexity of board bring-up and makes it easier to handle hardware obsolescence, because the SOM vendor typically manages low-level design, interface validation, and long-term component sourcing.”

Many embedded suppliers also offer product longevity programs – for example, NXP’s Product Longevity program guarantees certain microcontrollers will be manufactured for 10 or 15 years. Choosing components under such programs, or designing your PCB to accommodate multiple pin-compatible variants, can save you from a costly redesign when one chip goes end-of-life.

In a training webinar on designing for longevity, NXP experts John Terpening and Jim Hoffmann highlighted the importance of SoC selection and supply chain planning: pick parts with known long-term availability, and avoid “cutting-edge” components that might be discontinued in a few years if they don’t find a broad market. They also suggest maximizing the bill-of-materials lifecycle while minimizing sustainment activity – i.e. use parts and modules that will stay around, even if it means slightly less cutting-edge tech, so that you aren’t forced into constant component churn.

Abstraction helps here too: if you design with a clean separation between hardware-specific code (device drivers, BSPs) and your business logic, swapping out a sensor or radio module for a newer one (or a second source) is far less painful.

Longevity in hardware means expecting that something will become unavailable or outdated – be it the processor, an OS kernel, a radio chipset, or an encryption algorithm – and structuring your system so you can adapt. Loose coupling, standard interfaces, and broad community support all increase your resilience to inevitable change.

Designing for longevity also means anticipating the evolution of security threats and cryptography. What is secure today may be woefully insufficient in 10-15 years (consider that 15 years ago, SHA-1 and 1024-bit RSA were considered fine, which is no longer true). As Kushnir says:

“To keep a system secure for 10+ years, the update mechanism itself must be secure: signed and verified updates, encrypted transport, and a rollback option in case an update fails.”

An illustrative development in 2025 was NIST’s finalization of its Lightweight Cryptography standard, built on the Ascon algorithm family. This standard (NIST SP 800-232) specifically targets constrained devices – IoT sensors, medical implants, wireless tags – providing modern authenticated encryption and hashing that are efficient enough for low-power microcontrollers. Ascon was chosen for its robustness (withstood years of public cryptanalysis) and its ease of implementing countermeasures against side-channel attacks.

The emergence of standards like this indicates three best practices:

Longevity requires a security roadmap. Engineering teams must choose the right algorithms, build in the means to rotate keys or ciphers, and plan for secure updates.

Perhaps the most important ingredient for longevity is culture. As Kushnir says:

“Code review isn’t done just because “that’s the rule”; it’s done to catch defects and improve design. The same goes for documentation and tests—they’re tools, not rituals.”

Technical strategies will fall short if the engineering culture doesn’t value quality and continuous improvement. NASA’s approach to software is a case in point: to support missions that last decades (or human-rated vehicles with zero tolerance for failure), NASA instills a culture of exhaustive testing, peer review, and learning from mistakes. In a 2025 talk on how NASA tests their software for the Space Shuttle and Orion programs, NASA’s Darrel Raines explained that they use 4 to 7 levels of testing for each change, with independent verification teams and software quality assurance groups dedicated to finding potential defects. They deliberately bring in fresh eyes – separate teams that try to validate the software – to avoid blind spots.

This multi-layer test strategy, combined with strict coding standards and oversight, is how they achieved the Shuttle’s famously low defect rate (arguably one of the most reliable software systems ever built). Raines also emphasized using a diversity of tools and methods to catch errors: simulations, hardware-in-the-loop, static analysis, formal methods, etc., each can find different classes of bugs.

The philosophy is to never trust a single approach – if something is mission-critical, test it in many ways and assume nothing. For engineers in other domains, NASA’s example underscores that preventing and catching bugs early is far cheaper and safer than troubleshooting in the field. Thus, investing in robust test automation, code reviews, static analysis, and even techniques like fuzz testing or model checking for critical modules can pay immense dividends over a product’s life.

Modern programming practices and language features can also help here. The upcoming C++26 standard, for example, is adding design by contract capabilities (preconditions, postconditions, and assertions built into the language) as well as compile-time checks and safer standard library features. Embracing such features in embedded code can catch errors early or make the code’s assumptions explicit, easing maintenance. C++26 also brings improvements like bounds-checked iterators, nullptr validation, and pattern matching, which aim to reduce common sources of bugs and make code more self-documenting. Using these language improvements (once available in compilers) or similar features in other languages (Ada/SPARK contracts, Rust’s ownership model, etc.) can significantly improve software maintainability. They enable what one might call self-testing code – code that fails loudly if misused rather than silently corrupting data.

Finally, maintainability culture means continuous refactoring and knowledge sharing. A codebase is not a fixed asset; it’s a living one. Teams that succeed over the long run treat technical debt with the same seriousness as feature development. They allocate time in each release cycle to update stale documentation, improve code clarity, and refactor overly complex areas – especially if those areas hinder testing or pose a risk for future bugs. Long-serving products often see multiple generations of engineers; investing in clear code and design pays off when new eyes must understand the system in 5 or 8 years. In regulated industries, it also pays off during audits and recertifications if the design rationale is well-documented.

In the end, the true measure of success for safety-critical products is not just how well they work at launch, but how reliably and safely they continue to operate years and millions of hours later, when initial developers have moved on and the world around them has evolved. Achieving that kind of lasting dependability is difficult – but it has become the baseline expectation.

A MedTech systems engineer unpacks what it means to build software that must survive regulatory cycles, hardware obsolescence, and engineering turnover.

Zephyr RTOS 4.2 – Open-source real-time OS for production-grade embedded devices

Zephyr is a small, modular RTOS used in commercial products across Arm, RISC-V, and other MCUs. The 4.2 release (July 19, 2025) expands hardware coverage and streamlines portability work for long-lived systems.

Highlights:

That’s all for today. Thank you for reading this issue ofDeep Engineering. We’re just getting started, and your feedback will help shape what comes next. Do take a moment tofill out this short surveywe run monthly—as a thank-you, we’ll addone Packt creditto your account, redeemable for any book of your choice.

We’ll be back next week with more expert-led content.

Stay awesome,
Divya Anne Selvaraj
Editor-in-Chief,Deep Engineering

If your company is interested in reaching an audience of developers, software engineers, and tech decision makers, you may want toadvertise with us.