使用汽车IP，更容易将安全集成到soc中

文/ Shivakumar Chonnad, Vladimir Litovtchenko

如今用于汽车安全相关系统的soc集成了大量IP块。在系统层面，这些IP块之间的硬件软件接口(HSI)需要在仿真中验证，并在原型中验证。然而，基于soc及其组件(如IP)日益增长的复杂性，验证或验证范围和工作的扩展并不是线性的。在系统验证中，重点是验证逻辑中的场景和缺陷。在与安全相关的验证中，重点是故障，这是一种可能导致组件失效的异常情况。虽然SoC内部的IP块具有一组独立的安全相关逻辑及其相关的工作产品，但这些独立组件的安全概念和指标需要与SoC中各种IP块的层次结构合并，从而构成安全集成。SoC实现者需要描述安全相关功能的工作产品或文件，作为IP提供商的交付成果，以便将所有安全相关模块集成到SoC中，并确保SoC安全概念的完整性和正确性。

系统验证流程中的安全性
当多个IP块集成到一个SoC中时，IP块之间的交互功能将通过验证来解决。这些都是从概念阶段(包括规格和需求定义)到硬件和软件验证以及SoC预期功能的原型验证的有条不紊的步骤。重点是以高度的信心验证和验证SoC，确保SoC集成是完整的，并且没有所有已知缺陷。

同样，对于与安全相关的SoC，从需求阶段一开始就考虑每个与安全相关的SoC块和实现的安全概念是很重要的。起点和实现流可以并行执行，如图1所示。知识产权开发流程应该在所有阶段和发展阶段都从主导和安全角度了解SoC范式。

图1:安全性和标称功能开发流程示例

可衡量的指标
对于IP块和SoC的系统验证，存在定义良好的流，这些流具有可测量的目标，如功能覆盖和代码/行/切换/条件/fsm覆盖。类似的指标存在于模拟、自定义和射频设计中。

同样，与安全相关的流量也有定性和定量的可测量指标。与安全相关的IP块的关键目标是基于其定义的度量值的汽车安全完整性级别(ASIL)。

达到目标ASIL需要使用设计失效模式效应分析(DFMEA)对系统故障进行定性分析。DFMEA在IP和SoC级别捕捉元件的故障模式及其影响。接下来是对故障模式进行定量分析，以得出诊断覆盖率，这是安全机制检测到的故障与设计中总故障的函数。定量分析的结果被输入失效模式影响和诊断分析(FMEDA)。这些分析适用于IP和soc。

IP提供商必须提供足够的文件、安全论证和证据，以验证故障模式或诊断覆盖指标。对于asil C和D, ISO 26262标准要求对关键变量进行定量分析。IP提供商必须通过故障注入结果提供足够的证据，确保IP符合安全标准。

安全一体化的关键方面
产品的安全案例是通过一组描述各种安全相关活动证据的工作产品或文件来确定的。以下部分描述了SoC级安全集成的一些关键方面和文档。

技术安全理念，满足安全要求
IP的功能安全概念在功能安全要求(FSR’s)中有所说明。由于IP通常是作为上下文之外的安全元素(SEooC)开发的，因此IP集成商可以审查功能层面的安全要求，以确保与SoC相关的fsr在IP层面得到满足。技术安全要求(TSR)是在IP在不同层次结构上实现fsr时定义的。IP块的硬件安全要求(HSR)和软件安全要求(SSR)规范定义了更详细的安全措施属性。图2显示了IP或SoC级别的典型技术安全流程。

图2:IP或SoC级别的技术安全流程

IP块需要从设计阶段的最开始就将fsr捕获为工作产品的原因是为IP的整体安全概念提供足够的细节。这将有助于IP集成商分析IP块的安全实现，以减轻SoC级别的任何风险。

安全手册
与安全相关的IP的重要交付物之一是安全手册，它捕获了IP块的所有安全相关方面，这些方面表明安全相关逻辑、安全目标、监控IP内外安全相关逻辑的安全机制、硬件/软件接口(HSI)、安全机制对故障发生的反应、诊断覆盖范围和故障检测时间。

IP供应商的安全手册为IP集成商提供了所有必要的细节，以了解IP块的应用假设和通过其安全机制对各种故障模式的反应，以及是否有足够的时间预算来防止故障转变为故障之前的反应。因此，IP块的端口和软件接口的集成可以帮助做出关于如何对故障做出反应的系统级决策。

安全机制
与安全相关的逻辑需要具有自我监控和检测系统和/或随机硬件故障的安全机制。安全机制需要通过故障的检测、指示和控制来实现或保持安全状态。安全机制的选择在技术安全概念中规定，并取决于故障模式，它有助于定义和实现SoC的任何警告/错误指标和退化策略。虽然一些主动安全机制(如错误纠正码(ECC))可以检测并执行单个错误纠正，但其他安全机制仅执行检测和报告。

与安全相关的IP中的安全机制可以是内部的，也可以是外部的。IP内部的安全机制作为IP区块测试计划中系统验证的一部分进行验证。外部安全机制需要通过模型进行验证，以确保安全元素的预期用途和上下文。

在内部和外部安全机制的情况下，IP提供商需要在安全手册中提供文档，包括内部和/或外部安全机制正在监控什么安全功能，接口是什么，握手协议，定时关系，如何通过诊断点指示SoC，以及任何可编程性考虑因素。

使用假设(AoU)
鉴于大多数IP块都是作为SEooC开发的，因此记录如何在SoC中使用IP以实现安全操作的假设非常重要。这将帮助IP积分器了解各种IP假设，以及这些假设是否有效，是否可以满足。这种兼容性检查最终决定了集成IP块的安全/不安全操作。最终，系统需要得到发生故障的通知，采取适当的行动，并通过将安全状态转换为故障安全状态或故障操作状态来防止故障。

AoU信息在SoC或系统级别进行验证，以确保在IP级别指定的假设是可接受的。IP块假设的文档是SoC安全相关验证活动的关键参考。

可追溯性
知识产权集成商面临的主要挑战之一是确保对安全目标的遵守和相关安全目标的违反可以通过较低层次的功能安全需求细化来解决。这需要以双向的方式进行跟踪，从需求到实现再返回。双向可追溯性需要出现在从需求阶段到生产、交付，直到现场使用的所有阶段。欲知详情，请参阅汽车IP和soc功能安全要求可追溯性的最佳实践白纸。

SoC级别的安全集成
以下部分描述了一些关键的系统级集成需求和策略，这些需求和策略有助于在SoC级进行与安全相关的验证。本节还描述了IP可交付成果如何帮助满足集成需求。

吸收知识产权抵押品
由于许多IP块是作为一个SEooC独立开发的，因此在集成到SoC之前，它们是预先配置的。在此阶段的审查确保IP块的安全功能与SoC的安全功能兼容，并显示不同的IP块如何相互作用以及与SoC的软件相互作用。SoC的功能安全要求是根据每个IP的功能安全要求进行审查的。IP积分器通过影响分析的变更管理活动指出IP中需要变更的任何不兼容性。在SoC集成之前审查的定制IP抵押品如图3所示。

图3:为SoC集成审查量身定制的IP抵押品

安全验证
一旦完成了对各种IP安全文档的审查，各种IP块就会集成到SoC中，以便进行安全验证。系统级安全验证的目标设定在更高的抽象上，以提供证据，证明每个IP正确交互，并符合SoC级的技术和功能安全要求。特定的集成测试确保IP块能够正确地连接，并且不存在任何可能违反顶级安全需求的意外行为。

为了帮助SoC集成，可以帮助SoC活动的一些关键IP交付物如下:

• 测试用例和测试环境:这些环境有助于演示IP块的初始化顺序和刺激，以验证SoC的安全需求
• 故障注入:对于asil C和D, ISO 26262规范强烈建议采用故障注入流程来检查安全性的有效性
• 工具或测试断言应该检查从故障发生到检测的时间跨度，以及是否达到故障检测时间间隔(FDTI)的安全状态
• 假设:SEooC IP文件中的所有假设都应在SoC进行验证。这些假设都记录在可交付的IP安全手册等文件中。
• 硬件-软件集成验证:虽然在模拟级别的验证方法有助于清除硅前阶段的问题，但涉及硬件和软件的硅后验证证明了一个工作。如果IP有一个特定于应用程序的驱动程序需要实现，则硬件-软件接口规范(HSI)和相应的软件实现需要在SoC级别进行测试。

总结
由于汽车IP块是作为上下文安全元素(SEooC)开发的，因此任何有助于SoC集成工作的IP交付物都是至关重要的，可以确保不存在可能违反安全目标的意外行为。一些关键的IP交付是故障模式影响和诊断分析(FMEDA)、安全手册、使用假设(AoU)报告，以及由测试用例、故障注入流程和硬件-软件集成验证分析组成的安全验证文档。汽车安全是一个广泛的话题，还有更多的考虑因素可能没有在这篇文章中涵盖。然而，本文中的关键考虑因素将有助于验证由系统体系结构级别的安全分析产生的已定义的安全措施是否正确实现。它还有助于提供证据，证明集成的系统元素根据顶级安全需求满足其安全需求。

Synopsys提供一系列预先设计、预先验证、可重复使用的汽车IP，这些IP通过了ASIL Ready ISO 26262认证，适用于高级驾驶辅助系统(ADAS)、联网车辆和信息娱乐系统、网关和主流mcu。

点击此处阅读白皮书全文:调整IP和soc之间的汽车安全要求．

Vladimir Litovtchenko是Synopsys功能安全和质量工程的高级经理。