Leo说
大家好！我是Leo。
上一期汽车功能安全开发实践（1）—— 企业间功能安全合作模式DIA与SEooC介绍讨论了企业间的功能安全合作模式以及不同模式的特点，这本质上是属于"功能安全管理（Safety Management）"的话题。很多工程师对“功能安全管理”会有一些先入为主的印象，比如“流程化工作”，“虚”，“没有技术含量”...，甚至连一些功能安全工程师自己都会从某种程度上“轻视”功能安全管理的工作而只关心"功能安全开发（Safety Engineering）"相关的工作。然而，功能安全管理是顺利开展功能安全开发活动并且确保功能安全开发活动有效可靠的关键。功能安全管理工作不到位，功能安全开发活动的质量将大打折扣。
本文将系统化地讨论“功能安全管理”这一话题，目的不是对ISO 26262中的要求照本宣科，而是解释ISO 26262对功能安全管理活动的相关要求的核心诉求，只要抓住了这些核心点并确保在项目中落实，那么功能安全管理就能发挥它的价值。
本文思路
1. 功能安全成功的前提：好的安全文化
2. 好的安全文化的重要体现：完善的流程
3. 功能安全管理的关键活动
3.1 对外的关键活动
3.2 对内的关键活动
文章图片说明
ISO26262是功能安全的国际标准，GB/T 34590是功能安全的中国标准，为方便理解，本文从标准中的截图或引用优先选择GB/T 34590。
1
功能安全成功的前提：好的安全文化
“文化”这个词具有抽象的属性，从某种程度上，“安全文化”这个词可能是造成工程师对功能安全管理“虚”的印象的原因之一。但是当我们抛开对“安全文化”的定义或解释，讨论下面这几个场景时，相信不少读者一定会感同身受，深受其苦。
情况1：项目团队只关心项目进度和成本，压根不关心安全
情况2：为了应付项目释放的要求，到临近项目尾声开始补功能安全文档
情况3：功能安全工程师总是被项目团队遗忘，导致获取的都是“过时”的项目信息
情况4：企业开发流程对角色和责任划分不清晰，工程师遇到问题相互推诿
情况5：刚毕业就被项目委任功能安全经理，但企业却不提供足够的培训…
是不是唤起了读者朋友一些痛苦的回忆？而要避免这些情况的发生，就需要好的安全文化。
下面的表格是ISO 26262列出来的安全文化评估示例，相信大家基于这个表格可以更具象化“安全文化”的内容。
安全文化示例，图片来自GB 34590-2022,第2部分
对于一个企业来说，不应该期望在工程师团队自发地建立好的安全文化。“天下没有免费的午餐”同样适用于企业。如果要建立能支持功能安全的好的安全文化，企业必须投入人力，物力和财力去自上而下建立安全文化，确保在给工程师队伍提供充分的帮助的同时，约束工程师的行为规范。
2
好的安全文化的重要体现：完善的流程
上节提到，好的安全文化的结果是“确保在给工程师队伍提供充分的帮助的同时，约束工程师的行为规范。”其中，给工程师队伍提供充分的帮助包括但不限于建立完善的功能安全流程；把项目经验教训及时导入流程中；为工程师提供必要的培训，并给工程师预留出学习的时间等等。
而约束工程师的行为规范，同样也依赖于完善的功能安全流程。基于完善的流程，明确定义项目团队的角色以及每个角色的责任范围，避免出现“灰色地带“；对没有能够执行角色职责的工程师需要有相应的上升机制甚至是惩罚机制；同时需要确保所有功能安全相关的决策责任是可追溯的等等。
常见的功能安全团队角色设置（做参考）
综上，我们可以看到，完善的流程是好的安全文化的重要体现。
那么如何衡量一个流程的完善性呢？至少需要满足以下要求：
流程覆盖产品的完整生命周期，包括开发阶段，生产阶段，服务与报废阶段。（允许基于实际产品定位进行适当的裁剪）
流程定义角色完整，且各个角色分工明确，沟通渠道清晰。
流程清楚定义了各个开发活动的产物，同时流程需要提供对应产物的模板。
流程需要为工程师提供清晰的指南，明确指导每个开发活动如何展开，做到这一点，既要有企业专家的总结，也要有历史项目中的典型的经验教训的提炼。这一点既是指导工程师高效开展工作的重要保证，也是约束和规范工程师输出物质量的重要保证。
3
功能安全管理的关键活动
在一个完善的流程要求下，功能安全管理的目标非常明确：
对内：确保项目能够及时且高质量地完成企业内部所有功能开发活动并通过审核。
对外：并顺利推进和外部的合作。
在ISO 26262的第2部分及第8部分中包含了大量的功能安全管理相关的要求，这里不照本宣科，而是基于上面提到的功能安全管理的两个目标展开，介绍并解释其中的关键活动。
3.1 功能安全管理对外的关键活动
汽车是众多企业通力合作的产物。OEM - 上游供应商 – 中游供应商 – 下游供应商共同构成了完整复杂的汽车产业链。对功能安全开发而言，这条产业链上如何围绕着功能安全展开合作便成了一个关键性的问题。
ISO 26262将这种企业间的功能安全开发合作称为 “分布式开发，Distributed development” ，并提供了两种分布式开发模式。
Development Interface Agreement (DIA)，开发接口协议
Safety Element out of Context (SEooC)，独立于环境的安全要素的开发
从功能安全合作的质量来讲，这两种开发模式本身没有优劣之分，如何选择仅仅是一个合适与否的问题。如果要简单概括两者的区别，那么基于DIA的分布式开发更适用于具有“动态”属性的项目，客户的需求定制化且随时可能变化，这就要求供应商能快速及时响应；而基于SEooC的分布式开发更适用于具有“静态”属性的项目，供应商提供的产品方案是现成的，客户基于“使用说明书”判断是否合适，合适的话就采购，不合适就找下家，不期望供应商能为特殊需求而做出设计变更，否则这就是“动态”属性的项目，按DIA的分布式开发更合适。
基于DIA的分布式开发
基于DIA的分布式开发常见于OEM与Tier 1之间的合作，比如Tier 1提供整车的某个相关项（智驾系统，转向系统…），也见于Tier 1与Tier 2之间的“定制化”合作，比如某芯片供应商为某ECU涉及特殊的驱动芯片，当然除了这两例外，还有其他合作场景。
如果客户的需求定制化且随时可能变化，那么要想确保合作顺利，必须要在项目开始之初，合作双方就明确合作方式、合作内容、责任划分、变更管理等一系列具体细节并记录在案。从这个角度上看，DIA本质上就是客户与供应商之间的“功能安全开发合同”，它应该是项目合同的一部分，和项目资源安排与报价等活动强相关。
OEM与Tier 1之间就开发接口协议DIA展开功能安全合作示意图
DIA作为 “功能安全开发合同” ，默认由客户提供模板，但这并不唯一，如果供应商有成熟且适用的DIA模板，在客户同意的情况下也可以使用。模板包含了ISO 26262各个章节对功能安全管理与功能安全开发的要求。模板方便记录各个要求下双方的RASIC、递交物形式、递交物内容、双方讨论的记录等关键内容。
在讨论DIA的过程中，客户需要至少给出以下输入：
报价需求（RFQ）
供货范围的定义（供货范围规定了需要供应商提供的相关项或要素的功能、特性和边界）
基于供应商报价对象的安全目标或相关功能安全要求(包含其分配的ASIL等级)
（如果适用）基于供应商报价对象的要素的失效率目标值和诊断覆盖率目标值
供应商需要基于客户的输入来评估项目的复杂度，并围绕DIA模板发起和客户的讨论。讨论通常由客户的功能安全经理与供应商的功能安全经理对接，同时，在双方展开功能安全开发合作的过程中，客户可以对供应商发起功能安全评估。因此，在DIA中应规定供应商功能安全评估活动的计划，而且供应商应向客户提供功能安全评估报告，包括供应商对所开发的要素是否符合来自客户的安全要求的评估，以及所实施的流程是否满足实现功能安全的准则。
基于SEooC的分布式开发
汽车工业为不同的客户和不同的应用开发通用的要素。这些通用的产品是在不同的组织中独立开发出来的。在这种情况下，先做出关于需求以及设计的假定，这些假定包括了通过更高设计层级以及要素外部设计而得到的分配到要素的安全要求。这样开发出来的要素可以当作是独立于环境的安全要素(SEooC)。SEooC是与安全相关的要素，而不是为了一个特定相关项而开发的，这意味着不是在一个特定车辆环境中开发出来的。
基于SEooC开发的要素示意图
ISO 26262，part 10中明确提到：
SEooC可以是系统、系统组合、子系统、软件组件、硬件组件或元器件。SEooC的示例包括系统控制器、ECU、微控制器、执行通信协议的软件或者AUTOSAR软件组件。SEooC不可以是一个相关项，因为相关项总是需要用于批量生产的整车环境。
如果我们回顾上面提到的基于SEooC的分布式开发更适用于具有“静态”属性的项目，就很容易理解为什么ISO 26262如此强调SEooC的对象不可以是一个相关项。因为相关项提供整车层面的驾驶员可感知到的功能，对这些功能不同的客户一定会有不同的要求，“私人定制”不具备“静态”属性，因此不适合SEooC，相反基于DIA的分布式开发更合适。
和家电厂商将冰箱推向市场时附带使用说明书一个道理，基于SEooC开发的要素也需要有“使用说明书”，方便客户来评估该要素是否符合预期的要求，符合要求即可采购。ISO 26262将基于SEooC开发的要素的“使用说明书”称为”Safety Manual, 安全手册”。
SEooC开发背后的假设需要在Safety manual里面记录
因为SEooC是按照ISO 26262基于假设开发的，这对供应商（提供方）和客户（使用方）都提出了要求。
供应商需要有对市场当前需求与未来趋势的准确把握，确保产品面世后在几年内都有市场。
对客户来说，对假设的确认需要在使用该要素的相关项的开发过程中进行确认，以形成预期和实际的闭环。
限于篇幅，此处对DIA和SEooC不做过多细节展开，感兴趣的朋友可跳转至上一期文章：汽车功能安全开发实践（1）—— 企业间功能安全合作模式DIA与SEooC介绍。
3.2 功能安全管理对内的关键活动
考虑到基于DIA的分布式开发能更全面地体现功能安全对内的活动及要求，接下来以这种开发模式为例展开说明，其中的要点同样适用于基于SEooC的分布式开发的对内活动要求。
总的来说，按照项目报价到项目释放的时间轴，功能安全管理对内的活动可以概括如下。
安全影响分析
项目报价阶段，项目经理需要组建项目团队，并基于客户输入的如下信息进行评估，并选择内部的参考项目，参考项目的选择就一个核心原则：最大程度上复用已经量产项目的产出，实现投入最小化。
其中，功能安全经理需要在团队成员的协助下完成在相关项层面执行的影响分析以及执行要素层面的影响分析。识别出的修改对功能安全的影响，这部分将作为功能安全这部分的报价关键输入。
签署DIA
客户与供应商围绕DIA模板发起的讨论。讨论通常由客户的功能安全经理与供应商的功能安全经理对接，但是必须注意的是，ISO 26262的要求涉及范围之广，不是功能安全工程师一个角色就能确定所有合作细节的。因此，双方的功能安全经理作为”协调人”和部分功能安全活动“负责人”，在讨论DIA的过程中应该适时地把项目经理，系统开发团队，软硬件开发团队的成员甚至生产管理负责人员加入进来进行共同商定。
制定安全计划
功能安全经理需要结合项目的时间计划来制定功能安全计划，以跟踪和协调功能安全活动。这个工作需要团队成员的支持和输入。同时，可根据项目的实际情况，对安全计划进行适当的裁剪。
在实际开发中，项目的时间节点有调整是常态，因此功能安全经理需要确保安全计划与项目整体计划同步，这从侧面也体现了功能安全经理必须非常深入地参与到项目中去，而不能游离在项目之外。
执行确认措施
在完成某一阶段的功能安全开发活动后，功能安全经理在适当的时候发起认可措施，以判断产品实现了功能安全。认可措施的执行要求在资源、管理和发布权限上的充分独立性，且包含以下三个维度：
认可评审 (Confirmation Review)
功能安全审核 (Safety Audit)
功能安全评估 (Safety Assessment)
概括来说，认可措施就是在满足独立性要求的前提下，对项目的功能安全开发与管理活动进行三个维度上的检查，确保产品满足了ISO 26262的要求。
完成安全文档
在完成了功能安全开发活动及认可措施活动后，功能安全经理负责安全档案的整理，收录安全生命周期内的工作成果， 为实现功能安全提供论据。值得指出的是，为了支持逐步的功能安全评估，随着工作成果的产生，安全档案可以逐步发布。无论在客户端还是供应商端，都需要确保安全档案及其内容的追溯性，因为这既是功能安全工作成果的证据，也是后续排查问题的关键输入。
