半导体ISO26262功能安全合规性开发的3P法则(下)

发布于:2023-01-13 ⋅ 阅读:(804) ⋅ 点赞:(0)

半导体的ISO 26262功能安全合规性开发3P法则(上)中,我们提到,每个向汽车半导体市场提供产品的组织都必须能够证明开发活动符合标准。这些文档涵盖了相关的人员、开发的流程以及所需的产品分析。本篇,我们将具体陈述如何让人,流程,产品符合要求。

一、人员

半导体IP实现ISO 26262合规性的第一步是培训参与IP开发的人员。许多公司采用培训一小群人的“捷径”,通常是ISO 26262要求的功能安全经理(FSM)和少数“安全工程师”。

但是,这可能不足以符合ISO 26262的精神,因为ISO 26262第2部分“功能安全管理”,特别是第5.4.2条“安全文化”和第5.4.3条“能力管理”的要求。建设确保团队成员具备与其职责相对应的足够技术、能力和资格的可持续安全文化,需要在整个组织中广泛了解功能安全知识,这需要大量的员工培训。

1.1 针对个人的ISO 26262培训和认证

培训不仅涉及工程师,还需要包括组织内参与产品开发和支持的其他人员。这可能包括高管、营销人员、工程人员、文档团队、质量保证经理、应用工程师等。组织指定训练有素的功能安全经理(FSM),其任务是在所有参与产品开发的人员中推广强大的安全文化,并且FSM通常负责为所有这些员工组织内部或第三方培训。半导体IP的客户(在ISO 26262中称为“集成商”)以及第三方ISO 26262审核员通常需要员工功能安全培训证明。

作为实际实施的一个例子,数百名工程师已经接受了牛喀学城的培训并获得了ISO 26262功能安全工程师的认证,我们也是TUV官方授权的ISO 26262咨询认证机构。拥有经验丰富的安全专家,不仅开展ISO 26262培训,而且帮助企业建立功能安全流程,来促进安全实施,从而确保整个汽车电子系统乃至半导体IP开发流程的质量。

二、流程

使用良好的流程对于避免系统性失效至关重要。系统性失效可预测的方式与特定原因相关联,并且只能通过改变系统的设计、制造、操作程序、文档或其他相关因素来消除。简而言之,系统性失效被“设计到”系统中。质量流程有助于避免将失效设计到系统中。

因为我们是工程师,所以对ISO 26262流程的大部分关注都集中在使用技术和软件工具来解决名为“支持流程”的ISO 26262第8部分的细节上。这是错误的做法。

良好的安全过程或任何产品开发过程的关键不是专家使用和集成用于需求管理、变更管理、验证以及其他部分流程的工具,而是由所有员工持续使用质量管理系统(QMS)。

2.1 质量管理体系(QMS)

任何满足ISO 26262第8部分质量管理体系要求的过程都可以被ISO 26262接受。但是,现有的软件、硬件和汽车系统开发QMS已经是最先进的,可以成为供应商流程的基础。

下面的表2提供了一些示例:

表2:符合ISO 26262的质量管理体系(QMS)示例

第三方评估公司为每个质量管理体系提供认证。然而,作为汽车供应链中的供应商,您的客户将对您的流程进行独立审核,无论您是否获得了第三方流程认证。尽管第三方流程认证随附的报告可以帮助您的客户评估您的流程,但您的客户仍有义务确认您是否符合ISO 26262。

2.2 可追溯性

尽管选择、使用和管理相关的质量管理体系与流程相关的最重要的工作,但在可追溯性领域,技术和工具特别有助于实现ISO 26262合规性。

在芯片设计领域,大多数设计团队已经拥有最先进的系统,可以通过实施跟踪规范项目,然后进行验证测试。但是,ISO 26262要求从概念阶段(ISO 26262第3部分)到生产和运营(ISO 26262第7部分)对安全相关要求及其实施进行双向可追溯性。这意味着质量保证(QA)测试结果可以通过其验证测试、实施、规范和要求来反向追溯。此外,配置、变更和文档需要保持最新,成为可追溯性信息链的一部分。

这种级别的可追溯性对于尚未开发出服务于汽车市场的产品的半导体设计团队来说通常是新事物。这些团队很难改变过去运行良好的规范实施和验证系统,采用支持更广泛可追溯性的新系统。一种解决方案是实施一个集成并“围绕”现有开发系统的方案,以提供所需的可追溯性级别。

例如,如果一直使用Jira问题跟踪工具作为半导体IP和相关IP可配置软件的产品开发规范-实施-验证流程的核心。过去,基于MicrosoftWord的市场需求文档(MRD)、产品需求文档(PRD)和规范中的项目被用作Jira系统的输入,并与工程开发任务相关联,在这些任务中跟踪其状态并自动进行验证测试生成并记录。

图4 自动追溯工具提供了向前和向后追溯的手段,同时帮助进行变更管理

今天,由于需要满足ISO 26262更完整的可追溯性要求,可以使用JamaSoftware的系统执行需求输入和跟踪,该系统链接到现有Jira系统中的项目和活动。Jira和Jama相结合的系统帮助团队维护需求、规范项目、实施、验证和QA之间的联系,同时还解决了变更管理可追溯性和文档自动化问题。

ISO 26262流程的底线:大多数瞄准汽车市场的公司必须做到以下几点:

1. 选择一个符合ISO 26262标准的质量管理体系,使用它,并能够向第三方审核员和客户的审核员解释您对它的使用。

2. 实施更广泛级别的自动化可追溯性,涵盖从质量保证、交付和支持的所有需求。

三、产品

在这一点上,我们可以清楚地表明,如果供应商声称其产品“符合ISO 26262的安全要求”而没有提前培训其员工并记录其流程,那么它就不符合要求。一旦人员接受培训,质量流程到位并被使用,下一步就是根据ISO 26262分析产品,并向半导体集成商提供分析文档。对于半导体和半导体IP供应商而言,执行此分析需要记录一组预先设定的假设,因为芯片或IP供应商不会完全了解它将来要成为其中一部分的目标系统。

3.1 汽车芯片和IP:SEooC、AoU和ASIL裁剪

简而言之,这是一个问题:ISO 26262分析的前提是假设存在正在开发和分析的“系统”,ISO 26262的第1部分将系统定义为“一组至少包含传感器、控制器和执行器相互连接的单元。”显然,芯片和用于制造它的IP不是符合ISO 26262的系统。那么,它们是什么?

芯片及其IP成分通常被开发为(通常在设计时未知)系统的“元素”。由于并非100%了解它们最终将成为其中一部分的完整系统的知识,因此芯片和IP在ISO 26262中被归类为特殊类型的元素,特别是“脱离上下文的安全元素”或“SEooC”。对SEooC的分析需要IP提供商或集成商记录使用假设(AoU),以反映IP集成商/用户要使用的预期安全概念、安全要求和安全机制。

其他关于ISO 26262的哪些部分和条款与IP元素的实施和分析相关的假设,记录在称为“裁剪”的流程中。此外,基于对终端系统的特性和安全目标的假设以及IP的经过验证的硬件指标(见下文FMEDA),执行“ASIL裁剪”来确定哪些配置可以满足ASIL QM、A、B,C或D要求。

由于关于SEooC、AoU以及芯片和IP定制的假设太多,ISO 26262要求IP供应商和芯片集成商就开发接口协议(DIA)达成一致,明确双方使用的假设和责任。这份DIA文档将解释IP供应商的ASIL裁剪及其背后的原因,以及对所有使用假设的解释。

3.2 元件功能、失效模式和安全机制

产品中的功能安全机制用于检测、缓解和纠正系统运行时由随机错误引起的失效和故障。单事件效应(SEE)——由宇宙射线引起的电干扰以及它们与半导体相互作用时发出的电离能——是随机错误的原因。这些随机错误可能具有瞬时(临时)或永久影响。随机瞬态效应(也称为“软错误”)的示例包括单个位翻转(SBU),例如存储单元或逻辑触发器中的“位翻转”,以及单事件瞬态(SET),它们是电压毛刺,可能或者可能不会导致错误。在某些情况下,这些可能会同时发生,从而导致多位翻转(MBU)。由SEE引起的导致永久性损坏的“硬错误”包括单事件闩锁(SEL)、单事件烧毁(SEB)和单事件门破裂(SEGR)。

图5 单事件效应(SEE)错误层次图

由于这些错误的原因是自然物理现象并且它们会随机发生,因此检测和减轻它们的影响以实现和维护系统安全非常重要。为此,工程团队在其产品中开发特定于安全的技术功能。以下是这些功能的示例,也称为功能安全机制:

(1)添加和检查添加到片上通信流量的奇偶校验位或ECC位

(2)—重复逻辑和比较结果

(3)三重模式冗余(TMR)或多数表决

(4)通讯超时

(5)验证操作正确性的硬件检查器

(6)安全控制器从整个系统收集错误消息,理解它们,并与系统更高层进行通信

(7)针对所有功能安全机制的内置自检(BIST)

图6 失效模式影响和诊断分析(FMEDA)包括使用故障注入对BIST等安全机制进行分析

既然我们已经描述了分析IP和芯片所需的假设,以及它们的失效模式和安全机制,我们现在将讨论实际的分析过程。

3.3 首先是定性分析(FMEA),然后是定量分析(FMEDA)

一旦设计团队了解了其元素功能、失效模式和功能安全机制,就可以执行并记录定性安全分析,称为失效模式影响和分析(FMEA)。FMEA是一种循序渐进的方法,用于识别设计中所有可能的失效方式(失效模式)以及这些失效的后果(影响)。设计团队往往没有足够重视对其项目的定性分析,而是直接跳入定量分析。这是个错误!首先,正确执行FMEA是正确定义如何减轻故障的关键,也是后期用于验证FMEA的定量分析的基础。

完成FMEA后,设计团队必须使用定量分析进一步分析要素、失效模式和安全机制,称为失效模式影响诊断分析(FMEDA)。尽管可以估计关于大多数功能安全机制的诊断覆盖率(即“保护”)的假设,但大多数半导体集成商坚持要求IP提供商使用故障注入技术来验证项目中实施的功能安全措施的诊断覆盖率。需要详细了解IP实现,以确定必须在哪里注入故障以触发功能安全机制,以及应该在哪里最有效地观察机制的输出。此外,复杂的时钟方案和其他行为可以掩盖可能影响安全或显示为“安全失效”的失效,具体取决于使用场景。

尽管故障注入分析对于验证FMEA很重要,但仅靠它对于FMEDA来说是不够的。其他技术一起用于验证无法使用故障注入轻松演示的诊断覆盖率。一个示例是验证使用假设,该假设定义了客户必须与元素一起集成的安全机制。这对于驻留在IP块之外的安全机制(例如时钟和电压监视器)来说是很常见的。除了故障注入之外,还可用于验证FMEA的其他技术包括故障树分析(FTA)、相关故障分析(DFA)和引脚级FMEA。可以使用这些技术的组合来验证其互连IP的定性FMEA,并将此分析作为FMEDA报告的一部分提供给集成商。

由IP开发团队创建的FMEDA报告允许训练有素的安全经理审查有关符合ISO 26262的所有信息。IP提供商或半导体集成商聘请的第三方评估公司或咨询公司也可以审查分析和开发过程,以帮助评估功能安全符合性。

四、结论

符合ISO 26262功能安全标准是一个困难而艰巨的过程,涉及供应商的人员、流程和产品。创造满足这些需求的产品和技术需要关注运营和工程、安全文化、管理承诺以及大量的时间和资金投入。如果供应商提供此类产品,则由集成商确定供应商是否已采取超出产品级别的所有步骤,确认声明是否有效。未能进行进一步调查会使集成商面临无法经受其上游客户评估和审核的风险。

使用开发人员、流程和分析信息不完整的安全相关产品的项目,可能会使进入汽车电子市场的努力功亏一篑。电子系统集成商必须向汽车制造商提供证据,证明系统的所有组件都经过了全面评估,以佐证其安全可靠的说法。未能理解和遵守标准,以及未能就如何遵守标准进行沟通,可能会给供应商带来额外工作或返工。

关注牛喀网,学习更多实践技术


网站公告

今日签到

点亮在社区的每一天
去签到