最新资讯
在融合 ISO 21434（网络安全）与 ISO 26262（功能安全）的过程中，由于两者关注的危险类型不同（非故意故障与外部恶意攻击），在需求层面极易产生冲突。例如，安全系统侧重于可预测的安全行为，而安保系统则需要动态性和适应性以防止外部入侵。针对这些冲突，业界通常采用以下检测与消解方法：
关系矩阵分析法通过构建关系矩阵，将功能安全目标与网络安全目标进行交叉映射。例如，在矩阵中明确标识出哪些网络安全目标有助于满足功能安全目标（标记为“O”），以及哪些目标之间存在冲突（标记为“X”）。这种方法能够直观地帮助团队分析目标之间的相互依存关系，并就冲突点达成风险处理共识。
一致性与冲突检查活动在可信汽车软件开发生命周期（SDLC）中，专门设立结构化的检查活动。例如，在“影响评估结果”和“需求定义”阶段，执行一致性与冲突检查（Conformity & conflict check）。通过这种系统性的审查活动，能够在开发流程中及早发现并解决两项标准并行应用时产生的冲突。
FTMEA（故障、威胁与影响分析）框架针对传统方法难以定量模拟功能失效与网络威胁双向影响的问题，采用 FTMEA 框架。该框架在分析故障模式（FM）和威胁模式（TM）时，重点识别“共同影响”（即由功能故障或网络威胁导致的相同不良后果）。通过引入量化的相关因子和改进的风险优先数（RPN）计算方法，FTMEA 能够客观评估两者的相互影响，从而消除主观解读带来的冲突。
全生命周期协同工程（Co-Engineering）摒弃传统上将功能安全与网络安全分离考虑的方式，采用全局性的整体安全方法。将两个生命周期结构化为相关的活动对（如软件单元验证），使其能够作为协同工程的一部分被共同处理。在概念阶段、需求定义等关键节点设置同步点，供开发、功能安全和网络安全团队共同调整工作产品并进行必要的权衡。
制定统一的建模与编码规范在软件开发（特别是基于模型的开发 MBD）中，制定一套通用的规范集来同时解决两项标准的相关问题。例如，确保输入值的数据类型和范围一致性、避免算术运算中的数据溢出、检测并消除浮点数据类型之间不必要的直接相等比较等。借助自动化工具（如 MXAM），可以在模型层面自动检查并修正这些规范违规，从而在底层代码实现上消解安全与安保的冲突。
建立跨学科的统一量化语言通过提供通用的量化语言和结构化方法，从根本上优化安全团队和网络安全团队之间的协作。这有助于打破团队间的沟通壁垒，确保在应对“共同影响”和“优先级排序”时有一致的评估基准，从而打造更具弹性和安全性的系统设计。
遵循标准兼容性与优先级原则在实施安全措施时，应确保其与安保措施的实施相兼容。安全对策应有效防止威胁对安全相关系统造成不利影响，反之亦然。当面临冲突时，需要制定明确的优先排序策略，确保安全关键系统在不损害其功能安全（FuSa）的前提下保持网络安全。
推荐阅读：
亚远景-ISO 26262与ASPICE：汽车软件开发中的协同与互补
亚远景-拒绝“为了评估而评估”：如何让 ASPICE 真正融入日常开发？
亚远景-ASPICE在供应链管理中的角色：如何利用标准评估和选择供应商
亚远景-从仿真测试到实车验证：ISO/PAS 8800 的测试策略
推荐服务：
点击查看亚远景ASPICE、ISO26262实施工具-APMS研发过程管理平台
