家»汽车»必须避免的四个汽车功能安全错误

必须避免的四个汽车功能安全错误

文章作者：Poornima Jha和Vaibhav Anand

FuSa管理不善可能与组织内缺乏安全意识或不同团队之间协调不善有关。

汽车利益相关者，如原始设备制造商和一级供应商，必须遵守功能安全（FuSa）作为其整个组织的实践。说起来容易做起来难，实施起来难ISO 26262兼容的FuSa有自己的一系列挑战。这些挑战如果得不到解决，就会导致项目管理失误，给项目带来延误和成本上升的负担。管理不善的情况可能与组织整体缺乏安全意识或跨职能团队之间协调不善有关。

在汽车生态系统中，一个利益相关者的疏忽也会波及到其他利益相关者。如果一级供应商没有以广泛的方式进行危害分析，架构设计可能会被不明危害和相关风险所困扰。同样，利用资源开展安全关键项目没有接受过ISO 26262标准培训的人也有其自身的危险。在本文中，我们汇编了一组必须不惜一切代价避免的FuSa管理错误。

本组织缺乏安全意识

功能安全不限于在安全关键汽车项目上工作的安全团队。从开发人员和测试工程师到项目经理，每个团队成员都必须了解ISO 26262标准及其指导方针。让我们来看看在组织中总体缺乏安全意识时犯下的一些令人犯规错误。

缺失的安全文化：安全文化本质上意味着汽车软件或硬件开发过程中的每个利益相关者都认真对待功能安全。没有危险被忽视，安全生命周期的每个阶段都得到了关注，资源相互协调，协同工作。仅仅有一名职能安全经理/顾问，而不注重建立安全文化，是组织犯下的最常见错误。
专注于文档而不是安全：文档是ISO 26262合规性的重要组成部分。当OEM用于认证时，这些文件就作为证据。但是，仅关注文件而不是实际的安全要求，目标和机制是适得其反的。
基于假设的ASIL确定：在不进行危险分析和风险评估（HARA）的情况下确定汽车模块的汽车安全完整性等级（ASIL）值已被视为必须避免的常见做法。假设基于行业规范的ASIL不推荐，因为它可能导致遗漏危险。例如，信息娱乐系统通常被认为是ASIL B。因此，许多信息娱乐开发公司不执行HARA，并认为ASIL B的解决方案是足够的。如果信息娱乐系统还包含可能用于自动执行车辆中某些操作的摄像头数据，该怎么办？这是一个严重的安全隐患，由于假设而被忽略。

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

通过破坏功能安全引发的安全管理不善实例

一些汽车供应商或技术提供商意识到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标准中获得良好的指导。

图2功能安全，不再是事后的想法，在汽车设计中有它自己的生命。资料来源：埃姆比特尔

利益相关者之间协调不善导致FuSa管理不善

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

团队之间缺乏协调：组织内的不同团队需要协调以完成各种安全活动。例如，要执行硬件故障模式影响和诊断分析（FMEDA），软件团队必须清楚地了解安全机制。有时，团队不理解这种合作的重要性。
原始设备制造商和一级供应商之间协调性差：在某些情况下，原始设备制造商无法提供足够的安全合规支持和准备。跳过危险，未正确执行安全分析，各种管理不善的情况接踵而至。此外，原始设备制造商未能评估一级供应商的工具能力证明会对供应商造成不利影响项目

技术错误和管理错误的混合体

由于缺乏预算或超出项目管理的常见ISO 26262知识，并开始干扰技术方面，因此存在某些限制。让我们来看看这些限制。

对于安全关键系统而言，将标准设置得过低：当您开始忽略危害并放宽验收标准时，项目就受到了危害。例如，模块中可能只有一个安全问题需要ASIL C。但是，您选择忽略它并坚持ASIL B。这是组织犯下的一个严重错误。成本上升是此类错误的主要原因。Tes中止所有极端测试用例、执行额外的安全分析以及投资工具许可证都会增加项目成本。在测试过程中还存在烧坏电路板、LED和电机的风险。但是，为了安全起见，必须检查这些故障。
低估相关标准的重要性，如SOTIF和APPICE：除了功能安全外，还有其他标准，如ASPICE和网络安全(ISO / SAE 21434）基于项目的要求。由于所有这些标准都涉及编码和测试指南，因此它们之间存在很多重叠。这方面最常见的错误不是在创造安全计划时遵守这些标准之间的关系。有很多活动可以并行运行，甚至合并以节省时间。例如，Aspice推荐类似于ISO 26262和能力成熟模型集成（CMMI）的软件资格测试。原则上，所有这些都检查软件的高级架构。这种类似进程的模板可以合并以节省大量的时间和精力。在使用不同标准时承诺的另一个常见错误忽略了另一个标准的含义。