Orvostechnikai firmware-fejlesztés IEC 62304 szerinti dokumentációval

Elkészült a firmware, közeleg a benyújtás határideje, de hiányzik a dokumentáció

Egy akkumulátoros eszköz firmware-je már működik, és közeledik az FDA-benyújtás. Az architektúra, a részletes tervdokumentáció, a SOUP-nyilvántartás, a tesztspecifikációk, a threat model (az eszköz elleni lehetséges támadások módszeres elemzése) és az SBOM (a buildben szereplő összes szoftverkomponens jegyzéke) azonban hiányzik vagy elavult.

Először gap analysist (a szabvány követelményeihez képest fennálló hiányosságok vizsgálata) végzünk a dokumentáció, a kód és a folyamatok alapján. A hiányzó feljegyzéseket a forráskódból állítjuk helyre. Ezután ellenőrizzük őket a tervezett felhasználás, a rendszerkövetelmények és a kockázatkezelési dokumentáció alapján. Ha az eredeti fejlesztésből nem maradtak bizonyítékok, ezt a jelentésben rögzítjük. Elkészítjük az architektúrát, a szoftvertervezési specifikációt, a nyomon követhető követelményeket és a verifikációs specifikációkat. Az RTOS-t, a gyártói SDK-t, a Bluetooth Low Energy (BLE) stacket és a külső fejlesztésű bootloadert felvesszük a SOUP-listába. Rögzítjük a verziókat, az ismert rendellenességeket és a kockázatértékelést. Az SBOM-ot a buildből állítjuk elő, majd a gyártói bináris állományok felülvizsgálatával egészítjük ki.

Az együttműködés kizárólag a dokumentáció elkészítésére is kiterjedhet. Mérnökeink átvizsgálják a kódot, szabályozási szakértőink és FDA-tanácsadóink pedig összeállítják a benyújtáshoz szükséges dokumentumokat. A fejlesztést ezalatt a saját csapatod folytatja. Ha hiányoznak a végrehajtott tesztek jegyzőkönyvei, a gap analysis során meghatározzuk, mely teszteket kell még lefuttatni a benyújtás előtt.

Viselhető eszköz prototípusa, amelyből terméket kell fejleszteni

Egy viselhető eszköz Nordic nRF52 mikrokontrolleren, Zephyr RTOS-szel működik. A prototípus elkészült, de a firmware-frissítés időnként megakad. A csapatban nincs beágyazott rendszerekre szakosodott fejlesztő.

Először átvizsgáljuk a kódot és a frissítési folyamatot. Ellenőrizzük a bootloadert, az image-ek aláírását, a BLE-adatátvitelt és a sikertelen frissítés utáni helyreállítást. Ellenőrzött körülmények között reprodukáljuk a hibát, majd megszüntetjük a kiváltó okát.

Ezután tesztelhető modulokra bontjuk a firmware-t, elkészítjük a fejlesztési tervet és a szoftverbiztonsági osztálynak megfelelő, IEC 62304 szerinti dokumentációt. Ezzel folytathatjuk az eszköz CE-jelöléséhez vagy FDA-benyújtásához szükséges munkát.

Nehezen módosítható, régóta használt RTOS-alapú firmware

Egy eszköz STM32 mikrokontrolleren, FreeRTOS-szel futó firmware-e tízéves. Minden módosítás kockázatos, a teszteléshez szükség van a fizikai eszközre. Az eredeti fejlesztők már nem dolgoznak a projekten.

Szimulációs módot és hardverabsztrakciós réteget alakítunk ki. Így a unit és integrációs tesztek a fizikai eszköz nélkül is futhatnak a CI-folyamatban. A fennmaradó teszteket hardware-in-the-loop tesztrendszerekkel végezzük. Rögzítjük a fejlesztőeszközök verzióit, hogy a build reprodukálható legyen.

Ezután a nálatok alkalmazott változáskezelési folyamat szerint, modulonként refaktoráljuk a firmware-t. Csapatunk hosszú távon is átveheti a karbantartást, a SOUP-komponensek frissítését és az új release-ek elkészítését.

Többmodulos mérőeszköz

Egy betegvizsgálati mérőeszköz külön modulokkal méri az EKG-t, a vérnyomást, az SpO2-t vagy a hőmérsékletet. Minden modulnak saját mikrokontrollere van. Közeleg a tervezési verifikáció egyik mérföldköve.

Az egyes modulok firmware-je közös hardverabsztrakciós interfészre épül, amelyet az adott mikrokontrollerhez implementálunk. A modulok saját interfészen kommunikálnak a központi egységgel. Szoftverbiztonsági osztályukat (A, B vagy C, a szoftverhiba okozta lehetséges ártalom alapján) a kockázatelemzés és a modulok közötti, verifikált elkülönítés alapján határozzuk meg. Önmagában a külön mikrokontroller nem indokol alacsonyabb besorolást. A riasztásokat, a hibákra adott reakciókat és a plauzibilitási ellenőrzéseket az ISO 14971 szerinti kockázatkezelési dokumentációhoz kapcsoljuk. Az eszközszintű bizonyítékokat az ügyfél rendszermérnökeivel együtt készítjük el. Ezeknek az IEC 60601-1 és az egyes mérési funkciókra vonatkozó különös szabványok követelményeit kell teljesíteniük.

A verifikációt már a fejlesztés kezdetén megtervezzük. Minden buildnél automatizált regressziós teszteket futtatunk. Így a mérföldkőig a kóddal párhuzamosan elkészül a verifikációs dokumentáció is.