圖6——項目小組為循環(huán)周期中的每個“Sprint”確定“Sprint待辦事項”工作任務,并對其進行擴展和分配。然后,項目小組在日常的”Scrum“會議上評估進程,并消除相關障礙。小組在每個“Sprint”終止時向客戶交付產品功能。
在 Scrum/Sprint流程中,我們僅要求高級系統(tǒng)架構和規(guī)范即可啟動項目。我們將項目細分為4~6個星期長的“Sprint”。在每個 “Sprint”中,我們可確定我們認為流程將會要求的所有任務,并將其置于“燃盡”列表(burn-down list)中。圖5與圖6顯示了相關流程圖。HEI在全公司范圍內使用Scrum/Sprint開發(fā)流程,不僅將我們的開發(fā)進程加快了30%,而且還使我們提前數月完成了新產品的實施。表1對瀑布式開發(fā)與Srum/Sprint開發(fā)方案進行了比較。
醫(yī)療設備開發(fā)的第三階段,也是最后一個階段,屬于產品整個生命周期的后期(圖7)。這個階段要求的工程設計工作非常少,不過客戶反饋和市場成功將有助于推動新一代產品的概念形成,這樣生命周期又進入新的循環(huán)。
圖7—產品生命周期后期工作是將產品推向市場,獲取反饋,幫助確定新一代產品的功能。這樣就完成了本周期的工作,并將其帶入新的構思階段。
采用Scrum/Sprint產品開發(fā)流程,再結合使用基于FPGA的套裝硬件以及涵蓋從研發(fā)到制造過程的高級FPGA軟件設計工具,HEI就能夠迅速地開發(fā)出未來產品的衍生技術。我們發(fā)現(xiàn)在眾多情況下都可以使用我們在多種產品開發(fā)中采用的通用內核架構。例如,可調整IV與輸液泵的泵控制器架構,同樣也能用于可控制電機以實現(xiàn)輸血管理的其它設計項目中。
為何硬件優(yōu)于軟件
為了有效地使用這種方法,并進一步加快設計流程,就必須改變構思設計的方式,即從以軟件為中心轉變?yōu)楦嗟匾杂布橹行?。正如人們所意識到的,醫(yī)療設備的召回在2008年達到新高,比2007年上升43%。FDA專家認為,發(fā)生召回問題的主要原因有兩個:生產中采用的原材料存在缺陷;軟件開發(fā)工作存在問題。企業(yè)對原材料質量的管理相對容易一些,不過解決軟件的質量問題難度則要大得多。隨著設備軟件的代碼量迅速增加,問題只會日益嚴重。在FDA的消費者健康安全部表示醫(yī)療設備設計方要承擔眾多安全責任后,這個問題尤為突出。
在HEI,我們認為該問題具有一個潛在的解決方案,不過不是進行更多的測試、代碼檢查和引入更多的流程,相反,我們僅是盡量少編寫軟件,將更多的邏輯交給諸如賽靈思FPGA這樣的硬件元件來執(zhí)行。讓我們來看看發(fā)生軟件故障的常見原因,以及我們將如何使用FPGA來解決這些問題。
消除死鎖
大多數現(xiàn)代化設備都需要能夠同時處理多個任務,而大多數嵌入式處理器的處理內核仍然只有一個。這意味著處理器每次只能執(zhí)行一個指令。同時,并行處理也好不到那里去,因為他們仍然必須共享主系統(tǒng)CPU。此外,諸如通信驅動器、硬盤和用戶接口元件等其他共享資源也會引發(fā)死鎖——兩個或兩個以上的處理進程相互等待對方釋放資源。
由于死鎖狀況經常有賴于多個進程,并且通常要求事件在順序上出現(xiàn)同步,因而死鎖非常難以復制和調試。僅僅進行單元測試很難發(fā)現(xiàn)大多數死鎖問題。它們往往被代碼檢查人員、熟練的系統(tǒng)測試人員所發(fā)現(xiàn),甚至有時靠運氣發(fā)現(xiàn)。
相比之下,采用FPGA,相互獨立的進程擁有其自己的物理電路系統(tǒng),因而不存在共享資源。在每個時鐘信號報時的時候,組合邏輯不僅在每個電路中閉鎖,而且還會在獨立的寄存器中存儲相關值。由于進程不依賴其他資源,因而也不會發(fā)生死鎖問題。這樣您就能更多地相信仿真和單元測試的結果,因為諸如資源競爭這樣的未知因素不再是個問題。
互不兼容的中間件
在開發(fā)嵌入式軟件時,您基本上無需從頭開始編寫每一行代碼。有許多工具都可幫助固件設計人員提升工作效率,如簡單的驅動器、網絡協(xié)議棧、操作系統(tǒng)、乃至代碼生成工具等。雖然這些系統(tǒng)通常都進行過全面的獨立測試,但軟件還是會存在缺陷。由于工具和庫的組合方式多種多樣,將組件以全新的方式組合在一起使用的可能性非常大。
基于此種原因,F(xiàn)DA 要求對在醫(yī)療設備中使用的所有套裝軟件,企業(yè)必須根據其具體設計的具體使用情況對軟件協(xié)議棧進行審驗。這是什么意思呢?例如,若我們正在使用包含定點快速傅立葉變換的信號處理庫,并需要檢測是否存在特定的頻率組分,我們就無需驗證對于所有可能的輸入,F(xiàn)FT是否都會返回正確的值。但是,我們需要驗證的是,對于符合規(guī)范的所有有效輸入,F(xiàn)FT能否返回我們期望的值。例如,如果我們只檢測人耳能聽到的音調,就沒有必要測試輸入超過20KHz以上時返回的值是否正確。
不過,看上去相互獨立的軟件組件并不一定如此。因此,如果我們將軟件協(xié)議棧與SPI驅動器結合起來使用,并配以實時操作系統(tǒng)(RTOS),我們就需要對所有這些組件進行驗證才能對FFT充滿信心。如果FFT將有效輸出傳遞到SPI驅動器,但SPI驅動器出現(xiàn)系統(tǒng)性故障,那么問題顯然不可避免。然后,如果我們決定調整SPI驅動器,就需要再次驗證整個軟件協(xié)議棧。這非常麻煩,而且一個存在故障的組件會拖累整個系統(tǒng)的開發(fā)進程?;诖嗽?,在HEI,我們盡可能多地重復利用經檢驗具備良好特性的中間件和RTOS驅動器組合。例如,我們可使用NI單板RIO平臺上的中間件驅動器。
除了按照每種具體使用情況審驗軟件以外,我們還需要審驗我們在我們基于FPGA的設計中使用的所有第三方知識產權 (IP)。不過,一旦我們完成我們所有使用情況的審驗工作,我們就會深信不疑:IP在和其它組件集成后,工作情況會如同預期一樣。讓我們再來看看我們上面舉的FFT示例。如果我們使用FPGA,我們就可和使用軟件一樣,獲取或者生成FFTIP內核,根據每個使用情況驗證其數字的正確性。不過,間發(fā)故障的風險可大幅降低,因為我們不需要以軟件為中心的設計所需要的所有處理器中間件。這樣,RTOS及SPI驅動器就不再是其自身IP內核了,因為其工作不會直接影響FFT。另外,如果我們調整SPI驅動器的實施,我們就不需要對系統(tǒng)未影響的部分再進行審驗。
緩沖器溢出管理
我們如何使用FPGA來減少以軟件為中心的系統(tǒng)通常會產生的錯誤的另一個示例就是緩沖器溢出管理。當程序試圖存儲超過為其存儲分配的存儲器末端的數據時,程序就會重復寫入本不該寫入的某些相鄰數據,這樣就會產生緩沖器溢出。這是個很難察覺的缺陷,因為在將來任何時候都可訪問被重寫的存儲器,而且這種情況可能會造成明顯的錯誤,也可能不會。嵌入設計中一種比較常見的緩沖器溢出情況是某種高速通信造成的,或許來自網絡、磁盤或者A/D轉換器。如果通信中斷時間過長,緩沖器就會溢出,因此我們需要解決這個問題來防止各種沖突。
我們可以以兩種方式采用FPGA來管理緩沖器溢出。在第一種示例中,我們采用FPGA管理循環(huán)傳輸或者雙緩沖傳輸,這樣可卸載實時處理器的負荷。在這種情況下,F(xiàn)PGA可用作協(xié)處理器,降低主處理器的中斷負載。這是一種通用配置,特別是在高速A/D轉換器中。
在第二種示例中,我們將FPGA用作保護功能的安全保護層,讓針對病人的I/O在到達處理器之前,先通過FPGA。在這種情況下,您可以為FPGA增加額外的安全邏輯,這樣在處理器上的軟件崩潰時,您可將所有的輸出置于已知的安全狀態(tài)下。FPGA可發(fā)揮看門狗的作用,其邏輯可以在軟件發(fā)生故障的時候保證對病人的風險降低到最低程度。通過在架構設計中將FPGA引入設備的主信號鏈,您可以使用這兩種方法中的一種或者兩種來應對緩沖器溢出,以便在發(fā)生狀況的時候能夠更好地處置。
事實上,越多地將軟、硬件總體系統(tǒng)功能移至FPGA中,就能越快地完成設計流程,并最終越快地完成我們的設計在客戶最終產品上的驗證工作。如果我們能更快地驗證我們設計方案在總體系統(tǒng)上運行的可靠性,那么我們的客戶就能更快地驗證整個最終產品,進而將其交付 FDA審批。這一過程意味著我們的客戶能夠顯著加速其產品的上市進程,改善患者的生活質量,甚至拯救生命。
如果我們采用 ASIC工藝來實施設計,我們需要為代工廠生產出硬件等上好幾個月。驗證ASIC的物理設計、創(chuàng)建掩膜并將設計投產等額外的步驟會造成更多出錯和出現(xiàn)缺陷的幾率。如果設計在任何這些步驟中出現(xiàn)錯誤,結果都會導致產品上市時間被大大拖延。由于已生產出FPGA且經過全面的測試,因此我們只需關心我們的設計和軟件,并確保設計能夠符合客戶的規(guī)范要求。全面結合“Scrum/Sprint”方法、以硬件為中心的構思、使用高度可靠的工具并在FPGA與ASIC中選擇FPGA,我們便能使客戶實現(xiàn)差異化,進而也能為客戶的客戶,即患者帶來改變。