事件驅動錯誤注入方法

圖 4-4 錯誤注入模組虛擬程式碼

上圖是錯誤注入模組的虛擬程式碼，上面的虛擬程式中錯誤注入的啟動條件 是屬於事件組合的類型，此組合事件是由表 4.2 中的傳輸型態 (Type)、傳輸位址 (Address) 以及主人端編號 (MasterID) 三種類型的事件組合作為錯誤注入的動 條件，當此事件發生時錯誤注入模組就會進行錯誤的注入程序。由於 CoWare 的 Platform Architect 將 Transactor 模組分成兩大類，分別是主人端用和僕人端用，

因此我們也分別將之實踐出資料收集和錯誤注入等功能。由於主人端所能掌控的 資訊較僕人端來的多，因此主人端的錯誤注入模組所能套用的錯誤注入模型相較 於僕人端會有更大的發揮空間，這也是我們往後研究的重點之ㄧ。

型。舉例來說透過傳輸型態 (Type) 我們就可得知目前匯流排要進行的是讀取 (Read) 、寫入 (Write) 亦或是閒置 (Idle) 。透過傳輸模式 (Group) 我們能夠得 知目前傳輸的資料是屬於單筆傳輸 (Single) 、爆發式傳輸的起頭 (BurstStart) 、 爆發式傳輸中 (BurstCont) 或是爆發式傳輸中卻被閒置 (BurstIdle) 。為了對應 系統平台我們改以 ARM 系統匯流排的在運作中所會夾帶的傳輸資訊作為我們錯 誤注入的事件，這些事件是能夠明確對應到系統匯流排的實際運作，我們透過這 種方式對事件驅動中的事件下了個較為明確的定義。

在這篇論文中我們除了提出了一種較為明確的事件定義外更提出了事件組 合的概念，在講解事件組合的意義之前我們先介紹我們的事件樹。關於事件樹的 建立主要會依據你所使用的系統匯流排、傳輸模式、系統架構以及應用的不同而 產生不同的結果。表 4.2 的事件樹則是我們用來分析 AMBA 架構的系統平台所 建構出來的。在 AMBA 架構的平台中主要是先以主人端 (MasterID) 為起始，因 為在系統架構中只有當主人端送出需求後才會有資料傳輸的進行，因此匯流排的 資料傳輸 (Bus transaction) 即代表著是哪各主人端 (MasterID) 在進行動作。當 主人端進行資料傳輸時只會擁有三種狀態：讀取、寫入或是閒置，由於閒置則代 表此零件並未動作所以我們就不會將此狀態加入到我們的事件樹中，因此接續第 一層的資料傳輸後下一層便是分割為讀取和寫入這兩項。在 ARM 系統匯流排中 資料傳輸的模式主要可分為單筆資料傳輸 (Single) 以及爆發式傳輸 (Burst) ，無 論是讀取或寫入也都可以選擇採用單筆或是爆發式的資料傳輸方式，因此事件樹 架構中的第三階層就會以單筆資料傳輸和爆發式資料傳輸為主。最後的第四層就 主要是一些輔助性的事件，可說是提供使用者一些較為特殊用途的事件為輔助，

其最後架構圖如圖 4.5。

圖 4-5 事件樹架構圖

上面所架構出的事件樹正好可以對應到前一小節中的資料收集模組和錯誤 注入模組。在資料收集模組中所需要收集的資訊主要是以錯誤注入模組中所選擇 的事件為依據，而這些事件則是參考上面的事件樹中包含的事件來進行選擇。在 決定了所需要的組合事件後，資料收集模組將只會去對該事件發生時挾帶的資訊

加以收及，這樣做的目的在於減少所需收集的資料量。因此在我們所提出的錯誤 注入方法中資料收集模組、錯誤注入模組和事件樹三者之間可說是缺一不可，透 過這三部份的互相搭配才使我們能在系統晶片階層的平台上提出有效的事件驅 動錯誤注入方法，並且透過此方法來提升失敗模式分析的效率。

在這篇論文中我們提出了事件驅動的錯誤注入方法，我們透過 ARM 系統匯 流排在進行資料傳輸中所會夾帶的特殊資訊當成是我們的錯誤注入的啟動事 件。此外我們還提出了另外一種概念，透過將個別或是有關聯性的單一事件加以 組合成為一個新的錯誤注入啟動條件，在這個部份我們提供了一種具有彈性的使 用方式，使用者能依照他們所面對到的系統自行組合出最適合的錯誤注入驅動條 件。這種方式不只是能夠有效的針對不同的系統進行錯誤的注入，更能提升故障 模式分析時的效率。