幾乎每個使用手機的人都會有過幾次通話中斷的經歷。雖然這些產品以及其他消費類產品的系統故障或者小毛病會帶來不方便，但它們不會造成災難性的后果。然而，醫療電子設備的一次系統故障就會帶來生命威脅，這也是為什么醫療設備，以及這些系統中集成的器件和這些器件中運行的軟件必須通過嚴格測試，并符合美國食品藥品監督管理局(FDA)的嚴格要求。

　　為確保我們的新設計能夠發揮理想可靠的性能，順利通過FDA審批流程，我們采用了一種稱為“Scrum/Sprint開發流程”的高度結構化的設計方法。此外，通過減少在軟件中實施的功能，還能夠降低軟件出錯的幾率。我們已在賽靈思的FPGA中實施了這些功能。為了能夠更充分地理解這種方法，我們首先來分析一下醫療設備的設計流程。

三階段生命周期

　　FDA針對醫療電子產品制定了嚴格的規定、要求和指導原則，旨在確保社會大眾的人身安全。在這些規定中，FDA對醫療設備（圖 1）的生命周期制定了嚴格的要求。一般情況下，電子產品公司必須在如下方面都符合上述規定的要求，其中包括醫療設備的所有元件、零部件或者配件，醫療設備生產過程中采用的任何軟件，以及設備制造商質量系統使用的所有軟件，如可記錄并保持設備歷史記錄的程序等。

?

圖1、FDA定義的醫療設備設計整個生命周期圖.

　　我們可將醫療設備整個生命周期劃分為三個主要階段。首先是產品整個生命周期的初期階段（圖2），該階段是所有三個階段中系統性最差的階段，期間企業主要側重于理論與構思方面的研究和開發。該階段的持續時長從數星期到數年不等，這與企業準備開發的系統的復雜程度息息相關。

?

圖2、在產品整個生命周期的初期階段應用虛擬儀器和HEI設計方法，可以清晰地理解需要解決的問題。

　　產品整個生命周期初期階段的基本組成部分是數據采集與分析。通常情況下，研究人員與產品設計規范小組會使用多種工具來精簡流程。在這個階段，HEI通常會采用美國國家儀器(NI)公司的LabVIEW產品來調整 FPGA的I/O。一旦充分理解問題，我們就能設計出解決方案。對于器件開發及原型設計，我們結合直觀的圖形編程，重復使用數學與信號處理功能來開發新的算法。然后，通過使用商用套裝硬件，我們對現實世界的數據進行參考來對算法的性能進行驗證。在許多情況下，我們都能使用NI提供的基于FPGA的原型設計平臺來實現最終器件的實驗原型。確切地說，我們能夠將LabVIEWReal-Time模塊和FPGA模塊同NI CompactRIO結合使用，以便在算法設計和器件原型階段之間迅速實現疊代。使用硬件套件進行原型設計，不僅能夠顯著縮短硬件開發與集成時間，而且還使我們能夠將更多精力集中到交付功能強大、性能可靠的軟件設計中。

?

圖3、軟件設計的審核與驗證工作通常是在產品整個生命周期的中期完成。

　　可將醫療設備整個生命周期的第二階段稱為產品整個生命周期的中期（參見圖3），能夠充分滿足所設計的設備在產品化、驗證、審核以及制造等方面的需求。該階段的重點是制定準確定義的、清晰載明可量化要求的規范文檔。這些規范一經定義，即可在規范文檔與實際的實施代碼之間建立明確的映射關系。

?

圖4、傳統的“瀑布式”開發流程在進入到下一步前需完成每一階段的開發。

　　在當今錯綜復雜的醫療設備市場上，客戶必須加速上市，捷足先登。眾多公司紛紛采用傳統的“瀑布式”開發法來完成這項工作。“瀑布式”開發法中的設計小組在進入下一步前，需要完成設計流程的每個步驟（圖4）。瀑布法高度依賴在項目展開之初就擁有完整準確的規范。但是，在醫療設備市場，更多的時候需求會隨著產品的開發而不斷發展變化。這就需要能夠將發展演進也考慮周全的流程。HEI的Scrum/Sprint開發流程就是可充分解決這一問題的理想方案。

?

圖5? 在“Scrum/Sprint”流程中，啟動項目只需要高級系統架構和規范。

?

　　圖6——項目小組為循環周期中的每個“Sprint”確定“Sprint待辦事項”工作任務，并對其進行擴展和分配。然后，項目小組在日常的”Scrum“會議上評估進程，并消除相關障礙。小組在每個“Sprint”終止時向客戶交付產品功能。

　　在Scrum/Sprint流程中，我們僅要求高級系統架構和規范即可啟動項目。我們將項目細分為4～6個星期長的“Sprint”。在每個 “Sprint”中，我們可確定我們認為流程將會要求的所有任務，并將其置于“燃盡”列表(burn-down list)中。圖5與圖6顯示了相關流程圖。HEI在全公司范圍內使用Scrum/Sprint開發流程，不僅將我們的開發進程加快了30%，而且還使我們提前數月完成了新產品的實施。表1對瀑布式開發與Scrum/Sprint開發方案進行了比較。

　　醫療設備開發的第三階段，也是最后一個階段，屬于產品整個生命周期的后期（圖7）。這個階段要求的工程設計工作非常少，不過客戶反饋和市場成功將有助于推動新一代產品的概念形成，這樣生命周期又進入新的循環。

?

　　圖7—產品生命周期后期工作是將產品推向市場，獲取反饋，幫助確定新一代產品的功能。這樣就完成了本周期的工作，并將其帶入新的構思階段。

　　采用Scrum/Sprint產品開發流程，再結合使用基于FPGA的套裝硬件以及涵蓋從研發到制造過程的高級FPGA軟件設計工具，HEI就能夠迅速地開發出未來產品的衍生技術。我們發現在眾多情況下都可以使用我們在多種產品開發中采用的通用內核架構。例如，可調整IV與輸液泵的泵控制器架構，同樣也能用于可控制電機以實現輸血管理的其它設計項目中。

為何硬件優于軟件

　　為了有效地使用這種方法，并進一步加快設計流程，就必須改變構思設計的方式，即從以軟件為中心轉變為更多地以硬件為中心。正如人們所意識到的，醫療設備的召回在2008年達到新高，比2007年上升43%。FDA專家認為，發生召回問題的主要原因有兩個：生產中采用的原材料存在缺陷；軟件開發工作存在問題。企業對原材料質量的管理相對容易一些，不過解決軟件的質量問題難度則要大得多。隨著設備軟件的代碼量迅速增加，問題只會日益嚴重。在FDA的消費者健康安全部表示醫療設備設計方要承擔眾多安全責任后，這個問題尤為突出。

　　在HEI，我們認為該問題具有一個潛在的解決方案，不過不是進行更多的測試、代碼檢查和引入更多的流程，相反，我們僅是盡量少編寫軟件，將更多的邏輯交給諸如賽靈思FPGA這樣的硬件元件來執行。讓我們來看看發生軟件故障的常見原因，以及我們將如何使用FPGA來解決這些問題。

消除死鎖

　　大多數現代化設備都需要能夠同時處理多個任務，而大多數嵌入式處理器的處理內核仍然只有一個。這意味著處理器每次只能執行一個指令。同時，并行處理也好不到那里去，因為他們仍然必須共享主系統CPU。此外，諸如通信驅動器、硬盤和用戶接口元件等其他共享資源也會引發死鎖——兩個或兩個以上的處理進程相互等待對方釋放資源。

　　由于死鎖狀況經常有賴于多個進程，并且通常要求事件在順序上出現同步，因而死鎖非常難以復制和調試。僅僅進行單元測試很難發現大多數死鎖問題。它們往往被代碼檢查人員、熟練的系統測試人員所發現，甚至有時靠運氣發現。

　　相比之下，采用FPGA，相互獨立的進程擁有其自己的物理電路系統，因而不存在共享資源。在每個時鐘信號報時的時候，組合邏輯不僅在每個電路中閉鎖，而且還會在獨立的寄存器中存儲相關值。由于進程不依賴其他資源，因而也不會發生死鎖問題。這樣您就能更多地相信仿真和單元測試的結果，因為諸如資源競爭這樣的未知因素不再是個問題。

互不兼容的中間件

　　在開發嵌入式軟件時，您基本上無需從頭開始編寫每一行代碼。有許多工具都可幫助固件設計人員提升工作效率，如簡單的驅動器、網絡協議棧、操作系統、乃至代碼生成工具等。雖然這些系統通常都進行過全面的獨立測試，但軟件還是會存在缺陷。由于工具和庫的組合方式多種多樣，將組件以全新的方式組合在一起使用的可能性非常大。

　　基于此種原因，FDA要求對在醫療設備中使用的所有套裝軟件，企業必須根據其具體設計的具體使用情況對軟件協議棧進行審驗。這是什么意思呢？例如，若我們正在使用包含定點快速傅立葉變換的信號處理庫，并需要檢測是否存在特定的頻率組分，我們就無需驗證對于所有可能的輸入，FFT是否都會返回正確的值。但是，我們需要驗證的是，對于符合規范的所有有效輸入，FFT能否返回我們期望的值。例如，如果我們只檢測人耳能聽到的音調，就沒有必要測試輸入超過 20KHz以上時返回的值是否正確。

　　不過，看上去相互獨立的軟件組件并不一定如此。因此，如果我們將軟件協議棧與SPI驅動器結合起來使用，并配以實時操作系統(RTOS)，我們就需要對所有這些組件進行驗證才能對FFT充滿信心。如果FFT將有效輸出傳遞到SPI驅動器，但 SPI驅動器出現系統性故障，那么問題顯然不可避免。然后，如果我們決定調整SPI驅動器，就需要再次驗證整個軟件協議棧。這非常麻煩，而且一個存在故障的組件會拖累整個系統的開發進程。基于此原因，在HEI，我們盡可能多地重復利用經檢驗具備良好特性的中間件和RTOS驅動器組合。例如，我們可使用NI 單板RIO平臺上的中間件驅動器。

　　除了按照每種具體使用情況審驗軟件以外，我們還需要審驗我們在我們基于FPGA的設計中使用的所有第三方知識產權(IP)。不過，一旦我們完成我們所有使用情況的審驗工作，我們就會深信不疑：IP在和其它組件集成后，工作情況會如同預期一樣。讓我們再來看看我們上面舉的FFT示例。如果我們使用FPGA，我們就可和使用軟件一樣，獲取或者生成FFTIP內核，根據每個使用情況驗證其數字的正確性。不過，間發故障的風險可大幅降低，因為我們不需要以軟件為中心的設計所需要的所有處理器中間件。這樣，RTOS及SPI驅動器就不再是其自身IP內核了，因為其工作不會直接影響FFT。另外，如果我們調整SPI驅動器的實施，我們就不需要對系統未影響的部分再進行審驗。

緩沖器溢出管理

　　我們如何使用FPGA來減少以軟件為中心的系統通常會產生的錯誤的另一個示例就是緩沖器溢出管理。當程序試圖存儲超過為其存儲分配的存儲器末端的數據時，程序就會重復寫入本不該寫入的某些相鄰數據，這樣就會產生緩沖器溢出。這是個很難察覺的缺陷，因為在將來任何時候都可訪問被重寫的存儲器，而且這種情況可能會造成明顯的錯誤，也可能不會。嵌入設計中一種比較常見的緩沖器溢出情況是某種高速通信造成的，或許來自網絡、磁盤或者 A/D轉換器。如果通信中斷時間過長，緩沖器就會溢出，因此我們需要解決這個問題來防止各種沖突。

　　我們可以以兩種方式采用 FPGA來管理緩沖器溢出。在第一種示例中，我們采用FPGA管理循環傳輸或者雙緩沖傳輸，這樣可卸載實時處理器的負荷。在這種情況下，FPGA可用作協處理器，降低主處理器的中斷負載。這是一種通用配置，特別是在高速A/D轉換器中。

　　在第二種示例中，我們將FPGA用作保護功能的安全保護層，讓針對病人的I/O在到達處理器之前，先通過FPGA。在這種情況下，您可以為FPGA增加額外的安全邏輯，這樣在處理器上的軟件崩潰時，您可將所有的輸出置于已知的安全狀態下。FPGA可發揮看門狗的作用，其邏輯可以在軟件發生故障的時候保證對病人的風險降低到最低程度。通過在架構設計中將FPGA引入設備的主信號鏈，您可以使用這兩種方法中的一種或者兩種來應對緩沖器溢出，以便在發生狀況的時候能夠更好地處置。

　　事實上，越多地將軟、硬件總體系統功能移至FPGA中，就能越快地完成設計流程，并最終越快地完成我們的設計在客戶最終產品上的驗證工作。如果我們能更快地驗證我們設計方案在總體系統上運行的可靠性，那么我們的客戶就能更快地驗證整個最終產品，進而將其交付FDA審批。這一過程意味著我們的客戶能夠顯著加速其產品的上市進程，改善患者的生活質量，甚至拯救生命。

　　如果我們采用ASIC工藝來實施設計，我們需要為代工廠生產出硬件等上好幾個月。驗證ASIC的物理設計、創建掩膜并將設計投產等額外的步驟會造成更多出錯和出現缺陷的幾率。如果設計在任何這些步驟中出現錯誤，結果都會導致產品上市時間被大大拖延。由于已生產出FPGA且經過全面的測試，因此我們只需關心我們的設計和軟件，并確保設計能夠符合客戶的規范要求。全面結合 “Scrum/Sprint”方法、以硬件為中心的構思、使用高度可靠的工具并在FPGA與ASIC中選擇FPGA，我們便能使客戶實現差異化，進而也能為客戶的客戶，即患者帶來改變。