Embedded firmware & BLE

The firmware inside the device, written under the IEC 62304 lifecycle. Battery life, wireless reliability and update security are design decisions, not later fixes.

Talk to us

When embedded firmware and BLE are the right step

When a device has a microcontroller, a wireless link or a battery life to meet. The firmware is medical device software, so its process follows from the risk it carries.

Connect a device to a phone
A wearable or bedside device that sends data over Bluetooth Low Energy to an app or a gateway.
Make a battery last
A device that must run for days or weeks on a small battery, where sleep modes and radio use decide the design.
Secure the device
Pairing, encryption and firmware updates that protect patient data and guard the device against tampering.

What you bring, and what you get back

You bring

What the device does, and how long it must run
The hardware, or its schematics
The risk analysis so far
The app or gateway it must talk to
Any existing code, and the third-party libraries in it

You get back

Software development plan
Architecture and detailed design
Unit and integration test records
List of third-party software (SOUP)
Security controls and their records
Release notes for each controlled release

The software safety class follows from risk

IEC 62304 sorts software into class A, B or C by the harm it could contribute to. Class A: no injury is possible. Class B: a non-serious injury. Class C: death or a serious injury. The class decides how much design, testing and documentation the standard requires, so set it before the code is written. A risk control outside the software, such as a hardware cut-out, can lower the class.

How embedded firmware and BLE work

Step 1
Classify and plan
The software safety class, and a development plan to match it.
Step 2
Build the architecture
Drivers, the real-time design and the wireless stack.
Step 3
Test as you go
Unit and integration tests, run on every build.
Step 4
Secure and release
Security controls, and releases under configuration control.

Questions clients ask

Is our firmware medical device software?

If it runs on a medical device and affects how the device works, yes. IEC 62304 then applies to how it is developed and maintained.

What is SOUP?

Software of unknown provenance: third-party code, such as a real-time operating system, a Bluetooth stack or a library, that was not built under your process. IEC 62304 asks you to list it, state what you need from it and assess its known faults.

Do we need Bluetooth qualification?

A product that uses Bluetooth technology and its name or logo must complete the Bluetooth SIG qualification process. A pre-qualified module can reduce the work.

Can firmware be updated after release?

Yes, if the update process is designed in: signed images, a safe fallback if an update fails, and each release under configuration control. Each change is also assessed for its effect on safety.