Your hardware is late. Your SiMD verification doesn't have to be.

Hardware-software decoupling lets SiMD teams verify clinical logic months before the first PCB arrives. Here is how a hardware abstraction layer works, what it does and does not buy you under IEC 62304, and what still belongs in the physical lab.

The PCB is six weeks late. The software team is already on the payroll.

Anyone who has run a medical device programme knows what happens next. Developers write code they cannot execute against anything real. The unverified backlog grows. When the boards finally arrive, the first fortnight in the lab is spent chasing logic bugs that have nothing to do with hardware, and the verification window before submission shrinks by exactly the amount the board slipped.

In 6 hidden SiMD roadblocks that delay market entry, hardware dependency was roadblock number one. That article named the problem and pointed to hardware abstraction layers and digital twins as the way out. This one is about how to actually do it: what decoupling changes in a software in a medical device (SiMD) programme, what it costs, and where its limits are.

At a glance

Why hardware dependencies inflate SiMD cost

Embedded medical device software talks directly to sensors, radios, memory and power management. When the clinical logic is written against those interfaces rather than behind them, a change in one component ripples across the codebase, and a delay in one component stalls everything. Four risks follow, and each has a price.

1. Blocked workstreams

The business impact: On a 12-month SiMD programme, a six-week board delay with tightly coupled software is a six-week delay to the whole programme. Engineers are paid either way; what they produce in that window is code nobody can verify, and that backlog comes due during integration, when time is scarcest.

The modern approach: Put a stable interface between the application and the hardware, and give the application something to run against before the boards exist. The six weeks then cost the driver author six weeks, and nobody else.

2. Component changes that become rewrites

The business impact: A microcontroller or sensor reaching end-of-life mid-lifecycle is routine; many MedTech bills of materials carry parts with shorter commercial lives than the device itself. Dual-sourcing is the standard mitigation, but if the software is bound to one chip's registers, every alternative part means a scattered rewrite and a broad re-verification campaign.

The modern approach: Confine hardware specifics to a driver layer so that a part change is a driver change. The clinical algorithm is untouched, and the re-verification argument says so in the architecture, not just in a memo.

3. Cybersecurity patches that trigger full re-verification

The business impact: Post-market cybersecurity expectations (FDA's premarket cybersecurity guidance, EU MDR Annex I) assume you can patch a wireless stack or bootloader during the device's life. With coupled code, the change-impact assessment for such a patch cannot be bounded, so the safe answer is a full regression, and a full regression is why patches ship late.

The modern approach: A clear architectural boundary lets you scope the change-impact assessment to the affected layer, run targeted regression against the interface contract, and document why the clinical logic was out of scope. That is what keeps a security patch from becoming a re-submission-sized event.

4. Unpredictable release schedules

The business impact: If logic can only be tested on physical prototypes, defects in the core clinical behaviour do not surface until final integration. Every one found there is found with the least time left to investigate, fix and repeat the affected tests before a regulatory submission.

The modern approach: Find logic defects on every commit, in a pipeline, with a traceable record. The lab then sees only the defects that need a lab.

How a hardware abstraction layer isolates risk

A hardware abstraction layer (HAL) separates hardware-specific operations from the application logic that uses them. The application sees a defined interface; the HAL implementation behind it talks to the real silicon.

A note on the word, because embedded teams use it two ways. The HAL in this article is the interface your application owns and your team specifies. The vendor HAL (ST, Nordic, the Zephyr driver model) sits underneath it and is a convenient implementation detail, not the boundary. It is also software of unknown provenance under IEC 62304 §8.1.2, with the SOUP obligations that follow; keeping it below your own interface is what stops those obligations from reaching the clinical logic.

Take a connected device that monitors a patient's temperature. The clinical algorithm needs a reading to decide whether to raise an alert. It should not need to know the register map, the I2C protocol or the driver implementation of the thermistor. It calls read_temperature() on the HAL and gets a value, a timestamp and a status. Whether that value came from a physical sensor, a different sensor after a part change, or a test double feeding in 41.5 °C to check the alarm path is invisible to the algorithm, and that is the point.

Four things get called "simulation" in this context, and they are not interchangeable:

Most SiMD teams get the largest return from the first and third rows. The second and fourth earn their keep on complex or long-lived platforms.

Decoupling in practice: a four-step workflow

Follow that temperature-monitoring device through its lifecycle.

1. Concurrent development. While the PCB is being manufactured, the software team writes the clinical alerting logic and the user interface against the HAL interfaces only. No code above the HAL references a register, a bus or a part number.
2. Virtual verification. Through a mock, the team injects extreme highs, missing packets, out-of-range and malformed inputs. They confirm the software fails safely and raises the right alarms. Because the test environment has been assessed as fit for that purpose (more on this below), the results are recorded as early verification evidence, traced to the software version and the test configuration.
3. Hardware integration. When prototypes arrive, nobody is hunting for logic bugs. The lab time goes to what cannot be simulated: analogue signal noise, battery drain, I2C bus timing, thermal behaviour.
4. Component replacement. A year after launch the thermistor is discontinued. The team documents the change impact, rewrites one driver inside the HAL, reruns the automated suite to show the clinical algorithm is unaffected, and limits manual re-testing to the new physical interface.

That bounds the software work. It does not bound the device work: a new sensor changes the measurement chain, so accuracy, response time and drift are re-verified against the device’s performance claims, the risk file is updated, and the change is assessed for significance under MDR or FDA’s change guidance before it ships. The HAL keeps the clinical algorithm out of that assessment; it does not keep the device out of it.

The objective is not to replace physical testing. It is to make sure that when the hardware finally arrives, your software has already undergone appropriate, traceable verification.

One illustrative figure for the economics: in our experience on wearable projects of this kind, the majority of application-level defects surface and are fixed in simulation before the first hardware arrives. The lab finds the rest, and the lab is exactly where those belong.

When not to abstract

A HAL is a layer, and every layer is code to write, review, test and maintain under IEC 62304. It is not free, and it is not always worth it.

It usually pays when several of these are true:

• The application touches many hardware interfaces, or the same application will ship on several hardware variants.
• Any part on the bill of materials has a realistic chance of going end-of-life inside the device's commercial life, or the supply chain has already forced a substitution once.
• Late-stage integration failures have historically cost the programme weeks.
• The device will take post-market software updates, including cybersecurity patches, for years.
• Hardware and software are on different schedules or with different suppliers.

It usually does not pay for a single-chip, single-variant device with a fixed, long-life bill of materials, a short update horizon and a hardware team that sits next to the software team. There, a thin driver layer and a disciplined interface convention give most of the benefit at a fraction of the overhead. Abstracting that device is engineering for a future it will not have.

The test is simple: if you cannot name the second implementation of the interface (a second sensor, a mock, an emulated board), you do not need the abstraction yet.

Verifying SiMD before the hardware exists

Once hardware dependencies sit behind an interface, verification can move earlier in the lifecycle, the practice usually called shift-left testing. Final verification on representative hardware remains mandatory. What changes is how much reaches it.

1. Mocks and test doubles at the HAL boundary

A mock reproduces the responses the application expects from a peripheral. A heart-rate monitor team can inject sustained tachycardia, a flat line, a sensor-disconnect status or a corrupted frame and prove the software reaches its safe state every time. The limit is built in: a mock only reproduces the behaviour you programmed into it. It can show the logic is correct. It cannot show the sensor will behave as the mock did.

There is a second limit worth stating. Mock-based tests usually run on a host machine with a host compiler, and integer widths, floating-point behaviour and structure packing can differ from the target toolchain. For Class B and C software, plan for the same tests to run at least once on the target compiler, on an emulator or the bench, and say so in the fidelity statement. Host results are early evidence; target results are the evidence.

2. Emulation of the target platform

Instruction-set emulators such as QEMU run the real compiled image on a virtual CPU and board, which makes them the natural home for driver logic, OS integration and memory behaviour. Teams increasingly run fleets of emulated instances in cloud CI, which is how a nightly soak test across every supported variant becomes affordable. The results are only as good as the emulator's fidelity to the target, and timing-sensitive behaviour, analogue characteristics and power consumption fall outside what emulation can be trusted for.

3. Automated tests in the CI/CD pipeline, with traceability built in

The pipeline compiles the software, runs unit tests and executes simulated interface tests on every commit. For a medical device the extra requirement is that every run leaves a record a reviewer can follow: the software version, the test configuration, the environment it ran in, and the requirement and risk control each test covers. Done this way, the pipeline is not just a quality tool; it is the mechanism that generates verification evidence continuously instead of in a documentation sprint before submission, which was roadblock number two in part one.

What decoupling means for IEC 62304 and your QA team

Quality leaders are right to scrutinise any testing performed away from the final target hardware. The honest position is this: a HAL does not demonstrate IEC 62304 compliance by itself, and no simulated test replaces verification on representative hardware. What decoupling does is make several things the standard already asks for easier to do and easier to show.

Architecture (IEC 62304 §5.3). The standard asks for a software architecture that identifies software items and their interfaces. A HAL is a real, inspectable boundary: the interface specification is the architecture document, and the segregation between clinical logic and hardware-specific items is visible in the code, not asserted in a diagram.

Detailed design and unit verification (§5.4, §5.5). Units above the HAL can be verified against a defined interface with acceptance criteria that do not depend on which sensor is fitted. That makes unit verification repeatable and automatable.

Integration (§5.6). Software integration can be staged: application-to-HAL integration in simulation, HAL-to-hardware integration in the lab. Each stage has its own evidence and its own anomalies, and a reviewer can see which failures belonged where.

Maintenance and change control (§6, §8). The change-impact analysis for a driver rewrite or a cybersecurity patch can be bounded by the interface. "The clinical algorithm was not modified and its interface contract is unchanged" is a defensible statement when the architecture enforces it.

Risk management (ISO 14971, IEC 62304 §7). Fault injection through a mock is the cheapest way to exercise the hazardous situations in your risk file: sensor failure, data loss, out-of-range input. Each becomes a repeatable test rather than a one-off bench exercise.

The condition on all of this is that the simulated environment is fit for its intended use and documented as such. IEC 62304 does not prescribe how; ISO 13485 §4.1.6 and §7.6, and by extension FDA’s QMSR, which incorporates ISO 13485 by reference, expect software used in the quality system, which includes test tooling, to be validated for its intended use. In practice that means a short, written statement of what the mock or emulator faithfully represents (logical states, data formats, protocol sequences, error codes) and what it does not (thermal dynamics, electrical noise, timing, power), with the test cases allocated accordingly. That statement is what turns a green CI run into verification evidence a reviewer will accept.

What still needs physical hardware

Decoupling changes when and where you test. It does not close the lab. A passing simulated test establishes that the software behaves correctly against a model of the hardware; it does not establish that the complete device performs as intended. This is the allocation most SiMD programmes end up with.

Read the last two rows as the point, not the caveat. They are where lab time should go, and decoupling is what frees it to go there.

The schedule is yours again

Hardware-software decoupling gives a MedTech manufacturer back control of its own timeline. Software work that does not need the hardware proceeds without it; defects that do not need a lab are found before one is booked; a part change or a security patch is a bounded event with a bounded verification argument. The physical lab keeps the work only it can do, and gets it with time to spare.

None of this requires a new standard or a new tool. It requires one architectural decision made early, and a quality team that is brought into that decision rather than presented with its results.

Take the next step

• Review your architecture. If you are planning a connected device or modernising an existing platform, talk to our HealthTech engineering team about a 30-minute architecture review. We will tell you whether a HAL pays off on your device, including when it does not.
• Start with the diagnosis. If you have not read part one, 6 hidden SiMD roadblocks that delay market entry covers the other five.

Get the checklist.

The allocation table above is available as a one-page Simulated vs physical verification coverage checklist you can adapt to your own device. 

Download

Simulated vs physical verification coverage

Thank you for downloading our infographic. You can find the document in your downloads. :)

• Name
• Last Name
• Company Name
• Email Please enter your company email address.

Download