汽車業的功能性安全，一開始是專門保留給車輛內部一小部份電子控制單元(ECU)用來執行一些關鍵功能。不過，因應安全要求的汽車應用數目日漸成長，過去幾年這個情況已出現顯著變化。從Level 2自駕車上具有的安全性功能的數量，或許最能解釋這個現象，例如塞車協助與駕駛監控。隨著越來越多的駕駛輔助創新與應用被整合到車輛中，更全面地採用功能性安全，是邁向完全自駕之路最基本的要求之一。
工業界朝智慧製造演進與轉型，讓人們目睹自動化的崛起，以及生產線上與人類一起作業的協作機器人(Co-bot)越來越普遍地被採用。隨著人類與機器持續的在近距離內一起作業，控制系統必須不斷地監控機器人的完整性，並在錯誤情況下做出妥善的回應。這也帶動對更高層級的功能性安全的需求。
透過像是汽車業的ISO 26262、以及工業製造的IEC 61508等國際認證標準，開發者有可能以結構完整且一致的方式來執行安全性的要求。 為了開發橫跨產業的共同語言，同時提供大家視為最佳實作的參考，這些標準已經建置到位。為了滿足各項應用的安全性要求，開發者需要建立安全機制與嚴謹的開發流程。
功能性安全納入SoC設計
要減少硬體的隨機錯誤以達成最高水準的安全完整性，最被認可的方法之一是使用冗餘的硬體能力。以CPU來說，則是透過打造一個擁有雙核心鎖同步實作的處理器。這個方法通常會耗用相當的面積與電力，對於像是ASIL B或SIL 2等安全完整性等級較低的應用，恐怕不適用。多個安全機制的組合，例如錯誤更正碼(ECC)、內建自我測試(BIST)與其它安全機制，則可用來達成這些目標。BIST有許多形式，包括記憶體BIST、邏輯BIST以及軟體BIST(軟體測試庫)。
邏輯BIST由於會隨機產生的測試型樣載入掃描鍊測試邏輯，運作時對系統帶來高峰值的電力需求，因此實作起來可能頗為複雜。CPU必須離線才能運行邏輯內建自我測試(LBIST)的測試，並重新啟動。這對於在運行期間進行嚴格的故障檢測將形成挑戰。由於測試完成後處理器重置與重新啟動需要時間，對效能水準也將造成負面影響。就記憶體BIST來說，內建的測試主要是用來檢測記憶體內的固定型故障，而模式測試則套用最高的記憶體速度。記憶體BIST可以與其它的安全機制一起使用，因為它並不會測試CPU的功能邏輯。
當開發者拿軟體測試庫(STL)與記憶體保護一起使用時，STL就成為不二選擇。STL並不需要任何形式的硬體冗餘，因此它會使用較少的矽晶圓面積與電力。由於STL本身是軟體堆疊呼叫的簡單軟體函式庫，不需要重置處理器，因此部署起來沒有那麼複雜。或許更重要的是，STL可以部署在可用的矽晶圓的裝置上，不像線上LBIST必須在設計當時就要規畫在內。STL的電力使用相當於CPU運行應用消耗的電力，而且不像LBIST一樣會有額外的功率影響。
圖1呈現出了以雙核心鎖同步實作，軟體測試庫與邏輯內建自我測試，針對故障涵蓋、反應速度、彈性、能耗效率、面積需求等面向進行比較，以及各自能提供哪些功能性安全優勢。
圖1 比較STLs與其他功能性安全設計
軟體測試庫
STL是軟體的函式庫，可提供偵錯的能力。STL對硬體進行測試，以檢查處理器內的功能邏輯是否出現永久性的故障，例如卡在1或卡在0的故障。STL在汽車應用可以達成「中間值」的故障檢測率百分比，對於單點錯誤度量最高可達ASIL B的階段，對於安全失效分數(Safe Failure Fraction)最高可達SIL 2工業應用。在CPU利用雙核心鎖同步的ASIL D汽車應用中，STL可以在啟動時後、安全性應用運行前，檢查CPU的健康情況，並可以定期運行以檢測故障。STL原始碼通常都會優化，如此一來它只使用最低限度的記憶體足跡。測試一般會以組合語言編寫；與編譯像C語言等高階語言相比，可以提升執行確定性，與故障涵蓋範圍。
Arm的STL產品選項，最近新增了Arm Cortex-R5 STL與Arm Cortex-M33 STL。新近發表的STL可以使用Cortex-R5或Cortex-M33，整合進全新或現有的系統單晶片；而Cortex-R5與Cortex-M33兩者都鎖定汽車與工業應用。
STL實現功能性安全應用
要以既有的晶片來因應新市場或新應用的需求，開發者可能需要從現有的水準增加硬體度量，例如單點錯誤度量(SPFM)，原因是部份的功能性安全要求與STL可以提供協助。當開發者最高以ASIL B或SIL 2應用鎖定結構穩固的晶片，STL是可以考慮的自然選擇。開發者不必對裝置進行額外的硬體變更，就可進行STL的部署。此外，STL可以讓用戶定義執行的個別測試，因此可以限制測試時間與使用的記憶體資源。
實作STL時，可以思考軟體測試庫在CPU的整體安全概念中要擺在哪裡才合適、如何才能進行整合，以及偵錯涵蓋分析如何執行。Arm透過與STL一起提供的文件紀錄，讓獲得授權的客戶都可以做到這點，提升開發者的信心，達成訂定的安全目標。每個STL都有其具體的文件，如用戶指南、IP故障模式效應與偵錯分析(FMEDA)及安全手冊。
每個裝置都有一個功能性安全的概念，它包括在處理器內實作的安全措施與安全機制。當開發者部署STL時，如何為將被測試庫定址的安全概念區域下定義，非常重要。STL不但可以檢測CPU功能邏輯的故障，還能辨識出卡在1與卡在0的故障。Arm的STL FMEDA報告為獲得授權的客戶，提供特定CPU內測試庫可涵蓋區域的詳細資訊。這可做為如何為處理器應用硬體涵蓋的指南，以協助實現安全性概念。
STL可以利用標準的應用程式介面(API)，輕易整合進軟體堆疊中定期運行，同時具備定義測試執行方式的彈性。這種彈性讓獲得授權的客戶可以用單一的呼叫執行完整的STL，或是讓測試劃分成多個分開的區塊。這若不是藉由鎖定特定測試提升其選取的測試深度，就是讓測試的執行得以配合可行的時間段。這樣可以讓STL對主要應用作業負載的影響，降到最低，並協助達成想要的容錯測試間隔(FTTI)。Arm的STL使用指南，闡述STL的操作與整合。
偵錯分析可以在好幾個部份完成：它可以用分析為根據，找出需要偵錯涵蓋的相關區域，也可根據故障的涵蓋測量。處理器檢測出來的故障，可以透過缺陷注入模擬加以測量，其結果可以用在FMEDA，來記錄它們對整體故障檢測的貢獻，並找出殘餘的故障分數。每個STL都將獲得由Arm執行對本身處理器FMEDA分析，而分析的內容已經包含測量到的STL故障模擬涵蓋結果。分析是基於處理器特定的實作組態，在為實際的裝置連線表與組態提供結果時，可作為指南使用。為了協助進行分析，Arm同時也提供缺陷注入說明文字中，在設計的連線表上簡化故障模擬的執行。
產品的分析與其特定的安全目標，可能讓設計的某些區域被認為與安全性無關。這可以用來調整測量到的分析結果，並把它局限在設計的適當區域。如此一來，便有可能為裝置達成更高百分比的SPFM涵蓋。倘若最後的涵蓋目標與執行的分析之間仍然有落差，透過系統層級的檢查與安全應用相關的軟體，可能可以提供額外的涵蓋。
通常開發者都會對產品的安全性進行評估，而這方面雖然應對的不只是STL與處理器，它通常會構成評估關鍵的一環，並可利用Arm的STL提供的資訊，獲得協助。這些STL文件可以用來提供測試庫系統化發展的證據。它同時也可以幫忙展示正確的整合與處理器的分析，以達成產品的安全性目標。
儘管焦點一直都專注在為現有的設計進行STL部署，同樣的原則也適用於從頭開始開發的新裝置。以全新的裝置來說，這會產生包含進一步硬體措施以增強涵蓋的額外機會。
Arm軟體測試庫優點
使用Arm軟體測試庫有三大好處，包含用缺陷注入驗證的程式碼、執行更快的高度優化程式碼，以及優化系統化開發流程等環節。
・用缺陷注入驗證的程式碼
程式碼利用CPU上設計注入進行驗證，這對於已達成的硬體度量，可提供把握度與對狀況的瞭解。內部花費的功夫，包含設定缺陷注入的環境與結果分析，以便讓一切努力產出極大化的故障涵蓋。
・執行更快的高度優化程式碼
程式碼利用來自CPU微架構優化，而且並不只是測試Arm架構相關的形式。開發者可根據CPU的組態選擇測試，如此一來只會進行合適的必要測試，並可協助降低所需要記憶體。如此也能保留更多的記憶體資源供實際應用給客戶使用，並簡化STL的整合。此外，精簡的程式碼會讓故障檢測更快，也會降低運行STL需要的時間。
・系統化開發流程
STL依循ISO 26262標準開發，並對照ASIL D指南執行，且依循IEC 61508標準與對照SIL 3指南，以防範系統化的錯誤。
軟體測試庫使用場景
此軟體測試庫用於實際汽車與工業應用的案例如下：
・倒車攝影機
在圖像與圖像間隙執行STL，可以辨識出CPU內潛在的故障，但可能導致影像訊號饋送的畫面扭曲或凍結，推導出不正確的資訊。在這種情況下，警告訊息會傳送到數位駕駛艙，顯示倒車攝影機未如預期正常運作，告知駕駛停車時不能仰賴倒車攝影機，必須檢視照後鏡。
・工廠安全門
在使用籠中作業機器人的場景，工廠內的安全門特別重要。當安全門打開時，機器人必須永遠處於「安全狀態」；不過，倘若安全門的控制機制內部失靈，而機器人處於作業模式，這對工廠人員會出現潛在的嚴重危害。偵錯系統使用STL定期運行，可以檢查安全門控制機制使用的CPU內部，是否出現任何故障。STL倘若檢測出故障，可以透過警告燈號進行顯示，並向工廠的作業人員示警。
功能性安全要求與日俱增
對於需要促成功能性安全能力的現有SoC設計，軟體測試庫是個相當理想的資源。STL提供關鍵的元件，以便橫跨各種應用促成安全的系統執行，特別是在汽車與工業部門。STL提供彈性且高效率的解決方案，以因應關鍵的功能性安全要求。當我們邁向更加自動化的未來，這種要求只會與日俱增。Arm STL目前在各種CPU上都可使用，包括Cortex-A、Cortex-R與Cortex-M產品。
(本文作者為Arm車用與物聯網事業部產品經理)