Firmware for medical devices, with the IEC 62304 documentation written alongside.

Finished firmware, a submission date and missing documents

The firmware of a battery powered device works and is close to an FDA submission. Architecture, detailed design, SOUP records, test specifications, the threat model (a structured analysis of how the device could be attacked) and the SBOM (software bill of materials, the list of every software component in the build) are missing or out of date.

We start with a gap analysis (a review of what is missing against the standard) of the documents, the code and the process, then write the missing records from the code and check them against the intended use, the system requirements and the risk file. Where the original development evidence is missing, the gap analysis says so. The records include the architecture, the Software Design Specification, requirements with traceability and the verification specifications. The RTOS, the vendor SDK, the BLE (Bluetooth Low Energy) stack and a third party bootloader go into the SOUP list with version, known anomalies and risk assessment, and the SBOM is generated from the build and completed by review for vendor binaries.

The engagement can be documentation only. Our engineers read the code, our regulatory specialists and FDA consultants shape the records for the submission, and your team keeps developing. Where executed test records are missing, the gap analysis names the tests that have to be run before the submission.

A wearable prototype that has to become a product

A wearable runs on a Nordic nRF52 with Zephyr. The prototype works, firmware updates hang now and then, and nobody in the team is an embedded specialist.

We review the code and the update path first, from the bootloader and image signing to the BLE transport and the recovery after a failed update. The update problem is reproduced under control and fixed at its root cause.

Then the firmware is restructured into testable modules, a development plan and the IEC 62304 records are set up for the software safety classification, and the device can move towards CE marking or an FDA submission.

Long running RTOS firmware that is hard to change

A device has firmware on an STM32 with FreeRTOS that is ten years old. Every change is risky, tests need the physical device and the original developers are gone.

We add a simulation mode and a hardware abstraction layer, so unit and integration tests run in CI without the device, and hardware in the loop rigs cover the rest. The build is made reproducible with fixed tool versions.

Refactoring then goes module by module under your change control, and the same team can take over long term maintenance, SOUP updates and new releases.

A measurement device with several modules

A patient measurement device has separate modules for ECG, blood pressure, SpO2 or temperature, each with its own microcontroller, and a design verification milestone ahead.

Each module gets firmware on a common hardware abstraction interface, implemented for its microcontroller, with its safety class (A, B or C, by the harm a software failure could cause) set by the risk analysis and by verified segregation between the modules, since a separate microcontroller alone does not establish it, and its own interface to the main unit. Alarms, fault reactions and plausibility checks are traced to the ISO 14971 risk file, and the device level evidence for IEC 60601-1 and the particular standards for each measurement is prepared with your system engineers.

Verification is planned from the start, with automated regression on every build, so the verification record grows with the code up to the milestone.