下载掌阅APP，畅读海量书库
立即打开
功能安全是“流程和技术的结合体”，“流程”是功能安全管理的主要对象。功能安全管理在流程上类似项目管理，也就是要在项目实施环节对相关项的安全属性进行项目管理，以保证功能安全开发的流程符合要求。ISO 26262定义的V模型为功能安全管理提供了流程框架，每个阶段的任务也做了明确规定。功能安全管理是基于该流程框架，对功能安全相关活动进行计划、监督、管理的过程，最终形成各个阶段可管理的工作成果。
本章将从以下方面对功能安全管理相关活动进行介绍。
1）安全管理与其他活动的关系。
2）安全管理涉及的活动及角色。
3）安全计划。
4）安全档案。
5）认可措施的类别和形式。
6）功能安全的验证。
7）生产、运营、服务和报废环节的安全管理。
8）需求管理。
从图1-15的主体内容来看，功能安全管理部分主要涵盖以下活动。
❑创建、培育并维护安全文化。
❑建立组织特定的规则及流程（包括工具、模板、检查清单等）。
❑确保功能安全异常项得到有效传达。
❑经验教训库的建立与传递。
❑对相关人员进行功能安全培训。
❑确定要执行的安全生命周期阶段，分配安全活动和相关职责。
功能安全中有两个重要角色：项目经理和安全经理。标准中对二者的职责及分工要求如下。
1.项目经理
标准原文A project manager shall be appointed at the initiation of a product development concerning the item.
（参考ISO 26262-2:2018，6.4.2.1）
The project manager shall be given the responsibility and the authority，in accordance with 5.4.2.7，to ensure that：
a）the safety activities required to achieve functional safety are performed；and
b）compliance with ISO 26262 is achieved.
（参考ISO 26262-2:2018，6.4.2.2）
解读 从这条要求来看，确保功能安全在项目中落地并不应该是安全经理一个人操心的事，项目经理是整个项目的全权负责人，应提供达成功能安全所需的资源。
标准原文The project manager shall verify that the organization has provided the required resources for the safety activities，in accordance with 5.4.2.5.
（参考ISO 26262-2:2018，6.4.2.3）
The project manager shall ensure that the safety manager is appointed in accordance with 5.4.4.
（参考ISO 26262-2:2018，6.4.2.4）
解读 项目经理在项目中扮演着重要角色。在功能安全项目中，项目经理需要指定一位安全经理负责管理项目的安全相关活动。如果项目经理具备相关能力，可以兼任安全经理的角色，反之亦然。
总结来说，项目经理的职责如下。
❑确保各项安全活动得到执行。
❑实现ISO 26262标准的合规要求。
❑任命安全经理。
2.安全经理
标准原文The safety manager shall be responsible for the planning and coordination of the safety activities in which the organization is involved，in accordance with 5.4.2.7.
（参考ISO 26262-2:2018，6.4.6.1）
The safety manager shall be responsible for maintaining the safety plan，and for monitoring the progress of the safety activities against the safety plan.
（参考ISO 26262-2:2018，6.4.6.2）
The responsibilities with regard to performing the safety activities shall be clearly assigned and communicated within the organization in accordance with 5.4.2.7 and 5.4.4.
NOTE The safety manager is responsible for planning and coordinating the safety activities. Other persons can be responsible to detail the planning(see also 6.4.6.8)or to perform the safety activities(e.g. to plan or perform integration and verification activities and configuration management).
（参考ISO 26262-2:2018，6.4.6.3）
解读 安全经理要负责制订安全计划（静态），将安全相关的活动分配给组织中相应的人员，并根据计划组织、协调资源来实施安全活动（动态）。在任务分配过程中，安全经理应识别相关人员的能力，确认他们具备实施相关安全活动的能力，或者帮助相关人员建立起这种能力。
总结来说，安全经理的职责如下。
❑计划并定期检查项目的功能安全活动。
❑创建和维护安全计划。
❑监督安全计划的进展。
❑组织建立与功能安全相关的输出物。
❑对接客户和供应商的功能安全事项。
❑维护安全档案。
❑向项目经理汇报功能安全活动的进展。
先查看标准中对于安全计划有哪些要求，以下为摘选的标准中关于安全计划的相关要求，详细内容请参考标准对应章节。
标准原文The safety plan shall either be：
a） referenced in the project plan，or
b） included in the project plan，such that the safety activities are distinguishable .
（参见ISO 26262-2:2018，6.4.6.4）
Q：根据上述要求，安全计划和项目计划的区别与联系是什么？
标准原文The safety plan shall define the planning of the activities and procedures for achieving functional safety，including：
a）the implementation of project-independent safety activities in accordance with Clause 5 into project-specific safety management；
b）The safety plan shall be updated incrementally， as a minimum at the beginning of each phase.
（参见ISO 26262-2:2018，6.4.6.5）
从这条要求看，安全相关的活动似乎还是与常规的项目活动有些“独特”的地方。想一想标准中哪些活动是功能安全所独有的？或者说哪些输出物是常规项目管理（如PMBOK）中没有定义但在ISO 26262标准中有要求的？
标准原文In the case of a distributed development，both the customer and the supplier shall define a safety plan regarding the respective safety activities.
（参见ISO 26262-2:2018，6.4.6.10）
解读 不论是否为分布式开发，安全相关项目均需编写安全计划。安全计划用于计划、管理和指导项目安全活动的执行，包括日期、里程碑、任务、可交付物、责任人及所需资源。在实际实施安全管理过程中，安全计划需从“静态”和“动态”两个维度进行。安全活动包括安全生命周期中所有安全相关输出物编写及其验证与确认，包括验证开发接口协议计划、验证活动计划、认可评审计划等。
Q：那么，安全计划需要包含哪些内容，或者说，安全计划要计划些什么呢？
安全计划的详细内容要求参考标准第2部分第6.4.6.5节的内容。概括来说，安全计划包括以下内容。
❑实现功能安全的活动和流程规划。
❑将独立于项目的安全活动纳入项目特定的安全管理。
❑制定安全活动的定义。
❑危险分析与风险评估规划。
❑开发活动规划。
❑开发接口协议（DIA）规划。
❑支持过程规划。
❑验证和确认活动计划。
❑确认审查计划、功能安全审计的启动和功能安全评估的启动。
❑安全档案内容规划。
❑计划相关失效分析和安全分析。
❑对相关项所采用的硬件要素和软件组件的功能安全应用符合性的鉴定计划。
❑对相关项设计、开发流程中所采用的软件工具的功能安全应用符合性的鉴定计划。
接下来将挑选实践过程中大家容易对安全计划产生疑惑的部分内容进行介绍。
安全计划应将不同安全活动分配给对应的角色，并定义其责任。分配的表示方式不限，可以采用图形方式或表格方式，只要活动与人员及其责任能够一一对应即可。
1.图形表示方式
图2-1展示了安全计划中项目团队组织架构的图形表示方式。
图2-1 项目团队组织架构的图形表示方式
2.表格表示方式
表2-1展示了安全计划中项目团队组织架构的表格表示方式。
表2-1 项目团队组织架构表格表示方式
开发接口协议（DIA）是客户与供应商之间签署的一份开发责任框架协议，具有以下特点。
❑描述相关项及其要素在分布式开发过程中的角色分配和对应的责任。
❑适用于各个层级的客户-供应商关系。
❑适用于内部供应商。
❑只有合格的供应商，才能开发安全相关的系统和组件。
❑在签订协议前，客户需对供应商进行评估和审核。
解读 签订DIA其实对供应商在功能安全方面的开发能力起到了间接评估的作用。DIA中定义了功能安全标准全生命周期过程输出物的要求，如果供应商不具备这个能力，那DIA短时间内是签不下来的。所以，功能安全的项目对供应商还是有基本的要求的，至少在组织架构上需要有负责功能安全的岗位，否则很难与客户的功能安全团队顺畅对接。
由于DIA往往是客户提供给供应商进行确认的一份输出物，所以格式通常由客户定义，但这不是绝对的，最终的签署需要双方确认。格式在双方确认过程中可以修改，只要双方认可即可。标准第8部分附录B列举了DIA的格式示例，参见表2-2。目前，比较流行的方式是采用RASIC格式来定义DIA。
表2-2 DIA的格式示例
只要是项目管理就有异常管理，安全管理也不例外。安全异常也需要在日常安全管理中进行监控。但什么样的异常算是安全异常？如何识别安全异常？由谁来识别？
其实这些问题在日常项目管理中也会遇到，只不过ISO 26262标准将这些问题聚焦到了安全这个属性上并按照一定的流程提出来了。所以，所谓的“安全异常管理”，对于项目管理来讲，就是我们常说的问题管理，不要因为标准“换了个马甲”就不知从何下手。
日常项目管理中的风险项和开口项都属于异常，这些异常既有涉及流程层面的，也有涉及技术层面的。对于安全异常，我们需要识别当前的开口问题是否会影响到产品的安全性。这个识别工作可以由问题提出者执行，也可以由功能安全工程师执行，只要具备相应的分析能力即可，但需要明确定义相关责任人。
标准要求组织需定义一个明确的流程，说明组织如何处理安全异常问题。问题的处理最终要形成闭环。图2-2展示了安全异常管理流程。
图2-2 安全异常管理流程
然而，现实情况是，对于安全相关的系统，技术层面的问题有80%以上是安全相关的。因此，安全管理需要融入日常项目管理中，直面问题才能做好安全异常管理。
关于能力管理，标准提出的要求如下。
标准原文The organization shall ensure that the persons involved in the execution of the safety lifecycle have a sufficient level of skills，competence and qualification corresponding to their responsibilities.（参考ISO 26262-2:2018，5.4.4.1）
解读 这条要求提的可谓“天经地义”。进行一款产品的开发，人力资源是第一位的，有人做事才有成事的可能，而事情做得好不好则主要取决于负责人的业务能力。因此，在创建工作分解结构（WBS）的过程中，需要考量对应责任人的能力是否能胜任所分配的任务。如果不能，则在条件允许的情况下选用能胜任的人，或者对相关人员进行能力建设，如标准提到的培训就是能力管理中需用到的手段，培训可以是内部的也可以是外部的。不管怎样，我们得确认功能安全活动的干系人具备实施对应活动的技能、能力及资质。从实践经验来看，实施内部功能安全培训是最经济、高效的方式。
Q：什么是安全档案？安全档案用于做什么？
在回答这个问题之前，我们先来回顾一下标准对安全档案的定义。
标准原文：argument that functional safety is achieved for items or elements，and satisfied by evidence compiled from work products of activities during development.
（参考ISO 26262-1:2018，3.136）
解读 安全档案将作为项目功能安全符合性、满足性评估的证据文件，用于提供清晰、全面且有力的论据，证明系统在特定环境下运行时不存在不合理的风险。前文提到，功能安全是一门结合流程和技术的通用学科，安全档案中的论据也将从流程和技术两个维度来证明相关项目满足标准的安全要求，如产品论据可以是安全机制，流程论据可以是方法指引、审查、认可评审。
图2-3展示了V模型中安全档案在流程和技术两方面的证据。
图2-3 V模型中安全档案内容
关于安全档案标准有哪些要求？我们先来学习标准的内容。
标准原文A safety case shall be developed，in accordance with the safety plan，in order to provide the argument for the achievement of functional safety.
（参考ISO 26262-2:2018，6.4.8.1）
The safety case should progressively compile the work products that are generated during the safety lifecycle to support the safety argument.
（参考ISO 26262-2:2018，6.4.8.2）
标准中关于安全档案的要求总结如下。
❑应根据安全计划进行制定。
❑应逐步根据安全生命周期过程中生成的工作产品进行编辑。
❑独立执行认可评审（通常由另一个部门进行评审），这点隐含在认可措施的表格中，见表2-3。
表2-3 安全档案认可评审要求
Q：根据标准的要求及内容提示，安全档案需要包含哪些信息才算完整呢？或者说，安全档案要体现哪些内容呢？
从上述内容可知，创建安全档案时需要从技术和流程两个维度进行收集论证并结合安全计划中的规划活动。下面列出了一些安全档案的内容模块供参考。
❑认可报告。
❑需求规范。
❑安全分析报告。
❑安全计划、组织结构图、安全规则。
❑HARA报告。
❑开发接口协议。
❑测试计划及评审报告。
❑测试报告和评审报告。
❑评估和审查报告。
❑变更需求，释放备注信息。
在项目实践过程中，编写详尽的安全档案并非易事。这是一项伴随开发和验证阶段持续进行的工作。组织需要在流程上提供有效的配置管理系统或方法，以便更好地收集当前阶段的活动状态证据。这些证据收集需要测试团队、质量团队等的支持。无论是输出物版本的频繁变动，还是人员变动、多变种项目抑或工具系统的变更，这些因素都会影响过程证据的收集。
先来回顾标准中对相关项是否满足功能安全要求评估有哪些认可措施。
标准原文The functional safety of the item and its elements shall be confirmed，based on：
a） confirmation reviews to judge whether the key work products，i.e. those included in Table 1，provide sufficient and convincing evidence of their contribution to the achievement of functional safety，considering the corresponding objectives and requirements of the ISO 26262 series of standards，in accordance with Table 1 and 6.4.10；
b）a functional safety audit to judge the implementation of the processes required for functional safety，in accordance with Table 1 and 6.4.11；
c）a functional safety assessment to judge the achieved functional safety of the item，or the contribution to the achievement of functional safety by the developed elements，in accordance with Table 1 and 6.4.12.
（参考ISO 26262-2:2018，6.4.9.1）
从上述要求可知，标准中提到的认可措施有以下3类。
❑ 认可评审 ：目的是核查关键工作成果是否提供了充分且令人信服的证据，以证明所做的工作对实现功能安全有贡献。
❑ 功能安全审核 ：目的是评估功能安全活动的执行情况。
❑ 功能安全评估 ：目的是判断相关项目是否实现了功能安全，或判断所做的工作（例如要素的开发）对功能安全实现的贡献。
Q：这三种认可措施有什么区别和联系？3种认可措施确认的侧重点是什么？
图2-4展示了这三种认可措施的侧重点。
图2-4 3种认可措施的侧重点
3种认可措施的区别与联系总结如表2-4。
表2-4 3种认可措施的区别与联系总结
Q：从上面信息来看，执行认可措施的人需要什么资质和权限？实际操作过程中该如何保证组织的知识产权？
标准（参见ISO 26262-2:2018，表1）提供了示例来说明对哪些输出物实施哪些认可措施，详见表2-5。
表2-5对输出物实施认可措施要求
（续）
Q：表中的“I”代表什么含义？
认可评审是评估评审工作成果是否满足标准要求的过程，这需要结合相关项的安全目标和安全要求进行评价，因为标准的要求符合性是针对相关项的。
以下是标准中关于认可评审要求的摘录，帮助理解认可评审的具体含义。
标准原文A person responsible to perform the confirmation review shall be appointed ，in accordance with 5.4.4 and 5.4.2.7，for each confirmation review that is included in Table 1 and required by the safety plan. This person shall provide a report that contains a judgement of the achieved contribution to functional safety by the work product.
（参考ISO 26262-2:2018，6.4.10.1）
The confirmation reviews shall be finalized before the release for production .
（参考ISO 26262-2:2018，6.4.10.2）
A confirmation review may be based on performing a judgement of whether the corresponding objectives of the ISO 26262 series of standards are achieved .
（参考ISO 26262-2:2018，6.4.10.3）
解读 从以上标准条款来看，认可评审与常规设计评审其实只是关注点上的区别。标准提到的认可评审关注的是标准要求的符合性，所以要基于标准条款进行认可评审，对于非功能安全项目则不涉及。另外，在形式上，认可评审和常规设计评审也有一些差异。首先，认可评审有明确的独立性要求，当然常规设计评审基本都可以满足，区别在于标准要求要指定人员进行认可评审，这对组织的成熟度其实有要求。成熟度高的组织有专门的审核人员和专家成员实施不同层级的评审，而成熟度低的组织可能就没那么讲究了。
Q：从标准对于认可评审的要求来看，你认为实施认可评审的难点在哪？
标准中对功能安全审核的定义：对已实施过程进行针对过程目标的检查。
Q：标准对功能安全审核的要求有哪些？
下面摘选了标准中对于功能安全审核的部分要求，从中可以窥探功能安全审核这项活动的具体要求及表现形式。
标准原文For items and elements where the highest ASIL of the safety requirements is ASIL（B），C，or D:a functional safety audit shall be carried out in accordance with 6.4.9；and shall be finalized before the release for production.
（参考ISO 26262-2:2018，6.4.11.1）
A person responsible to carry out a functional safety audit shall be appointed in accordance with 5.4.4 and 5.4.2.7.
（参考ISO 26262-2:2018，6.4.11.2）
A functional safety audit may be based on a judgement of whether the process related objectives of the ISO 26262 series of standards are achieved.
（参考ISO 26262-2:2018，6.4.11.3）
解读 任何一项认可措施都需要指定相应的人员去执行，功能安全审核也不例外，需要指定特定人员实施审核。ASIL B及以上的目标才需要实施功能安全审核。功能安全审核工作不是一次性完成的，需要根据安全计划中定义的活动，按阶段执行一次或多次。指定的审核员需要为每一次审核提供相应的报告，该报告应评估功能安全审核要求的实施情况。
Q：既然审核是为了确认流程的符合性，那么像ASPICE这类关于过程评估模型的标准，如果项目通过了ASPICE的某个能力等级（比如Level 2），是否可以证明对应过程域的功能安全相关活动流程是满足标准要求的呢？
上文介绍了功能安全评估的目的是确认项目最终是否达到了安全目标的要求，而这些要求都是要遵循标准来开发的。
标准对于功能安全评估的要求具体概括如下。
❑ 目的 ：评估相关项是否实现功能安全。
❑ 评估流程 ：安全评估员应进行充分的评价，但没有特定的流程要求。
❑ 对安全评估员的要求 ：没有特定的资质或认证要求。
❑ 独立性要求 ：参见表2-6示例。
表2-6 功能安全评估的独立性要求示例
❑ 生命周期中的执行时间 ：逐步进行评估，必须在产品发布前完成。
❑ 评估对象 ：工作成果、流程、安全措施。
❑ 评估结果 ：接受、条件接受（存在开口项，但相关项的功能安全性被认为是明显的）、拒绝。
❑ 输出 ：功能安全评估报告。
Q：我们在前面介绍认可措施时提到了独立性，这里也提到独立性，什么是认可措施的独立性？为什么需要独立性？
首先回顾标准中关于独立性的定义。
标准中对独立性的定义：两个或者多个要素之间不存在导致违背安全要求的相关失效，或者从组织上分隔执行某一活动的各方。
对于认可措施的独立性，它适用于此定义的后半句，即实施认可措施的人员与被实施对象的负责人之间要具有一定的独立性关系。
标准中对于认可措施独立性要求的标记方式参见表2-7。
表2-7 认可措施独立性要求的标记方式
表2-7中各种独立性标记的解释参考如下。
❑——：对于认可措施没有要求和建议。
❑ I0 ：应执行认可措施，但如果执行，应由不同的人员执行。
❑ I1 ：认可措施应由不同人员执行。
❑ I2 ：认可措施应由来自不同团队的人员执行，即不向同一个直接上级汇报。
❑ I3 ：认可措施应由来自不同部门或组织的人员执行，即在管理、资源和发布权限方面独立于负责相关工作成果的部门。
Q：仅实施标准提到的这三项认可措施就能证明相关项满足安全目标的要求吗？或者说，仅凭认可措施就能证明相关项开发过程中的安全要求都落地了吗？
我们先回顾标准中关于验证的相关定义。
标准中对验证的定义：确保开发活动结果满足项目要求和/或技术要求的活动。
标准原文The objective of verification is to ensure that the work products comply with their requirements.
（参考ISO 26262-8:2018，9.1）
从以上标准条款可以看出，验证是为了确保被检查对象符合规定的要求。
验证方式如图2-5所示，包含以下几种。
图2-5 验证方式
❑ 评审 ：根据评审目的，对工作成果进行检查，以实现预期的目标。
❑ 走查 ：为了发现异常，对工作成果进行系统性检查。
❑ 检查 ：依据正式流程对工作成果进行检查，以发现异常。
❑ 测试 ：通过运行相关项或要素，以验证相关项或要素是否满足所定义的要求、探测其异常的过程。
在实际项目实践中，走查和检查实施方法如下。
❑ 仿真 ：使用专门的工具实现设计模型的仿真（例如，原理图仿真、热仿真、结构仿真等），以验证预期的设计模型。
❑ 原型开发 ：基于开发的原型机来验证当前设计模型的符合程度。
❑ 分析 ：通过各种分析手段和方法（例如FMEA、FTA、控制流分析等）来验证当前设计是否满足需求。
Q：走查和检查有什么区别？在实际项目实践中，走查和检查是如何实施的？
第一版ISO 26262标准中对输出物的验证评审及独立性要求进行了总结。我们可以通过比较验证和认可措施所关注的对象和要达成的目的，梳理出两者的关系，如图2-6所示。
图2-6 验证与认可措施的关系
解读 简而言之，验证是基本要求，即使是非功能安全项目也会实施相应的验证活动。而认可措施是针对标准要求实施的认可活动，因此认可措施具有标准的特色。此外，一些验证方法在认可措施中也需要使用，验证的结果可以作为认可措施的输入或基础。
标准中关于需要进行验证的内容概览见表2-8。
表2-8 验证内容概览
解读 认可措施和验证在关注对象和目标上存在一些差异。GB/T 34590：2017的其他部分也要求进行评审，目的是验证相关工作成果是否满足项目要求，以及是否满足与应用案例和失效模式相关的技术要求。
Q：想想在日常工作中，你所在组织使用了哪些验证方法？你们是如何称呼这些验证方法的？
标准要求的量产前后的一些活动如下。
❑制订生产计划。
❑确保生产过程中的功能安全。
❑制订运营、服务及报废计划。
❑确保运营、服务和报废过程中的功能安全。
除去功能安全这个属性，这些活动实际上在质量管理中也需要定义，问题在于如何确保这些活动中涉及的功能安全性。
这里先回顾标准对每项活动的具体要求，然后再确认功能安全该如何体现在这些活动中。
功能安全相关项的生产计划涉及的活动和常规项目类似，唯一的区别在于要关注在生产环节是否有安全相关的要求需要追溯，其他都可以按照质量管理标准对生产的要求进行。下面总结了标准对于功能安全相关项的生产计划涉及的具体活动及要求，详情可参考ISO 26262-7:2018第5.4.1节。
1）应考虑装配指引、公差、标定数据要求、存储、运输和处理条件、授权的配置、以前生产计划的经验教训、人员能力要求。
2）在生产环节，应考虑审查和装配步骤、工具及使用方法、部件标识、文档可追溯性、返工流程。
3）确保正确的配置管理，考虑确保安装了正确的嵌入式软件版本与使用了正确的标定数据。
Q：关于生产计划要求，你在项目实践过程中是如何将需求落实的？
4）生产计划应描述为了实现相关项或要素的功能安全所要求的生产步骤、顺序和方法。下面为参考要求及方法。
❑定义生产工艺流程和指引，例如作业指导书。
❑生产工具和设备。
❑追溯性措施，例如PCB板二维码等。
❑一些专门措施，如使用麦拉片进行绝缘。
❑一些合理的、可预见的生产过程失效，可以通过PFMEA方法识别。例如，某些特殊工序的相关人员容易犯困，可以设计“看门狗”机制等。
5）要求制定控制步骤，确定必要的测试设备和工具，制定测试标准。
6）识别合理的可预见的过程失效，评估其影响并采取预防措施。这条要求需要先识别工艺流程，然后根据工艺流程实施对应的PFMEA方法。
7）发生变更时，应遵循正式的变更管理流程。
样件制造、预生产及生产的相关要求的目的是确保涉及功能安全生产的各个方面都被考虑到，具体如下。
1）在生产释放前，样件（或预生产过程）应与实际产品（或目标生产过程）保持一致，相关要求为：
❑知道目前与目标生产过程之间还有多大差距。
❑评估生产过程能力。
❑评估生产过程中哪些环节仍需要进一步改善。
2）评估生产过程能力包括周期性审核、人员能力鉴定、测试设备监控。
3）避免过程失效。对于将所执行的控制措施文档化，可以通过PFMEA输出对应的控制计划（CP）来实现。
解读 PFMEA和CP是将功能安全属性与生产相连接的两个非常重要的活动。在生产过程中，有些安全特性需要满足，以确保产品在生产端的安全。这些安全特性需要传递到PFMEA中进行分析，然后得到相应的控制措施，这些措施要在CP中体现并文档化输出。
4）在生产释放后，只生产已批准的配置，并按计划控制。
生产相关的要求其实在质量管理体系中也会涉及，可以通过质量管理标准（例如IATF 16949）要求的输出物进行覆盖，如标准中这样一条要求：
标准原文The organization shall have a quality management system that supports achieving functional safety and complies with a quality management standard，such as IATF 16949 in conjunction with ISO 9001，or equivalent.
（参考ISO 26262-2:2018，5.4.5.1）
解读 该要求说明了针对标准第7部分的要求，组织可以通过IATF 16949等相关质量管理标准要求来支持ISO 26262的对应部分要求，体现了两者在某些部分的联系。
Q：那么，安全在生产、运营、服务和报废环节是如何体现的呢？
首先要看有没有安全相关的特殊特性被识别出来，这些特殊特性在生产环节是如何得到保障的。比如激光雷达的光学器件，虽然是非电子电气部件，但其设计公差会直接影响激光雷达的功能和性能，导致输出的点云数据所表征的位置信息不准。那些光学部件的设计公差将被识别为安全关键特性。在产线阶段，我们需要设计相应的措施来验证这些安全关键特性是否得到了实现。典型的措施如进行光学模块的光学校准等。这些要求和措施最终都要形成需求输出。需求是功能安全落地的基础。
ISO 26262-7:2018第5.4.3节对服务与维修的内容描述如下。
1）包括工作步骤、流程、诊断程序和方法。
2）包括维护工具和手段，如程序设定、传感器校准/设置和诊断设备。
3）用于验证安全相关特殊特性的控制步骤的顺序、方法，以及控制准则。
4）进行有关相关项、系统或要素的配置，包括可追溯性措施。注：这包括用来确保车辆下载正确版本软件的维护工具特性（如果在维护中执行这种操作）。
5）包括关闭的相关项或要素的功能关闭及其所引发的车辆的任何变更。
6）针对允许功能关闭和变更的驾驶员信息的描述，例如通知驾驶员某项辅助功能已被关闭。
7）备件的供应。
8）用户手册应对相关项正确使用提供指导说明和警告，如适用，还应提供以下信息。
❑相关功能（例如预期使用、状态信息或用户交互）及其运营模式的描述。
❑在通过告警和降级表明失效时，描述确保可控性所需的维护行为。
❑在通过告警和降级表明失效时，描述所期望的维护活动。
❑关于与第三方产品交互可能导致的已知危害的警告。
❑关于可能导致驾驶员误解或误用的安全相关创新功能。
9）报废说明应描述在拆卸前所采用的措施，以及防止车辆、相关项或要素被拆卸、处理过程中违背安全目标的活动和措施，以保证其安全报废。例如，说明安全气囊的拆除流程，并说明在拆除过程中如何确保维修人员的安全。
10）在运营、服务（维护和维修）以及报废计划中提出的系统、硬件或软件层面的安全要求应被明确界定，并传达给负责开发的人员。
在项目实践过程中，这部分要求可以在类似“用户手册”或“产品说明书”这样的输出物中覆盖。所以，关于这部分要求的落地，首先需要考虑组织是否已经输出了相关的文档，这些文档是否对上述要求进行了说明。在这方面，如何体现安全相关的内容呢？
其实不用想得太复杂，产品使用中的一些风险提示都是安全相关的内容。例如，高压锅的产品说明书中会说明在人工泄压时需要注意什么，以免烫伤。随便翻一翻汽车用户手册，也能看到很多基本的使用说明和安全提示，比如仪表上的指示灯代表什么含义，多久需要进行发动机保养，以及驾驶辅助功能使用时应注意的事项等。
这些使用注意事项的说明其实也可以作为标准中提到的“可合理预见误用”的预防型措施。
大家在做项目的过程中或多或少都能感受到，需求提清楚了，项目开发起来神清气爽。需求提不清楚，项目开发起来一团乱麻。可见，需求不仅得定义好，还得管理好。
功能安全有一条很清晰的需求链条，从整车层面的概念阶段到系统层面的零部件，再到软硬件层面的零部件开发都有对应的开发需求。标准要求这些需求要具备可追溯性。
根据上文描述，安全相关需求的追溯链条为安全目标（Safety Goal，SG）→功能安全概念（Functional Safety Concept，FSC）→技术安全要求（Technical Safety Requirement，TSR）→硬件安全要求（Hardware Safety Requirement，HSR）/软件安全要求（Software Safety Requirement，SSR），如图2-7所示。
图2-7 安全相关需求的追溯链条
图2-7所示的安全相关需求追溯链条，可进一步简化成图2-8。
图2-8 安全相关需求的追溯链条（简化）
Q：单从安全相关需求的追溯链条来看，整个需求链条是自上而下的单向追溯，大家经常听到的双向可追溯性是怎么一回事？
关于这个问题，以下是标准中关于需求管理的描述，看看标准对需求管理有哪些具体要求。
标准原文The functional safety assessor considers if requirements management（see ISO 26262-8:2018，Clause 6），including bidirectional traceability，is adequately implemented.
（参考ISO 26262-2:2018，6.4.12.7，Note 2）
解读 在进行安全评估/审核时，评估师/审核员必然会关注被审组织如何实施需求管理，以及需求是否具有可追溯性，包括双向可追溯性，这贯穿了评估/审核的整个过程。
标准原文To achieve the characteristics of safety requirements listed in 6.4.2.4，safety requirements shall be specified by an appropriate combination of：
a）natural language；
b）methods listed in Table 1.（对应表2-9）
（参考ISO 26262-8:2018，6.4.1）
表2-9 安全需求描述方法
解读 描述需求的方式包括自然语言和非自然语言两种。自然语言是指我们常用的具备一定语法和语义的文字语言。非自然语言则包括表2-9中列出的几种形式。通常，多种描述方式结合使用能使需求更加清晰、易懂。
有时候仅看需求描述可能会比较吃力，但如果能配上对应的图示进行解释，尤其是涉及状态跳转逻辑较复杂的需求，辅以图形化的表示对于理解需求来讲更容易。
标准原文Safety requirements shall be unambiguously identifiable as safety requirements.
（参考ISO 26262-8:2018，6.4.2.1）
解读 安全需求只是项目开发过程中的一小部分。为了便于识别这些需求，建议将安全需求文档单独输出和管理，这也是目前大多数公司的做法，即功能安全由专人进行安全相关活动的管理，然后和项目经理并行管理整个项目。标准并不强制要求将安全需求与常规项目需求分开在不同文档中输出。成熟度较高的组织会将安全需求和非安全需求整合在一份文档中，只要安全需求能够被清晰识别，并满足标准要求即可。
标准原文Safety requirements shall inherit the ASIL from the safety requirements from which they are derived，except if ASIL decomposition is applied in accordance with ISO 26262-9.
Safety requirements shall be allocated to the item or element which implements them.
（参考ISO 26262-8:2018，6.4.2.3）
解读 无论是安全需求还是非安全需求，最终都要将分配到各层级架构中的不同模块（负责实现对应需求的模块）。
标准原文Safety requirements shall have the following characteristics：
a）unambiguous；
b）comprehensible；
c）atomic（singular）；
d）internally consistent；
......
（参考ISO 26262-8:2018，6.4.2.4）
解读 标准中关于需求的属性非常全面。在实践中，大家最关心的需求的两个属性是“颗粒度”和“完整性”。
Q：需求写到什么程度才合适？写成这样可以吗？需求写多少或怎样写才算完整？目前写的这些需求够了吗？
其实，颗粒度的问题没有标准答案。如果非要说有，那标准的说法可以认为是标准答案。在实践过程中，我也是基于架构设计的层次，对需求进行层次化描述的。我个人觉得，需求如果能与架构对应，实现层次化，那就是最佳的表现形式。
如果系统、软件和硬件的详细设计需求看起来都一样，仅从内容上看可能没有错误，但不能很好地展示设计思路，即无法体现出这条需求如何分解出其他需求的思路。
另外，软硬件的需求如果只是系统需求的简单拆分，除非系统需求已经过全面验证且写得非常细致，否则这样的软硬件需求的完整性是有问题的。毕竟，软硬件层级的设计有其自身的一些考量，而且软硬件层级的架构较系统架构也更加细化，需求描述中的主语应对应各自架构里的要素，因此其对应需求的颗粒度理应在系统需求的基础上更加细致且全面。
对于需求完整性这个问题，也是很多人的困扰，怎么确定需求写得够不够？这个问题实际上是一个需要自我验证的问题。在个人实践和培训过程中，我习惯用“ 输入-处理-输出 ”的方式来编写某个功能的需求，并称之为“ 需求编写三板斧 ”。
厘清功能的输入输出关系，结合功能自身目的来编写需求基本能保证其完整性。由于输入和输出可能与其他功能部分重叠，在整体需求完善之后需要进行整理，尤其在任务分工环节进行最终的需求汇总时，也会有一个整理的过程。结合分析、评审等手段对需求的完整性进行验证，经过多层内部/外部审核后，如没有新的需求提出，则可认为当前基线的需求是完整的。
标准原文Safety requirements shall have the following attributes：
❑a unique identification remaining unchanged throughout the safety lifecycle；
❑a status；
❑an ASIL.
（参考ISO 26262-8:2018，6.4.2.5）
解读 需求必须拥有唯一的ID。需求的状态可以有多种表现形式，如Reserved（预留的）、Assumed（假设的）、Draft（草稿）、Reviewed（评审过的）”等。安全需求必须有对应的ASIL等级标识，这是区分安全需求和非安全需求的基本要求。
标准原文The set of safety requirements for an item，an element，which are derived from one or more safety goals shall have the following properties：
❑hierarchical structure；
❑organizational structure according to an appropriate grouping scheme；
❑completeness；
❑external consistency；
❑no duplication of information within any level of the hierarchical structure；
❑maintainability.
（参考ISO 26262-8:2018，6.4.3.1）
解读 需求需要层次化、唯一化、类别化，并保证完整性、外部一致性及可维护性。这些是标准概括性的要求，实现这些特性在实践中并不困难。例如，使用Excel管理和编写需求，在上游需求下紧接着写下游需求，能够体现层次结构并具备可维护性。同样，使用Excel基于功能对需求进行分类编写，如电源管理的需求单独一页，并在ID中带有电源管理的标识。
标准原文Safety requirements shall be traceable with a reference being made to：
❑each source of a safety requirement at the next upper hierarchical level；
❑each derived safety requirement at the next lower hierarchical level，or to its realisation in the design；
❑the verification specification in accordance with 9.4.2.
（参考ISO 26262-8:2018，6.4.3.2）
解读 从上述要求来看，需求的可追溯体现在需求的上下游追溯。注意：第二项关于需求下游追溯中描述的“realisation in the design”，即需求到设计实现层面的追溯，比如需求到架构、需求到图纸、需求到代码都得可追溯。提到这里，上面提到的“bidirectional traceability”（双向可追溯）是不是得到了体现？再看第三项，标准还要求需求和验证规范之间可追溯，即需求到测试用例、测试用例到测试结果之间要可追溯，这也是需求的双向可追溯的体现。另外，可追溯性做好了，需求间的一致性也会得到保障。
图2-9展示了需求与设计、验证之间的双向可追溯关系。
图2-9 需求与设计、验证之间的双向可追溯关系
对表2-10中列出的验证方法适当组合，可验证安全需求是否符合安全要求定义和管理的要求，以及它们是否符合ISO 26262系列标准各部分中关于安全需求验证的具体要求。（参考ISO 26262-8:2018，6.4.3.3）
表2-10 安全需求验证方法
表2-10中提到的走查和检查两种验证方式在2.6.1节中有详细的介绍。这里介绍标准中的另外两种需求验证方式：半形式化验证和形式化验证。
这两种验证方式都可以用可执行的模型来实现，那么在实际过程中如何落实呢？比如，通过搭建仿真模型来验证硬件设计的具体需求。基于模型的测试，如通过MIL测试来验证模型与算法的一致性和正确性，也因此验证了模型开发的需求。使用公式、定理来证明设计的正确性也是一种典型的形式化验证方式，如图2-10所示。这种方式在代码验证中较为常用，通过证明题的方式，验证设计满足相应的公式、定理，从而确保其符合相关需求。
图2-10 形式化验证
标准原文Safety requirements shall be placed under configuration management in accordance with Clause 7 to maintain consistency throughout the safety lifecycle.
（参考ISO 26262-8:2018，6.4.3.4）
解读 需求管理包括变更管理和配置管理，都是为了保证需求在整个生命周期内的一致性。举例来说，从产品A到产品B，功能发生了变更，相应的需求也会随之变化。此时，我们需要将配置同步为变更后的需求的配置。如果后续发布的需求文件仍然是产品A的需求，就会导致产品B需求的不一致，这通常是需求基线管理不当引起的。因此，变更管理和配置管理常常需要联动进行。
以上是标准对需求管理的要求。正如上文所述，个人认为需求编写和创建过程中“颗粒度”和“完整性”是困扰大家的两大问题。如果能“完美地”解决这两个问题，那么需求的其他属性的实现都是水到渠成的。
在上文中我们提到功能安全的需求追溯链条，了解到功能安全管理中很大一部分任务是需求管理，而需求管理的一大任务是建立可追溯性。我们还谈到了双向可追溯性。
需求是产品开发工作的主线，贯穿了产品整个生命周期的各个阶段。因此，在每个阶段明确需求、清晰书写、实现到位并全面验证，能从侧面反映组织具备了一定的成熟度。在这种情况下，整个功能安全管理工作的质量也不会差。
Q：既然需求那么重要，那么需求从哪里来？
需求来源比较广泛，按出处可分为内部和外部。总体而言，产品的开发需求可以从以下几个渠道获取，如图2-11所示。
图2-11 需求来源
1）用户反馈。比如你去4S店试乘试驾时的意见，或者你在网上购物后的评价。
2）用户调研。比如询问希望车辆座椅具备哪些功能，以及车外后视镜的设计期望等问卷调查。
3）数据分析。通过收集相关数据，分析并提取有用信息以形成结论，这个结论将成为新开发需求的一部分。
4）竞品分析。例如，每家车厂的每款车型的对标车型，以特斯拉Model 3为例，通过对标车型进行实车测试（包括驾驶）以获取相关数据，然后开发出差异化的需求。
5）组织内部。例如利用组织既有产品已开发的功能来形成新的需求；利用组织内部其他部门反馈的问题例如运营部门从市场端、客户端收集整理的问题来开发需求；组织头脑风暴产生的问题和点子也可形成需求。
以上关于需求来源的介绍可能是一个较为通用的标准答案，可以作为参考。本节更多探讨的是安全需求的来源问题。
在图2-8中可以了解到安全相关需求的追溯链条为： SG→FSR→TSR→HSR/SSR 。不管是刚接触ISO 26262的人员，还是从事功能安全开发和管理工作多年的老兵们，几乎每天都要与这条安全需求链打交道。你是否思考过该需求链中每种需求是如何得到的呢？
如果答案是这样的：HARA方法得到SG，SG分解得到FSR，FSR分解得到TSR，TSR分解得到HSR/SSR。
这个答案更多是将安全需求链用自然语言描述一遍而已，接触过功能安全的人都知道这一点。只是知道这条需求追溯链，能写出对应的需求吗？
如果没有相关产品的功能安全项目实践经验，仅仅知道需求追溯链是很难写出具有指导意义的安全需求的，更不用说需求的正确性、完整性和可追溯性了。
我认为，安全相关的需求首先应该从功能出发。毕竟，功能安全关注的是防止功能异常或故障后引发不合理的风险，因此，必须先确保功能完善，然后再谈安全。
功能安全要落地，首先需要在各层级的需求链中定义好安全需求。要做到这一点，必须先厘清相关项的功能、设计意图和设计约束，然后基于这些信息进行安全分析，通过分析得出对应的应对措施，再将这些应对措施导出，并经过收集、整理得到安全需求。如果各位在为如何编写需求而烦恼，不妨试试这个方法。这个方法个人称之为“ 需求分析三部曲 ”，如图2-12所示。
图2-12 需求分析三部曲
2.8.1节中提到写需求的两大痛点是“颗粒度”和“完整性”的问题。颗粒度是一个“运用之妙，存乎一心”的问题，你的需求是否具有层次感与其正确性无直接关联，但对感官有很大影响。这需要通过层次化的架构思维进行多思考、多练习来解决，并没有捷径。这里想再讨论一下完整性的问题。
如何保证需求的完整性？前文介绍过“需求编写三板斧”即从“输入-处理-输出”这三个方面来展开需求的编写。这三个方面正好也是构成系统的三要素，这也证明了该方法具备一定的系统性。
❑ 第一板斧 ：输入。为实现当前功能需要什么样的输入信息？对输入信息有什么要求？将这些问题的答案写出来，形成当前功能输入部分的需求。
❑ 第二板斧 ：处理。当前功能本身应该如何使用？如何处理输入信息以达到设计意图或功能目的？需要具备哪些条件来实现这些意图或目的？将这些问题的答案写出来，形成当前功能处理部分的需求。
❑ 第三板斧 ：输出。当前功能对数据、信息处理完后，要把处理后的数据、信息发送给谁？通过什么方式发送？希望接收方有什么反应？将这些问题的答案写出来，形成当前功能输出部分的需求。
其实，这三板斧不仅适用于写需求，在进行一些安全分析时也同样适用。典型的例子如FTA，也可以使用“三板斧”这一招。后面介绍FTA时，会详细讲解FTA中的“三板斧”。
功能安全要落地，安全需求得先落地，安全需求提不清楚，功能安全在项目中落地就无从谈起。前面介绍的“需求分析三部曲”以及“需求编写三板斧”就是编写安全需求的经过实践检验的可落地的方法论，可供参考但并不唯一，各位不妨试试。
项目管理中有个“铁三角”，即“范围-成本-时间”构成的项目管理“铁三角”，如图2-13所示。这个三角需要在一定的质量约束条件下实现平衡，所以也被称为“项目管理的‘不可能三角’”。当然，这个“不可能”是相对的，最终要以是否满足客户需求为考量。
图2-13 项目管理“铁三角”
比如，成本往往是客户非常关心的一项指标。当客户提出“在现有成本上降低50%”这样的要求时，组织是否思考过如何对客户的需求进行重新定义？毕竟，30万元的车能将乘客从A点带到B点，10万元的车同样能实现这个要求。
所以，当客户项目管理的“铁三角”某一角面临挑战时，是否可以从需求分析的角度出发，根据客户的新需求重新定义项目开发需求？
1.客户需求管理现状
按照ISO 26262中V模型的概念，产品需求贯穿了产品的整个生命周期，如何定义这些需求、管理这些需求成为项目管理的重中之重。需求管理对于项目管理而言至关重要，可以毫不夸张地说，它关乎产品最终输出的形态，甚至决定了项目的成败。
对于以上见解，学过项目管理的人可能会有疑问，项目管理的十大管理知识领域中并没有需求管理这一项，既然需求管理如此重要，为什么不在十大管理知识领域之列呢？
其实，需求管理并非不在，而是包含在范围管理中。在定义项目范围时，需要将“客户需求”和“产品需求”定义清楚。这些需求决定了项目的开发边界，即项目范围。
Q：在产品开发过程中，需求的生命周期是怎么样的？谁来定义需求？谁来实施需求？谁来验证需求？谁又来管理需求？
对于未曾涉及有严格流程要求的项目（例如功能安全）的组织，或是没有自己的产品开发和管理流程的组织而言，要清楚回答上述问题是相当困难的。这类组织缺乏需求定义、分析和管理的概念，在项目开发和管理过程中更依赖口头沟通，经常将听到的内容直接作为需求来实施。
项目开发过程中频繁沟通本身没有问题且非常重要，但沟通也是需要进行管理的。如果在涉及产品开发的具体需求时，仅进行口头沟通并直接在开发中实施，而没有任何需求整理及评审等中间环节，这会导致项目“千疮百孔”且频繁返工。因为每个人在表达需求时都会带上自己的理解，经过多次传播后，内容可能就与原始需求存在偏差了。随着项目的进行，有些这样的“偏差”已经实施却未被发现，有些在后续沟通过程中被发现又需要返工修改。如此带着“偏差”在产品开发过程中一路狂奔，最终掉进了深渊——项目失败。
以上问题是很多组织的现状，即没有进行客户需求管理。实施客户需求管理的目的是追溯和确认客户需求，确保组织理解了客户需求和期望。
2.将客户需求转化为产品需求
Q：既然客户需求管理如此重要，那具体管理的是什么？或者说，在产品开发过程中，需求的作用是什么？
在回答这个问题之前，我们不妨先看看产品需求的定义。
项目管理协会（Project Management Institute，PMI）对于产品需求的定义如下。
产品需求是指产品必须具备的功能特性，这一特性通常用于解决客户的特定问题，或为客户带来额外的价值。
可以理解为，需求是一种用需求语言描述的细化要求，产品开发需要满足这些要求。这些需求不仅涵盖客户对于产品开发范围内的具体问题，还可能包括超出客户预期的功能特性，为客户创造额外的价值。
这样看来，产品需求最终还是要聚焦客户需求，以客户需求为导向分解出来的产品需求才是项目成功的关键。
在做好客户需求追溯后，还需对其进行分析，将客户需求转化为产品需求，实现从客户需求到产品需求的追溯。这是需求管理中非常重要的一步。
在现实场景中，项目团队未能充分理解客户的真实想法和意图的情况并不罕见，即未进行客户需求分析，也因此缺少将客户需求转化为产品需求的过程，最终可能导致项目结果与预期相差甚远。
3.需求管理示例
这里分享一下项目管理中经常提到的一个示例——秋千制作过程，以此来延伸理解客户需求在项目管理中是如何一步步被带偏的。
漫画显示客户的需求是这样的：在院子里的树上安一个秋千，供家中3个小孩一起玩耍。
1）客户需求 ：我家有3个小孩，我需要一个能供3个人使用的秋千。它由一根绳子吊在我花园里的树上。
根据客户需求的描述，制作出了图2-14所示的秋千。
2）项目经理/产品经理理解到的客户需求 ：秋千=一块板子+两条绳子，需要在一棵树上安一个秋千，就用一块板子，两侧用绳子吊起来，挂在两根树枝上。于是，基于该分析得到的产品需求制作出了图2-15所示的秋千。
图2-14 客户描述的期望的秋千
图2-15 项目经理理解的客户需求
3）系统工程师收到产品经理的需求后，开始分解系统需求并进行系统架构设计。系统工程师通常具有严谨的工程思维，看到产品经理的需求后会想，图2-15中在两根树枝上挂上秋千怎么能荡起来？除非把树从中截断再支起来，这样才能在秋千上愉快地荡起来——构想之精妙啊！
经过系统工程师对需求描述的进一步“优化”，制作出了图2-16所示的秋千。
4）软件工程师收到系统工程师的需求后开始分解软件需求并编写对应程序。软件工程师将系统需求分解，得到的软件需求是这样的：一块板，两条绳，一棵大树，绳子接在树的中段。经过软件工程师进一步分解需求后，制作出的秋千如图2-17所示。
图2-16 系统工程师设计的秋千
图2-17 软件工程师编码后的秋千
5）测试人员收到开发部门的需求和产品后进行测试。测试人员理解的功能需求是这样的：一根在树末端系有一个圈的绳子。于是，测试人员搭建了图2-18所示的“秋千测试台架”。
6）产品开发完成并量产后，销售人员是这样向客户推销该款秋千产品的：基于人体工学和工程力学的多方面研究，本着让客户满意的宗旨，我们的秋千产品可以让您如同坐在沙发上一样舒适，如图2-19所示。
图2-18 测试人员接收到的功能需求
图2-19 销售人员描述的秋千
7）组织认为，对于这样的小型项目，不写技术过程文档是正常的，也没有必要。只要有需求说明书（如SOR、RFQ）和合同就足够了。因此，实际项目过程中，技术过程文档中对于秋千制作的设计需求并未描述，如图2-20所示。
8）由于缺乏技术过程文档，运维人员只能根据研发人员提供的信息进行理解，最终安装出了图2-21所示的秋千。
图2-20 技术过程文档的状态
图2-21 运维人员安装的秋千
9）在供应商一番生动形象的介绍之后，客户脑海中接收到的秋千模型如图2-22所示。
10）客服接到客户投诉后的解决方法往往简单粗暴：既然这个秋千不好用，那干脆不用，不就解决“烦恼”了吗，如图2-23所示。
11）市场推广必须让人耳目一新，于是有了广告语“暗夜黑+天使白”。市场推广描述的秋千如图2-24所示。
12）客户的真实需求只是一个能给小孩子玩的秋千。
上面秋千制作过程漫画中出现的问题是什么原因造成的？
你可能会说，是组织内部沟通不到位导致各功能小组获得的信息不一致引起的，这个说法没有问题。项目管理的大部分时间确实是在沟通，但关键在于沟通的信息和信息的传递方式。
项目组的各个功能小组首先需要明确各自负责的需求。如果接收到或分解出的需求在上下游或前后之间不一致，必然会导致开发出的产品与客户需求不符。
此外，将客户需求转化为产品需求的过程，其实就是对客户需求进行分析并逐层分解，同时建立相关过程文档的过程。
图2-22 客户想象的秋千
图2-23 客户投拆后客服的方法
图2-24 市场推广描述的秋千
解读 要确定项目范围，必须进行需求分析，明确符合客户需求的项目开发要求。在有具体客户的情况下，需求分析关注的是客户真正需要什么，而不是自行假设或认为客户需要什么或者能够为客户提供什么。不然就成了闭门造车，最终造出来的“车”客户也不会买账。
因此，我们在需求分析时应以客户需求为导向，分解出完整、准确、清晰、具体的需求，并对这些需求进行管理。这对项目的成功至关重要。如果需求分析不充分，势必会导致需求的不断变更，从而影响进度、成本及产品质量，甚至导致项目失败。
那么，你们的组织有进行需求分析吗？分析得到的需求有进行需求管理吗？在进行需求管理时是否解决了以下问题：
1）需求都清楚了吗？
2）需求都实现了吗？
3）需求都验证了吗？
2.8.2和2.8.3节中多次提到安全需求的追溯链，概念层面有FSR，系统层面有TSR，软硬件层面有HSR、SSR，又可从1.3.5节中了解到，这几个层面对应的输出物有FSC、TSC、HSR、SSR。这时很多细心的朋友的问题来了：
1）输出物中怎么没有看到FSR和TSR？
2）FSR和FSC是什么关系？TSR和TSC是什么关系？
3）TSC和相关项的常规系统需求及设计是什么关系？是否可以合并在一起写？
4）为什么软硬件层面的安全需求是HSR、SSR？为什么不叫HSC、SSC呢？这样看起来不是更顺理成章吗？
关于上述问题，先回顾标准对于FSR、FSC、TSR、TSC这些术语的定义。
标准中对FSR的定义：独立于具体实现方式的安全行为，或独立于具体实现方式的安全措施，包括安全相关的属性。
标准中对FSC的定义：为了实现安全目标，定义功能安全要求及相关信息，并将要求分配到架构中的要素上，以及定义要素之间的必要交互。
解读 FSR定义了在概念层面的需求，这一层面主要从整车层级的角度来确定相关项的功能，而不关注其具体实现方式，更多涉及的是一些功能性、逻辑性的描述，如定义中的安全行为和安全措施，简单而言，就是偏向于整车层级的安全需求。而FSC从定义上看，包含了FSR，还定义了不同FSR之间的交互关系、需求的描述性和解释性信息，以及FSR如何分配到架构中的要素。这样，FSC使FSR的信息更加完整，将需求和架构的关系进行对应，使其在概念层面具有实施的指导性。
图2-25展示了FSR与FSC之间的关系。
图2-25 FSR与FSC之间的关系
再看TSR和TSC在标准中是如何定义的。
标准原文technical safety requirement:requirement derived for implementation of associated functional safety requirements.
（参考ISO 26262-1:2018，3.168）
标准原文technical safety concept:specification of the technical safety requirements and their allocation to system elements with associated information providing a rationale for functional safety at the system level.
（参考ISO 26262-1:2018，3.167）
解读 这里的定义与FSR和FSC的定义类似，只不过TSR是从FSR分解出来的，用于相关项在系统层面的安全设计和实现相关的需求。TSC不仅包含这些需求，还定义了这些需求之间的关系，以及这些需求在系统层面的系统架构中的分配方式。因此，TSR是TSC的一个组成部分，TSC为如何通过TSR实现系统的安全设计提供了技术指导。
通过上述提示，大家对于第一个和第二个问题是否已经有了一些自己的答案？
因此，概念层面和系统层面的输出物并非不包含FSR和TSR。事实上，这两者都包含在FSC和TSC中，而且通常是先对FSR和TSR进行分析整理，然后作为FSC和TSC的一部分在对应层面进行输出。
既然TSR、TSC也是用于系统层面的设计，那它和常规的设计有什么不一样？能不能只输出一份系统设计就可以了？
这个问题不仅与技术层面的概念相关，还与公司的组织架构及开发流程有关。
这里我们先从技术层面来看几者之间的关系。
巧的是，标准对TSC、TSR、系统架构设计的基本概念做了解释，具体如下。
标准原文The technical safety concept is an aggregation of the technical safety requirements and the corresponding system architectural design that provides rationale as to why the system architectural design is suitable to fulfil safety requirements resulting from activities described in ISO 26262-3（with consideration of non-safety requirements）and design constraints.
（参考ISO 26262-4:2018，6.2）
The technical safety requirements specify the technical implementation of the functional safety requirements at their respective hierarchical level；considering both the item definition and the system architectural design，and addressing the detection of latent failures，fault avoidance，safety integrity and operation and service aspects.
（参考ISO 26262-4:2018，6.2）
The system architectural design is the selected system-level solution that is implemented by a technical system. The system architectural design aims to fulfil both ，the allocated technical safety requirements and the non-safety requirements.
（参考ISO 26262-4:2018，6.2）
根据以上描述，TSC、TSR与系统架构设计三者的关系如图2-26所示。
图2-26 TSC、TSR与系统架构设计三者的关系
解读 从上述标准的基本概念可以看出TSR与TSC之间的关系，但看完系统架构设计的概念描述后，大家可能对几者的关系有些疑惑。从描述可知，系统架构设计是一种系统级的设计方案，既要考虑安全需求，也要考虑非安全需求，这个概念本身没有问题，大家可能疑惑的是既然系统架构设计要考虑安全和非安全的需求，那项目实践过程中，TSC和系统架构设计中的架构是使用同一张图还是分开使用不同的图？另外，既然系统架构设计考虑了安全需求和非安全需求，那么系统需求规范中的需求是否也要考虑安全和非安全的系统需求？如果是这样，为什么还要单独花精力输出什么TSR和TSC？在传统的开发流程中，系统层面的输出物（如系统设计规范/描述，或是分开的系统需求规范、系统架构设计）不就已经足够了吗？
这里先从技术操作层面思考这几个问题。
在2.8.2节中关于需求来源的介绍中提到，安全需求要具备可追溯性。安全需求并非凭空想象或随意决定的，而是需要经过系统性的安全分析。这些分析是在基本设计（即非安全需求设计）的基础上实施的。这个过程也是标准中提到的对设计进行验证的方式之一。
因此，传统的系统需求和系统架构并未能够体现安全的相关概念，而TSR和TSC则是基于标准要求针对安全提出的需求和架构设计方案。这些方案是在对基本设计进行验证后得出的，并为了更好地满足需求追溯性的要求，对需求进行了单独的输出和管理，这也是标准推荐的方式。
有了TSR和TSC之后，将其分别融入系统需求规范和系统架构设计里，这样在系统层面照常管理传统的输出物就行了吗？
这个问题从流程角度来看是可行的，只要能满足安全需求的可追溯性及标准的其他要求。如果有的公司在组织架构上没有单独的功能安全负责人员，而是由负责系统的人员兼顾，且其开发流程在系统设计阶段只定义了系统需求规范和系统架构设计两份输出物，只要这些输出物能覆盖安全相关的要求，那也是没问题的。
因此，理论上可以将安全需求和非安全需求相关输出物的合并输出，只要你的组织在流程和技术上能够满足标准要求。然而，实际操作的可行性取决于你所在组织的成熟度。
现在来看最后一个问题。
为什么在软硬件层面的设计端，安全相关的输出只有HSR和SSR？为什么不像在概念和系统层面那样，也有HSC和SSC？
能提出这个问题的人，不得不说具备较强的独立思考能力和找规律的能力，因为绝大多数人在阅读标准的过程中并不愿意给自己“找麻烦”。大众的思维通常是：既然标准已经这么规定了，为什么还要纠结呢？
对于这个问题，我想谈谈我的观点。标准没有定义并不代表你不可以定义，只要在满足标准要求的基础上能够自圆其说，这也是可以的。
另外，标准没有定义HSC和SSC这样的输出物，笔者认为有以下几点考虑。
1）概念具有一定的抽象性。像FSC和TSC分别是整车层级和零部件层级的输出物，在其对应层级都具有一定的抽象性。而到了软硬件层级，要求要与具体的软硬件实现对应，这时要求相关的需求和架构设计要有具体的可实现性描述。
2）标准没有定义这样的输出物并不代表实际过程中不需要有对应的输出物，比如软件有软件架构设计和软件详细/单元设计、硬件有硬件架构设计和硬件详细设计。同样地，HSR和SSR也需要分别分配到硬件架构设计和软件架构设计当中，这与FSR和FSC、TSR和TSC是有相通之处的。
综上所述，对于本节的几个问题，标准实际上提供了自己的答案，但这些答案可以理解为推荐性质的。关于安全和非安全相关需求能否使用同一份输出物，软硬件层面能否定义HSC、SSC这样的输出物等问题，理论上的答案是“可以”。这取决于组织的成熟度、公司的组织架构以及组织开发流程。只要能够满足标准的要求，如何输出、如何定义都是组织自己的事。
本章聚焦于功能安全管理中涉及的一些典型安全活动和概念，介绍了功能安全项目组织架构与传统项目组织架构的不同之处，功能安全计划与传统项目计划的区别，功能安全中的认可措施与传统项目管理的评审的异同，功能安全在生产、运营、服务和报废阶段的要求与质量管理的要求的异同，以及需求管理在功能安全管理中的意义。相信通过本章的学习，你会在传统项目管理中如何融合功能安全的活动进行功能安全管理找到一些有价值的思路。