Model V w rozwoju oprogramowania wbudowanego urządzeń medycznych. Jak inżynieria systemów zabezpiecza cykl życia produktu?

Model V (V-Model) jest naszym fundamentem inżynieryjnym. To systemowe podejście do rozwoju produktu, które w naturalny sposób odpowiada na wymagania dotyczące jakości urządzeń medycznych.

Rynek wyrobów medycznych (Medical Devices) należy do najbardziej rygorystycznych sektorów gospodarki. O ile błąd w aplikacji mobilnej czy systemie CRM skutkuje co najwyżej irytacją użytkownika lub stratą finansową, o tyle awaria oprogramowania wbudowanego (embedded software) w defibrylatorze, pompie infuzyjnej czy systemie monitorowania pacjenta może bezpośrednio zagrozić ludzkiemu życiu.

Dla startupów medycznych oraz doświadczonych producentów sprzętu (OEM) proces certyfikacji i przejścia przez audyty jednostek notyfikowanych bywa barierą nie do przebicia. Kluczem do sukcesu nie jest pisanie kodu „na czas”, ale udowodnienie, że każda pojedyncza linijka oprogramowania powstała w sposób kontrolowany, powtarzalny i w pełni bezpieczny.

W ICU tech od lat łączymy zaawansowane projektowanie elektroniki z tworzeniem niezawodnego software’u. Poniżej szczegółowo analizujemy, jak Model V chroni projekty naszych klientów przed błędami w kodzie, optymalizuje koszty i gwarantuje płynną certyfikację wyrobu.

Podsumowanie AI

1. Model V odpowiada na rygorystyczne wymagania jakościowe rynku wyrobów medycznych. * W Modelu V plany testów oraz kryteria akceptacji są tworzone równolegle z definiowaniem wymagań i architektury systemu.
2. Struktura wymagań normy IEC 62304 idealnie mapuje się na topologię Modelu V, wymagając m.in. pełnej identyfikowalności wstecznej i postępującej.
3. Automatycznie zarządzana Macierz Identyfikowalności (Traceability Matrix) integruje poszczególne fazy projektu i stanowi kluczowy dowód podczas audytu jednostki notyfikowanej.
4. Rozwój produktu w oparciu o Model V zmniejsza koszty biznesowe, ponieważ wykrycie błędu na wczesnym etapie jest znacznie tańsze niż po wdrożeniu urządzenia na rynek.

Czym jest Model V w inżynierii systemów wbudowanych?

Model V to rozwinięcie tradycyjnego, kaskadowego modelu wytwarzania oprogramowania (Waterfall), ustrukturyzowane w taki sposób, aby procesy testowe i weryfikacyjne ściśle odpowiadały poszczególnym etapom definiowania systemu. Wizualnie układa się on w literę „V”, gdzie lewe ramię reprezentuje dekonstrukcję i specyfikację systemu (od ogółu do szczegółu), wierzchołek na dole to faktyczna implementacja (kodowanie i montaż hardware’u), a prawe ramię oznacza integrację, weryfikację i walidację (od szczegółu do ogółu).

„Model V ma tę ważną cechę, że plany testów i kryteria akceptacji powstają równolegle do wymagań i architektury. Kiedy nasi inżynierowie R&D definiują wymagania systemowe, zespół QA (Quality Assurance) natychmiast projektuje testy walidacyjne dla tych wymagań. Oznacza to, że nie czekamy na gotowe urządzenie, by zastanowić się, jak je przetestować. Architektura testów rośnie wraz z architekturą systemu.”

Dawid Klewer, główny inżynier innowacji w ICU tech

Dlaczego Model V to fundament normy IEC 62304?

Norma IEC 62304 (Oprogramowanie wyrobów medycznych – Procesy cyklu życia oprogramowania) jest międzynarodowym standardem wymaganym przez agencje regulacyjne na całym świecie (w tym w UE w ramach rozporządzenia MDR oraz w USA przez FDA). Norma ta nie narzuca wprost konkretnej metodyki zarządzania projektem, jednak jej struktura wymagań idealnie mapuje się na topologię Modelu V.

IEC 62304 nakłada na producenta obowiązek zachowania pełnej identyfikowalności wstecznej i postępującej (traceability). Oznacza to, że audytor musi mieć możliwość prześledzenia drogi od pojedynczego wymagania użytkownika, przez analizę ryzyka, architekturę systemu, szczegółowy projekt modułu, aż po konkretny test jednostkowy, integracyjny i systemowy.

Klasyfikacja oprogramowania i zarządzanie ryzykiem

W ramach normy IEC 62304 oprogramowanie medyczne przypisywane jest do jednej z trzech klas bezpieczeństwa, opartych na potencjalnych skutkach awarii dla pacjenta lub operatora:

• Klasa A: Brak możliwości spowodowania obrażeń ciała lub uszczerbku na zdrowiu.
• Klasa B: Możliwość spowodowania niegroźnych obrażeń ciała.
• Klasa C: Możliwość spowodowania śmierci lub poważnych obrażeń.

Dla klas B i C wymagania dokumentacyjne oraz zakres testowania drastycznie rosną. Model V pozwala okiełznać i uporządkować tę złożoność.

Model V w ICU tech: Krok po kroku

Zobaczmy, jak w laboratorium i biurze projektowym ICU tech przekładamy teorię inżynierii systemów na praktyczne działania inżynieryjne. Każdy krok lewego ramienia modelu ma swój precyzyjny odpowiednik na ramieniu prawym.

Do opisania naszych działań posłużymy się hipotetycznym przykładem:

1. Wymagania Użytkownika (Customer Requirements) vs Walidacja Systemu (System Validation)

• Model V Lewe ramię (Definicja): Wspólnie z klientem oraz personelem medycznym (jeśli to konieczne) definiujemy, co urządzenie ma robić, w jakim środowisku będzie pracować i jakie kryteria musi spełnić, by zrealizować cel terapeutyczny lub diagnostyczny. Powstaje dokument URS (User Requirement Specification).
• Model V Prawe ramię (Weryfikacja/Walidacja): Na tym najwyższym poziomie przeprowadzamy walidację. Odpowiada ona na pytanie: „Czy zbudowaliśmy właściwy system?”. Testy walidacyjne sprawdzają, czy gotowy wyrób medyczny spełnia potrzeby lekarza i pacjenta w realnych warunkach (lub symulowanych warunkach klinicznych).

2. Wymagania Systemowe i Architektura (System Specification) vs Testy Systemowe (System Testing)

• Model V Lewe ramię (Definicja): Przekładamy język użytkownika na parametry techniczne. Definiujemy wymagania funkcjonalne dla hardware’u i oprogramowania wbudowanego. Określamy architekturę całego urządzenia – podział na moduły elektroniczne, interfejsy komunikacyjne (np. BLE, Wi-Fi, CAN), zasilanie oraz kryteria wydajnościowe.
• Model V Prawe ramię (Weryfikacja): Na etapie testów systemowych weryfikujemy kompletne urządzenie jako „czarną skrzynkę”. Sprawdzamy zgodność z wymaganiami technicznymi – badamy czasy reakcji, stabilność komunikacji, pobór prądu oraz zachowanie systemu w stanach awaryjnych (np. nagłe odłączenie zasilania).

3. Projekt Architektury Oprogramowania (Software Architecture) vs Testy Integracyjne (Integration Testing)

• Model V Lewe ramię (Definicja): Nasi architekci embedded dzielą oprogramowanie na konkretne komponenty i warstwy (np. warstwa sterowników HAL, system operacyjny RTOS, warstwa aplikacji, algorytmy medyczne). Definiujemy strukturę danych oraz interfejsy API pomiędzy modułami. Na tym etapie kluczowa jest izolacja elementów krytycznych dla bezpieczeństwa (Klasa C) od elementów pomocniczych (Klasa A).
• Model V Prawe ramię (Weryfikacja): Testy integracyjne polegają na stopniowym łączeniu poszczególnych modułów oprogramowania i sprawdzaniu, czy poprawnie wymieniają one dane. W ICU tech wykorzystujemy techniki Hardware-in-the-Loop (HIL), gdzie testowany software uruchamiany jest na docelowym mikrokontrolerze, a otoczenie sprzętowe jest symulowane przez dedykowane systemy testowe.

4. Szczegółowy Projekt Oprogramowania (Software Detailed Design) vs Testy Jednostkowe (Unit Testing)

• Model V Lewe ramię (Definicja): Schodzimy na poziom pojedynczych jednostek oprogramowania (funkcji, klas, plików źródłowych). Opisujemy logikę działania algorytmów (np. filtrowanie sygnału EKG, sterowanie PWM silnika krokowego w pompie) za pomocą maszyn stanów czy pseudokodu.
• Model V Prawe ramię (Weryfikacja): Najniższy poziom weryfikacji kodu. Każda jednostka oprogramowania jest testowana w izolacji. Wykorzystujemy frameworki do testów automatycznych (np. Unity, CppUTest). Narzędzia te sprawdzają pokrycie kodu instrukcjami i rozgałęzieniami (Code Coverage). Dla oprogramowania klasy C wymagane jest zbliżenie się do poziomu 100% pokrycia, co eliminuje ryzyko istnienia tzw. „martwego kodu”, który mógłby wywołać nieprzewidziane zachowanie mikrokontrolera.

Macierz Identyfikowalności (Traceability Matrix) – Serce audytu medycznego

Samo realizowanie etapów Modelu V to za mało. Aby jednostka notyfikowana (np. TÜV SÜD, BSI) wydała certyfikat zgodności, musimy przedstawić niepodważalny dowód na integrację tych faz. Tym dowodem jest Macierz Identyfikowalności (Traceability Matrix).

W ICU tech zarządzamy tym procesem automatycznie za pomocą systemów klasy ALM (Application Lifecycle Management). W naszym przykładzie każdy element w projekcie posiada unikalny identyfikator:

Dzięki takiej strukturze, jeśli w trakcie rozwoju projektu klient zdecyduje się na zmianę jednego z wymagań użytkownika, natychmiast wiemy:

1. Które elementy architektury oprogramowania musimy zmodyfikować.
2. Które testy automatyczne straciły aktualność i wymagają przepisania.
3. Jakie ryzyka medyczne musimy ponownie oszacować.

„Transparentność macierzy identyfikalności drastycznie skraca czas trwania audytu certyfikacyjnego i redukuje do zera ryzyko odrzucenia dokumentacji przez jednostkę certyfikującą.”

Dawid Klewer, główny inżynier innowacji w ICU tech

Jak ICU tech eliminuje błędy w kodzie?
Dobre praktyki R&D i Modelu V

Sama struktura Modelu V to ramy procesowe. Aby zapewnić najwyższą jakość inżynieryjną, wypełniamy te ramy rygorystycznymi praktykami technicznymi na każdym etapie cyklu życia produktu.

Statyczna Analiza Kodu i Standard MISRA C

Przed uruchomieniem jakichkolwiek testów dynamicznych, kod źródłowy pisany przez naszych inżynierów trafia do narzędzi statycznej analizy kodu (Static Code Analysis). W przypadku systemów medycznych standardem branżowym jest MISRA C (Motor Industry Software Reliability Association) lub CERT C. To zbiory reguł programistycznych, które wykluczają stosowanie niebezpiecznych konstrukcji językowych (np. dynamicznej alokacji pamięci, która w systemach embedded może prowadzić do fragmentacji pamięci RAM i nagłego zawieszenia mikrokontrolera).

Code Review i Pair Programming

Żadna linijka kodu nie trafia do głównego repozytorium projektu bez weryfikacji przez drugiego, doświadczonego inżyniera. Proces Code Review pozwala wychwycić błędy logiczne, nieoptymalne zarządzanie rejestrami czy potencjalne wyścigi do zasobów (race conditions) w systemach wielowątkowych, zanim kod w ogóle trafi na platformę sprzętową.

Ciągła Integracja (Continuous Integration – CI)

W ICU tech automatyzujemy wszystko, co możliwe. Każda zmiana w kodzie (tzw. Pull Request) uruchamia potok CI (Continuous Integration pipeline). Serwer automatycznie kompiluje kod dla docelowej architektury (np. ARM Cortex-M), uruchamia testy jednostkowe, sprawdza reguły MISRA C oraz generuje raporty pokrycia kodu. Jeśli jakikolwiek test zakończy się niepowodzeniem, system natychmiast blokuje wdrożenie zmian.

Wartość biznesowa dla klienta: Dlaczego warto nam zaufać?

Inwestycja w rygorystyczny proces inżynieryjny oparty na Modelu V może wydawać się na pierwszy rzut oka kosztowna i czasochłonna. Z perspektywy biznesowej jest to jednak najbardziej opłacalna strategia rozwoju wyrobu medycznego.

Zasada Boehma (Koszt usunięcia błędu): Wykrycie błędu w architekturze na etapie zbierania wymagań kosztuje jednostkę. Wykrycie tego samego błędu podczas testów jednostkowych to koszt rzędu 10-krotności. Jeśli błąd logiczny zostanie wykryty dopiero po wdrożeniu urządzenia na rynek (u pacjentów), koszt jego usunięcia (akcje naprawcze, wycofanie produktu z rynku, utrata reputacji, kary regulacyjne) wzrasta nawet 100- do 1000-krotnie.

[Faza Wymagań] -> Koszt błędu: 1x

   [Faza Projektowania] -> Koszt błędu: 5x

      [Faza Kodowania] -> Koszt błędu: 10x

         [Testy Systemowe] -> Koszt błędu: 50x

            [Po Wdrożeniu na Rynek] -> Koszt błędu: 100x – 1000x!

Decydując się na współpracę z ICU tech, zyskujesz partnera, który:

• Eliminuje ryzyko „ślepych uliczek” technologicznych: Dzięki wczesnemu projektowaniu testów wykrywamy nieścisłości w założeniach projektowych, zanim powstanie pierwszy prototyp PCB.
• Gwarantuje gotowość do certyfikacji: Dokumentacja techniczna (Software Development Plan, Software Architecture Description, Verification Reports) generuje się sukcesywnie w trakcie trwania projektu, a nie „na kolanie” przed audytem.
• Zapewnia ciągłość technologiczną: Jako firma oferująca kompleksowe usługi – od doradztwa R&D po produkcję – bierzemy pełną odpowiedzialność za synergię sprzętu z oprogramowaniem.

Model V w wydaniu ICU tech to nie tylko schemat inżynieryjny – to polisa ubezpieczeniowa dla Twojego wyrobu medycznego. Przekształcamy skomplikowane rygory w przejrzysty, powtarzalny proces, który bezpiecznie i przewidywalnie wprowadzi Twój innowacyjny produkt na rynek medyczny.

Zapraszamy do kontaktu z naszym zespołem R&D za pośrednictwem poniższego formularza, aby omówić architekturę Twojego kolejnego sukcesu, by unikąć poważnych błędów.

FAQ

1. Czym wizualnie i strukturalnie charakteryzuje się Model V?

Model V układa się w literę „V”, gdzie lewe ramię reprezentuje dekonstrukcję i specyfikację systemu (od ogółu do szczegółu), wierzchołek na dole to implementacja (kodowanie i montaż hardware’u), a prawe ramię oznacza integrację, weryfikację i walidację (od szczegółu do ogółu).

2. Kiedy w Modelu V powstają plany testów i kryteria akceptacji?

Plany testów i kryteria akceptacji powstają równolegle do wymagań i architektury – zespół QA projektuje testy walidacyjne natychmiast, gdy inżynierowie R&D definiują wymagania systemowe.

3. Czym jest norma IEC 62304?

Jest to międzynarodowy standard wymagany przez agencje regulacyjne na całym świecie (w tym w UE w ramach MDR oraz w USA przez FDA), który dotyczy procesów cyklu życia oprogramowania wyrobów medycznych.

4. Na czym polega pełna identyfikowalność (traceability) wymagana przez normę IEC 62304?

Polega na obowiązku zapewnienia możliwości prześledzenia drogi od pojedynczego wymagania użytkownika, przez analizę ryzyka, architekturę systemu, szczegółowy projekt modułu, aż po konkretny test jednostkowy, integracyjny i systemowy.

5. Jakie są klasy bezpieczeństwa oprogramowania medycznego według normy IEC 62304?

Oprogramowanie medyczne dzieli się na trzy klasy: Klasa A (brak możliwości spowodowania obrażeń), Klasa B (możliwość spowodowania niegroźnych obrażeń) oraz Klasa C (możliwość spowodowania śmierci lub poważnych obrażeń).

6. Na jakie pytanie odpowiada walidacja systemu na najwyższym poziomie prawego ramienia Modelu V? Walidacja systemu odpowiada na pytanie: „Czy zbudowaliśmy właściwy system?”.

7. Na czym polegają testy integracyjne w ICU tech i jaka technika jest w nich wykorzystywana?

Polegają one na stopniowym łączeniu poszczególnych modułów oprogramowania i sprawdzaniu poprawności wymiany danych, z wykorzystaniem techniki Hardware-in-the-Loop (HIL), gdzie otoczenie sprzętowe jest symulowane przez dedykowane systemy testowe.

8. Co stanowi serce audytu medycznego i służy jako niepodważalny dowód integracji faz projektu dla jednostki notyfikowanej?

Tym dowodem jest Macierz Identyfikowalności (Traceability Matrix), zarządzana w ICU tech automatycznie za pomocą systemów klasy ALM.

9. Czym jest standard MISRA C stosowany podczas statycznej analizy kodu?

Jest to zbiór reguł programistycznych, które wykluczają stosowanie niebezpiecznych konstrukcji językowych, takich jak na przykład dynamiczna alokacja pamięci w systemach embedded.

10. Jak zmienia się koszt usunięcia błędu w zależności od fazy jego wykrycia zgodnie z Zasadą Boehma?

Koszt wykrycia błędu w fazie wymagań wynosi 1x, w fazie projektowania 5x, kodowania 10x, podczas testów systemowych 50x, a po wdrożeniu urządzenia na rynek wzrasta od 100- do nawet 1000-krotnie.