实施汽车功能安全的四个关键错误

OEM 和一级供应商等汽车利益相关者必须将功能安全 (FuSa) 视为整个组织的实践。说起来容易做起来难，实施符合 ISO 26262的 FuSa 会带来一系列挑战。如果不解决这些挑战，则会导致项目管理错误，从而给项目带来延误和成本上升的负担。管理不善的情况可能与组织中整体缺乏安全意识或跨职能团队之间的协调不佳有关。

在汽车生态系统中，一个利益相关者的疏忽也会影响到其他利益相关者。如果一级供应商不以广泛的方式进行危害分析，架构设计可能会充满未识别的危害和相关风险。同样，使用未受过 ISO 26262 标准培训的资源从事安全关键项目也有其自身的危险。在本文中，我们整理了一组必须不惜一切代价避免的此类 FuSa 管理错误。

1. 组织缺乏安全意识

功能安全不仅限于从事安全关键型汽车项目的安全团队。从开发人员和测试工程师到项目经理，每个团队成员都必须了解 ISO 26262 标准及其指南。让我们看看在组织中整体缺乏安全意识时所犯的一些 FuSa 错误。

缺失的安全文化：安全文化本质上意味着汽车软件或硬件开发中的每个利益相关者都认真对待功能安全。不忽视任何危险，关注安全生命周期的每个阶段，资源相互协调，协同工作。仅仅拥有一名功能安全经理/顾问而不专注于建立安全文化是组织所犯的最常见的错误。

关注文档而不是安全：文档是 ISO 26262 合规性的重要组成部分。当 OEM 进行认证时，这些文件可作为证据。然而，仅仅关注文档而不是实际的安全要求、目标和机制会适得其反。

基于假设的 ASIL 确定：在不执行危害分析和风险评估 (HARA) 的情况下确定汽车模块的汽车安全完整性等级 (ASIL) 值已被视为必须避免的常见做法。不建议假设基于行业规范的 ASIL，因为这可能会导致遗漏危险。例如，信息娱乐系统通常被认为是 ASIL B。因此，许多信息娱乐开发公司不执行 HARA，而是将 ASIL B 视为其解决方案就足够了。如果信息娱乐系统还包含可用于自动执行车辆中某些操作的摄像头数据会怎样？这是一个严重的安全隐患，由于假设而被忽略。

图 1：HARA 作为一个流程，是 ISO 26262 规定框架和团队对功能安全和汽车功能的理解的结晶。资料来源：恩比特尔

2. 破坏功能安全引发的安全管理不善事例

一些汽车供应商或技术提供商了解 ISO 26262 标准及其细微差别。然而，为了避免成本和缩短上市时间，它们往往会破坏某些安全关键组件的功能安全性。似乎对安全要求或危险的偶然无知可能会危及车辆乘员的生命。

低估整个项目的时间线/工作量：一旦将安全关键性纳入图片，以及 ISO 26262 标准，工作量会因显而易见的原因而增加。随着努力，时间线也延长了。通常，ASIL A 意味着工作量增加 10-15%，对于符合 ASIL D 的项目，这一数字会上升到 100%。在不考虑安全要求和目标的情况下低估这项工作是另一个需要避免的 ISO 26262 合规性错误。当公司试图挤入实施部分以遵守预先确定的任意期限时，项目开始受到影响。

考虑产品生命周期结束时的安全性：如前所述，ISO 26262解决方案的架构设计是基于软件需求和安全需求创建的。当您开发符合ISO 26262标准的汽车解决方案时，必须从产品生命周期开始就遵循标准指南。由于以下因素，在生命周期结束时或在第二次迭代中合并这些指南被证明是一个巨大的错误：

由于原始设计不包含安全方面，因此设计返工很重。

旧代码不可能重用，因为它不符合ISO 26262。检查前置条件、在发送/接收信号的模块之间使用包装器以及引入新模块意味着可能需要编写大量新代码。

有时，整个设计需要更改，这可能会导致微控制器平台的更改。这意味着从头开始设计产品。

工具和工程技能投资不足：许多组织认为，拥有一名功能安全经理足以确保符合ISO 26262。对安全的态度往往有一定程度的不敏感。这可能是在使用合格工具或提高资源技能方面。始终建议培训与每个符合ISO 26262的项目相关的每个资源。从开发人员和测试人员到项目经理，每个利益相关者都必须很好地掌握ISO 26262标准中列出的实践。

Figure 2: Functional safety, no more an afterthought, has life of its own in an automotive design. Source: Embitel

3. 利益相关者之间协调不善造成的 FuSa 管理不善

符合 ISO 26262 的项目涉及来自不同团队和不同技能的资源。有开发人员、测试工程师、硬件专家、项目经理、功能安全经理等等。

团队之间缺乏协调：组织内的不同团队需要协调以完成各种安全活动。例如，要执行硬件故障模式影响和诊断分析 (FMEDA)，软件团队必须清楚地了解安全机制。有时，团队不了解这种合作的重要性。

原始设备制造商和一级供应商之间的协调不佳：在某些情况下，原始设备制造商无法在安全合规方面提供足够的支持和准备。跳过了危险，没有正确执行安全分析，各种此类管理不善的情况接踵而至。此外，OEM 未能评估一级供应商的工具能力被证明对项目不利。

4.技术和管理错误的混合

由于缺乏预算或超出项目管理并开始干扰技术方面的通用 ISO 26262 知识而导致某些限制。让我们来看看它们。

将安全关键系统的标准设置得太低：当您开始忽略危险并放宽验收标准时，项目就会受到威胁。例如，模块中可能只有一个安全问题需要 ASIL C。但是，您选择忽略它并坚持 ASIL B。这是组织所犯的严重错误。成本上升是造成此类错误的主要原因。测试所有极端测试用例、执行额外的安全分析以及对工具许可证的投资都会增加项目成本。测试时还存在烧毁电路板、LED 和电机的风险。尽管如此，为了安全起见，必须检查这些故障。

低估了 SOTIF 和 ASPICE 等相关标准的重要性：除了功能安全，还有 ASPICE 和 Cybersecurity 等其他标准（ISO/SAE 21434) 是根据项目的要求而遵循的。由于所有这些标准都涉及编码和测试指南，因此它们之间有很多重叠之处。这方面最常见的错误是在制定安全计划时没有考虑这些标准之间的相互关系。有许多活动可以并行运行，甚至可以合并以节省时间。例如，ASPICE 推荐的软件资格测试类似于 ISO 26262 推荐的软件集成测试和能力成熟度模型集成 (CMMI)。原则上，它们都检查软件的高级架构。可以合并此类类似流程的模板，以节省大量时间和精力。使用不同标准时犯的另一个常见错误是忽略一个标准对另一个标准的影响。

过度工程：并非每个汽车模块都对安全至关重要。只有在执行 HARA 时，您才会知道关键程度。组织有时不希望执行所有安全活动并为模块假设更高的 ASIL 等级只是为了安全起见。这导致实施甚至不需要的安全机制。必须避免此类做法，以优化成本和上市时间。

ISO 26262 是一个广泛的标准，组织无法在短时间内达到功能安全实践的成熟度。但是，通过避免上面列出的错误，他们可以加快这个过程。

— Poornima Jha，功能安全经理和 FSCP-L2 认证 ISO 26262 专家，是 Embitel 的项目经理。

——Vaibhav Anand 是一位数字营销专业人士，对汽车的一切都有着根深蒂固的兴趣 ， 他是 Embitel 的内容作家。

审核编辑 黄昊宇