摘要

靜態和動態分析是滿足軟件測試合規性的關鍵，但這些過程并不容易實施。這篇文章提供了有關如何自動化該過程的專家指南。

網絡安全是 FDA 的重點關注對象，對靜態和動態代碼分析有具體要求。因此，工程師將這些實踐自動化并將其集成到現有的開發工作流程中非常重要。

對于開發和交付醫療設備安全和安全關鍵軟件的公司來說，實施靜態和動態代碼分析實踐，并將其部署在從相對簡單的血糖儀到更復雜的系統（如輸液泵、患者監護儀和肺通氣裝置）的項目中，是該過程不可或缺的一部分。這篇文章涵蓋了醫療設備軟件中的靜態與動態代碼分析，并分享了實用技巧和最佳實踐。

1. 醫療器械軟件風險分析介紹

醫療器械是現代醫療體系的重要組成部分。世界衛生組織（WHO）估計，全球約有200萬臺醫療設備。隨著人工智能（AI）、機器學習（ML）和物聯網（IoT）的發展，現代醫療設備的連接性比以往任何時候都更加緊密，這種情況增加了其復雜性和用例水平。

隨著軟件技術在醫療設備實踐中的使用的越來越多，醫療設備也越來越依賴軟件來執行一些關鍵功能。例如，醫療設備可以做一些事情，例如分析醫學圖像并提供診斷支持，部署具有與臺式或移動設備通信的傳感器的智能植入物，以及執行機器人手術程序等。雖然醫療設備軟件在醫學領域取得了進步，但它給我們留下了一些必須謹慎管理的風險。

醫療設備軟件風險可能來自各種來源，包括編碼錯誤、硬件故障、用戶錯誤等。這些風險可能會對患者、醫療保健專業人員或任何接觸該設備的人造成傷害。

除了上述風險外，這些設備在收集、存儲、處理和傳輸醫療數據時還存在網絡安全風險。因此，像美國食品藥品監督管理局（FDA）這樣的監管機構負責監管醫療設備軟件的制造和部署。然而，要了解您的醫療設備軟件是否符合這些監管標準，在使用之前進行徹底的醫療設備風險分析至關重要。

1.1 什么是醫療器械軟件風險分析

在討論醫療設備軟件風險分析之前，讓我們先來看看風險。在最基本的定義中，風險是損失或傷害的可能性。醫療器械軟件風險分析是測試醫療器械軟件以識別、評估和減輕相關風險的過程。它還包括使用一些風險管理基準測試軟件的預期用途、功能以及對患者或操作員的潛在危害。

對于醫療器械制造商來說，風險分析是醫療器械軟件開發過程的重要組成部分。這是幫助醫療器械制造商達到監管標準的基本要求。

醫療設備軟件風險分析的主要目標是確保軟件安全有效，不僅用于醫療用途，還確保這些設備不易受到網絡攻擊并導致重大數據泄露。

1.2 為什么醫療器械軟件風險分析很重要

想象一下，在不檢查制動系統、安全氣囊、車燈、懸架和轉向系統等關鍵部件的情況下，將汽車行駛在路上。忽視這些檢查可能會增加發生車禍的可能性。在不進行風險分析的情況下部署醫療設備軟件也是如此。

醫療設備軟件風險分析對于確保患者安全、減少醫療危害和患者病歷安全漏洞的潛在發生至關重要。

此外，美國食品藥品監督管理局等監管機構要求醫療器械制造商在其醫療器械軟件被批準用于消費者之前，對其進行風險分析。不遵守監管要求可能導致設備審批延遲或導致召回。

換言之，風險分析還可以幫助制造商確定提高設備安全性和可用性的機會，從而提高銷售額和市場份額。

2. 醫療器械軟件風險分析的監管框架

醫療器械軟件開發受到各種監管機構的監管，如美國食品藥品監督管理局（FDA）和歐洲醫療器械監管局（MDR）。

作為一個監管機構，美國食品藥品監督管理局確保人類和獸醫藥物、生物制品、醫療器械、食品供應、化妝品和其他產品的安全、高效和保障。美國食品藥品監督管理局的使命是通過監管和監督這些產品的開發、制造、營銷和分銷來保護和促進公眾健康。

同樣，ISO 13485是全球公認的標準，概述了醫療器械行業的質量要求。本標準為制造商實施商業和技術實踐提供了實用指南，以確保所有醫療設備符合法規要求和客戶需求。

通過采用ISO 13485中概述的最佳實踐和流程，制造商可以簡化運營、降低成本、管理風險、提高生產力，并不斷改進其產品和服務。

還有IEC 62304，這是一套國際標準，為醫療器械軟件的開發、維護和風險管理提供了指南。該框架概述了必須滿足的要求，以確保醫療設備中使用的軟件是安全、可靠的，并符合可接受的標準。IEC 62304規定了軟件開發過程、文件要求驗證和確認程序。

這些監管框架旨在作為對醫療器械進行風險分析的標準。因此，遵守這些規定對于獲得醫療器械軟件開發的監管批準以及證明制造商的承諾力和交付高質量產品的能力至關重要。

為了使醫療設備軟件制造商遵守這些規定，通常需要軟件測試過程來檢查編程錯誤、違反編碼標準、違反語法、不安全配置等。這就是靜態分析和單元測試的用武之地。

3. 靜態分析

測試金字塔

靜態分析是一種自動檢查是否符合眾所周知的編碼準則（MISRA、CERT、AUTOSAR、JSF）并檢測潛在錯誤（如空指針解引用、除零和緩沖區溢出）的實踐。現代靜態分析工具還通過將手動工作量減少至少30%來補充傳統的代碼審查實踐。

在大多數情況下，針對當前代碼的靜態分析工具的第一次運行將顯示數千個違規。一些醫療器械開發團隊在第一次運行時甚至遇到了20000多個違規。這可能是令人難以置信的結果。可能需要花費需要數年時間才能修復所有問題。以下是一些解決這些問題的專家提示:

技巧1：編譯器是減少違規的”好幫手”

有紀律的開發團隊通常使用–Wall和–Werror（在GCC中）或/Wall和/WX（在Visual Studio中）進行編譯，或在其他編譯器中使用類似選項進行編譯。修復編譯器警告是為靜態分析執行做準備的一種簡單并且極具價值的方法。以“paranoid”模式查看編譯器的輸出可以減少靜態分析違規的總體數量。

雖然修復了所有編譯器警告是一件好事，但在許多項目中，僅使用編譯器是不夠的，而且出于合規性原因，僅僅使用編譯器檢查是絕對不夠的。

在最大化利用編譯器的檢查能力后，再使用靜態分析工具，這些工具可以更深入地挖掘代碼，并為您提供更多提示。

技巧2：在開發過程早期采用靜態分析

如果你目前正在開發醫療設備軟件，那么你應該準備好解決自動靜態代碼分析實踐的問題。靜態分析幾乎可以保證在內部/外部審計階段，甚至上市前提交時成為保證軟件質量的關鍵證據。

關鍵是以這樣一種方式部署工具，既要保證在提高質量的同時，開發速度也不會降低。這是一種平衡行為，需要實踐和專業知識。您可能會發現，在報告中找到錯誤的根本原因的同時，發現其中許多錯誤其實很容易修復。

靜態分析報告中的試例

以下是靜態分析報告中的幾個例子，這些例子很容易用簡單的腳本或經過簡單學習的工程師來修復。

1. 在析構函數中調用clear函數

析構函數“~CTitle”不應調用不在try上下文中的函數“clear_”中

析構函數“~THelper”不應調用不在try上下文中的函數“removeModule”中

2. 檢查是否為 NULL

“pMP” 可能為NULL

“((NPage*)this)->pSysCfg_” 可能為NULL

3.可能在錯誤的代碼部分進行聲明

數據成員“D_FILE_1”聲明為“public”

4.非常量參數

字符串“MCollection”被傳遞給函數“FixedBlockHeap”作為指向非常量對象的指針

用戶可以將許多現有代碼的違規結果放在一起，并在非開發時間段進行處理。然而，在開發代碼時，不要引入新的違規行為（也稱為技術債務），這一點很重要。例如，Parasoft C/C++test 具有允許工程師過濾噪音違規并專注于修復最近最關鍵的靜態分析違規的功能。

這一篇文章我們簡單介紹了醫療設備軟件關于風險方面的相關背景，以及兩個技巧，下文我們繼續深入了解剩下的3個技巧，以及如何管理風險。

審核編輯：湯梓紅