在業者競相發展自動駕駛汽車的趨勢下，相關技術的進步可說是日新月異。這個新的市場以極快的速度推動著車用系統單晶片(SoC)開發的演進。做為全自動駕駛車輛的前導技術，先進駕駛輔助系統(ADAS)已經在車載電子設備的數量和複雜度方面造成指數級的增加。據說現代高級車輛竟有多達九十個電子控制單元(ECU)，用來執行各種先進功能，例如主動式定速巡航控制、碰撞迴避系統、自動停車。
ADAS應用需要處理由雷達、光達及攝影機與感測器融合所提供的資料，藉此辨識環境，是以具有極高的運算密集性，並且需要先進程序節點的支援以符合性能/功率要求。這使得汽車產業面臨走向先進技術的轉型，並因此在可靠性上面臨更大的挑戰，例如製程變動、靜電放電、電子遷移。
安全性是車用系統保障可容忍風險程度的基本要求，其定義可參照國際電工委員會(IEC)的IEC 61508以及國際標準化組織(ISO)26262 (IEC)兩項現行安全標準。前者是由IEC所制定的泛用電子設備市場功能安全標準，而後者則是由ISO所制定的汽車功能安全標準。自2007年推行以來，ISO 26262已經迅速成為汽車工程界公認的指導方針。
傳統上是由汽車製造商和系統供應商負責確保符合上述要求，但隨著複雜性的提升，業界現在採取的是一種分而治之的做法，供應鏈上的所有參與者現在都必須在達成功能安全與可靠性標準上出一份力。這些度量現正成為半導體設計流程中不可或缺的環節。
了解功能安全基本原理
以下的重點在於功能安全的基本概念、其生命週期和分析技術。
認識功能安全定義
ISO 26262：道路車輛-功能安全為汽車產業標準，係自範圍較廣的IEC 61508功能安全標準(IEC)衍生而來，主要針對最大總重在3,500公斤以內且配備有一或多個電氣/電子(E/E)子系統的批量生產載客車輛所使用的安全相關系統。
依據ISO 26262，功能安全的定義是「並無因電氣/電子系統的功能異常行為所造成危險而引起的不合理風險」，上述定義可用圖1中的含義鏈來表示。
圖1 ISO 26262含義鏈
故障分類與硬體隨機故障度量
依據ISO 26262，電氣/電子(E/E)組件功能異常可分為系統性故障和隨機故障兩種類型的故障。
意指在開發、製造或維護(製程問題)過程中以決定性方式產生的項目/功能故障。這些通常是出於製程原因的故障，可透過改變設計或製造程序、操作程序、使用說明或其他相關因素來解決。一般要求是追蹤和追溯性。ISO 26262-2：2011所述的功能安全管理活動對於這些方法和期望皆有所說明。
硬體元件在使用壽命期間發生，源自製程固有隨機缺陷或使用條件的隨機故障。硬體隨機故障又可區分為永久故障(例如固定型故障)與暫時故障(例如單一事件擾亂或軟體錯誤)。隨機故障的處理方式是在硬體/軟體系統的設計與驗證過程中導入安全機制，讓架構具備偵測並修正功能異常的能力。
依據ISO 26262：1-2011的定義，安全機制是指由E/E功能或元件，或藉由其他技術所實施，而能用以偵測故障或控制故障，從而達成或維持安全狀態的技術解決方案。舉例而言，安全機制可包括錯誤修正代碼(ECC)、循環備援檢查(CRC)、硬體備援、內建自我測試(BIST)。
解決方案能否有效偵測上述隨機故障，可參考其偵測故障和故障率(FIT)的三種度量以及風險整體可能性，包括單點故障度量(SPFM)、隱蔽故障度量(LFM)以及硬體故障機率度量(PMHF)。這三種度量是ISO 26262中用來判定硬體組件功能安全的測量方式，本文其餘部分主要聚焦於如何進行分析以達成這些度量的目標值。定義硬體架構度量的架構和公式，可參閱ISO 26262-5：2011，附錄D、C.2和C.3以及9.2：
反映項目/功能對於單點故障的強健性，藉由設計或以安全程序涵蓋均包含在內。
反映項目/功能對於隱蔽故障的強健性，藉由設計(根本安全故障)、透過安全程序的故障涵蓋，或駕駛人在違反安全目標前即認知故障存在等情形均包含在內。
說明因隨機硬體故障引起的違反安全目標殘餘風險夠低。
簡單來區分，單點故障可能直接導致違反安全目標，而隱蔽故障則是指可能容許另一故障造成危險的未測得故障。
車輛安全完整性等級(ASIL)
若已知某項功能的異常屬於車輛層級(例如防鎖死剎車系統)，應繼而進行危險與風險分析以判定其傷及人員並造成財物損失的風險。此項分析是根據危險的接觸情況、嚴重性及可控制性和因而產生的風險，來判定車輛安全完整性等級(Automotive Safety Integrity Level, ASIL)，亦即欲達成可容忍風險所需降低的風險程度。圖2說明ASIL基於功能異常及其可能影響而做出判定的範例步驟。ASIL A是最不嚴格的安全降低程度，而ASIL D最為嚴格。
圖2 在ABS範例中，概念階段基於危害分析與風險評估的車輛安全完整性等級。
對於硬體組件，ASIL要求決定達成表1中故障度量所需的數值。在解決系統性故障時，ASIL也將設定製程合規的嚴格程度，例如追溯性、製程品質、使用說明。
表1 每個ASIL級別的失敗度量標準
ISO 26262標準對於功能安全生命週期的所有階段提出明文定義。圖3a描繪概念與開發階段的順序，圖3b和圖3c則舉例說明對應的功能安全活動。概念階段屬於汽車製造商，定義在車輛層級實施功能的系統(採用ISO 26262術語，例如自動緊急剎車系統)。在此層級決定ASIL，再依ASIL設定安全目標和功能安全要求。然後，在系統層級的產品開發階段展開時，針對各項功能安全要求取得安全相關功能軟硬體組件的技術安全要求。
圖3 功能安全開發過程的階段，相應的要求和範例。
基本上，安全目標是於車輛層級開始，並沿著開發鏈規畫調整，直到定義出硬體故障度量，並配置至各種硬體子系統為止。
進行功能安全分析
功能安全分析用於評估產品(例如IP、SoC)所達到的安全程度，其包含量性評估，例如故障模式效應與診斷分析(FMEDA)、時序分析以及質性評估，例如相依故障分析(DFA)。
故障模式效應與診斷分析(FMEDA)
FMEDA是一種用於定義硬體組件故障模式、故障率及診斷能力的結構性方式。基於組件機能，FMEDA等級制度是以零件/子零件/基礎子零件(依據詳細程度)/故障模式(ISO 26262：道路車輛-功能安全)建構。故障模式的分類取決於其是否影響安全目標。而對於影響安全目標的每一種故障模式，必要的基本輸入包括：故障率(FR)(組件發生故障的比率，也就是可靠性)、安全機制(SM)(有無用於偵測故障模式的安全機制)、診斷覆蓋(DC)(安全機制偵測故障的有效程度)。
此外，用於評估功能安全準備度的輸出資料是硬體結構度量SPFM、LFM和PHFM。
上述度量以直觀方式記錄組件的可靠程度(或是多可能發生故障)，以安全機制對於偵測該種故障並將系統修復回安全狀態的可靠程度。
故障率是組件的靠性的計量方式，單位為FIT。組件的FIT率是10億小時操作內的預期故障次數。換言之，若裝置的FIT率等於1，該裝置的平均無故障時間(MTTF)為10億小時(ISO 26262：道路車輛-功能安全)。
依據ISO 26262，估計硬體零件故障率的方式有以下三種，包括參考業界可靠性資料手冊進行預測(如IEC 61709、IEC TR 62380)、經觀察現場事故而決定(例如針對因現場故障而退回的物料進行分析)，以及經實驗測試決定。
表2為經過簡化的FMEDA表，如表中所示，針對每一故障模式，結合FR、SM和DC來計算SPFM、LFM及FIT率。將各排加總，即可得總度量值。藉由分析整體度量和逐排貢獻，FMEDA可讓設計人員得知設計的哪些部分需要提高安全準備度。
表2 簡化的FMEDA表示例，涉及由雙核鎖步(DCLS)覆蓋的安全目標SG1
在表2範例中，針對永久故障已經執行了FMEDA，可依循相同方式對暫時故障進行分析。
時序分析
儘管目前為止所討論的硬體結構度量並不包含時序限制，但完整的安全機制評估顯然必須涉及時序性能。事實上，系統必須能夠在特定的時間內偵測到故障以及到安全狀態的過渡時期，而這段特定時間就稱為容錯時間間隔(FTTI)；否則故障即可能演變成系統層級的危險因素。
圖4中除了說明容錯時間間隔外，也顯示診斷測試間隔(DTI)，這是FTTI中用於偵測故障的部分(ISO 26262：道路車輛-功能安全)。做為參考，中央處理器(CPU)的故障偵測DTI約為10毫秒(ms)，整體系統FTTI約為100毫秒。
圖4 FTTI和DTI
相依故障分析(DFA)
連同硬體隨機故障的分析，另一個待評估的問題就是相依故障分析(DFA)，特別是在系統具有共用資源的情況下。
相依故障分析也稱為已知元件間的可能共同原因和連鎖故障分析，其目的在於釐清可能迴避已知元件間必須的獨立性或無干擾性並違反安全要求或安全目標(ISO 26262：道路車輛-功能安全)的單一原因。
兩種最為直觀的結構特徵相關情境，包括相似與相異的備援元件、以相同軟體或硬體元件實施的不同功能。ISO 26262列出了需要評估的相依故障起始因子，以及為控制或減輕此類故障所必須採取的安全措施。
因共用資源隨機硬體故障而產生的相依故障起始因子，可包括時鐘元件、電源供應元件或共同重設邏輯。與隨機實體性根本原因有關的相依故障起始因子，則包括短路、閂鎖效應及串擾等等。
此外，依據ISO 26262，解決隨機實體根本原因的通常對策，包括：共用資源的專屬獨立監控(例如時鐘監控)、開機時自我測試(例如安全機制啟用檢查)、影響的多樣化(例如主控端與核對器核心之間的時鐘延遲)、利用特殊感應器的間接監控(例如以延遲線做為同因故障感應器)、故障迴避措施(例如實體分離/隔離)。
剖析功能安全要求與設計流程
功能安全是指採取主動措施，藉以在可靠性與主動安全性兩方面達到必須的風險降低結果。
本文僅聚焦於傳統RTL至GDS流程中部署功能安全的方式。此處將討論功能安全分析是如何在硬體設計與驗證流程中達到必須的風險降低結果，也就是必須的硬體安全度量。
FMEDA帶動設計探勘以符合功能安全目標。事實上，藉由研究故障模式及其度量，可以得知應聚焦於何處的設計錯誤以符合限制條件。據此也可規畫故障注入，藉以對安全機制診斷覆蓋進行直接且更精確的評估。若要確保在RTL至GDS流程中採取適當措施以保證獨立性並避免同因故障，則必須執行DFA。
針對特定基礎單元，最佳安全機制的選擇，須審慎分析效用與成本之間的平衡，在功耗、面積、安全度量和時序性能等方面都必須加以評估。
安全機制可為實施於軟體堆疊中的軟體測試，也可為手動置入RTL或經由設計流程自動插入的硬體測試，這裡僅針對後者討論。
設計與實施
在設計流程已自動化的安全機制中，最知名的是內建自我測試(BIST)，用於汽車使用壽命可靠性的系統內/現場測試，以達成所需ASIL。而用於測試隨機邏輯的BIST技術分為線上BIST和線下BIST兩大類型，對於安全度量具有不同影響，且需要不同的時序性能：
此項測試是在功能電路系統處於正常操作模式(任務模式)時執行。其結果顯示SPFM度量，且由於必須在DTI內完成，所以時序要求更為嚴格。
此項測試是在能電路系統並非處於正常模式時執行，例如在發動引擎的電源重設期間。其結果顯示LFM，且時序要求較為寬鬆。
BIST整合過程中要解決的問題包括速度測試能力、功耗、面積、線路簡化及ASIL目標。壓縮技術的整合，提供品質及高效率的資源分享。
在BIST插入期間預測的測試覆蓋雖然有關，但並非就是ISO 26262所要求的DC度量；DC的精確測量可能還需要進行功能安全驗證。參照圖5中的範例AEB系統，BIST可用來避免CPU快取記憶體中的累積故障(複雜微處理器中的常見問題)。
圖5 BIST架構範例
安全機制的另一例子是三重模組備援(TMR)技術。在此案例中，將對於單一事件擾亂有感的邏輯(記憶體元件)三倍設置，並將表決器放在輸出端以釐清正確值。圖6顯示應用於正反器層級的TMR架構，此技術涵蓋經三倍設置連續元件的SPFM和LFM。
圖6 應用於觸發器的TRM架構
只要安全架構是基於硬體備援，便需要執行DFA以解決出於隨機實體根本原因的同因故障：必須將邏輯獨立性轉譯為實體獨立性。
另一種基於備援的安全機制是表2中也有提及的雙核心鎖步(DCLS)。共用資源(例如電源供應、時鐘、重設訊號)和單一實體根本原因兩者都是必須考量的可能同因故障，且需要特殊設計技巧來保持可達成的高DC。
圖7顯示針對例如時間分集和輸出反向等功能層級同因故障的解決對策範例，並說明如何透過布局來避免串擾或保障冗餘區塊之間的確實隔離(例如環阻)。其中實施多種位置和路徑限制以確保實體獨立性，例如同值暫存器間距和電源域繞線的安全標色。
圖7 針對常見原因故障採取對策的DCLS架構
圖8為採用益華電腦(Cadence) Innovus實現系統的設計，顯示使用與不使用功能安全繞線限制的情形：左下區域為區塊的主內容，而右上區域是出於備援目的而插入的複製內容。只要保證屬於主區塊的線路絕對不會進入右上區域，冗餘區塊在結構上就能確實獨立並符合DFA要求。
圖8 布局繞線和路由功能安全約束以保證物理獨立性
進行功能安全驗證
在設置初始FMEDA以評估IP/SoC的安全準備時，可根據ISO 26262：2011-5，附錄D，表D.3至D.9中所定義的可達成值(低、中、高)來估計安全機制的DC。
某些標準安全機制(例如ECC)的DC值，可透過分析方式計算而得。此一運算只涉及邏輯的某些部分，例如就ECC而言，DC在資料單元上堪稱精確，但對於記憶體前方的解碼器則不然。在此情況下，會產生高階ASIL目標(ASIL-D)可能無法接受的變異範圍，須要透過故障注入來對DC值進行更精確的調查。
若為訂製硬體或軟體安全機制(標準測試庫，又稱STL)，可利用故障注入模擬技術對DC值進行更精確的驗證。此項技術亦可用於評估DTI及故障反應時間(參照表2)，或確認故障效應。
功能安全驗證是從標準功能驗證設置開始。用以評估安全機制DC的故障注入需要知道執行觀察點所需的工作負載，也就是說，要觀察故障效應(以及偵測點)之處，就是觀察安全機制反應之處。
參照圖7，觀察點設置在CPU主控端的主輸出，而偵測點則位於比較器的警報器上。DTI就是依據故障出現時間與發現故障時間之間的落差來決定。故障可依其對觀察及診斷點的影響來分類：
觀察點及診斷點皆可見故障的影響。也就是功能輸出確實受到注入故障所影響，但安全機制已經偵測到故障。
觀察點可見故障的影響，但偵測點則否。換言之，故障已經影響功能輸出，安全機制卻尚未偵測到故障。
故障並未影響觀察點。應注意只有在工作負載提供功能驗證的良好覆蓋時，才可將故障歸類為安全。
在設定故障注入活動時，故障的注入位置非常重要。事實上，接受評估的安全機制是針對電路的特定故障模式，故障只可注入屬於相關故障模式的邏輯。
何謂軟體工具信心水準
在解決系統性錯誤的功能安全管理上，用於開發安全攸關應用的工具應接受信心水準的評估。工具信心水準(TCL)是將對於能否偵測到軟體工具中的故障的信心加以量化，與適用於硬體組件的原理相同。工具信心水準等級分為TCL1、TCL2和TCL3，TCL1最高。如此分類的工具不需要額外的資格判定，且可用於任何ASIL的開發應用。
TCL判定是根據ISO 26262-8：2011所總結的標準，其包含評估工具對安全應用的可能影響以及工具錯誤偵測能力。關於軟體工具合規的資訊包含在產品為符合ISO 26262功能安全要求所開發的安全套裝中。
了解功能安全概念 提升對安全要求支援
業界競相實現自動駕駛汽車的趨勢，造成電子設備內容和複雜度對應提升，因而使得保證功能安全的責任擴大到必須由整個供應鏈共同承擔，從汽車製造商/系統提供者到半導體公司和工具提供者均不能自外。本文介紹功能安全的基本概念，並針對設計方法如何經由設計/實施及驗證來掌握及滿足新的安全度量進行探討。這樣的設計方法將可進一步擴展以提升對於安全要求的支援。
(本文作者Alessandra Nardi為益華電腦汽車解決方案軟體工程事業群總監，Antonino Armato為益華電腦汽車解決方案總產品工程師)