如何管理项目中的功能安全（ISO26262）
原文：Managing Functional Safety (ISO26262) in Projects作者：Agish George, Jody Nelson译文审核：阚博然 吴姿 卢雪梨1概述
功能安全标准ISO 26262于 2011 年首次发布，现已被大多数 OEM 和Tier1供应商广泛采用。产品的设计和功能安全标准的一致性与产品的开发周期密切相关，因此需要谨慎管理。功能安全的考量需要从产品概念阶段开始，贯穿整个工程研发和生产阶段，直至最终退役。用户在项目中应用该标准可能会遇到重大挑战，尤其是对于刚接触该标准的管理人员而言。本白皮书针对在项目管理中ISO26262 所涉及的关键任务以及应对这些任务的方法提供了一些指南。本文件有望帮助组织内的管理人员更好的管理符合ISO26262 标准的项目。同时，本文也提出了一个度量指标，可用于估算项目中实施 ISO26262的所需资源。
2简介
ISO 26262 标准提供了一个框架用于规划、设计、实施、集成、验证和确认汽车电气电子 (E/E) 系统，已使这些系统免受系统性失效和随机硬件故障的危害。自 2011 年以发布以来，ISO 26262 标准已被汽车行业广泛采用以实现功能安全。该标准针对产品安全生命周期中的每个子阶段—管理、概念阶段、产品开发、生产和运营都制定了相关要求。
该标准由以下几个部分组成：
第1部分实际上是标准中的专业术语表。第2部分侧重于描述在产品生命周期及后续对组织范围内的安全文化和安全管理的需求。第3部分或概念阶段说明了如何定义项目及其危害和 ASIL 等级。这也是根据初步架构假设定义项目的功能安全概念。安全经理的主要职责之一是能够定义适合该项目的安全生命周期，该项工作的开展通常基于影响分析。
第4、第5和第6部分为系统、硬件和软件级别的产品开发核心要素。安全经理负责通过相应的计划启动每个阶段。计划包含了确定每项功能安全活动的工作成果、时间进度安排和相关责任人。任何对业务活动、流程或方法的裁剪（如果适用）均在此处标识。
第7部分定义了生产和服务的要求，由专门的安全经理负责监控生产过程和现场的产品。
第8部分定义了 ISO26262 的一些支持流程。其中一些过程，比如分布式开发的接口、软件工具的资质、软件组件的资质以及通过使用验证的论据，这些过程可以在很大程度上围绕安全经理进行展开。第9部分说明安全分析要求，而第10部分主要提供相关信息。
3主旨本文的主旨在于：
1. 为项目经理、安全经理和管理人员提供参考，文章重点介绍他们在开展需要符合ISO 26262的项目工作时，需要准备应对哪些挑战；2. 为新项目报价时提供 ISO26262 工作量估算指南和方法。
4功能安全管理中的角色与职责
ISO26262 标准中针对项目定义了2个功能安全管理者的角色：安全经理和项目经理。
ISO26262 标准的第 1 部分将术语“安全经理”定义为 “在项目研发期间由负责功能安全管理的人员担任的角色。”
安全经理的职责是计划和协调项目的各项功能安全活动。通常，安全经理专门负责项目的功能安全活动。安全经理需要确保与项目相关的功能安全活动得到规划，并按照安全计划进行。安全经理获得正式授权是其开展工作的关键所在，这样可以确保项目中功能安全工作成果及时的输出，并且确保对需要实现功能安全但又缺乏必要可信度的产品不会投入生产。安全经理需要同时掌握汽车技术和 ISO26262 流程以及成果输出物方面的知识。安全经理不必是组织内部常规意义上的经理，也可以由团队内部高级技术成员担任。
项目经理负责确保为项目指派一名安全经理。严格意义上讲，安全经理是一个角色，可以由受过专业培训的项目经理担任，或者将责任分配给多个人员，例如，团队中的项目经理、高级系统工程师、软件架构师和高级硬件工程师。这种方式可以帮助减轻资源压力，特别是对于首次应用ISO26262的组织。由于有正式授权的要求，项目经理往往会成为安全经理角色的不二人选。因此，在许多组织中，项目经理是事实上的安全经理。项目经理还负责：
[*]确保为项目能够被分配到足够的资源以在项目中实施所需的功能安全，并且
[*]发布产品以证明其已达到所需的功能安全目标或需求。
5实践中的一些挑战
本章节主要讨论在实际项目中实施ISO26262时遇到的一些实际困难。
工作成果遗漏
功能安全概念FSC是功能安全要求FSR及其相关信息的规范，它们在架构中被分配的结果，以及相互作用是实现安全目标所必需的。根据 ISO26262 第4部分 条款6.4.1，技术安全要求TSR需要符合在概念阶段识别的功能安全概念FSC。但是有可能某个项目会遇到FSC缺失的情况，并且FSC的工作也未列入分工职责范围。在这种情况下，需要对 FSC 进行反推或重新拟定以完成安全档案。另一种情况是存在FSC被识别到，但功能安全要求FSR未被正确衍生以及未输出部分工作成果。这两种情形都不是理想的，并且违背了标准中旨在输出工作成果的目的。供应商的另一种选择是将其产品设计为“独立于环境的安全要素”(SEooC)，并向客户提供安全手册。供应商应通过 DIA 确保上游工作成果在双方认可的节点内按时交付。
多方开发
现今由多个组织共同开发的产品并不少见。对于软件开发来说尤其如此。OEM 开发高级应用程序软件，一级供应商提供大部分基础软件，第三方供应商提供 CAN 堆栈的产品并不罕见。在这些情况下，关键是要在 DIA 中记录相关方所分配的工作和时间表并得到各方的同意。在同一产品上各团队之间如果缺乏协作和团队合作，很可能不利于产品的安全验证和确认活动。因此要关注在项目早期通过 DIA 确定多方责任和时间表的重要性。
既有系统的挑战
近年来，OEM 强烈需要获得越来越多的控制单元以满足 ISO26262 标准。随着车型年份的更新，车辆中的大多数电子控制单元通常会保持现状或进行最少的更改。然而，新的 ECU 或经过工程更改的 ECU 可能会决定采取措施以符合 ISO26262。然而，ECU 通常可以从传感器或 CAN通信接收输入信号，这可能成为安全概念的一部分，从而将 ASIL 要求与之关联。这将导致信号发送端的 ECU 或硬件组件发生变化。但是，由于决定保留既有组件或可能使用经过验证的论据，OEM 可能会立即推迟进行这些更改。在这种情况下，系统中的缺陷需要在功能安全评估中进行明确沟通说明和相互认同并记录在案。此外，应记录并商定因这些缺陷而可能产生的任何法律责任。
关键运算资源
这可以在与既有系统相同的环境中看到。作为ECU 硬件的微控制器可能没有充足的资源，如可用的运行时间、内存分区能力、可用 RAM 或闪存来实施满足项目目标 ASIL 所需的安全控制策略。有时，可以通过仔细选择安全策略来克服运行时间或 CPU 吞吐量等挑战。例如：与基于定时器中断的反馈相比，选择基于 ADC 的反馈可能需要更少的 CPU 吞吐量。应在报价请求阶段评估预期选型的硬件是否能支持实施适合该项目的安全概念。既有微控制器可能不具备更高 ASIL 所需的诊断覆盖率DC级别。这将有助于各方真实地了解在一个项目中重新实施 ISO26262 所涉及的成本、时间和精力。
利益相关者缺乏兴趣
ISO26262 的成功实施取决于所有利益相关者的协作和团队合作，包括 OEM、Tier1 和任何子供应商或第三方。如果原始设备制造商的承诺较低，那么一级供应商可能很难开发出符合 ISO26262 的产品。期间将会面临各种调整，从缺少 HARA 和 FSC 等安全概念工作成果到无法执行安全验证。正如第 1 点和第 2 点所提到的，从项目开始就应倚重于由各方参与并签署的DIA 的安全管理可以帮助缓解这个问题的影响。另一方面，如果 ISO26262 的实施只是为了供应商的利益，那么供应商可以在其内部模仿这些遗漏的工作成果和 OEM 的角色。
多站式开发
通常一级供应商的组织会遍布世界各地。这意味着多元文化的交融以及存在（或不存在）不同时区大幅重叠的挑战。当这些分布的团队需要共同努力在产品中来共同实施功能安全时，问题将会愈发严重。问题与其说是功能安全，不如说是与各个团队对功能安全实施的解释有关。明确分配和标记职责的 RASIC 图表可用于最大程度地减少误解。
6管理功能安全的关键任务
管理功能安全在项目启动前开始并且可能延伸到产品离开工程组后很长一段时间。项目经理/安全经理的首要任务之一是评估实施功能安全在项目中的成本和时间影响。产品投入生产后，通常由一名专门的安全经理负责跟踪可能从现场报告的多个产品的安全异常情况。
在本节中，我们将尝试捕捉项目经理/安全经理在产品开发过程中承担的一些关键任务。
建立DIA
开发接口协议（DIA）是一个非常关键的文件，需要在项目早期建立。DIA在OEM和供应商之间建立了完成相关功能安全工作产品的责任矩阵。DIA还将记录每个工作产品的时间，以及它是否是供应商向OEM交付的产品，反之亦然。这也是OEM可以正式传达任何目标度量（例如硬件的SPFM、LFM和PMHF）的地方。
OEM应确保在RfQ时发送DIA（ISO26262标准第8部分第5.4.4节），因为这应是范围界定的基础，因此成本和时间都需要包含在报价中。供应商经理可以创建一份DIA草案，记录其所有假设（例如，功能安全概念和安全验证由OEM完成），以防OEM在RfQ时未及时发送。这有助于建立假设并为今后讨论项目范围奠定基础。
客户安全经理和供应商安全经理应使用DIA定期审查项目中的功能安全实施进度，并在所有主要里程碑进行审查。
在存在多个供应商或子供应商的情况下，DIA可以帮助提供非常需要的清晰性。例如，以ECU为例，其中硬件和基础软件由供应商X提供，CAN通信堆栈由另一供应商Y提供，如果应用软件由第三供应商提供。在此场景中，需要引出安全需求规范、验证和集成测试的责任，以便恰当地涵盖所有用例。
附录显示了示例DIA的简要快照。DIA的假设是OEM将负责HARA、FSC和安全验证。除了一级供应商X外，还有一个额外的软件供应商Y，该供应商提供需要集成到模块中的软件插件模块。
DIA中捕获的详细程度可能需要根据具体项目和相关方进行调整。太多细节会导致“分析瘫痪”，而太少细节会导致预期不一致。与所有工作产品一样，记录项目结束时的经验教训将有助于持续改进。
实施功能安全的工作量估算
对于项目经理/安全经理来说，最具挑战性的任务之一是能够相当准确地估计在任何特定项目中实施功能安全所需的工作量所面临的挑战从缺乏过去的数据到因具体项目情况而引入的特殊动态。后者的一个例子是，供应商负责功能安全的所有方面，包括危害分析和风险评估（HARA）和安全验证。
本节提供了构建工作量评估工具的框架。一个组织可以使用这个工具，并且在一段时间内能够以相当高的精度估计功能安全工作。关键是不断用组织中实施功能安全的各种项目的过去数据填充工具。
我们将应用该框架，假设项目需要新实施功能安全，并且OEM在RfQ时至少提供了HARA和安全目标。所提议的工作量估算标准是每个ASIL每个安全目标的小时数。
该框架假设实现功能安全的总体努力取决于两个关键参数——安全目标总数和分配给每个目标的ASIL。
之所以选择安全目标，是因为安全目标可以被视为最高级别的安全要求。如图所示——安全要求的推导，所有安全要求被包括。硬件和软件安全要求可以显示为源于安全目标。因此，我们可以得出结论，这将是一个合理的度量标准，包括系统、硬件和软件学科的开发工作。
此外，图2–产品开发生命周期中的棕色箭头显示，几乎所有产品开发活动都是在概念阶段（ISO26262第3部分第7条）确定HARA之后的安全目标后开始的。
该标准提供了五种分类，ASIL A最不严格，要求也最严格，而ASIL D则相反。质量管理分类不需要ISO26262标准中的特殊措施，使用适当的行业特定质量标准就足够了。ASIL级别是根据概念阶段危害分析和风险评估期间确定的最高ASIL级别危害确定的。
从长远来看，实现两个ASIL A安全目标所需的努力可能小于ASIL D安全目标的努力。这主要是由于更高的ASIL（如ASIL D）所需的更严格的度量要求和开发严格性（设计、验证和测试）的差异。例如，在实现ASIL D安全目标时，必须确保99%的可能违反安全要求的单点故障能够在FTTI内诊断。
此外，评估软件和微控制器自身的常见安全策略（如RAM测试、闪存测试、看门狗测试、堆栈溢出等）应单独捕获，并作为第二个独立操作数用于公式中。这些工作通常会在每个项目中花费一次，并不受安全目标数量的影响。
在这个阶段，工作量估算公式可以稍微修改为
如果在影响分析过程中，很明显硬件或软件工作产品只有有限的变化，那么最好使用组织中已经使用的现有方法来估算软件或硬件变化的工作量。例如，只有验证和确认可以重复，或者更改可以仅包含在少数软件安全要求中。如果该项目已经实现了功能安全，并且只是进行了一些小的增强，则可能会出现这种情况。
无论如何，这说明了为什么组织从过去的项目中获取数据和经验教训。重要的是，还应根据产品开发各个阶段，例如概念阶段、系统开发、硬件开发、软件开发、验证、评估、安全验证等。
以这种粒度级别捕获的数据提供了非常需要的准备工作，组织可能需要对竞争性的工作量评估做出快速反应。供应商可能需要根据OEM在RfQ中规定的多种方案进行报价。例如，OEM可能要求供应商确定安全目标，这意味着必须包括项目定义、HARA和FSC等活动的时间和努力。另一种情况可能是OEM同意提供一辆生产目的车辆用于安全验证，但要求Tier1进行实际验证。
根据项目中更精细的决策，始终存在进一步创新和完善的空间
[*]是否为ASIL B项目进行SPFM/LFM/PMHF计算（例如使用FMEDA）
[*]材料清单中的正在计算硬件指标的元件数量
[*]根据硬件部件数量估算SPFM/LFM/PMHF计算工作量
[*]微控制器是否支持功能安全，例如，具有MPU（这可能会减少证明不受干扰所花费的精力）
以上的因素可以被称作影响系数，并可以在每个项目结束前将基于经验教训进行修正。
基于这点，公式可以进一步细化为：
估算工作量的方法
上述用于评估工作量的方法，可以总结为以下六个主要步骤。使用上面讨论的框架进行工作量估计的方法可以总结为六个主要步骤:
[*]创建/更新基线；
[*]使用基础的工作量评估公式；
[*]影响系数的补偿计算；
[*]获取数据；
[*]经验教训总结/分析新的影响系数；
[*]计算每个安全目标的实际工作量
7管理功能安全的关键任务估算工作量的方法
上述用于评估工作量的方法，可以总结为以下六个主要步骤。使用上面讨论的框架进行工作量估计的方法可以总结为六个主要步骤:
[*]创建/更新基线；
[*]使用基础的工作量评估公式；
[*]影响系数的补偿计算；
[*]获取数据；
[*]经验教训总结/分析新的影响系数；
[*]计算每个安全目标的实际工作量
步骤1：创建/更新基线组织在采取实施功能安全的第一步时，首先应该建立一个基线。基线可以通过使用专家判断对每个交付物进行详细评估来建立。对于HW和SW交付物，可以使用现有的过程和方法。或者，组织可以寻求外部顾问或专家的帮助，他们可以帮助建立初始基线。如适用的话，则基于步骤六的新的可用数据更新基线。
步骤2：使用基础的工作量评估公式用以下公式计算工作时数:对于从ASIL A到ASIL D的每个ASIL的安全目标，属于各自ASIL的安全目标的数量乘以“每个ASIL的每个安全目标的小时数”。
步骤3：影响系数的补偿计算根据第2步估计的工作量可能需要进行补偿，以考虑到可能影响实际工作量(积极和消极)的各种因素。这方面的例子可以是:
[*]一个由于与另一个产品的协同作用，许多微控制器级别的安全机制已经就绪的项目
[*]ASIL等级最高为B的项目且客户对硬件指标无要求
[*]如果一个项目有非常多的组件，因此评估硬件指标的工作量将会增加一个系数
[*]各利益相关方(如供应商工程团队，OEM安全经理)在功能安全方面的成熟度
[*]一个涉及多个供应商集成组件并以联合方式执行验证和测试的项目。可能需要一个系数来调整工作量如1.2倍，然后根据项目结束时基于经验教训进行调整。补偿量可以根据专家的判断进行
步骤4：收集数据项目应该强调数据的质量，同时强调至少每周一次定期收集数据的需求。使用界面简单的工具，并确保以正确的格式收集数据。例如，分别获取花在质量管理体系要求的测试活动和安全相关测试上的小时数；还要确保任务被分解到适当的颗粒度，并在数据获取工具中可用，以获取每个安全目标的工作量。例如，分析安全目标1 TSR的工作量，分析安全目标1软件安全需求的工作量，分析安全目标1硬件指标的工作量等等。确保工程师能够以直观的方式输入数据，有助于确保数据的质量，并有助于计算第6步中每个安全目标的实际工作量。
步骤5：经验教训总结/分析新的影响系数在项目结束时，查看实际工作与估计工作量之间的偏差有多大。与团队进行头脑风暴，了解原因。每个组织可能有不同的公差，例如可接受的偏差为+/-5%。确定任何新的影响系数，例如导致需求波动的OEM文化差异，或拥有一个对功能安全相对陌生的团队；识别任何经验教训，例如使用新的硬件设计和由此产生的额外测试。
步骤6：计算每个安全目标的实际工作量根据收集到的数据计算每个安全目标的实际工作量，如果适用，更新基线，例如新数据和旧估计之间的偏差超过阈值。
分配正确的人力资源
项目经理负责为项目确定和任命安全经理。项目经理应确保安全经理接受过相应的培训，并具备相应的资质。有时，安全经理的角色可能由多个项目员工承担，也可能由项目经理自己承担。在任何一种情况下，项目经理都需要确保做出正确的决定，记住他或她最终要对项目的成功负责。此外，项目经理应确保安全经理获得履行职责所需的足够正式的权力。安全经理需要的一些个人品质是自信，建立共识和协作。
项目经理应确保项目人员得到适当的培训。硬件工程师的培训需求可能不同于软件工程师或系统工程师。然而，项目经理应该为项目分配足够的资源和相关培训，以便能够执行功能安全任务。
培育功能安全文化
项目经理/安全经理有责任确保安全文化在基层得到真正的实践和培养。安全文化是把安全放在第一位的文化。
安全文化的一些例子是：
[*]确保在开发过程中报告的安全异常不被忽视，并在判断前进行充分分析
[*]确保正确的利益相关方参与各种功能安全活动，例如:来自不同学科的广泛专家参与HARA分析。HARA中的错误判断会导致项目后期的大量返工。另一个例子是确保验证评审是由具有正确技能的人员完成的
[*]确保从其他项目中获得最佳实践，并在组织中分享当前项目的经验教训
[*]确保升级路径被明确标识
一个常见的缺陷是没有赋予安全经理足够的权力来影响可能影响安全的决策。附录中还列出了该标准中有关安全文化的大量例子。
产品开发策划
在启动安全生命周期时要采取的第一个步骤是执行影响分析。影响分析的目的是检查已经应用ISO26262的产品中有哪些变化会影响其功能安全。其结果将是确定将受到影响的活动和工作产品，并需要在安全生命周期中加以考虑。对于ISO26262的新开发或第一次应用，影响分析没有什么意义。
作为计划阶段的一部分，经理需要确定和计划在不同阶段(系统开发、硬件开发和软件开发)需要完成的活动和工作产品。活动、工作产品和它们各自的时间表都记录在安全计划中，以及谁对它们负责。例如，软件开发计划可能包括:使用哪一种编程语言，遵循什么设计和编码准则，以及软件验证计划。第8部分中对过程的任何裁剪和对支持过程的识别在这个阶段也有最好的文档说明。
变更管理
项目需求很少在RFQ时被冻结，新的需求会随着项目的进展而发展。就像正常的产品开发一样，项目经理应该查看在没有正式更改请求的情况下沟通的需求范围渐变和更改的可能性。后期的更改、无文档记录的客户更改、没有可跟踪需求的更改都可能对项目预算、时间安排和已实现的项目功能安全造成严重破坏。
软件工具的选择
标准“软件工具使用的置信度”第8部分第11条-要求为用于安全相关项目的产品开发软件工具建立所需的置信度水平。本条款在标准第8部分第11.2条中描述的目的是
[*]将由于软件工具故障导致错误输出而导致的已开发产品系统故障的风险降至最低。
[*]如果ISO 26262要求的活动或任务依赖于所使用的软件工具的正确功能，则开发过程在符合ISO 26262方面是充分的
项目经理/安全经理在评估计划中使用的第三方工具时，应该验证供应商是否会提供针对该工具将被使用的特定版本和环境的工具确认报告。许多工具供应商将他们的产品作为ISO26262合格的产品进行营销，但是这种资质只对软件工具每一个唯一版本和配置有效。
在公司内部重复这项工作可能会增加相当大的工作量，而且还需要一个具有专门知识和训练的人。据独立估计，专家鉴定一个工具的平均工作时间为80小时以上。
一个好的组织级最佳实践应该是在组织级整合所有工具鉴定活动(功能安全)，并发布结果供单个项目使用。
软件组件管理
将来自多个供应商的软件集成在一起并不罕见。最重要的是通过DIA澄清谁将负责引出软件需求，并作为单个软件单元进行验证。确定每个软件供应商的职责也很重要，因为它适用于识别和实现安全需求，并在软件开发生命周期的后期执行集成测试。如果软件组件以前是按照ISO26262开发的，并且计划重用，请确保报告按照第8部分第12条进行验证，以确保确认有效。
8总结
项目经理和经理们不应轻视在新项目中实施ISO26262所面临的挑战。本文旨在涉及一些在实施ISO26262过程中可能压倒组织的主要任务，并试图帮助新的管理者将ISO26262落地运行。
随着2011年ISO26262标准的发布，对产品符合相关完整性级别所需的过程和工作产品有了明确的标识。尽管其中一些工作产品可能已经是产品开发的一部分，但肯定还有额外的工作，其努力不容忽视。组织需要能够识别额外的任务、工作产品和过程(缺口)，它们需要建立以符合功能安全标准。这既可以由公司内部的中心小组完成，也可以由外部专家完成。低估在项目中实现功能安全的时间和精力影响会很快导致错过截止日期和客户不满意。
为了能够估计额外的费用并确保在预算中执行项目，组织应该通过估计、测量和重新确定所花费的努力的原则。总会有新的动态带来新的挑战，管理者需要做好应对这些挑战的准备。还建议项目审查委员会密切监测和支持。
最后，管理项目是一个不断发展的过程，组织应该吸取教训和最佳实践，以培养安全文化和持续改进为目标。
... （END） ...
免责声明：如涉及侵权请及时与我们联系反馈，我们会在第一时间做更正声明或做删除处理。文章版权及解释权归原作者及发布单位所有，仅供参考学习。
SASETECH是国内首个由汽车安全专家发起组建的技术社区，致力于为汽车安全的从业者提供交流、学习、合作的中立性平台。
SASETECH 致力于推动功能安全、预期功能安全、信息安全在行业内外的影响力，成为国内广有影响力的公益型安全社区。“建立安全生态圈，成为汽车安全的布道者”是我们的使命，“专业创新、开放共享、实事求是”是我们的共同价值观。在现有工作基础上，未来我们将陆续展开安全行业大型线上WIKI、基础导读文章框架等项目。
页:
[1]