精品译文 | 如何管理项目中的功能安全(ISO26262)(上)
原文：Extending Software Architectures from Satety to Security
作者：Agish George, Jody Nelson
译文审核：阚博然 吴姿 卢雪梨
➡本文分为上下两部分（第一部分约5800字，20钟阅读）
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_（这可能会减少证明不受干扰所花费的精力）_
以上的因素可以被称作影响系数，并可以在每个项目结束前将基于经验教训进行修正。
基于这点，公式可以进一步细化为：
估算工作量的方法
上述用于评估工作量的方法，可以总结为以下六个主要步骤。使用上面讨论的框架进行工作量估计的方法可以总结为六个主要步骤:
- 创建/更新基线；
- 使用基础的工作量评估公式；
- 影响系数的补偿计算；
- 获取数据；
- 经验教训总结/分析新的影响系数；
- 计算每个安全目标的实际工作量
...未完待续...
免责声明：如涉及侵权请及时联系反馈，我们会在第一时间做更正说明或做删除处理。文章版权及解释权归原作者及发布单位所有，仅供参考学习。
作者：SASETECH
文章来源：sasetech
推荐阅读
更多物联网安全，PSA等技术干货请关注平台安全架构(PSA)专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入PSA技术交流群，请备注研究方向。
