本文將依據ISO 26262針對嵌入式安全系統開發提出的相關建議，介紹高壓(HV)電池電動車的功能安全概念，其中將涵蓋ISO 26262的方法，並考量依此安全概念完成的不同工作產品：
．ISO第3部分—項目定義、風險評估、安全目標定義。
．ISO第3部分—高壓牽引變頻器功能安全概念。
．ISO第4部分—高壓牽引變頻器技術安全架構。
．ISO第4部分—系統故障檢測及響應。
汽車硬體設計需定義安全項目
汽車電子元件日漸增多為汽車產業的共識。汽車開始變得更加精密複雜，並納入各種感測、思考及執行功能以輔助駕駛使用，電子元件的形式已經改變。特別是油電混合車及電動車將大幅成長，而自駕功能也是一樣。
朝向全電池電動車的目標發展需經過多步驟程序，其中包含由基本的電氣化系統轉變為功能更豐富的系統，並包括移轉所有高功率負載。業界在前述轉變過程中的關鍵挑戰之一，就是確保系統承受峰值狀態的強健程度。
市場迅速成長，許多國家以政策獎勵促進成長。而各界擔憂長期永續發展問題，因此強烈要求對排放、材料及製程訂定更嚴格的法規。不過目前電動車的商業模式無法讓OEM長期獲利的問題需待解決，因為基本電動車的平均預估成本仍是一大問題。OEM將尋求各種方式消弭成本落差，如在內部自行處理更多設計工作，或是跳過第一層供應商，直接與IC供應商接洽。這裡所面對的困難，在於以全新方式結合ECU及成套功能，以整合嵌入式電子架構。
因此業界合作夥伴密切合作，加速找出方法因應以上限制。其中一種方式為開發參考設計，結合系統知識及安全專業。這代表參考設計從一開始就要納入關鍵安全系統要素。若要開發硬體參考設計的安全概念，必須能定義安全目標、概念及功能，讓預定項目能夠識別適當的系統實作，進而納入系統設計中。
ISO 26262 V週期程序流程
ISO 26262針對車輛安全系統產品的各個開發階段提供建議及準則，協助達成適當程度的功能安全成熟度。ISO在第2、第8及第9部分說明程序及方法，此外也說明V週期專案開發過程中，有關特定工作產品的技術層面，以及需要執行的各項審查(圖1)。透過第一層供應商或系統供應商，V週期由上而下，從OEM到IC供應商考量功能安全開發事宜。視公司在電動車開發中所負的責任而定，開發階段期間可能適用第3、第4、第5、第6及第7部分的內容，或選擇量身打造。
如果以系統供應商開發變頻器模組作為電動車SEooC為例，就可適用第3部分的用途假設、第4部分的系統、第5部分的硬體、第6部分的軟體，以及第7部分的主要生產。而第10及第11部分為ISO 26262的應用準則。
V週期需參考設計安全概念
如簡介所述，IC供應商預期及開發系統ECU的方式，與傳統第一層相同。如此可加速開發時間，提供標準交付項目，並有利於整條生態鏈。其中的目標並不一定是提供解決方案，達到第一層所能提供的相同成熟度，而是為第一層加速開發工作產品。不過，為了適當定義安全概念，使其盡可能接近客戶安全概念，應針對ISO各部分內容進行開發作業。除了專門用於第一層量產的第7部分以外，IC供應商的重點就是因應V週期的各部分需求(圖2)。
第3部分引導協助建立安全概念，定義目標系統中的項目，其中也包括初步功能安全架構，以及功能安全概念不應違背的可能危害及安全目標。本部分內容可協助客戶輕易瞭解業者提出的參考設計內容是否與其應用相符。
第4部分為技術說明及定義，以所需系統產品的系統架構需求為依據。本部分也定義及分析所有系統故障，以便定義診斷達到適當的安全層級。
第5部分及第6部分是軟硬體架構開發的V週期以及相關原型。本文涵蓋所有安全驗證及認證要點，並協助確認安全概念。
高壓變頻器開發安全目標/架構剖析
ISO 26262說明需要定義的項目，以便系統概念開發著手進行。
項目定義
這將釐清預定項目及系統的範圍與邊界，以及初步項目架構(圖3)及分配的功能假設。
在電動車的高壓變頻器範例中，功能假設可概述如下：變頻器是電動車的主要牽引系統，依據車輛控制單元(VCU)提出的扭矩需求，負責控制電源(HVDC電池)及電動馬達機械軸之間的能量轉換。VCU解讀駕駛指令，作為電動馬達的加速或減速要求。變頻器將此扭矩要求轉譯為進入牽引馬達的相位電流。在較先進的電池電動車中，通常是以沒有離合器的簡易變速箱連接馬達軸及車輪。
這是本文的第一項假設，其中關鍵是要具體明確，因為如果車輛設置離合器，安全概念及安全狀態就會不同。就現有的情況而言，萬一發生危害，駕駛或電動系統光是斷開電動馬達與車輪之間的連接，將不可能停止車輛牽引。
HARA及安全目標
HARA及安全目標的定義，一般是在OEM層級進行的大型分析，並提供給第一層供應商，作為對預定開發系統的需求。此項程序於ISO 26262第3部分定義，目標是分析定義項目故障時對人類的影響。其中提出所有可能駕駛及非駕駛情境有關的所有可能EE系統故障，同時考量各種操作及環境條件(圖4)。
ISO 26262 ASIL表格(圖5)使用一組風險參數定義ASIL等級，涵蓋品質管理(QM)至最嚴重的ASIL D。這樣就能依據此項排名，針對危害指定相關的ASIL等級。一旦識別危害及安全目標，就能針對各項危害定義安全狀態及故障容錯時間間隔。安全目標是最高層級的功能安全需求，並由此衍生所有其他的安全需求。
第二層供應商，很難由OEM取得這些安全目標及危害資訊。不過必須能夠對自身開發的任何系統，提出所考量使用案例的明確證據，包括合理分析的HARA，以便為客戶釐清安全目標。筆者考量合理的情境選擇，主要將重點放在最糟的情況。電動車高壓變頻器的危害及安全目標清單範例如圖6所示。
功能安全概念
有了以上的假設、項目定義，以及危害和安全目標，就可定義第一批高階系統功能。之後將定義首要功能需求(FR)及相關的高階功能安全需求(FSR)用於功能安全架構(圖7)。
高壓變頻器的功能安全架構，則可概述為圖8所示的主要功能及安全功能。
ASIL等級和FTTI與安全目標衍生及直接承襲的安全需求有關。之後ASIL等級會傳播給ISO第4部分所述的較低層級需求與技術系統安全架構。
因此在此功能層級中，項目定義、危害及安全目標假設，以及功能安全架構及需求，都是IC供應商客戶的第一批首要交付項目。這些首要交付項目應協助他們瞭解個案研究及開發的參考設計是否與其想要開發的應用相符。如果並未完全相符，就需分析其中落差並建立行動計畫，以合併客戶及供應商的安全概念。
技術安全概念滿足實作需求
技術安全概念是指依據安全及非安全需求完成的系統架構設計，其中提供系統架構適當性的理由，以滿足第3部分實作的項目定義、安全目標及功能安全需求的安全需求及設計限制。
技術安全概念之後將分隔，並代表達成預定項目及系統功能所需的全部軟硬體子要素功能。必須指定所有安全機制及故障偵測反應，以避免在技術功能故障時違反安全目標(圖9)。
ISO 26262建議對系統設計架構執行安全分析，例如FTA或安全FMEA，以定義這些安全措施。這有助於詳盡識別所有可能以單點故障或潛在故障形式違反安全目標的系統故障。之後會以故障偵測功能處理各項故障，以減輕故障及降低其嚴重性。
使用此項安全分析可建立安全機制清單，衍生成為新的安全需求，然後分配至所有安全相關的系統架構區塊，並於安全分析時加以識別。所有安全機制定義，是以偵測故障的運作、技術及時間條件為依據(圖10)。安全機制技術定義可提供證據及適當反應，足以在FTTI之前達成安全狀態，而且不會違反項目的安全目標。
安全機制可能是硬體或軟體。故障及安全機制清單有助於定義軟硬體架構，以及執行ISO第5及第6部分的FMEDA。
各項故障偵測的反應已被定義。擬定此反應流程的目的是讓系統回到安全狀態。在使用電動車高壓變頻器的情況下，安全狀態的定義相當複雜，原因是有大量能量流入電動馬達。在部分情況下，這可能會造成不穩定狀態而無法確保系統要求的安全狀態。
因此，依據定義安全機制彙總的系統故障清單，應由故障相關的適當安全狀態適當完成。本項系統故障偵測及反應矩陣為恩智浦在系統安全啟用範圍內提供的部分交付項目。
於ISO 26262第4部分開發的不同工作產品，包括技術安全架構及需求、安全分析及系統故障矩陣，可有效協助客戶評估業者提出的參考設計，提供安全完整性證據，證明能夠達成預期的功能安全完整性。這些工作產品就是TSC滿足項目頂級安全需求的論據及理由；此外，還向客戶提供可重複使用及微調的資料，以便將參考設計個人化，配合客戶本身的應用開發工作。
安全狀態定義
安全狀態定義以及在安全狀態中要求過渡的所有故障事件，也是技術安全概念的重要一環。安全狀態機器、安全狀態定義及圖式和過渡需求，均於此技術安全概念中定義。
就變頻器模組而言，其中存在多項複雜的安全狀態。故障時的安全狀態目標，就是停止車輛推進，因此要向電動馬達提供0扭矩。最直接的解決方案，就是斷開所有變頻器的IGBT，讓電流不會再送往電動馬達。不過視駕駛狀況而定，這可能對馬達產生高度的煞車力—直接作用於車輪，尤其是在高速情況下，對駕駛而言可能相當危險。
斷開所有IGBT，並不一定是讓車輛回到安全狀態的解決方案。就以上範例而言，安全狀態可能是讓馬達的三個相位短路，因此需要斷開或關閉所有三個高側或低側IGBT。圖11概述高壓變頻器系統的三種主要安全狀態。也存在其他選項，如降低電力或由PWM確保0扭矩控制。
安全架構客製化符規格要求
在此部分的ISO 26262中，大部分軟硬體工作產品均以類似方式量身打造，符合軟硬體需求規格。本階段僅開發軟硬體架構、示意圖及配置。如前所述，目標並不是比照第一層提供通過認證的變頻器模組，而是建立參考設計供客戶使用，作為包含安全概念的Asample原型。這樣客戶就能在開發及原型階段增加三至六個月的時間。
硬體安全架構
為了產生Asample原型，其中假設之前識別的程序流程及工作產品，具備足夠的成熟及詳細程度，能夠建構適當的Asample硬體安全架構，並向客戶提供證據，證明已考量及滿足其關切的安全問題。
接著將依據以上假設及定義，由系統安全概念衍生硬體安全架構。其中將選擇及附加所有IC元件，以滿足有關診斷以及對安全狀態反應的安全需求。在此恩智浦提出的參考設計，是以該公司IC建構完整架構。為打造安全系統，需將建立硬體架構原型，以便透過注入系統故障的方式驗證安全概念。而在技術安全概念中定義的系統故障及安全機制將接受測試；原型則支援業者在軟體系統啟用套件中，所提供的軟體應用開發及安全機制程式庫。
硬體FMEDA搭配IC系統故障模式
安全分析是ISO 26262的重要環節。FMEDA等安全分析會在不同的系統層級執行，是業者與客戶分享的重要交付項目。由於FMEDA在IC層級的目的是執行詳盡完善的IC故障分析，因此通常過於詳細，並不適合在系統層級使用。
為了簡化詳細FMEDA的結果，需要在系統故障模式中由IC故障模型重組故障。例如閘道驅動器的所有內部邏輯故障，可利用相關的λsafe、λMPF及λRF重組為一個故障模式(FM)內部邏輯。之後這些數據就可在系統層級導入更高層級的FMEDA。
這項概念雖然簡單，但系統安全分析所需的精細度，將成為複雜度的來源。有些故障可輕易重組，但有些故障仍然必須維持低度的詳細程度。例如在電源管理IC中，負責系統點火的輸入僅由系統安全機制保護，而不是IC安全機制。在這種情況下，重要的是確保獨立研究此項針腳及故障，不要與其他區塊重組，以避免單點故障。
軟體安全架構
圖10中開發的故障反應表，是ISO 26262第4部分的一部分，強調系統需要執行的定期檢查及反應清單，其中大部分檢查程式都是在軟體執行。為了簡化使用此項安全概念，恩智浦已開發一項軟體程式庫交付項目，可實作這類檢查程式及程式庫(圖12)。
此程式庫是由多個模組組成(圖13)。
．檢查程式是應用程式診斷功能，會定期呼叫使用，如馬達強度檢查、扭矩監控檢查程式和電流感測器檢查程式。
．安全管理程式負責計數故障，於超過臨界值時呼叫反應管理程式，此外也負責在初始階段期間注入故障，以驗證各項檢查程式是否正常運作。
．安全管理程式偵測到故障後，反應定序器負責讓系統轉移至安全狀態。
．其他必要的模組，如核心間通訊負責管理非安全核心(QM)間執行馬達控制時的資訊分享，安全核心(ASIL D)則執行安全檢查，此外，記憶體管理則負責保證核心間隔離。
本文所述的參考設計遵循ISO 26262開發程序提供技術工作產品，對客戶而言相當寶貴。這項參考設計不僅協助加速開發時間，也提供一定程度的技術安全架構，說明分配至各個故障類型的故障及安全機制。本項提案硬體架構安全完整性層級的成果證據，是本套件的部分內容。因此客戶能夠依據需求判斷、重複使用及修改內容，達成自身的概念假設。
(本文作者皆為恩智浦半導體資深研發工程師)
