不論是傳統或自主車輛，負責與安全相關嵌入式系統的汽車工程師都正在尋找有效率的方法以達成適用於座乘用車開發功能安全標準ISO 26262 [1]所規範的嚴格流程。

當幾乎所有媒體都聚焦自主車輛，看起來在建議並不缺乏。不過這些建議通常著重於最新的程式碼編寫方法或摧毀程式臭蟲的工具。如同產業專家長期以來意識到的，安全性其實更貼近於讓系統以及其需求正確運作，而不僅僅是關注軟體的運行和如何編程[2]。

透過Simulink進行的模型化基礎設計(Model-Based Design)以連續和離散時間的模擬為骨幹，讓你可以在實際在試驗場或執行車隊測試之前，先在種類廣泛的駕駛條件與過失駕駛情境下設計和測試完整的系統。它還支援ISO 26262規範的流程活動，包含工具的資格認證。IEC安全驗證套裝組(IEC Certification Kit)詳細說明這項支援，並提供國際認證機構TUV SUD的工具認證和報告。

本文將說明如何透過TUV SUD認可的Simulink工作流程來進行ISO 26262專案計畫。文中首先介紹ISO 26262與模型化基礎設計，並接著涵蓋下列幾項任務：

* 需求開發

* 建立設計模型

* 產生程式碼

* 設計驗證

* 程式碼驗證

* 工具資格認證

ISO 26262與模型化基礎設計

ISO 26262除了涵蓋手動設計及編寫程式碼的指南之外，也包含模型化基礎設計。它認可使用模型化基礎設計所帶來的幾項好處[3]：

無縫地利用模型，可帶來相當一致且有效率的開發。

這項標準提及「廣泛使用」數學模型，並註記建模工具利用了「半正式圖解方法(semi-formal graphical methods)」來進行軟體開發。它說明到，建模不僅是捕捉(嵌入式軟體)將要實現的功能，也協助了真正的實體系統(車輛模型與環境模型)模擬，以創造一個完整的系統模型：

如此一來，就有可能建立出具備高度細節、非常複雜的車輛系統模型，以可接受的運算速度來模擬接近現實的行為。當車輛/環境模型逐漸在開發過程中被真實系統與其真實的環境取代，功能模型可以在程式碼生成時作為嵌入式軟體在控制單元上實現的藍圖。[3]

圖1為一個典型的Simulink閉迴系統模型。它由一個控制器與受控體、加上訊號處理器組合而成。在ISO 26262，系統設計規格是一項軟體開發的輸入值，但其實不僅於此，因為安全性是一個根本的系統議題[2]。

圖1 : Simulink系統設計模型。

你的系統設計接著會繼續精進，直到變成具備充分細節，讓你可以產生產品程式碼的軟體藍圖。ISO 26262以「模型演化(model evolution)」描述了這個模型的精進過程[2]：

在實務上，功能模型[有一個]從早期規格模型，經過設計模型，再到實現模型，最後自動轉換為程式碼的演變(模型演化)。

ISO 26262針對多種依據汽車安全完整度等級(Automotive Safety Integrity Levels，ASILs)的活動各提出方法建議。你可以利用這些指南，依照你的使用情況，來建立一個適當的工作流程。圖2提供一個ISO 26262流程總覽。色塊箭頭代表了開發活動，而線段的虛線箭頭代表驗證與有效性檢測活動。參照自ISO 26262的「模型演化」則以圓點(…)虛線箭頭表示。

圖2 : 使用Simulink進行ISO 26262軟體開發與驗證的流程。

需求開發

你可以透過編寫功能和安全需求來展開安全相關的開發流程。ISO 26262建議可以利用「在軟體架構設計和軟體安全性需求之間的雙向可追蹤性」來驗證軟體架構設計。為了達成這項任務，你可以使用Simulink需求管理工具(Simulink Requirements)來編寫需求，並在模型、測試、及程式碼追蹤需求的符合情況。Simulink需求管理工具支援其他工具的雙向追蹤，包含MicrosoftR WordR、Microsoft ExcelR、以及IBMR RationalR DOORSR。在Simulink需求管理工具裡面可以進行需求的實現和驗證狀態的監控與管理。需求連結也會在接下來產生的程式碼出現(圖3)。

圖3 : Simulink內的需求規格。

建立設計模型

如同在「ISO 26262與模型化基礎設計」段落所提，ISO 26262描述了功能模型從高階可執行規格到準備拿來產生產品程式碼的細節設計之間的演化。傳統的修改和精煉包含了：

* 利用Simulink控制模塊組(Simulink Control Design)的離散化工具，將模塊從連續時間(S domain)轉換為離散時間(Z domain)。

* 利用定點設計工具箱(Fixed-Point Designer)，將資料從雙重精確度轉換為單精確度或定點資料。

* 利用事件導向系統模擬軟體(StateflowR)，加上診斷、模式邏輯、狀態機、以及排程。

針對ASIL B到D，ISO 26262強烈建議使用模型化準則，於此，你可以使用Simulink提供的MAAB Style Guidelines [4]和High Integrity Guidelines for ISO 26262。這兩種準則都可以透過Simulink驗證標準檢測工具(Simulink Check)自動檢查。它可以在特定議題加上旗幟標示，例如插入的模塊尚未完成、編輯中等等。你也可以加入自己的準則和檢查。

產生程式碼

ISO 26262指明「軟體單元的實現包含開源程式碼的產生以及目標程式碼的編譯」。為了達到這個目的，你可以使用嵌入式程式碼轉碼器(Embedded CoderR)來產生C、C++程式碼，並從Simulink模型產生你的AUTOSAR程式碼。這些程式碼遵從MISRA CR:2012自動程式碼準則[5]。ISO 26262提到，模型化基礎設計和手動編寫程式碼的程式碼準則可能不同，並以MISRAR作為範例。

IEC安全驗證套裝組提供嵌入式程式碼轉碼器在C、C++、和AUTOSAR的工具資格認證支援(包含ASIL A-D)。其TUV SUD報告聲明：

嵌入式程式碼轉碼器符合ISO 26262於工具支援和自動化之需求。

3.為用於產生產品程式碼之模型產生C++程式碼

嵌入式程式碼轉碼器提供選項，以進行程式碼在記憶體和速度上面的優化。除此之外，你可以產生利用硬體加速器，例如ARM和Intel的SIMD的處理器專用的優化方式。你也可以利用ISO 26262描述的模型到程式碼(model-to-code)、處理器迴圈(processor-in-the-loop，PIL)測試驗證，經過優化的程式碼是否符合模擬結果的規定誤差範圍。

可執行目標程式碼會以你的編譯器和連結器從開源程式碼產生。IEC安全驗證套裝組內的工作流程，支援轉碼器、編譯器、以及處理器的優化。只要是PIL測試會被用來驗證可執行目標程式碼，這項支援對於大量生產的ECUs非常重要。

設計驗證

ISO 26262建議了幾種靜態和動態方法來驗證軟體設計與實現，包括單元及整合層級的活動。針對模型化基礎設計，它提到「依據軟體開發流程，測試目標可以是由模型導出的程式碼或者模型本身」。

Simulink測試工具箱(Simulink Test)在Simulink環境為ISO 26262的驗證和有效性檢測活動提供了一個架構。你可以使用它來為模型和從模型產生程式碼來編寫、管理、以及執行系統的、以模擬為基礎的測試。圖4為一個測試序列和估測模塊的範例。

圖4 : 建模與編寫複雜測試情境的Simulink測試序列和估測模塊。

IEC Certification Kit (for ISO 26262)的TUV SUD報告書釐清了Simulink測試工具箱的角色，在於幫助驗證和有效性檢測的自動化：

[Simulink測試工具箱]

讓Simulink模型與產生的程式碼的核心驗證與有效性檢測活動得以自動化。接下來的事件反映出依據功能安全標準ISO 26262在軟體開發流程的必要活動：

* 需求與測試案例之間的可追蹤性鑑定

ISO 26262建議以結構覆蓋度分析來判斷測試完整性及鑑定不在計畫中的功能性。它列出三種方法來增加嚴謹程度，後面兩種方法非常建議ASIL-D等級使用。

* 陳述覆蓋度

* 分支覆蓋度

* MC/DC覆蓋度

標準中提到模型化基礎設計，「可以在模型層級以類似的結構覆蓋度量來執行模型的覆蓋分析」。它繼續指出，如果結構覆蓋度不足，「應再增加制定其他測試案例或提出理由」。

Simulink程式碼覆蓋度測試工具(Simulink Coverage)為模型和產生的程式碼提供了結構覆蓋，而且可以很容易地利用Simulink測試工具箱執行測試。如果你的模型覆蓋不足，則可以使用Simulink設計驗證工具(Simulink Design Verifier)來自動產生另外的測試案例以達到要求的覆蓋程度。它內含一個度量儀表板來衡量專案的品質，並滿足ISO 26262在「複雜性低且軟體元件與介面規模有限的執行」要求(圖5)。

圖5 : 度量儀表板顯示了模型指南的遵照程度。

IEC安全驗證套裝組提供工具資格認證支援，包含Simulink驗證標準檢測工具、Simulink程式碼覆蓋度測試工具(包含模型與程式碼的覆蓋度)、Simulink設計驗證工具、Simulink測試工具箱的TUV SUD認證與報告。

程式碼驗證

ISO 26262為軟體設計和實現的驗證提供了幾種選擇。在IEC安全驗證套裝組描述的第一種方法能夠允許有限的追蹤檢查，來偵測生成的程式碼中不在預期內的功能，像是程式碼並未追蹤至模塊或訊號。這個套裝組為了這個目的自動產生一個追蹤矩陣。或者，也可以在軟體迴圈(software-in-the-loop，SIL)測試階段利用Simulink程式碼覆蓋度測試工具比較模型覆蓋與程式碼覆蓋，或使用Simulink程式碼檢查器(Simulink Code Inspector?)。

最後，可以透過Polyspace查錯器(Polyspace Bug Finder)檢查是否遵照了MISRA。使用MISRA檢查與程式碼覆蓋分析對混合了自動產生程式碼和手寫程式碼軟體的專案特別有幫助。再更嚴謹一點，還可以使用Polyspace程式碼驗證器(Polyspace Code Prover)來證實，程式碼不會出現像是除以零這種執行階段錯誤(run-time errors)。

IEC安全驗證套裝組提供工具認證支援，Polyspace產品有TUV SUD的認證和報告。

在編譯及產生可執行程式碼之後，在目標處理器上執行程式碼時，可以利用PIL測試來重複利用模型測試(圖6)。

圖6 : 嵌入式處理器的PIL範例

ISO 26262強烈建議ASILs C與D採用背向測試。它指出在一個具代表性的目標硬體環境測試的重要性，並強調察覺測試環境與硬體環境之間差異的重要性：

測試環境及目標環境的差異可能在開源程式碼與目標程式碼出現，比如，資料文字與處理器顯示文字的位元寬度不同。

不過每一位電腦工程師都應該要知道[6]，在平台之間存在許多潛在的數值差異，特別是浮點資料。有的差異在開始時十分細微，但卻會累積、增長，尤其是在回饋控制系統。因此ISO 26262列出幾種背向測試的迴圈方法：

軟體單元測試可以在不同環境執行，例如：

—硬體迴圈測試

Simulink測試工具箱可以將迴圈測試自動化，包含透過嵌入式程式碼轉碼器進行SIL與PIL，以及透過Simulink即時控制工具(Simulink Real-Time)進行HIL，並經由Simulink程式碼覆蓋度測試工具，提供包含覆蓋度量的pass/fail報告。

工具資格認證

ISO 26262-8描述了其它的過程，包含版本控管、結構管理、以及文件。這些過程可分別由Simulink Projects、Simulink模型差分化與合併、以及Simulink報告產生器支援。

這項標準也提供了工具資格認證指南。它不允許工具供應商認證自己的工具，而是要使用者為特定的專案進行工具認證。IEC安全驗證套裝組可以藉由提供典型的使用案例、參考工作流程、產品分級分析、軟體工具文件、工具認證報告、以及有效性檢測報告來有效地預先驗證工具。

TUV SUD審核並稽查MathWorks工具開發與品質流程，以及錯誤回報能力，並且認證了每個產品版本的結果。IEC安全驗證套裝組包含這些在遵循適當驗證與有效性檢測工作流程時所需要的TUV SUD認證和報告。這一個套裝組如同文章稍早所提，依據典型的工具使用案例提供了參考工作流程。

IEC安全驗證套裝組提供更多細節資訊，包含映射ISO 26262目標於Simulink所支援的能力(圖7)。

圖7 : 節錄自IEC安全驗證套裝組的ISO 26262-to-Simulink映射

請注意使用經過認證的工具並不保證在考量中的軟體或系統的安全性。

（本文由鈦思科技提供；作者Tom Erkkinen任職於MathWorks公司）

參考文獻

[1] ISO 26262 Road vehicles — Functional safety

[2] Nancy G. Leveson, Engineering a Safer World, Systems Thinking Applied to Safety

[3] ISO 26262-6 — Part 6: Product development at the software level

[4] MAAB Style Guidelines

[5] MISRA C:2012

[6] David Goldberg, What Every Computer Scientist Should know about Floating-Point Arithmetic

[7] ISO 26262 Road vehicles — Functional safety

[8] Nancy G. Leveson, Engineering a Safer World, Systems Thinking Applied to Safety

[9] ISO 26262-6 — Part 6: Product development at the software level

[10] MAAB Style Guidelines

[11] MISRA C:2012

[12] David Goldberg, What Every Computer Scientist Should know about Floating-Point Arithmetic