基於 ISO26262 的功能安全 Funktionale Sicherheit nach ISO 26262: Ein Praxisleitfaden zur Umsetzung

《基於ISO26262的功能安全》以一個虛擬項目Joy中的操縱桿傳感器開發流程為例，
系統介紹了基於ISO26262功能安全的安全理念、團隊組建、團隊成員角色、具體項目、
操作流程、技術手段、驗證與確認計劃、工作中產生的文檔和工作產品、評審等內容，並在項目結束後進行了回顧。

《基於ISO26262的功能安全》結合具體項目，
手把手引導讀者進行功能安全管理方面的學習，把枯燥單調的功能

Vera Gebhardt

Vera Gebhardt直到1999年底是一名認證的保險專家，在DBV Winterthur保險公司內部服務做多領域保險和電話客戶支持。
與此同時，通過在個人保險部門的認證諮詢，她建立了一個穩定的客戶群。
2000年1月，她轉向IT行業，擔任高級質量經理和測試經理，重點關注財務和保險。
在轉到工程/汽車行業後，她獲得了SPICE審核員、CMMI專業顧問和流程專家的資格，擔任Ruecker AG股份公司的軟件質量經理。
從2004年開始，她成為IAE GmbH公司領導層的質量經理和項目經理，具有人事責任和簽字授權。
隨後又獲得在項目管理和功能安全方面的資格和認證。
今天Vera Gebhardt是獲得認證的SPICE審核員、iSQI項目管理認證專家、功能安全首席顧問和tecmata GmbH公司的主要分公司領導。
她負責人力資源、功能安全、質量管理和項目管理這些領域，以及整個業務網絡的擴展。
Vera Gebhardt是ASQF的安全技術組的創始人和組長，她也是很多專業報告的作者。

vera.gebhardt@tecmata.de · http://www.tecmata.de

Gerhard M. Rieger

Gerhard M. Rieger在奧格斯堡學習電氣工程/通信工程。
完成學業後，他在TÜV Bayern eV 的電子設備»自動化和安全技術«部門IQSE擔任原型驗證的審核員。
1992年他額外還負責TÜV Bayern Sachsen eV的測試機構，
到1998年前在工作領域»電信設備和遠程控制設備«的管理層工作。
直到2001年，Rieger先生在在TÜV產品服務有限公司的安全相關電子系統領域擔任市場部門經理，並於2001年轉到RWTÜV下的TÜV Informationstechnik GmbH公司擔任部門主管負責»安全認證服務«。
他的職責包括功能安全工作領域的建立，人事領導和測試機構的經濟。
他繼續在母公司RWTÜV完善功能安全領域的建設，2004年轉到RWTÜV公司
（自2006年起，改名為TÜV NORD SysTec GmbH＆Co. KG）的安全相關服務部門。
在那裡直到2010年他領導奧格斯堡場所的運營並負責工作領域“功能安全”。
自2011年以來，他繼續負責擴大奧格斯堡場所的建設以及TÜV NORD Systems GmbH＆Co。
KG的功能安全工作領域的擴展。

Rieger先生是眾多專業文章的作者，並在奧格斯堡大學的精英學位計算機科學講解»功能性

安全性“課程。

grieger@tuev-nord.de · http://www.tuev-nord.de

Jürgen Motto

教授JürgenMottok博士在雷根斯堡應用科學大學教授計算機科學。
他的教學領域是軟件工程，編程語言、操作系統和功能安全。
他領導人身安全和信息安全系統實驗室，是巴伐利亞信息技術(IT)d的安全與安全集群顧問委員會成員，
汽車安全軟件系統論壇顧問委員會成員，ASQF安全諮詢委員會委員，計算機協會東歐巴伐利亞州的理事機構成員。
巴伐利亞軟件工程教學工作組的組織者。
是具有授予博士學位合作的研究項目DynaS3和VitaS3，S3OP和S3EMO的項目經理，
研究項目的合作夥伴是AVL Software and Functions GmbH公司，Continental Automotive GmbH（大陸汽車公司），
iNTENCE Automotive GmbH公司，Manu AG公司和exida GmbH公司。
教授Jürgen Mottok博士在眾多科學技術會議的議程委員會中擔任委員。
他是巴伐利亞州的科學、研究和藝術部的傑出教學獎獲得者。

juergen.mottok@hs-regensburg.de · http://www.las3.de

Christian Gießelbach

工程數學碩士Christian Gießelbach科隆大學學習數學和計算機科學，畢業後*初是IVU Traffic科技股份公司的軟件開發人員。
2007年，他轉到了tecmata GmbH公司並作為軟件架構的專家以及測試設計師負責安全相關嵌入式開發領域的不同工業項目。
Christian Gießelbach是功能安全與安全的首席顧問，負責安全軟件系統的概念設計。
他是ASQF安全專家組成員和tecmata GmbH公司的功能安全專家組顧問。

c.giesselbach@tecmata.de · http://www.tecmata.de

【譯者簡介】

程威為

上海同濟大學汽車系，德國卡爾斯魯厄大學計算機系碩士。
德國頂級汽車零部件企業項目安全經理，安全專家，負責多國客戶項目及平台項目的功能安全。
在功能安全領域深耕十餘年，擁有完整的功能安全開發技術和項目管理經驗，
涵蓋汽車動力總成、自動駕駛及工業自動化等領域。

張律

畢業於德國斯圖加特大學車輛工程碩士專業，後就職於全球頂級汽車零部件供應商，
在其德國總部從事電子控制器在平台和客戶項目中的研發工作。
始終致力於功能安全概念的研究和軟件層面的實現，針對於不同的客戶產品特點，
就其特有的架構給出可行的功能安全解決方案，具有豐富的ISO26262在產品研發中的實踐經驗。

張亮

畢業於哈爾濱工業大學汽車工程學院內燃機系，德國埃森林根應用科技大學汽車機電系，
先後就職於中國某頂級大型汽車公司，德國某頂級汽車零部件供應商。
多年來從一直從事汽車動力系統的研發工作，具有豐富的理論和實踐經驗。

楊青

德國杜伊斯堡-埃森大學機械電子專業碩士，中德教育與科技合作促進中心成員，
全德華人機電工程學會成員，德國頂級汽車零部件企業功能安全應用工程師。
他多年來一直致力於動力總成方面電子控制單元的功能安全應用客戶項目，具有豐富的實踐經驗。

劉晨光

曾任德國聯邦科學研究員，獲得卡爾斯魯厄大學應用計算機學博士。後加入德國採埃孚集團研發中心，計算工程師，
從事變速器創新軟件設計，兼任技術和商務談判翻譯。
兼任北京交通大學外籍客座教授，國際汽車工程師學會SAE會員。

羅本進

德國斯圖加特大學工學博士，中德教育與科技合作促進中心主席，江蘇省產業技術研究院首席科學家，
長期任職德國汽車零部件企業前瞻開發部高級系統工程師。
他多年來一直致力於混合動力系統、電驅動系統、全自動變速器及工業4.0的研究，具有豐富的實踐經驗。

譯者的話
前言
作者團隊
譯者簡介

第１章 引言 １
１.１ 為何*擇汽車專用安全標準 ＩＳＯ ２６２６２：２０１１ １
１.１.１ ＩＳＯ ２６２６２：２０１１，２０１１.１１.１５版本 ２
１.１.２ 汽車技術委員會 ２
１.１.３ ****水平 ２
１.１.４ ＩＳＯ ２６２６２：２０１１——可實際應用的標準 ３
１.１.５ 舉*責任反轉 ４
１.２ 符合 ＡＳＩＬ的產品等級 ４
１.２.１ 明確的責任分配 ４
１.２.２ 流程模型和流程成熟度 ５

第２章 在這本書將會學到什麼 ７
２.１ 一般提示 ７
２.２ 項目 “Ｊｏｙ”及其產品 “操縱桿傳感器”的前提和*設 ９
２.３ 本書的閱讀指引 １０
２.４ 項目 “Ｊｏｙ”描述文檔 １１
２.４.１ 創新* １２
２.４.２ 產品信息 １２
２.５ 參與的公司 １４
２.６ Ｊｏｙ開發團隊 １６
２.７ 法律基礎和責任 １８

第３章 階段模型 ２０
３.１ 組織結構要求 ２０
３.２ 流程模型和功能安全管理 ２１
３.３ ＩＳＯ ２６２６２：２０１１階段模型 ２１
３.４ 創建安全文化 ２３
３.４.１ 項目舉例 ２４
３.４.２ 安全文化問卷調查 ２５
３.４.３ ＷｏｒｌｄＣａｆｅ和開放空間方法 ２７
３.５ 技術安全管理 ２７
３.６ Ｊｏｙ項目的功能安全管理 ２８
３.７ ｓａｆｅｈｉｃｌｅ*司*全政策和安全計劃 ２８
３.８ 安全生命週期活動 ３０
３.８.１ 項目實踐舉例 ３０
３.８.２ 管理活動 ３１
３.８.３ *實措施 ３３
３.９ 所需的流程支持 ３３

第４章 安全生命週期中的特定角色 ３５
４.１ 高效的團體 ３５
４.１.１ *源規劃項目舉例 ３５
４.１.２ 有條理地確定培訓需求 ３７
４.２ *質 ３８
４.３ Ｊｏｙ項目安全經理 ４０
４.４ 功能安全經理職位描述 ４０
４.４.１ 項目舉例 ４２
４.４.２ Ｊｏｙ項目的安全協調員 ４２
４.５ 安全協調員職位描述 ４２
４.６ 安全生命週期的**角色 ４３
４.６.１ 銷售代表和產品專家 ４３
４.６.２ 招標部門的職員 ４４
４.６.３ 訂*處理負責人 ４４
４.６.４ ＡＳＩＬ產品專家 （產品管理部門員工） ４４
４.６.５ 項目經理 ４４
４.６.６ 研發人員和測試確認人員 ４５
４.６.７ 裝配人員 ４５
４.６.８ 檢查和調試人員 ４５
４.６.９ 處理訂*的服務人員／文員 ４６
４.６.１０ 車間維修技師 ４６
４.６.１１ 獨立的第三方 （評估） ４６
４.７ 角色多樣* ４６

第５章 配置和更改管理 ４７
５.１ 配置管理 ４７
５.１.１ 配置管理的任務 ４７
５.１.２ 活動項目舉例 ４７
５.１.３ 里程碑 -基線 -接口 -權限 ４８
５.１.４ 工具使用和交付 ＫＭ項目 ４８
５.２ 配置經理 ４９
５.３ 根據 ＩＳＯ ２６２６２：２０１１進行更改管理 ５１
５.４ ｓａｆｅｈｉｃｌｅ公司更改管理計劃 ５２
５.５ 流程調整方面 ５３
５.６ 審批過程 ５４
５.７ 接口修改和批准 ５５
５.８ 回顧 ５７
５.８.１ 回顧方法 ５７
５.８.２ 實施回顧 ５７

第６章 安全生命週期和開發接口協議的初始化 ５９
６.１ 初始化 ５９
６.２ 供應商*擇 ５９
６.３ *質查詢和*擇報告 ６０
６.４ 開發接口協議 ６１
６.５ ＤＩＡ——程序 Ｊｏｙ項目舉例 ６３
６.６ 安全生命週期初始化 ６３
６.７ 招標和轉包 ６４

第７章 汽車安全完整*等級的概念 ６６
７.１ ＡＳＩＬ的歷史和背景 ６６
７.１.１ 降低風險 ６７
７.１.２ 在 Ｊｏｙ項目裡從安全目標到安全概念 ６８
７.２ ＡＳＩＬ在標準書中表格的意義 ６８
７.３ 依賴於 ＡＳＩＬ的要求和推薦 ７０
７.４ ＡＳＩＬ分解的基礎 ７０
７.４.１ 操縱桿傳感器的分解方法 ７１
７.４.２ 安全要求的分解 ７１
７.４.３ 分解的局限和限制 ７３
７.４.４ 可用*的方面 ７４
７.４.５ 安全狀態的簡例 ７４
７.５ 使用 ＩＳＯ ２６２６２的優點和啟示 ７５
７.５.１ 更優的流程質量 ７５
７.５.２ 更優的商務關係 ７５
７.５.３ 更優的產品質量 ７６
７.５.４ 經濟上的益處 ７６
７.６ 定量和定*的方法 ７６
７.６.１ 定*的方法 ７７
７.６.２ 定量的方法 ７７
７.７ 安全*分析 ７７
７.７.１ 在操縱桿項目中的定*和定量方法 ７９
７.７.２ 認識論 ７９

第８章 危害分析與風險評估 ８０
８.１ 危險和分類識別 ８０
８.２ 執行分析——項目實例 ８０
８.３ 在產品生命週期階段的程序 ８２
８.４ 與**系統的相互作用 ８２
８.５ 風險分析 ８３
８.６ 風險分析的方法 ８４
８.７ ＡＳＩＬ的確認 ８６
８.８ 來自於 Ｊｏｙ項目的具體案例 ８８
８.８.１ 驅動的案例 ９１
８.８.２ 制動力的案例 ９４
８.８.３ 轉向的案例 ９７
８.９ 危害分析與風險評估的總結 ９９

第９章 功能和技術安全要求規範 １００
９.１ 功能安全要求規範 １００
９.２ 操縱桿 Ｊｏｙ和操縱桿傳感器規範程序 １０１
９.２.１ 功能安全要求規範 １０１
９.２.２ 子系統的技術安全要求 １０１
９.２.３ 實施技術要求以降低風險 １０２
９.２.４ 項目示例 Ｊｏｙ １０４
９.３ 系統確認 １０４
９.４ 可靠*、功能安全*和可** １０５
９.５ 安全*審核 １０６
９.５.１ 獨立* １０７
９.５.２ 規劃安全審核 １０８
９.５.３ Ｊｏｙ項目中的安全審核議程 １０８
９.５.４ 推導出措施 １１３

第１０章 驗*和確認計劃 １１４
１０.１ 關於 Ｖ Ｖ的一般信息 １１４
１０.２ 驗*工作的作用領域 １１７
１０.２.１ 驗*規範 １１７
１０.２.２ 測試報告 １１９
１０.３ 確認工作的作用領域 １１９
１０.３.１ 確認計劃的範圍 １２０
１０.３.２ 聯合確認計劃和計劃內容 １２１
１０.４ 硬件 -軟件集成 １２４
１０.５ 系統集成測試 １２４
１０.６ 集成測試方法 １２６
１０.６.１ 故障注入測試 １２７
１０.６.２ 背靠背測試 １２７
１０.６.３ 接口檢查 １２８
１０.６.４ 基於經驗的測試 １２８
１０.７ 車輛級別的集成和測試 １２９
１０.８ 硬件的確認計劃 １３０
１０.８.１ 硬件集成和硬件集成測試 １３０
１０.８.２ Ｊｏｙ項目中的方法 １３１
１０.８.３ 評估隨機硬件故障造成的安全目標違規 １３３
１０.８.４ 確認隨機硬件錯誤的度量標準 １３３
１０.８.５ 評估硬件架構的指標 １３３
１０.８.６ 評估硬件設計的輸入和輸出 １３４
１０.８.７ 項目示例硬件設計評審 １３４
１０.９ 軟件模塊測試 １３５
１０.９.１ 導出和執行軟件模塊故障的方法 １３５
１０.９.２ 軟件集成和測試 １３７
１０.９.３ 軟件集成測試 １３８
１０.１０ 項目示例軟件測試 １３８
１０.１１ 驗*軟*安全要求 １３９
１０.１２ 機電一體化系統的分析和驗* １４０

第１１章 系統級的產品開發 １４２
１１.１ 在概念階段的 ２０００個要求 １４２
１１.２ 概述 １４２
１１.３ 初始化系統級的產品研發階段 １４４
１１.４ 規範技術安全要求 １４５
１１.４.１ 系統機制的規範 １４６
１１.４.２ 硬件故障的分類和指標 １４７
１１.４.３ 隨機硬件故障的過程模型 １４８
１１.５ Ｊｏｙ項目的技術安全要求 １４９
１１.５.１ 通往技術安全要求的途徑 １５０
１１.５.２ 項目示例 １５１
１１.５.３ 在內部處理時的錯誤 １５２
１１.５.４ 系統設計中的冗餘 １５３
１１.５.５ 對於傳輸傳感器信號的要求 １５４
１１.６ 系統設計 １５４
１１.６.１ 避免系統*的故障 １５５
１１.６.２ 隨機故障的識別措施 １５６
１１.６.３ 項目示例 １５６
１１.６.４ 故障樹分析 （ＦＴＡ） １５７
１１.６.５ **的指標——用於硬件錯誤的 “ＣｕｔＳｅｔ方法” １５８
１１.６.６ 度量的邊界值 １５９
１１.７ 規範軟硬件之間的接口 １６０
１１.８ 驗*系統設計 １６１
１１.９ 相關項整合和測試 １６１
１１.１０ 總結 １６２

第１２章 文檔和工作產品 １６３
１２.１ 文檔要求 １６３
１２.２ “誰寫下來誰就有理”或 “凡事不宜過分”——項目 示例 １６６
１２.３ 跨越階段的文檔 １６７
１２.４ ＩＳＯ ２６２６２：２０１１的關鍵*文件——第２部分 “功能 安全管理” １６８
１２.４.１ 總體安全管理計劃 １６８
１２.４.２ *格*明 １６９
１２.４.３ **的書面質量管理體系 １６９
１２.４.４ 安全計劃 １６９
１２.５ 安全** １７１
１２.５.１ 安全**——安全檔案 （功能安全工作產品） １７１
１２.５.２ 參考和相關文件 １７１
１２.５.３ 引用與核心安全相關的文件 １７１
１２.５.４ 定義、術語、縮寫 １７１
１２.５.５ 安全計劃 １７２
１２.５.６ 相關項定義 １７２
１２.５.７ 遵規矩陣 １７２
１２.５.８ 會議紀要 １７２
１２.５.９ 計劃過程中的工作產品 １７２
１２.５.１０ 出自安全生命週期初始化階段的工作產品 １７２
１２.５.１１ 來自於支持過程的工作產品 １７３
１２.５.１２ 狀態報告 １７３
１２.５.１３ 生產安全控制計劃 １７３
１２.５.１４ 危害分析與風險評估摘錄 １７３
１２.５.１５ 功能安全概念 １７４
１２.５.１６ 安全要求確定 １７４
１２.５.１７ 來自驗*和確認的工作產品 １７４
１２.５.１８ 安全分析和安全報告 １７４ 
１２.５.１９ 安全*參數 １７４
１２.５.２０ 安全**中的安全事項清* １７５
１２.５.２１ 評估計劃和過程的符合* １７５
１２.５.２２ 總結 １７６
１２.６ ＩＳＯ ２６２６２：２０１１的關鍵文件——第３部分 “概念 階段” １７６
１２.６.１ 相關項定義 １７６
１２.６.２ 工作產品影響*分析 １７７
１２.６.３ 危害與風險分析 １７７
１２.６.４ 功能安全概念 １７８

第１３章 相關文檔和工作產品 １８０
１３.１ 概述 １８０
１３.２ ＩＳＯ ２６２６２：２０１１的關鍵文件——第４部分 “系統級 產品開發” １８１
１３.２.１ 確認計劃和確認報告 １８２
１３.２.２ 系統級安全評估 １８３
１３.２.３ 生產釋放的文檔 １８３
１３.２.４ 技術安全要求 １８３
１３.２.５ 技術安全概念 １８３
１３.３ ＩＳＯ ２６２６２：２０１１的主要文件——第５部分 “硬件級 產品開發” １８４
１３.３.１ 硬件級別的安全計劃 １８５
１３.３.２ 硬件級別的規格 １８５
１３.３.３ 硬件設計文檔 １８５
１３.３.４ 安全*分析 １８６
１３.３.５ 硬件架構指標的文檔 １８７
１３.３.６ 硬件集成和硬件測試 １８７
１３.４ ＩＳＯ ２６２６２：２０１１的主要文件——第６部分 “軟件 實施” １８８
１３.４.１ 計劃和啟動 １８９
１３.４.２ 軟件安全要求和驗*計劃 １８９
１３.４.３ 軟件設計 １８９
１３.４.４ 軟件模塊設計和軟件實現 １９０
１３.４.５ 軟件模塊測試 １９０
１３.４.６ 軟件集成和測試 １９１
１３.４.７ 配置數據和標定數據 １９２
１３.５ ＩＳＯ ２６２６２：２０１１的主要文件——第７部分 “生產和 操作” １９３
１３.５.１ 生產計劃和生產控制計劃 １９４
１３.５.２ 運行、維護和報廢 １９４
１３.６ ＩＳＯ ２６２６２：２０１１的關鍵文件——第８部分 “支持 流程” １９５
１３.７ ＩＳＯ ２６２６２：２０１１的關鍵文件——第９部分 “ＡＳＩＬ和安全導向*分析” １９５
１３.７.１ ＡＳＩＬ分解 １９５
１３.７.２ 要素共存的標準 １９６
１３.７.３ 依賴*錯誤和失敗的分析 １９６
１３.７.４ 安全分析 １９６
１３.８ 總結 １９６

第１４章 評審 １９８
１４.１ 通常意義 １９８
１４.１.１ 評審程序 １９９
１４.１.２ 評審技術 １９９
１４.１.３ ＡＳＩＬ和評審技術之間的依賴* ２０１
１４.２ 閱讀技術 ２０２
１４.２.１ 簡介 ２０２
１４.２.２ 即席閱讀 ２０４
１４.２.３ 基於清*的閱讀技術 ２０５
１４.２.４ 逐步抽象閱讀 ２０６
１４.２.５ 基於錯誤類別的閱讀 ２０７
１４.２.６ 基於視角的閱讀 ２０７
１４.２.７ 總結 ２０８

第１５章 對軟件工具的信任* ２１０
１５.１ 軟件工具的信任*和*格 ２１０
１５.２ 為什麼謹慎*擇工具很重要 ２１１
１５.３ 工具置信度 ２１４
１５.３.１ 工具鑑定計劃 ２１６
１５.３.２ 工具文檔 ２１６
１５.３.３ 工具錯誤報告 ２１７
１５.３.４ 評估工具開發過程 ２１７
１５.３.５ 檢查工具的*能 ２１７
１５.３.６ Ｊｏｙ項目中的*格報告 ２１８
１５.４ 題外話：操作可靠*的重複使* ２１９
１５.５ 總結 ２２１

第１６章 回顧 ２２２
１６.１ 安全相關項目的規劃 ２２２
１６.２ ｓａｆｅｈｉｃｌｅ公司——來自規劃活動的流程更改 ２２３
１６.３ 總結 ２２７

第１７章 展望 ２２８

附錄 ２２９
附錄Ａ ２２９
Ａ.１ 計劃的工作輔*清* ２２９
Ａ.２ 安全文化的例子 ２３５
Ａ.３ 基本測試過程 ２３６
Ａ.４ 錯誤的心理原因 ２３７
Ａ.４.１ 思維陷阱作為錯誤原因 ２３８
Ａ.４.２ 總結 ２３９

附錄Ｂ 詞彙表 ２３９
附錄Ｃ 縮寫索引 ２４７
附錄Ｄ 規範和標準 ２５０
附錄Ｅ 參考文獻 ２５１