安全功能的案例
功能安全管理（四）：功能安全審核及功能安全評估
作者 | HYZY
出品 | 焉知
知圈 | 進“芯片社群”請加微信13636581676，備注芯片
功能安全開發(fā)流程的終點應該是對相關項的安全認可，以確認其達到了生產發(fā)布的安全條件。
一、認可措施的關系
ISO 26262標準中定義的認可措施包括認可評審、功能安全審核和功能安全評估三種類型，ISO 26262標準中允許將認可評審和功能安全審核與功能安全評估合并、聯(lián)合，以支持相關項類似變型的處理。
下圖1展示了三種認可措施及驗證評審之間的關系，可以看出：
認可評審/驗證評審與功能安全審核相對獨立，分別是針對工作成果及功能安全開發(fā)流程；
功能安全評估的范圍最廣，除涵蓋了認可評審、驗證評審和功能安全審核外，還包括安全措施的適宜性和有效性、功能安全實現(xiàn)的論證、安全檔案提供的論證、安全異常原因已按規(guī)定關閉等其它內容。
圖 1 認可措施及驗證評審范圍
二、功能安全審核
1、功能安全審核內涵
功能安全審核可類比ASPICE過程能力審核與TS 16949體系審核，可由公司的體系審核員或第三方機構審核員按照ISO 26262標準中對于過程的要求，審核項目開發(fā)中的安全流程實施情況。
功能安全審核可與ASPICE過程能力評估一同進行（特別是對于支持過程的審核），但ASPICE過程能力評估不能代替功能安全審核。
展開 EPB系統(tǒng)功能安全筆記 (19)： 功能安全的認可措施（Confirmation Measures）理解與辨析
，是否真的能夠實現(xiàn)功能安全。
經緯恒潤預期功能安全（SOTIF）解決方案為自動駕駛安全保駕護航
· 產品上：一方面，經緯恒潤基于駕駛數(shù)據、場景提取算法、聯(lián)合分布統(tǒng)計等數(shù)據驅動方法，結合安全分析構建關鍵臨界風險場景并進行解算，在整車開發(fā)早期提出量化需求指標和測試驗證準則，以便在車輛后期測試階段有較為明確的輸入，避免因定義模糊造成大量重復且無意義的測試驗證工作。另一方面，基于在高級自動駕駛領取多年深耕的經驗，經緯恒潤總結關鍵技術，通過預期功能安全模板、開發(fā)實例及定制Workshop給客戶提供專業(yè)的咨詢服務?？梢愿玫刂ζ髽I(yè)高級別自動駕駛功能“安全”落地。
自動駕駛安全組件是經緯恒潤獨立研發(fā)的一種解決方案，通過使用經緯恒潤的自動駕駛安全組件，企業(yè)可以節(jié)省大量的時間和精力，因為組件已經經過獨立研發(fā)和測試，具備符合功能安全和預期功能安全的能力。企業(yè)無需從零開始開發(fā)安全組件，而是可以直接使用經過驗證的解決方案，從而加快自動駕駛功能的開發(fā)進程。此外，自動駕駛安全組件還具備適配結構化和非結構化場景的能力。這意味著無論是在道路上的結構化環(huán)境還是復雜的非結構化環(huán)境中，組件都能夠提供可靠的安全性支持，確保自動駕駛系統(tǒng)在各種場景下的穩(wěn)定運行。
經緯恒潤功能安全團隊成立于2008年，系國內較早從事功能安全技術研究的團隊。作為功能安全、預期功能安全國家標準委員會成員，參與GB/T 34590第一版、第二版起草及修訂工作。經緯恒潤在汽車電子產品研發(fā)實踐中全面導入功能安全方法論，目前研發(fā)流程、生產流程已通過ISO26262的功能安全開發(fā)過程認證，功能安全開發(fā)過程已達到ASIL-D級別。智能駕駛產品開發(fā)內部按照SOTIF流程開發(fā)，并通過了ISO21448的預期功能安全開發(fā)過程評估。
展開 智能駕駛安全專題 | 功能安全與SOTIF如何融合實施
智駕功能安全平臺
結合客戶工程需求，經緯恒潤會協(xié)助構建適配智能駕駛的可靠、自動化功能安全平臺，以基于模型的安全分析為重要手段驅動智能駕駛產品架構及設計不斷持續(xù)改進。
Medini為經緯恒潤長期合作的專業(yè)功能安全平臺，可以覆蓋ISO-26262、ISO-21448（SOTIF）行業(yè)核心過程，針對自動駕駛SOTIF領域的解決方案，可以覆蓋SOTIF安全分析過程（Part5-Part8），同時參與ISO 21448標準制定，隨時更新保持與標準同步。
依托Medini平臺及豐富的API接口可以構建基于模型開發(fā)的功能安全平臺，系統(tǒng)功能和系統(tǒng)架構基于SysML模型描述，基于這些系統(tǒng)設計，可以直接生成FMEA表格，以及快速的構建故障樹，進行FTA。
在集成化的平臺里，可以管理安全目標、安全需求，并把安全需求分配給對應的系統(tǒng)和組件。進而，安全需求、系統(tǒng)設計、安全分析三者可以平臺中進行連接、交互和管理。
經緯恒潤從2008年開始研究及實施功能安全，并于同年組建了功能安全團隊，從消化ISO-26262標準到參與2017年GB/T 34590功能安全標準的制定；結合自身汽車電子產品研發(fā)實踐，經緯恒潤的功能安全團隊在智駕域、底盤域、動力域、車身域實施國內外100+成功案例，積累了豐富的經驗。迎合市場所需，結合量產產品功能安全落地實施的技術難點，經緯恒潤功能安全團隊以智能駕駛功能安全為主題，陸續(xù)發(fā)布解決方案系列文章。
經緯恒潤
北京市海淀區(qū)知春路7號致真大廈D座6層
郵箱：market_dept@hirain.com
網址：www.hirain.com
展開 
汽車功能安全工程師入行指南
同時，對于主機廠或供應商各自內部的功能安全開發(fā)來說，正如前面提到，功能安全經理通常也就是系統(tǒng)功能安全工程師，他將作為系統(tǒng)層的接口協(xié)調系統(tǒng)與軟硬件團隊的功能安全工作，保證系統(tǒng)層和軟/硬件層功能安全需求的互相傳遞和執(zhí)行。
功能安全開發(fā)過程交流示意圖
5
系統(tǒng)/軟件/硬件功能安全工程師的日常工作
不管對主機廠還是供應商，在一個客戶項目中，很少遇到要從零開始開發(fā)一個全新的產品，一般都是基于現(xiàn)有的產品作為base進行開發(fā)，以滿足新的項目需求，功能安全也是如此。圍繞項目需求與平臺Base不同的部分進行功能安全開發(fā)，識別不同點的活動稱作FSIA（functional safety impact analysis）。
我們前面提到，一個完善的功能安全開發(fā)團隊通常定義三個角色：
系統(tǒng)功能安全工程師
軟件功能安全工程師
硬件功能安全工程師
每個角色負責下圖中的一個V模型開發(fā)活動。
功能安全開發(fā)中的三個V模型 （截圖來自GB/T 34590）
當功能安全是基于base來開發(fā)時，不管是對主機廠或供應商來說，這三個角色并不需要定義三個獨立的工程師來做，這未免太奢侈，實際上也沒必要。通常軟/硬件功能安全工程師由軟/硬件工程師兼任。
對軟件功能安全開發(fā)而言，在軟件開發(fā)流程完善和開發(fā)工具滿足要求的前提下，在軟件設計和驗證過程中，功能安全需求和功能需求無需過分區(qū)別對待，有很多公司的軟件開發(fā)流程本身就能保證符合ISO 26262中ASIL D的要求。
展開 功能更新 | medini analyze — 符合ISO 26262的功能安全平臺工具
? Mobileye——自動駕駛安全策略的分析
Mobileye將medini analyze作為其自動駕駛安全策略開發(fā)的核心工具，將自動駕駛安全目標拆分為功能安全ISO26262安全目標及預期功能安全SOTIF安全目標，系統(tǒng)性解耦了功能安全與預期功能安全之間的關聯(lián)關系，不但實現(xiàn)了產品的功能安全開發(fā)，并且利用medini analyze積極探索了SOTIF的落地過程。
medini analyze在深耕ISO 26262功能安全的同時，也在持續(xù)開發(fā)SOTIF、cybersecurity等功能，不久將會推出支持SOTIF和cybersecurity的全新版本，敬請期待！
經緯恒潤
北京市海淀區(qū)知春路7號致真大廈D座6層
電話：010-64840808
郵箱：market_dept@hirain.com
網址：www.hirain.com
展開 詳解功能安全概念階段
派生的過程中，功能安全需求獨立于系統(tǒng)的技術架構，還要給功能安全需求分配唯一的ID，當前狀態(tài)及對應ASIL等級屬性。下面是一個表格形式的功能安全需求的例子：
1.7 功能安全概念（Functional Safety Concept）
功能安全概念（Functional Safety Concept）是Part 3的最后一個活動。雖然在產品開發(fā)尚未進入系統(tǒng)設計階段（Part 4），但此時需要假設一個系統(tǒng)架構（System Architectural Design），因為功能安全概念需要在整車的架構上實現(xiàn)。功能安全概念階段需要描述必要的功能安全需求，并分配這些安全需求到系統(tǒng)的功能要素（Element）上。在ISO 26262中，功能安全概念階段要求達成以下目標：
指定與相關項安全目標相符功能行為（Functional Behavior）或者降級的功能行為（Degraded Functional Behavior）。系統(tǒng)功能的降級是指如果由于故障不能正確的運行，需要系統(tǒng)工作在一個功能或性能受限的狀態(tài)。一般系統(tǒng)降級要設計降級的策略，如近光燈系統(tǒng)，降級策略要求至少有一個燈可以工作。
根據安全目標，指定針對合適的手段及時檢測和控制相關的故障的限制條件
在相關項的層面上，設計策略或者措施用來達成要求的容錯能力，或者基于相關項本身、駕駛員或者外部措施以減輕相關故障造成的影響
分配功能安全需求到系統(tǒng)架構或者外部措施上
驗證功能安全概念并指定功能安全確認標準，這里的驗證是指對設計過程的驗證（Verification），主要是檢查設計過程的正確性。
2 功能安全概念階段相關技術
為保障功能安全概念階段的活動能夠正確實施，對應每個活動都有一系列的實施方法。本節(jié)對涉及到的一些重要技術手段進行介紹。
展開 詳解功能安全概念階段
派生的過程中，功能安全需求獨立于系統(tǒng)的技術架構，還要給功能安全需求分配唯一的ID，當前狀態(tài)及對應ASIL等級屬性。下面是一個表格形式的功能安全需求的例子：
1.7 功能安全概念（Functional Safety Concept）
功能安全概念（Functional Safety Concept）是Part 3的最后一個活動。雖然在產品開發(fā)尚未進入系統(tǒng)設計階段（Part 4），但此時需要假設一個系統(tǒng)架構（System Architectural Design），因為功能安全概念需要在整車的架構上實現(xiàn)。功能安全概念階段需要描述必要的功能安全需求，并分配這些安全需求到系統(tǒng)的功能要素（Element）上。在ISO 26262中，功能安全概念階段要求達成以下目標：
指定與相關項安全目標相符功能行為（Functional Behavior）或者降級的功能行為（Degraded Functional Behavior）。系統(tǒng)功能的降級是指如果由于故障不能正確的運行，需要系統(tǒng)工作在一個功能或性能受限的狀態(tài)。一般系統(tǒng)降級要設計降級的策略，如近光燈系統(tǒng)，降級策略要求至少有一個燈可以工作。
根據安全目標，指定針對合適的手段及時檢測和控制相關的故障的限制條件
在相關項的層面上，設計策略或者措施用來達成要求的容錯能力，或者基于相關項本身、駕駛員或者外部措施以減輕相關故障造成的影響
分配功能安全需求到系統(tǒng)架構或者外部措施上
驗證功能安全概念并指定功能安全確認標準，這里的驗證是指對設計過程的驗證（Verification），主要是檢查設計過程的正確性。
2 功能安全概念階段相關技術
為保障功能安全概念階段的活動能夠正確實施，對應每個活動都有一系列的實施方法。
展開 智能駕駛車輛功能安全測試解決方案
伴隨著電子電氣系統(tǒng)（E/E系統(tǒng)）復雜程度和控制權的增加，E/E 系統(tǒng)失效引發(fā)的安全風險日趨成為行業(yè)整車廠和供應商重視的問題。
經緯恒潤功能安全團隊致力于為國內外整車廠和零部件供應商提供優(yōu)質的功能安全咨詢服務，涵蓋功能安全流程建設服務、功能安全開發(fā)咨詢服務、功能安全測試咨詢服務和工具平臺的綜合解決方案。其中，功能安全測試咨詢服務旨在滿足客戶在測試環(huán)境搭建、測試開發(fā)和測試實施等環(huán)節(jié)的全方位需求，及早發(fā)現(xiàn)產品潛在安全缺陷，提升整車開發(fā)效率和保障安全品質。
功能安全測試咨詢服務
經緯恒潤功能安全團隊可提供軟件開發(fā)階段、系統(tǒng)開發(fā)階段和整車開發(fā)階段的功能安全測試服務。
展開 EPB功能安全筆記(20) 尾聲：ISO26262的總結和展望
沿著這個思路理解功能按照開發(fā)中的概念，可以得到如下解釋：
Safety verification：驗證功能安全需求有沒有被實現(xiàn)？
Safety validation: 確認功能安全需求提的對不對？即功能安全需求實現(xiàn)了是否確實能保證安全？
根據這樣的解釋可以發(fā)現(xiàn)功能安全驗證（safety verification）和功能安全確認（safety validation）屬于兩個維度。
關于系統(tǒng)/硬件/軟件三個層級的功能安全需求如何進行安全驗證（safety verification）分別記錄在標準中的第4/5/6部分。而安全確認的目的概括為：
提供符合安全目標的證據及功能安全概念適合相關項的功能安全的證據。
提供安全目標在整車層面上是正確的、完整的并得到完全實現(xiàn)的證據。
由此可以看出安全確認中的“確認”在于確認安全目標及安全目標對應的安全標準(safety criteria)是否被滿足。
在《EPB功能安全筆記(18)——功能安全驗證和確認》中對功能安全驗證和確認的關鍵點進行了詳細說明。
1.6.功能安全評估
當一切功能安全開發(fā)活動完成后，在正式量產之前，需要對開發(fā)產物進行審核，審核通過后方能釋放產品?！癐SO 26262，part2，功能安全管理”中詳細介紹了功能安全的審核流程和要求，對應的術語為“認可措施，Confirmation measures”。
展開 自動駕駛預期功能安全要素及準入難點解讀
當前，自動駕駛功能的研發(fā)及量產已經進入白熱化階段，各家主機廠在該領域的投入也傾注了大量的精力和能力，對于上市也是勢在必得。但是對于法律和標準規(guī)定來說，自動駕駛上市必須拿到工信部代表交通部頒發(fā)相關的準入牌照才能受到相關社會的認可。
然而，自動駕駛準入需要充分考慮汽車研發(fā)的各個方面，最重要的是保證駕駛過程中具備足夠的安全性，這就要求在設計之初就需要充分考慮到其中的關鍵一環(huán)：功能安全及預期功能安全。由功能安全涉及的失效和故障（一般指系統(tǒng)級功能和功能故障的E / E故障）將導致錯誤的轉向或制動，這被認為是自動駕駛與安全性相關的最高風險（一般能達到ASIL D）。通過根據ISO PAS 21448 SOTIF方法開發(fā)的功能來定義安全功能和系統(tǒng)，包括第一個初步的體系結構，是朝著按照ISO 26262應用功能安全性邁出的第一步-創(chuàng)建項目定義。該項目定義應包括功能的定義，包括其對環(huán)境和其他項目/車輛的依賴性以及與環(huán)境和其他項目/車輛的相互作用。根據項目定義，可以進行危害分析和風險評估，以找到該功能及其相關系統(tǒng)的根本要求或安全目標。下一步是開發(fā)功能和技術安全概念。
自動駕駛預期功能安全分析能力
自動駕駛系統(tǒng)必須具有一組基本的系統(tǒng)屬性，此處將其指定為功能。下面將討論為了聲明整個系統(tǒng)是安全的應具有的功能。這些功能分為故障安全功能（FS）和故障降級功能（FD）。故障安全功能可提供并實現(xiàn)客戶價值。故障安全功能可以被終止，因為其不可用性的安全相關性足夠低，或被故障降級功能所覆蓋。即使在發(fā)生故障的情況下，也應該以一定的性能水平執(zhí)行故障降級的功能，以在特定時間范圍內提供安全的系統(tǒng)，直到達到最終的最小風險條件（MRC）并允許停用為止。下表中的選擇矩陣展示了導出能力的完整性狀態(tài)，以證明對其設計原理的可追溯性。
展開 
如何理解預期功能安全
當前汽車行業(yè)熱度非常高的三個標準為預期功能安全ISO21448，功能安全ISO26262和網絡安全ISO21434，其中預期功能安全對于系統(tǒng)開發(fā)者來說比較陌生，容易將它與功能安全混為一談，預期功能安全要解決的問題是什么，為什么要在功能安全之外還要考慮預期功能安全，網上已經有很多的資料去講，本篇談談對預期功能安全概念的理解。
背景
Road vehicles - safety of the intended functionality SOTIF（道路車輛 預期功能安全）標準在2019年1月作為公開技術規(guī)范發(fā)布（ISO/PAS 21448），正式版預計將于2022年發(fā)布，目前PAS版本共有29頁+23頁附件，重點關注SAE自動化level 1和level 2駕駛輔助功能。
這個規(guī)范用于降低由于系統(tǒng)的預期功能不足（設計不足或性能局限）或可預見的人員誤操作導致的不可接受風險，這也是預期功能安全概念的定義，適用的電子系統(tǒng)為安全功能受外部環(huán)境影響的功能，來自于傳感器和處理算法，典型的有AEB自動緊急制動系統(tǒng)、車道保持系統(tǒng)等高級駕駛輔助系統(tǒng)。
預期功能安全概念
功能安全在于解決系統(tǒng)內的隨機失效和系統(tǒng)性失效引起的危害，造成安全事故，包括硬件故障、軟件故障，而系統(tǒng)功能正常時出現(xiàn)的危害不在功能安全考慮的范圍內，由于使用傳感器或算法的性能限制，駕駛人員對系統(tǒng)的誤操作，SOTIF規(guī)范的推出旨在解決這一類問題。下圖來自中國汽車標準化技術委員會在2020年發(fā)布的《預期功能安全國際標準ISO21448及中國實踐白皮書》，用于說明功能安全與預期功能安全概念的區(qū)別。
展開 控制閥聯(lián)鎖功能安全要求和設置
編 輯 | 化工活動家
來 源 | 石油化工自動化 長城能源化工
作 者 | 陳志飛
關鍵詞 | 控制閥 聯(lián)鎖 功能安全 要求
共 1456 字 | 建議閱讀時間 7 分鐘
導讀
控制閥是過程控制工業(yè)里最常用的終端控制元件，在安全儀表系統(tǒng)設計中除機泵等動設備外控制閥往往都是作為聯(lián)鎖動作的最終執(zhí)行者，是整個控制回路的核心和失效占比較高的環(huán)節(jié)?？刂崎y除了用作正常調節(jié)外，在安全領域有時需要承擔切斷、放空等功能?？刂崎y承擔安全功能時，具有嚴格的功能要求。今天主要講解的控制閥主要指氣動調節(jié)閥和氣動開關閥。
控制閥聯(lián)鎖安全要求
控制閥除了泄漏等指標外，聯(lián)鎖動作時一般還需具備三個基本要求：故障安全位置；執(zhí)行的可靠性；全行程響應時間。
01
故障安全位置
在工程實踐中，當遇到氣源、電源、信號故障時，不同的場合對閥門的狀態(tài)有不同的要求，故障位置基本類型有故障開（FO）、故障關（FC）和故障保持（FL）三種，主要基于以下三方面：
1）事故條件下，工藝裝置盡量處于安全狀態(tài)。
2）事故狀態(tài)下，減少原料或動力消耗，保證產品質量。
3）考慮介質的特性。如氣化爐燒嘴冷卻水進口切斷閥要求為FO，氣化爐鎖渣閥要求為FC等。
02
可靠性
功能安全是安全功能設計的重要內容，是評價安全功能實現(xiàn)的有效性和可靠性。
展開 電動汽車電機驅動控制器功能安全架構研究
0 引言
伴隨著新能源汽車產業(yè)的發(fā)展，車用電子電氣系統(tǒng)的功能也日趨復雜，如何確保電子電氣系統(tǒng)的功能安全已成為行業(yè)關注的重點和研究的熱點。國際標準化組織（ISO）于2011年正式發(fā)布了ISO26262《道路車輛功能安全》標準，其提供了一套涵蓋系統(tǒng)（包括硬件和軟件）及其生產制造的完整功能安全設計流程與認證制度，以確保汽車行駛的安全性，并已成為汽車行業(yè)目前普遍接受的一套完整的評估并降低風險的方法，獲得了全球主要汽車制造商以及零部件供應商的廣泛認可和采用。盡管該標準針對功能安全性給出了完整的設計流程，對功能安全理念的引入發(fā)揮了至關重要的作用，但由于其并不涉及特定產品的具體設計，同時國內外的相關文獻也鮮有介紹，因此如何正確地實現(xiàn)產品級的功能安全，對設計人員而言仍然具有一定的難度。
作為純電動汽車核心動力部件，電機驅動控制器其功能安全的正確實施顯得尤為重要。本文將從純電動汽車電機驅動控制器的安全目標出發(fā)，詳細闡述針對不同微處理器結構如何實現(xiàn)系統(tǒng)架構設計層面的功能安全。
1 電動汽車電機驅動控制器安全完整性等級分析
1.1 安全目標及安全完整性等級ASIL
產品安全性開發(fā)的最終目的是為了符合安全目標。安全目標是系統(tǒng)最高層面的安全要求，是危害分析和風險評估（HARA）的結果?；贖ARA分析可以得出針對安全目標的汽車安全完整性等級（ASIL）。根據文獻可知，ASIL等級的確定需要針對危害事件綜合考慮嚴重度（S）、暴露概率（E）和可控性（C）的因素，如表1所示，其中D代表最高等級，A代表最低等級，QM表示質量管理。
對于S，E，C指標，文獻中均有明確定義，本文不再贅述。需要說明的是，一個安全目標可能與多種危害相關，而多個安全目標也可能與某種單一的危害有關。
展開 Medini Analyze — 智能駕駛功能安全平臺工具
“安全”被普遍認為是智能駕駛汽車被用戶接受或者得到商業(yè)應用的顯著問題，傳統(tǒng)汽車電子按照功能安全（ISO 26262，避免系統(tǒng)性故障及隨機硬件失效）標準進行安全設計，而智能駕駛汽車安全要求超越了功能安全范疇，尤其是L4及以上智能駕駛車輛中駕駛員將不再接管對車輛的控制權，功能安全要求演化為失效可工作（Fail-operational），產品設計需要兼顧預期功能安全（ISO/PAS 21448，解決產品性能受限及駕乘人員誤操作）、信息安全（ISO/SAE 21434，防御網絡攻擊）等多重安全需求。
如何進行安全分析才能確保安全需求完整而充分？如何驗證系統(tǒng)/ 軟件/ 硬件設計方案的安全性？如何有效融合功能安全、預期功能安全及信息安全要求以創(chuàng)建高安全智能駕駛體系？如何保證開發(fā)過程的追溯性、一致性、完整性？
2020年3月，Medini Analyze推出了針對預期功能安全（SOTIF）、信息安全（Cybersecurity）領域的解決方案，成為一款具備功能安全、預期功能安全（SOTIF）、信息安全（Cybersecurity）三大領域開發(fā)的專業(yè)安全開發(fā)平臺。
展開 