包含軟件系統(tǒng)的醫(yī)療設(shè)備與構(gòu)建復(fù)雜系統(tǒng)一樣，制造商面臨著相同的挑戰(zhàn)：時(shí)間、質(zhì)量、規(guī)模(功能的數(shù)量和復(fù)雜性)和成本。此外，產(chǎn)品還需通過(guò)當(dāng)?shù)乇O(jiān)管部門(mén)的審批，如美國(guó)食品及藥品管理局(FDA)、歐盟醫(yī)療器械指令司(MDD)、英國(guó)藥監(jiān)局(MHRA)以及其他同類(lèi)監(jiān)管機(jī)構(gòu)。

　　在本文中我們將探討動(dòng)態(tài)代碼分析如何幫助醫(yī)療設(shè)備展示安全合規(guī)性以及動(dòng)態(tài)分析工具所應(yīng)具備的關(guān)鍵功能。為了幫助設(shè)計(jì)人員選擇操作系統(tǒng)(OS)，文章還簡(jiǎn)要介紹了OS的哪些特性可以推動(dòng)安全相關(guān)軟件加速設(shè)計(jì)、開(kāi)發(fā)和審批流程等。

　　專(zhuān)業(yè)知識(shí)和流程

　　專(zhuān)業(yè)知識(shí)和良好的開(kāi)發(fā)流程并不能確保系統(tǒng)符合所需滿(mǎn)足的可靠性，甚至不能確保它是一個(gè)好系統(tǒng)。但是這兩者的確能極大提高這種可能性。

　　創(chuàng)造安全關(guān)鍵系統(tǒng)所要求的簡(jiǎn)潔設(shè)計(jì)需要卓越的專(zhuān)業(yè)知識(shí)。要證明被測(cè)試的軟件系統(tǒng)符合安全要求，需要對(duì)軟件驗(yàn)證方法、被評(píng)估的軟件以及評(píng)估環(huán)境(包括類(lèi)似系統(tǒng)的驗(yàn)證)有全面透徹的了解。

　　毫無(wú)疑問(wèn)，IEC62304標(biāo)準(zhǔn)專(zhuān)注于開(kāi)發(fā)流程。理解這點(diǎn)，我們的工作將會(huì)做得更好，不僅僅是在滿(mǎn)足最嚴(yán)苛質(zhì)量管理標(biāo)準(zhǔn)的環(huán)境下進(jìn)行軟件開(kāi)發(fā)，同時(shí)還使用工具來(lái)幫助確保我們的系統(tǒng)符合這些標(biāo)準(zhǔn)，并向?qū)徲?jì)員和監(jiān)管機(jī)構(gòu)提供證據(jù)加以證明。

　　展示可靠性

　　為了確保通過(guò)監(jiān)管機(jī)構(gòu)的審批，制造商必須證明這些設(shè)備滿(mǎn)足安全規(guī)格。對(duì)于設(shè)備軟件來(lái)說(shuō)，要證明他們符合可信任(可靠性和可用性)標(biāo)準(zhǔn)的要求。具體是滿(mǎn)足可靠性還是可用性方面的要求，則要取決于系統(tǒng)的使用情況。詳細(xì)的要求限制和精確的可信性要求提供了既定的前提和精準(zhǔn)的方法，幫助我們驗(yàn)證軟件系統(tǒng)的可信性。

　　定義可接受風(fēng)險(xiǎn)

　　沒(méi)有任何軟件系統(tǒng)是絕對(duì)可靠的。即使系統(tǒng)絕對(duì)可靠，我們也無(wú)法證明它?，F(xiàn)有可用的方法無(wú)法證明系統(tǒng)將永不失效，他們僅能幫助我們找到并避免錯(cuò)誤的發(fā)生，并估計(jì)失效的可能性。因此，當(dāng)軟件系統(tǒng)的故障率足夠低，沒(méi)有不可接受的風(fēng)險(xiǎn)，它就是“安全”的?！安豢山邮茱L(fēng)險(xiǎn)”或“可接受風(fēng)險(xiǎn)”的精確含義因行業(yè)及行政轄區(qū)而異。衡量方法包括：

　　? ALARP(As Low as Reasonably Practical，最低合理可行)：將潛在的危害和相關(guān)的風(fēng)險(xiǎn)定義和分類(lèi)為：a)明確不可接受，b)如果移除成本過(guò)高，則可以容忍，以及c)可接受。所有不可接受風(fēng)險(xiǎn)必須被移除，但是僅當(dāng)移除成本和時(shí)間較為合理時(shí)，可容忍風(fēng)險(xiǎn)才會(huì)被移除。

　　? GAMAB(globalement au moins aussi bon)或GAME((globalement au moins équivalent)：新系統(tǒng)的風(fēng)險(xiǎn)水平至少要與現(xiàn)有系統(tǒng)的風(fēng)險(xiǎn)水平大體相當(dāng)。

　　? MEM(Minimum Endogenous Mortality)：在新系統(tǒng)部署的領(lǐng)域，它帶來(lái)的死亡率不能超過(guò)該地區(qū)常規(guī)死亡率的十分之一。舉例來(lái)說(shuō)，在西方國(guó)家年齡為20多歲的人群，這個(gè)值約為0.0002。

　　所有這些方法都需要按實(shí)際情況調(diào)整，主要取決于設(shè)備的嚴(yán)重故障可能同步影響到的人數(shù)。當(dāng)使用ALARP方法時(shí)，為了確定哪些風(fēng)險(xiǎn)不可接受、哪些可容忍以及可接受，我們需要決定每個(gè)風(fēng)險(xiǎn)的嚴(yán)重故障所允許的最大失敗可能性。而如果使用GAMAB和MEM準(zhǔn)則，我們則需要在全球范圍確定這個(gè)數(shù)值。

　　證明軟件可靠性的方法

　　目前，沒(méi)有任何一種單一的方法足以證明軟件系統(tǒng)滿(mǎn)足可靠性方面的要求。因此，我們的可靠性演示必須使用整合了各種方法和技巧，它們包括但不限于：

　　? 符合IEC 62304及其他同類(lèi)標(biāo)準(zhǔn)要求的開(kāi)發(fā)環(huán)境

　　? 要求跟蹤矩陣，確保所有安全相關(guān)的要求都已得到滿(mǎn)足

　　? 正規(guī)的設(shè)計(jì)方法和工具，可以為設(shè)計(jì)的正確性提供數(shù)學(xué)依據(jù)

　　? 使用貝葉斯置信網(wǎng)絡(luò)方法的故障樹(shù)分析

　　? 回顧性設(shè)計(jì)驗(yàn)證，基于已完成的工作來(lái)評(píng)估系統(tǒng)設(shè)計(jì)

　　? 靜態(tài)分析，使用模型檢測(cè)或者數(shù)據(jù)流分析等方法

　　? 使用直接故障檢測(cè)技術(shù)進(jìn)行測(cè)試，如動(dòng)態(tài)分析，通過(guò)產(chǎn)生的誤差和失效來(lái)識(shí)別故障

　　圖1 IEC 62304標(biāo)準(zhǔn)涉及的不同分析方法和相關(guān)章節(jié)，表現(xiàn)為典型的“V”字形發(fā)展模型。圖中顯示的每一種方法都不依賴(lài)于進(jìn)程。任何其他開(kāi)發(fā)進(jìn)程模型都可用類(lèi)似的表述：瀑布式、迭代的、靈敏的等

　　IEC 62304

　　IEC 62304 已成為醫(yī)療設(shè)備軟件的生命周期過(guò)程必須遵循的全球統(tǒng)一標(biāo)準(zhǔn)。FDA推動(dòng)了它的發(fā)展，而且該標(biāo)準(zhǔn)正與歐盟標(biāo)準(zhǔn)93/42 EWG(MDD)逐步取得一致。

　　與圖1顯示的其它標(biāo)準(zhǔn)一樣，IEC 62304是基于IEC 61508標(biāo)準(zhǔn)，根據(jù)現(xiàn)有的行業(yè)特定實(shí)踐補(bǔ)充而來(lái)。舉例來(lái)說(shuō)，IEC 62304與ISO 26262不同，甚至與IEC 61508本身也不同， 它未定義可接受故障率(安全完整性等級(jí)SIL的一個(gè)評(píng)定)的常見(jiàn)數(shù)值。相反，它根據(jù)故障可能對(duì)病人、操作員或其他人員造成的傷害程度規(guī)定了安全等級(jí)。這些等級(jí)與FDA的醫(yī)療設(shè)備等級(jí)類(lèi)似，即：不會(huì)損害健康、可能輕微損害健康和可能?chē)?yán)重?fù)p害健康甚至導(dǎo)致死亡。

　　在大多數(shù)情況下，從IEC 61508演化而來(lái)的標(biāo)準(zhǔn)與其類(lèi)似，因?yàn)樗麄兌即_實(shí)規(guī)定了軟件生命周期的流程(包括風(fēng)險(xiǎn)管理過(guò)程)、活動(dòng)和任務(wù)，并指出該周期不應(yīng)隨著產(chǎn)品的發(fā)布而結(jié)束，只要軟件還在運(yùn)行，這個(gè)流程就必須貫穿于產(chǎn)品維護(hù)和問(wèn)題解決的全過(guò)程。因此，不管他們?nèi)绾味x可接受和不可接受風(fēng)險(xiǎn)，IEC 62304、IEC 61508和其它類(lèi)似的標(biāo)準(zhǔn)提供了證實(shí)系統(tǒng)符合安全要求必須使用的指導(dǎo)和方法。

　　圖2 IEC 62304標(biāo)準(zhǔn)從IEC 61508標(biāo)準(zhǔn)演化而來(lái)，因此與其它行業(yè)標(biāo)準(zhǔn)一樣，有同樣的起源。要注意的是，IEC 62304清楚說(shuō)明了它并不依賴(lài)于IEC 61508，但是可參考IEC 61508的工具和方法

　　動(dòng)態(tài)分析

　　動(dòng)態(tài)分析用于檢驗(yàn)編譯源代碼的執(zhí)行情況，可以整體檢驗(yàn)，也可以分開(kāi)進(jìn)行。由于動(dòng)態(tài)分析執(zhí)行代碼，它不僅測(cè)試源代碼，也測(cè)試編譯器、鏈接器、開(kāi)發(fā)環(huán)境，甚至有可能是目標(biāo)硬件。通常來(lái)說(shuō)，動(dòng)態(tài)分析包括結(jié)構(gòu)(代碼)覆蓋分析和單元測(cè)試，這兩者的結(jié)合不僅可以提供非常有效的檢測(cè)軟件故障的方法，還可以為證明執(zhí)行了哪些軟件以及如何執(zhí)行提供證據(jù)。

　　結(jié)構(gòu)覆蓋分析是航空行業(yè)標(biāo)準(zhǔn)DO-178B/C的基礎(chǔ)。航空事故往往較為重大和悲慘，因此新聞報(bào)道往往比醫(yī)療設(shè)備事故報(bào)道頻繁，而航空業(yè)也有一個(gè)安全記錄模范。從前一里到下一里，航空是最安全的交通工具之一。

　　結(jié)構(gòu)覆蓋分析

　　動(dòng)態(tài)分析工具使用介入式探針或非介入式探針。介入式探針系統(tǒng)將軟件探針(計(jì)數(shù)或程序呼叫)放置在即將被分析的代碼里(高級(jí)語(yǔ)言或者匯編器)。這些探針會(huì)記錄流程執(zhí)行的相關(guān)信息，并生成執(zhí)行歷史。

　　介入式探針和非介入式探針

　　使用介入式探針時(shí)，證明探針不會(huì)改變測(cè)量代碼的功能對(duì)于分析的有效性非常重要。除了證明介入式探針不會(huì)影響源代碼，這樣的演示通常還要求探針本身不會(huì)帶入可能導(dǎo)致編譯器出現(xiàn)漏洞的事物。這可以通過(guò)使用Compiler Validation Suite(一套源代碼，用于證明編譯器履行正確的計(jì)算功能)來(lái)展示編譯器的有效性并未受到加載進(jìn)程的影響。

　　非介入式探針系統(tǒng)擁有與介入式探針系統(tǒng)一樣或類(lèi)似的信息，但直接來(lái)自于處理器，并且動(dòng)態(tài)分析工具會(huì)將這個(gè)低層信息連接至原始表示方法(高層語(yǔ)言或者匯編器)。但是，出于各種原因(比如編譯器優(yōu)化的影響)，不能總是明確地建立這種聯(lián)系。

　　請(qǐng)注意，與所有測(cè)試一樣，在一個(gè)復(fù)雜的軟件系統(tǒng)，我們同樣無(wú)法證明結(jié)構(gòu)覆蓋分析所用的探針絕對(duì)不會(huì)影響代碼表現(xiàn)。舉例來(lái)說(shuō)，從定義上看，Heisenbugs為不可再現(xiàn)的錯(cuò)誤，通常被認(rèn)為由微妙的時(shí)間條件導(dǎo)致，他們可能會(huì)因代碼的任何改變而校正(甚至是帶入)，包括加載檢測(cè)探針。

　　圖3 LDRA代碼覆蓋工具的截圖，彩色的圖形信息清晰說(shuō)明了未被執(zhí)行的代碼

　　可靠性判斷的證明

　　關(guān)鍵不是為了證明故障不存在(不可能性)，而是為了收集證據(jù)，供我們用于軟件可靠性判斷。特別是如果我們的系統(tǒng)使用SOUP(第三方的軟件)，結(jié)構(gòu)覆蓋分析可以幫助證明系統(tǒng)沒(méi)有未使用的或者多余的代碼。

　　單元測(cè)試

　　單元測(cè)試驗(yàn)證小單元，使得觀察到不正確的表現(xiàn)更為簡(jiǎn)易，以便檢測(cè)故障。在單元測(cè)試?yán)?，程序或程序串都?dú)立于完整的系統(tǒng)進(jìn)行隔離測(cè)試，以確定他們滿(mǎn)足特定的要求。

　　通常情況下，這些要求比項(xiàng)目的要求更加全面，因此，舉例來(lái)說(shuō)，可以對(duì)界面條件進(jìn)行測(cè)試：對(duì)一個(gè)像素為750 x 1000的顯示的著色測(cè)試可能需要針對(duì)像素為1200 x 1600的顯示進(jìn)行。每一個(gè)程序的界面都進(jìn)行輸入值測(cè)試，這可能被更高級(jí)程序排除在外，來(lái)探索普遍性——該程序的表現(xiàn)一直符合要求。

　　單元測(cè)試使得測(cè)試通常無(wú)法觸及的內(nèi)務(wù)代碼成為可能，保護(hù)性代碼元件可以同樣被測(cè)試。一些偶然糾錯(cuò)的情況可以被移除;舉例說(shuō)，在較大型的系統(tǒng)中，可能引入了一個(gè)不必要的程序，或者與之相反，并讓觀察者以為一切正常。因?yàn)槲覀兲幚淼氖禽^小的元件，就較為容易觀察到不正確的行為，并檢測(cè)錯(cuò)誤。

　　如何處理被測(cè)試的單元內(nèi)的子程序取決于測(cè)試的目標(biāo)。傳統(tǒng)上，單元測(cè)試會(huì)引入一個(gè)從細(xì)節(jié)到總體的測(cè)試戰(zhàn)略(有時(shí)候被稱(chēng)為模塊或者集成測(cè)試)。在這樣的方法里，首先對(duì)單元進(jìn)行測(cè)試，接著再將其與其他單元整合測(cè)試。在這樣的測(cè)試中子程序并不包括在測(cè)試?yán)?，它們可以被“存根”取代?/p>

　　圖4 在整個(gè)系統(tǒng)或某個(gè)子系統(tǒng)進(jìn)行結(jié)構(gòu)覆蓋測(cè)試提供極大的靈活性

　　當(dāng)與結(jié)構(gòu)覆蓋分析相結(jié)合，在測(cè)試?yán)锟梢噪S意添加呼叫樹(shù)的數(shù)量的靈活性可以幫助系統(tǒng)符合最嚴(yán)格的質(zhì)量和認(rèn)證機(jī)構(gòu)的覆蓋要求。

　　結(jié)構(gòu)覆蓋標(biāo)準(zhǔn)

　　在驗(yàn)證任何系統(tǒng)時(shí)，其中一個(gè)最艱難的步驟是決定何時(shí)停止測(cè)試。該決定需要考慮系統(tǒng)可靠性要求，并最終取決于IEC 62304以及監(jiān)管機(jī)構(gòu)對(duì)于醫(yī)療設(shè)備的安全規(guī)章。

　　覆蓋標(biāo)準(zhǔn)可以幫助衡量動(dòng)態(tài)測(cè)試已經(jīng)實(shí)現(xiàn)的成果，也可以用于測(cè)量剩余需要完成的測(cè)試工作。這些標(biāo)準(zhǔn)包括：

　　? 語(yǔ)句覆蓋：最基礎(chǔ)的標(biāo)準(zhǔn)，由被測(cè)試系統(tǒng)的語(yǔ)句部分組成。

　　? 分支/判定覆蓋：覆蓋的控制流分支部分。平均而言，每一個(gè)語(yǔ)句和程序呼叫被執(zhí)行的次數(shù)是單獨(dú)語(yǔ)句覆蓋的兩倍。

　　? LCSAJ覆蓋：路徑相關(guān)的標(biāo)準(zhǔn)，LCSAJ(線(xiàn)性代碼順序和跳轉(zhuǎn))覆蓋比分支/判定覆蓋要求更高，并且在應(yīng)用的大多數(shù)關(guān)鍵領(lǐng)域都可使用。市場(chǎng)上較復(fù)雜的工具會(huì)包含此功能。

　　? 修正條件/判定覆蓋：在一個(gè)程序中每一種輸入輸出至少要出現(xiàn)一次，在程序中的每一個(gè)條件必須產(chǎn)生所有可能的輸出結(jié)果至少一次，并且每一個(gè)判定中的每一個(gè)條件必須能夠獨(dú)立影響一個(gè)判定的輸出，則完全的MC/DC覆蓋已經(jīng)達(dá)到。

　　軟件分析工具的選擇

　　所有軟件工具提供商都非常希望售出自己的產(chǎn)品，因此極少有廠商會(huì)主動(dòng)介紹他們的工具無(wú)法實(shí)現(xiàn)的功能。下面是評(píng)估軟件分析工具時(shí)的一些注意要點(diǎn)：

　　錯(cuò)誤報(bào)告

　　? 該工具是否會(huì)產(chǎn)生很多假陽(yáng)性報(bào)告?也就是說(shuō)，它是否會(huì)報(bào)告其實(shí)并不存在的故障?

　　? 該工具是否會(huì)產(chǎn)生假陰性報(bào)告?也就是說(shuō)，它沒(méi)有及時(shí)報(bào)告其實(shí)存在的故障?

　　項(xiàng)目兼容性

　　? 該工具在生成有益的信息時(shí)是否需要很長(zhǎng)時(shí)間?工具運(yùn)行所需要的時(shí)間通常并不是問(wèn)題，但仍是一個(gè)考慮因素，因?yàn)槿绻臅r(shí)過(guò)長(zhǎng)，則會(huì)成為項(xiàng)目實(shí)施的障礙。

　　? 該工具是否支持項(xiàng)目的語(yǔ)言?很多編譯器執(zhí)行自己的語(yǔ)言版本，并在該版本下分析代碼。因此，確保分析工具支持項(xiàng)目所用的語(yǔ)言就非常重要。

　　? 該工具是否可以立即整合至開(kāi)發(fā)進(jìn)程?如果需要不相稱(chēng)的努力來(lái)將工具集成到項(xiàng)目，則其作用不大。

　　功能和局限性

　　? 該工具是否可在整個(gè)系統(tǒng)工作?這是一個(gè)非常重要的問(wèn)題，因?yàn)閮H當(dāng)對(duì)整個(gè)系統(tǒng)進(jìn)行分析時(shí)，有些故障才能被檢測(cè)到。

　　? 該工具是否可以適應(yīng)跨程序循環(huán)?即使是在單一隊(duì)列，如果僅當(dāng)另一程序被分析時(shí)，某個(gè)程序才能被完全分析，跨程序循環(huán)也極為重要。

　　? 該工具的局限性有哪些?所有的工具都有局限性，包括所能分析的代碼數(shù)量，所能處理的模塊深度，所允許的嵌套深度以及表格規(guī)格。這些局限性及其對(duì)項(xiàng)目的影響也需要被注意且考慮在內(nèi)。

　　總結(jié)

　　鑒于復(fù)雜的軟件系統(tǒng)是很多醫(yī)療設(shè)備的核心，這些設(shè)備的成功與否與制造商展示軟件系統(tǒng)是否符合可靠性要求的能力有越來(lái)越密切的聯(lián)系。如FDA、 MDD和MHRA等的監(jiān)管機(jī)構(gòu)負(fù)責(zé)審批整個(gè)設(shè)備，而不是其中的一部分，證明設(shè)備軟件(軟件安全例證)可靠對(duì)于整個(gè)設(shè)備的審批就非常重要。因此，密切關(guān)注設(shè)計(jì)和開(kāi)發(fā)實(shí)踐，仔細(xì)選擇驗(yàn)證方法以及實(shí)施工具，對(duì)于任何使用軟件系統(tǒng)的醫(yī)療設(shè)備項(xiàng)目的成功都極為重要。

　　操作系統(tǒng)

　　不管驗(yàn)證工具多么優(yōu)秀，歸根結(jié)底它也是設(shè)備，它的軟件也需要通過(guò)審批。對(duì)任何使用軟件的系統(tǒng)而言，芯片以上的任何元件都需要依賴(lài)于操作系統(tǒng)(OS)。這意味著包含軟件的醫(yī)療設(shè)備的可靠性取決于其OS，而該OS必須有能力支持對(duì)于設(shè)備安全性提出的要求。在為安全系統(tǒng)選擇OS時(shí)需要注意以下幾個(gè)關(guān)鍵要求。

　　實(shí)時(shí)擔(dān)保

　　只有實(shí)時(shí)操作系統(tǒng)(RTOS)可以確?？煽啃运蟮募皶r(shí)反饋，而可靠性對(duì)任何安全軟件系統(tǒng)來(lái)說(shuō)都是最基本的。

　　架構(gòu)

　　實(shí)時(shí)執(zhí)行或者宏內(nèi)核操作系統(tǒng)的失效通常要求設(shè)備進(jìn)行重啟，這就使得系統(tǒng)可用性大打折扣。在微內(nèi)核實(shí)時(shí)操作系統(tǒng)中，應(yīng)用程序、設(shè)備驅(qū)動(dòng)程序、文件系統(tǒng)和網(wǎng)絡(luò)協(xié)議棧都運(yùn)行在內(nèi)核外部的獨(dú)立地址空間，因此它們不僅與內(nèi)核隔離，而且彼此之間也互不影響。一個(gè)組件出現(xiàn)故障不會(huì)導(dǎo)致整個(gè)系統(tǒng)癱瘓。

　　內(nèi)存保護(hù)

　　OS架構(gòu)需要將其內(nèi)存里的應(yīng)用和關(guān)鍵進(jìn)程分開(kāi)，防止單個(gè)故障蔓延至整個(gè)系統(tǒng)。

　　優(yōu)先級(jí)繼承

　　為防止優(yōu)先級(jí)反轉(zhuǎn)，RTOS需要支持將被阻止的高優(yōu)先級(jí)任務(wù)的優(yōu)先級(jí)分配給阻止任務(wù)的低優(yōu)先級(jí)線(xiàn)程，直至完成被阻止的任務(wù)。

　　分區(qū)

　　為了確?？捎眯?，RTOS需要支持固定分區(qū)或者更受青睞的自適應(yīng)分區(qū)。后者強(qiáng)制執(zhí)行資源預(yù)算，但采用一種動(dòng)態(tài)調(diào)度算法將一個(gè)分區(qū)內(nèi)閑置的 CPU 周期重新分配到另一個(gè)需要更多處理時(shí)間的分區(qū)內(nèi)。

　　高可用性

　　一個(gè)自啟動(dòng)的監(jiān)視程序需要監(jiān)控、停止以及在保證安全性的前提下來(lái)重啟進(jìn)程，而不需要系統(tǒng)的復(fù)位。如果重啟并不安全，則監(jiān)視程序需要將系統(tǒng)設(shè)置在設(shè)計(jì)安全狀態(tài)。