IEC 62304在醫(yī)械軟件開發(fā)中的實施

• 預期用途所需的SOUP項目的功能和性能要求

• 讓SOUP項目正常運行所需的系統(tǒng)硬件和軟件的生產規(guī)范

• 證明醫(yī)療器械架構能夠讓任意SOUP項目正常運行所需的詳情

大多數(shù)情況下，SOUP項目是作為源代碼提供的，但是不帶設計文件，這樣就很難分析它們。使用現(xiàn)代測試工具有助于實現(xiàn)早期代碼設計可視化。

不論它是否應用于語句模塊、進程(或類)、應用和/或系統(tǒng)，現(xiàn)代測試工具提供的系統(tǒng)可視化設施功能都非常強大。應用和系統(tǒng)實體的分層示意圖如圖3a 內的靜態(tài)調用圖所示;圖3b內的靜態(tài)流程圖展示了整個程序模塊的控制流程。利用彩色編碼圖對于了解SOUP極有好處。這類調用圖和流程圖只是綜合分析代碼內使用的所有參數(shù)和數(shù)據對象的一部分優(yōu)勢。

圖3

圖3 靜態(tài)調用圖(a)和流程圖(b)以圖形的形式分別說明了代碼的結構和邏輯。

需求管理和跟蹤已經證明了它們在軟件開發(fā)生命周期內的優(yōu)勢，能夠確保實現(xiàn)所有需求和所有開發(fā)成果都可以追溯到一個或多個需求。同樣的，需求管理與跟蹤可以保證根據系統(tǒng)要求添加和驗證SOUP項目。

RTM在架構設計和SOUP項目之間實現(xiàn)了可追蹤性。由于這些項目都包含在源代碼內并且現(xiàn)在需要按照IEC 62304的要求進行系統(tǒng)級合規(guī)性測試，所以代碼驗證就成了制造商的責任。

大多數(shù)SOUP項目都不嚴謹，從而為系統(tǒng)集成商提高了嚴格驗證與風險分析要求。由于SOUP驗證非常耗時，所以開發(fā)人員一開始通常需要滿足一系列編碼標準，再逐漸采用其他規(guī)則。雖然測試工具只辨別而不糾正代碼內存在的違規(guī)之處和本征誤差，但是它們確實通過指出問題所在而加快了代碼糾正速度。

IEC 62304希望醫(yī)療器械制造商評估SOUP項目供應商提供的軟件異常列表，以便確定已知異常是否會引發(fā)事件，進而導致出現(xiàn)危險情形。

測試工具的靜態(tài)分析能力能夠確定異常及其對軟件系統(tǒng)的影響。如果確定了SOUP供應商提供的列表以外的任何其他異常，則應告知相應供應商以解決問題。