1
機能安全とは
1
バックグラウンド
自動車は複雑であるため、業界は安全要件を満たすコンポーネント システムの提供に取り組んでいます。例えば、アクセル・バイ・ワイヤシステムでは、ドライバーがアクセルペダルを踏むと、ペダル上のセンサーがコントローラーに信号を送り、コントローラーはエンジン回転数、車速、ペダル位置などの信号を総合的に分析します。 、などを実行し、制御コマンドをアクセラレータ オントロジーに送信します。スロットルバイワイヤシステムなどのシステムのテストと検証は、自動車業界にとっての課題です。ISO 26262 の目標は、すべての自動車 E/E システムに統一された安全規格を提供することです。
IEC-61508 から生まれた機能安全の国際規格草案 ISO-26262 は、2009 年 6 月にリリースされました。ドラフトの公開以来、ISO-26262 は自動車業界で広く注目を集めています。エンジニアは ISO-26262 を最先端のものとみなしています。テクノロジーの最先端とは、デバイスまたはプロセスが特定の時点で開発された最高の最先端技術です。製品の故障によって生じた損害については、自動車メーカーが通常責任を負います。ISO-26262 は、システムの安全性を測定する方法を提供する自動車業界の共通規格です。
図 1: 安全関連システム
ISO-26262 は、V モデルを使用して機能安全を管理し、システム、ソフトウェア、およびハードウェアのレベルで製品の開発を規制します。ISO-26262 規格は、製品のコンセプト段階から製品寿命段階まで、製品開発プロセス全体にわたる規制と推奨事項を提供します。システムとコンポーネントに許容可能なリスク レベルを割り当てる方法を詳しく説明し、テスト プロセス全体を文書化します。一般に、ISO 26262:
車両の安全ライフサイクル全体 (管理、開発、生産、運用、サービス、廃止) を提供し、これらのライフサイクル段階で必要なアクティビティのカスタマイズをサポートします。
リスククラス (ASIL) を決定するための自動車固有のリスクベースのアプローチを提供します。
ASIL を使用して、許容可能な残留リスクを達成するためにプロジェクトに必要な安全要件を指定します。
適切かつ許容可能なレベルの安全性を確保するための検証および検証措置の要件を提供します。
2
リスクの評価 – ハザード分析とリスク評価 (HARA)
新しく開発されたモデルを明確に定義したら、自動車の機能安全の最初のショットも開始しました。潜在的な危険を特定し、評価するには HARA が必要です。通常、OEM の機能安全エンジニアは、車両レベルの機能に対して HARA 分析を実行して、潜在的な危険シナリオを特定し、潜在的な危険ごとに必要なリスク軽減のレベルを決定します。HARA は、特定の運転シナリオにおける潜在的に危険な状況にさらされる頻度と期間 (露出)、潜在的な危険を軽減するために誤動作を修正するために必要な制御の量 (制御可能性)、および運転シナリオにおける潜在的な結果の重大度を考慮します。誤動作が発生します (重大度)。
HARA は、コンポーネントまたは要素レベルではなく、車両レベルで特性に対して実行されます。潜在的な危険ごとに、いくつかの潜在的な運転シナリオが考慮されます。例: 前方衝突軽減システムでは、意図しないブレーキの潜在的な危険性が、動作速度や運転条件などのさまざまな運転シナリオに従って評価されます。
3
安全レベルの割り当て – 機能安全整合性レベル (ASIL)
HARA プロセス中に、OEM は特定された潜在的なリスクごとに ASIL (自動車安全度レベル) 評価を割り当てます。ASIL は開発プロセス中に決定されます。考えられるリスクに応じて。
図 2: 機能安全レベルの評価
たとえば、特定の車のスピードメーターが故障し、車の発進時から何も情報が表示されない場合、ドライバーは容易に故障を認識し、運転しないことを選択したり、非常に慎重に運転したりする可能性があるため、その場面は QM として分類できます。つまり、シナリオの制御性は非常に高く、重大度は非常に低いです。対照的に、ドライバーが高速でブレーキを踏み損なった場合、重傷を負う可能性が高いため車両を制御できない場合は、ASIL-D に分類できます。
これらの状況に適切に対処するために、ISO 26262 は ASIL 評価を使用してサプライヤーが取るべき開発手順の厳密さを決定し、安全目標の要件を定義します。
1. FIT 率 (時間内故障率): FIT 率は、所定の期間内の車両の許容可能な故障率です。車両は ASIL 評価で指定された FIT レートを満たす必要がありますが、OEM はシステム内の基礎となるコンポーネントの FIT レートを柔軟に選択することもできます。
2. 安全概念（Safety Concept）：安全概念决定如何检测顾故障及如何控制故障，具有更高ASIL评级的系统需要更严格的故障检测和响应能力。
3. 安全要求（Safety Requirements）：安全要求规定了对任何给定故障的适当响应。比如，传感器检测到与内部安全相关的问题，如内存损坏，故障响应系统可能会在规定的时间内终止通过控制器的通信，以便向其他系统指示其故障状态。这是安全要求所描述的典型的安全机制——但故障响应系统并不总是恰当合适的。如：对于智驾功能，车辆可能采用故障操作系统，这要求冗余系统接管必要的时间，以使车辆处于最小的风险状态（比如，安全停车在路边）。对于系统故障，遵循严格的开发过程有助于增加该功能将以一种安全的方式运行的信心。
4
持续的测试和集成
汽车功能安全在整个开发过程中都采用了V模型。V模型要求，对于开发的每一步骤，在测试中都必须对应有一个相应的步骤。供应商定期评估其开发过程，以确保硬件和软件开发都遵循了所需要的步骤。
图3：V字开发模型
OEM，供应商或者独立的第三方公司对所有相关的工作产出物进行功能安全审核和评估，以确保功能安全的实现。功能安全需求一个全面的管理过程，以确保适当的监督和完整的系统集成。
2
什么是功能安全工程师，
功能安全工程师做什么？
关于什么是功能安全工程师？这个问题乍一看很好回答，但如果仔细思考下就会发现，想找到真实统一的答案却并不容易。比如拥有完善开发体系流程的大公司和初创的小公司，他们对功能安全工程师的定义大概率是不同的。思来想去，还是决定以一个新项目为例，来说明下什么是功能安全工程师以及在产品开发过程中功能安全工程师做什么。
1
报价阶段
1. 安全要求的分析与澄清：
功能安全工程师要对客户的安全输入进行分析，以确认公司内部产品的安全要求是否与客户匹配。通常会以会议的形式跟客户讨论和澄清相关安全要求。
2. 执行影响分析：
分析完客户的安全要求之后，一般功能安全工程师还会做影响分析，以确定公司内部的平台项目或者已经量产的其他客户项目是否有可以直接复用的功能，或者修改之后可以复用的功能。如果是全新的产品开发，则客户忽略影响分析。
3. 开发接口协议（DIA）责任划分：
弄清楚产品的开发边界之后，功能安全工程师要跟客户去确定每一方的开发责任范围，并明确开发过程中的产出物的责任方以及双方如何进行产出物的交互，双方对以上内容都打成一致后，DIA也就完成了。最后别忘了双方都需要在DIA上签字。
4. 准备项目功能安全计划和安全档案：
在报价阶段，功能安全工程师要根据项目的时间计划以及客户的安全输入来准备初版的项目功能安全计划（主要内容是计划管理和指导整个项目开发过程中的安全活动的执行，包含日期、关键节点、任务、可交付的成果、职责和资源等）以及安全档案（主要内容是与客户阐明所开发的产品已经按照ISO 26262的要求进行开发并实现了功能安全所准备的证据，包含产品开发各个阶段的关键产出物的记录，产出物的评审记录等）。
5. 准备评审会议：
以上内容都完成之后，功能安全工程师就可以跟审核员（Assessor）约评审会议了。在会上，审核员会根据功能安全工程师准备的证据对该项目的产品开发成熟度进行评估以确认是否满足当前的开发需要，以及是否有安全相关的风险，并输出当前阶段的评估报告。【注】：由于每家公司的开发流程不同，所以对功能安全评估次数要求也不同，但基本都会在项目的关键节点进行功能安全评估。
6. 相关项定义以及危害分析：
如果站在主机厂角度，功能安全工程师要完成所开发产品的相关顶定义（主要内容是在整车层面对相关项进行定义和描述，包括功能，及其与驾驶员、环境和其他相关项之间的依赖性和相互之间的影响），并对其进行危害分析和风险评估（主要是识别并分类由相关项中的功能异常表现引起的危害事件，以及定制防止危害事件发声或者减轻危害程度的安全目标及其安全等级，来避免不合理的风险），以便得出产品的顶层功能安全目标，以及功能安全概念，并打包发给供应商。
2
概念设计阶段
功能安全概念/要求开发：功能安全工程师要完成功能安全概念/要求（FSC/FSRs）的开发。功能安全概念的主要目的如下：
1) 要根据功能安全目标定义产品的功能性或者降级的功能性行为；
2) 要根据功能安全目标定义关于合理地、及时地检测和控制相关故障的约束条件；
3) 要定义产品层面的策略或者是措施，以通过产品本身、司机或者外部的措施来实现故障容错或者减小对相关故障的影响；
4) 把功能安全要求分配给系统架构设计；
5) 确认功能安全概念并且定义号安全确认的准则；
图4：功能安全目标和安全要求层级
3
开发设计阶段
系统开发设计
1. 技术安全概念/要求开发：
功能安全工程师要完成（或者协助系统需求工程师完成）TSC/TSRs的开发。技术安全概念的主要目的如下：
a. 制定系统要素和接口关于功能、相关性、约束和属性方面实施中所需的技术安全要求；
b. 制定系统要素和接口实施安全机制的技术安全要求；
c. 制定在生产、运行、服务和报废中系统及其要素功能安全的相关要求；
d. 验证技术安全要求在系统层级是否符合功能安全要求并与功能安全要求一致；
e. 制定满足安全要求且不与非安全相关要求冲突的系统架构设计和技术安全概念；
f. 分析系统架构设计，防止故障并为生产和服务得出必要的安全相关特殊特性；
g. 按照各自的ASIL等级，验证系统架构设计和技术安全概念是否适用于满足安全要求；
图5：系统层面的产品开发
2. 安全机制的裁剪：
一般在产品设计初期，开发人员已经完成了关键芯片（比如：Micro-controller, SBC, ASIC, Driver ICs, Intelligence Sensor等）的选型。功能安全工程师在此阶段还要主导完成对芯片手册安全机制的裁剪活动，哪些是产品所必须用到的，哪些是可以裁剪的，并给出充分的理由。
3. 系统安全架构开发：
有了系统需求，系统架构，功能安全要求和技术安全要求后，功能安全工程师就可以开始设计（或者协助系统架构工程师设计）系统安全架构了。设计系统安全架构要注意以下几点：
a. 确保系统安全架构和前面阶段的系统架构设计的一致性；
b. 系统安全架构要能实现技术安全要求；（相应的安全要求和安全机制最好能体现在系统安全架构中）
c. 设计的系统安全架构能否被充分验证，预期的软硬件设计是否能满足此系统安全架构，是否方便于系统集成时测试的执行；
d. 设计时要充分考虑安全相关的内部和外部接口；
e. 如果此阶段需要进行ASIL等级的降级分解，要按照ASIL的要求进行分解；
4. 启动系统层面的安全分析：
有了完整的安全要求和系统安全架构之后，功能安全工程师就可以启动系统层面的安全分析（FMEA分析，FTA分析，DFA分析）了。执行安全分析的主要目的在于：提供证据证明系统设计实现了相应ASIL等级的功能安全要求、识别失效原因和故障影响、识别或者确认安全相关系统组件和接口。
a. FMEA分析：FMEA是一种定性的、归纳式的单点故障分析方法，主要是在早期检测和消除产品设计和制造过程中的薄弱点。
b. FTA分析：FTA是一种演绎式故障分析，它使用布尔逻辑来分析系统不期望的状态，以结合一系列较低级的事件。FTA的目标是分析在系统中发生的实际故障的路径，以定位系统故障的原因。
c. DFA分析：DFA的主要目的是通过分析潜在原因或者诱发因素，来确认设计中已经充分实现了要求的独立性（Independence独立性是指在两个或者多个元素之间没有级联故障和共因故障，从而可能导致违背安全目标），或相互之间免于干扰（FFI免于干扰是指在两个或者多个元素之间没有可能导致违反安全要求的级联故障）。如果有必要的话，也可以制定相应安全措施，来减轻可能的相关失效。
图６：不同类型的相关性失效之间的关系
硬件开发设计
1. 硬件安全要求开发：
有了系统层面的安全要求、安全架构和安全分析的输入后，功能安全工程师就可以开始开发（或者协助硬件工程师开发）硬件安全要求了。硬件安全要求主要从分配给硬件的技术安全要求和系统架构设计中导出。
图７：硬件层面的产品开发
2. 硬件安全架构设计：
硬件安全架构设计主要是硬件架构师来负责，功能安全工程师协助支持，并支持做硬件架构的评审。硬件安全架构应尽量满足模块化、适当的粒度水平、简单性等特征。在硬件架构设计过程中，也可以参考ISO 26262第５部分中硬件架构的设计方法（Table1）。
图８－硬件架构设计原则
3. 软硬件接口列表（HSI）：
在硬件设计阶段，功能安全工程师还要协助硬件工程师完成软硬件接口列表的设计。在定义软硬件接口时，要考虑好以下的要素：
a. 存储器（RAM,ROM等）；
b. 总线接口（CAN, LIN等）；
c. 转换器 （A/D，D/A，ＰＷＭ）；
d. Ｉ/O口；
e. 看门狗（内狗，外狗）；
f. 多路转换器；
【注】：每家公司对HSI的责任划分也是不同的，有的可能要求系统工程师或者软件工程师主导HSI的定义。
图９：软硬件接口概览
4. 硬件安全分析：
功能安全工程师要协助硬件工程师进行硬件层面的安全分析，包括FMEA和FMEDA分析。
a. FMEA分析：硬件FMEA分析直接在系统FMEA分析的基础上继续对硬件组件进行分析就可以了。
b. FMEDA分析：FMEDA的计算，需要的输入比较多（如：安全目标，硬件失效率目标值，安全要求，安全架构，BOM表，Mission Profile，安全机制列表，SN29500的基础失效率等），有了这些输入就可以开始FMEDA的计算了，以检查所设计的硬件产品的三个指标值（SPFM，LFM，PMHF）是否满足相应ASIL等级的要求。
图10：硬件失效率度量指标值
软件开发设计
1. 软件安全要求开发：
与硬件开发类似，有了技术安全要求、系统需求和系统架构、硬件设计规范、软硬件接口列表和软件开发环境的输入后，功能安全工程师就可以协助软件需求工程师来开发软件安全要求了。软件安全要求一般来源于分配给软件的技术安全要求或者软件功能和特性的要求（如：能够安全执行相关功能，能够使系统达到或者维持安全状态的相关功能等）。
图11：软件层面的产品开发
2. 软件安全架构：
软件安全架构设计主要是软件架构师来负责，功能安全工程师协助支持，并支持做软件架构的评审活动。软件架构的设计要尽量满足一致性、简单性、可验证性、模块化、可维护性等特征。在软件架构设计中也可以参考ISO 26262第６部分中软件架构设计的方法（Table2, Table3 和Table４）。
图12：软件架构设计原则
3. 软件单元设计和实现：
软件单元设计与实现主要由软件开发人员负责，功能安全工程师能提供的支持相对有限。与软件架构设计类似，软件单元设计也应尽量满足一致性、可维护性、可验证性等特性。在软件单元设计和实现的活动中，也可以参考ISO 26262第６部分中软件单元设计的方法（Table5, Table6）。
图13：软件单元设计和实现的设计原则
4. 软件安全分析：
功能安全工程师要协助软件工程师完成软件的安全分析。与硬件相比，软件安全分析没有特定的方法，有的公司要求做软件FMEA分析；而有的公司觉得用FMEA的思路来做软件安全分析也并不是特别合适，这时候通常采用一种软件关键路径分析的方法来对软件进行安全分析（需要软件的动态架构和静态架构来支持分析）。
4
测试验证阶段
对于各个阶段的测试话题，由于很少有公司要求功能安全工程师去执行测试活动，这里只简单聊一聊各个阶段的测试以及功能安全工程师在测试验证阶段要做些什么。
在各个阶段的测试开始之前，功能安全工程师要主导ISO 26262方法的裁剪活动。功能安全工程师要跟系统、软硬件和相关测试工程师一起，完成对ISO 26262方法的裁剪，被裁剪掉的方法要给出充分合理的理由。（“＋＋“代表高度推荐该方法，一般不能裁剪掉；“＋”代表推荐该方法，如果有合理的理由可以进行裁剪；“ｏ”代表不推荐该方法）
系统测试验证
系统阶段的测试一般包含以下几种：
a) 系统功能测试：验证系统功能是否满足系统要求
b) 系统集成测试：验证组件之间的接口是否满足设计要求
c) DV测试：DV是设计验证，验证产品设计是否满足要求，其中DV测试又包含环境耐久测试、电磁兼容测试、电气特性测试
d) PV测试：PV是产品验证，主要验证产线上生产出来的产品是否符合要求。一般PV之后的产品，就具备了批量生产的资格了。
硬件测试验证
硬件阶段的测试一般比较关注硬件功能测试，也就是基于相关硬件需求的测试，以确认硬件电路设计与硬件需求是一致的。
软件测试验证
硬件阶段的测试一般包含以下几种：
a) 软件功能测试：验证软件实现是否与软件需求一致。
b) 软件单元测试：验证单元设计是否与单元设计需求规范一致。
c) 软件集成测试：验证集成的软件是否满足软件需求，以及软件组件之间的接口是否一致。
上述系统、硬件和软件层面的测试验证分别由系统、硬件和软件测试工程师来负责。功能安全工程师主要关注相关的测试结果是否都通过，测试覆盖度是否满足100％。如果有测试失败项，该测试会不会对产品的功能安全有影响。如果有失效项，复测结果如何。
【注】：通常故障注入测试会涵盖在功能测试里，所以这里没有单独把故障注入测试拎出来。对于有些产品，如果用到的ASIC有安全手册，也需要对裁剪后的安全机制进行故障注入测试，以确保实现的安全机制满足要求。
3
参考文献
[1] ISO 26262:2018, Part1
[2] ISO 26262:2018, Part2
[3] ISO 26262:2018, Part3
[4] ISO 26262:2018, Part4
[5] ISO 26262:2018, Part5
[6] ISO 26262:2018, Part6
[7] ISO 26262:2018, Part9
[8] SEMANTIC SCHOLAR search, A free, AI-powered research tool for scientific literature