汽车信息安全进阶之路----ISO/SAE21434解读（三）

最新推荐文章于 2025-06-24 16:47:03 发布

物方科技

最新推荐文章于 2025-06-24 16:47:03 发布

阅读量780

点赞数

CC 4.0 BY-SA版权

文章标签：汽车安全网络

本文链接：https://blog.csdn.net/kilas1984/article/details/131456323

信息安全、功能安全和其他学科之间的关系

将信息安全技术应用于汽车系统的一个关键点是要结合汽车工程的其他安全方面来考虑。传统的车辆工程基于指定车辆的属性或目标，这些属性或目标通常在设计开发流程的早期进行设置。例如，通过将开发测试活动与可比车辆进行基准测试。这些属性可能是客观存在的（例如，电动汽车的续航里程或加速时间等）或驾乘人员的主观感受（例如，行驶和操控、噪声和震动等）。然后将这些属性级联并细化为车辆、系统和组件需求的连续级别，以便它们可以在产品中实现。

这种需求及相关的测试和验证活动通常使用系统工程的“V”模型进行管理。当然，在产品开发过程中，可能需要在属性之间进行折衷或权衡（例如，牺牲续航里程的性能，或在乘坐舒适性与操控性之间进行平衡）。

功能安全学科中出现的一个重要原则是，作为安全目标表示的危险分析和风险评估（H&R/HARA）的结果及其相关的汽车安全完整性等级（ASIL）值有效地代表了需要在计划早期定义的属性，以便对实现这些目标所需的产品开发的严格性设定期望。

因此，作为属性（ISO 26262术语中的“项目”），为特定系统指定的安全目标和ASIL总结了所需的性能目标和所需的相关开发严谨性，并可供更高管理层用来签署根据所需的严格性开发产品所需的承诺。根据经验，ISO 26262第1版的缺点之一是，由于其故意缩小范围，施用者倾向于忽略与其他工程学科的联系以及由此产生的协同效应，这些协同效应可以使多个领域受益。示例范围限制包括：

“危险”的定义仅限于电子系统故障行为（包括系统间交互）造成的潜在危害。其他危害，例如与更广泛的产品安全问题和特定技术实施固有的危害相关的危害，除非与电子系统故障直接相关，否则被视为不在范围之内。例如，在混合动力或电动汽车中与可充电储能系统相关的危险电能水平的情况下，电击和触电等危险超出了ISO 26262的范围，但在其他标准范围内，这些标准对物理保护和隔离电阻等事项提出了要求。但是，如果电子系统故障可能导致缓解措施的危险或失败，则属于ISO 26262的范围。
“伤害”的定义仅限于人身伤害或健康损害;即使可能是由电子系统故障引起的，也不会考虑更广泛的损失或影响。

这导致了忽视或忽略与其他领域重要因素相互作用的趋势，例如机械故障模式。虽然通过避免标准故障模式和可靠性技术可以正确解决针对此类故障模式的产品设计，但应考虑此类故障模式对电子系统行为的影响，例如，考虑电子系统是否需要检测故障并向驾驶员发出警告或实施策略作为缓解措施的一部分。

在车辆中使用电子转向柱锁（ESCL）的案例可以证明这一点。ESCL是一种防盗条款，通常用于帮助满足FMVSS 114和联合国（UN）法规116的要求，以防止未经授权的车辆使用，并取代了无钥匙进入和启动车辆中的传统钥匙操作转向柱锁。

从功能安全的角度来看，危险分析将识别危险，例如在车辆行驶时不要求锁定方向盘，以及授权驾驶员进入车辆时未能解锁转向柱，这意味着车辆在转向锁定的情况下驶离停车位置。将确定安全目标以避免或减轻危害，并制定战略，并将其表述为实现这些安全目标的安全要求。

对于与避免不必要的与锁定相关的安全目标，典型的策略表现为检测可能导致危险的故障并确保系统处于“安全状态”（通常禁用ESCL功能）。对于避免在转向锁定的情况下驶离停车位置相关的安全目标，该策略通常还涉及检测转向柱是否未解锁等。未能解锁转向柱可能包括机械原因，虽然电子系统无法阻止这些根本原因，但可能需要检测它们是否已经发生并调用适当的操作，例如，警告驾驶员转向柱已锁定，他们应该尝试通过转动方向盘并抑制发动机启动来释放它，直到转向柱成功解锁。如果对功能安全采取非常狭隘的观点，则可能会忽略后一方面。

在制定ISO 26262第2版期间，负责工作组经常被要求考虑将信息安全纳入该标准。人们很快认识到，信息安全是一门足够复杂和独特的学科，其本身的标准已足够适用; 但是，至少它的某些方面与功能安全密切相关。因此，ISO 26262第2版包含以下与信息安全相关的四个要点（三个直接和一个间接）：

作为ISO 26262第2部分“功能安全管理”中建立安全文化的一部分，现在要求与功能安全相关的学科“建立和维护有效的沟通渠道”，信息安全作为具体示例。这一要求承认功能安全的某些方面与信息安全之间的密切关系。下面将对此进行更详细的探讨。
第 2 部分还包含一个新的信息性附件E，该附件为功能安全与信息安全之间的相互作用提供了额外的指导。这是从安全从业者的角度编写的，使他们能够了解从信息安全角度做出的决策如何影响电子系统的安全目标和其他安全属性的实现。
第6部分（软件级别的产品开发）认为，对于许多实现者来说，需要一个通用的软件开发过程，从许多来源（例如安全要求，功能要求）及其相关属性中收集需求。因此，通用的开发方法是可取的，甚至可以寻求共同的解决办法。
作为间接的观点，人们认识到，将故障电子系统设计为在故障原因中“故障沉默”的经典方法不适用于SAE J3016的3级及以上的自动驾驶功能，因为驾驶员可能无法立即（或根本无法）做出反应，因此，可能需要一定程度的“可用性”，以便在发生故障时允许继续或替代操作，因此需要确保安全解决方案不会与可用性要求相冲突（这样做可能会成为拒绝服务攻击的载体）。

SOTIF（预期功能安全）作为“公开可用的规范”（ISO/PAS 21448：2019）已经发布，并将继续朝着完整标准发展，SOTIF方法最初源于在高级驾驶辅助系统（ADAS）和自