摘要
如今车辆功能的复杂性要求采用有条理的流程来确保功能安全。过程审计和功能安全评估可确认产品是否符合标准以及是否安全。安全生命周期的一项成果是安全档案，它应 "清晰、全面且有说服力地论证系统具有可接受的安全性"。在本文中，我们提出了一种工作流程，以引入一种符合 ASPICE和 ISO 26262 标准的、基于过程和产品的联合论证方法。该方法由论证模式支持，这些模式涵盖了与相关标准有关的主要论证思路。这些模式与开发过程并行制定，涉及安全论证思路的可视化以及证据的链接。它们具有通用规范，提供模板并涵盖两个论证方面。基于过程的论证涉及工程过程，支持过程审计；而基于产品的论证涉及项目特定成果，即工作产品的内容，支持功能安全评估。通过混合动力汽车动力总成高压电池系统这一汽车用例，证明了该方法的适用性。
一、引言
如今车辆中众多控制单元上实现的联网功能数量正在不断增加。这些异构功能的相互作用导致了高度的复杂性，这需要在开发前、开发过程中以及开发后给予特别关注。从安全角度来看，这些功能必须无故障运行，否则可能导致具有灾难性后果的危险（例如伤害人员或破坏环境）。汽车安全标准 ISO 26262将项目定义为实现特定功能的系统或系统组合，例如汽车电气 / 电子（E/E）系统。ISO 26262 提供了有关功能安全的要求和建议，以处理项目整个生命周期内所需的安全活动，例如对制定的工作产品的可追溯性。必须证明开发过程符合标准，并且按照标准推荐的方法，所实现的产品必须是安全的。安全活动的成果必须记录在大量工作产品中。工作产品被定义为与 ISO 26262 的一项或多项要求相关联的结果。此外，ISO 26262 要求对相关工作产品采取确认措施，由独立机构或组织检查其在形式、内容充分性和完整性方面的正确性。在大多数情况下，成果是诸如 "安全分析"、"安全完整性确定" 或 "可靠性计算" 之类的文件。所有文件共同构成了编制安全档案的证据。
为了论证所有与过程有关的要求都得到满足，需要充分的证据。然而，必须能够清晰地区分证据和产生证据的信息。从这个角度来看，找到一种改进的方法来指明所需证据是有益的。安全要求和证据之间的关系必须通过清晰、全面且有说服力的论证来传达，以强调可追溯性。
包括工程师、评审员和审计员在内的所有利益相关者可能并非都深入熟悉工程过程以及所有生成的工作产品的内容。利益相关者将能够更快地理解论证，从而缩短评审周期、获得简洁的反馈并更好地理解整个产品开发过程。
二、问题陈述
涉及安全关键产品的公司会聘请外部授权机构来认证其在功能安全开发方面的能力（例如功能安全审计和功能安全评估）。安全认证确保特定产品在特定环境中满足特定的安全要求。它需要完整且结构化的证据集合，以表明所开发的系统具有可接受的安全性。
安全论证的作用往往被忽视，因此那些不直接参与工作产品创建的利益相关者（例如评审员）可能难以重现有关所做决策的思路。以易于理解的方式记录决策可避免关键信息的丢失。需要一种伴随过程的论证方法，能够处理这些单个工件之间复杂的联系。为了提出一种能够应对各种复杂系统和过程的通用方法，该方法必须具有结构化、模块化和可扩展性。
针对已识别的问题，我们提出以下解决方案。定义论证模式和匹配指南，并使其伴随开发过程。它们以易于理解的方式突出开发过程与其相关论证之间的关系。应在基于过程和基于产品的论证之间建立清晰的关系，以避免论证思路出现系统性错误。一种能够清晰呈现所有现有关系的结构化方法将易于使用，并节省时间和成本。目标结构符号（GSN）被定义用于构建通用论证。在 ISO 26262 方面，GSN 有助于在证据和安全要求之间建立有效的关系。应制定论证模式以支持相应的工件类型。将基于过程和基于产品的论证结合起来，以编制具有说服力的安全档案。
三、背景和相关工作
A. 汽车功能安全 ------ISO 26262
ISO 26262 是汽车领域安全关键产品开发的基础。它要求有证据表明已建立的过程运行适当。ISO 26262 将 "汽车安全完整性等级"（ASIL）定义为安全关键危险情况的风险分类参数。这是一个重要参数，规定了安全生命周期内所有后续安全活动的最低工作要求。安全生命周期已被定义，但 ISO 26262 假定已满足诸如ASPICE [3] 之类的特殊质量标准。过程的既定质量水平是功能安全活动的基础。ISO 26262 中的要求期望各种确认措施，例如评审（例如安全分析评审）、审计（例如功能安全审计）和评估（功能安全评估）。为了通过这些确认措施，能够随时获取所有必要的论证是有益的。
在 ISO 26262 的背景下，一个非常重要的主题是安全档案的制定。它将安全档案定义为 "用于证明项目的所有要求都得到满足的所有工作产品的汇编。...... 三个主要要素是要求、论证和证据"。论证解释证据和要求（目标）之间的关系。尽管分布式开发在汽车领域普遍存在，但 ISO 26262 并未提供有关安全档案的详细要求。ISO 26262 定义了 "开发接口协议"（DIA），用于阐明原始设备制造商（OEM）和不同供应商（Tier x）之间的关系。如果进行分布式开发，DIA 会将安全档案联系起来。
看看其他领域，安全档案被视为重要内容并受到广泛关注。根据不同的背景，可以定义安全档案的不同阶段。英国 "核监管办公室"定义了核设施生命周期中的 11 个主要阶段。Kell根据军事领域的 "MoD国防标准 00-55"定义了三种软件安全档案。
在本文中，重点关注四个适合汽车安全档案的阶段。在第四节 A 中对它们进行详细解释。
B. 质量管理 ------ ASPICE
ASPICE 是一项质量开发标准，重点在于改进软件密集型系统的开发过程。ASPICE 提供了涵盖整个产品生命周期的过程参考模型。所属的三个过程类别是 "主要生命周期过程"、"组织生命周期过程" 和 "支持生命周期过程"。它们涉及所有过程方面，但功能安全方面仅通过引用相关标准来涵盖。ASPICE 包含评估过程能力的指标。过程质量必须至少达到 "已管理过程" 的能力水平。借助 ISO 26262，将安全和汽车相关要求添加到符合ASPICE 的开发过程中。
C. 流程要素建模的流程线
面向安全的流程线（SoPL）定义了一种方法，该方法提供了导出可重用的符合标准的过程的机会。其目的是增加可重用过程要素的数量。过程要素是特定标准合规活动的表示，包括角色、任务、工作产品、工具和指南。首先分析相关标准，并构建由可重用过程要素组成的符合标准的过程模型。SoPL 能够从公司特定过程中定制出可执行的项目特定过程。"公司特定" 一词表示已定义了一套工具和方法，用于在公司内部执行与质量和安全相关的活动。我们以 SoPL 为工作基础，并通过安全论证方法扩展该方法。
D. 使用 GSN 进行论证建模
GSN是一种可用于记录论证的图形符号。在 GSN 中，论证被定义为一系列相互关联的主张。策略要素用于声明目标和子目标之间联系背后的推理。上下文要素提供额外信息，以支持对特定论证部分的正确理解。解决方案是支持目标的要素，因为它们记录了证据。GSN 要素之间的关系通过不同的链接要素（箭头）以图形方式记录。两种链接要素类型是 "SupportedBy（由...... 支持）" 和 "InContextOf（在...... 背景下）"。前者用带实心箭头的线表示，指示推理或证据关系；后者用带空心箭头的线表示，声明上下文关系。
模块用于隐藏详细结构并简化目标结构，以提供总体视图。模块之间可以使用两种链接类型。此外，如果进行分布式开发，模块提供了集成来自其他来源的论证的机会，并支持 ISO 26262 的 DIA。图 1 显示了一个简单的目标结构用于说明。要素中的尖括号表示元数据，在这种情况下是要素 <名称> 和 < 描述 >。
图 1. 基于 GSN 标准的基本论证要素
E. 相关论证方法
以下论文展示了不同论证方法的精选内容，这些方法研究了安全档案和论证主题。它们以各种方式强调了区分基于过程和基于产品的论证的相关性。
及时生成重点突出的安全档案能够在开发和评估过程中带来相当大的益处，并有助于根据 ISO 26262 确保汽车 E/E 系统的安全。基于过程的论证只是以不同形式呈现标准的隐含论证。还需要进一步的论证，为开发过程中特定于产品的决策提供合理的依据。文献中展示了一种从过程模型生成基于过程的论证的过程论证方法。它减少了认证过程中的成本和时间。文献中对基于过程和基于产品的论证进行了区分，但仅详细考虑了基于产品的论证。它涉及可重用安全档案和模式的构建。
文献的作者提出了一种集成的基于过程和产品的论证。基于过程的论证是基于产品的论证的支持性论证，用于导出安全档案。《安全档案开发手册》提供了航空领域安全档案开发的指南。在本手册中，要求明确区分基于产品和基于过程的论证，因为 "前者关注获得正确的产品，后者关注正确地生产产品。"
四、方法论
所提出的方法论考虑了符合ASPICE 和 ISO 26262 要求的公司特定过程。我们展示了如何基于 SoPL 方法通过集成安全论证建模来增强工程过程。
A. 重要术语的定义
为了区分基于过程和基于产品的论证，我们对工作产品进行如下分类。
i. 用于证明开发过程能力和成熟度的工作产品（例如项目计划）。
ii. 用于表明符合 ISO 26262 的工作产品。此类工件提供证据，证明所定义的过程满足要求的安全方面（例如确认评审报告）。
iii. 用于确保产品安全的工作产品。此类工件提供评估中所需的特定于产品的论证，以表明产品的安全性（例如安全目标）。
在项目生命周期中，每个工作产品都会经历不同的开发阶段。为了确保开发过程中的持续论证，必须考虑工作产品的不同状态。因此，安全档案不应是项目结束时的最终交付成果。为了克服这一限制，我们为汽车安全档案引入四个开发阶段。
-
"初步安全档案" 在系统需求规范的定义和评审之后可用（功能安全概念已存在）。
-
"中间安全档案" 包含初始系统设计和初步验证活动。这种类型的安全档案可能是获得工程原型车在公共道路上行驶许可所必需的（车辆由专业司机驾驶）。
-
"运行前安全档案" 证明所有必要的运行前行动已完成、验证和实施（生产发布的基础）。
-
"运行安全档案" 在投入使用前可用，包括满足系统要求的完整证据（运行中的客户车辆 ------ 现场监控、维护）。
由于安全档案的这种多样性，有必要采用系统的方法对其进行管理。在本文中，我们介绍了这种系统方法，适用于所有四个阶段。我们示例性地重点关注安全档案的第一阶段，即初步安全档案。
B. 连接符合标准的流程和论证
完整的流程考虑了功能安全和过程质量等方面。ISO 26262 规定了流程要求，可将其视为定制的框架。仅基于这一单个标准直接导出开发过程并非建设性的做法。为了实现 E/E 系统，还必须遵守其他特定于产品的标准（例如硬件组件的 EMC 指令、锂离子电池的 IEC 62660 等）。每个供应商公司都确定自己的优先级和工程方式，因此定义自己特定的开发过程。因此，每个过程都需要单独的论证来证明符合标准。
为了便于构建伴随开发过程的论证，使用 GSN 论证模式。直接关系实现了标准（例如 ISO 26262、ASPICE）、过程和论证（在 GSN 中实现）之间的可追溯性。这很重要，因为论证和要求的可追溯性是当前标准中的基本主题。如果论证以系统的方式提供，那么任何利益相关者在特定项目中都易于理解和重用它们。一个很好的例子是现场经验。如果现场出现系统故障累积，汽车制造商需要采取行动。这可能需要工程师理解几代产品之前做出的设计决策。
GSN 论证结构中的证据被建模为解决方案要素，这些要素直接与过程相关。开发项目中解决方案的名称可能与标准中使用的名称不同。因此，指定为符合标准的工作产品是指在过程执行期间创建的成果。特定于产品的工作产品与符合标准的工作产品之间的关系随时都有。
C. 基于流程和产品的论证思路
为了在定义的开发阶段提供功能安全证明，必须涵盖标准（例如 ISO 26262）要求的所有要求。
本节解释两种论证类型之间的区别，即基于过程的论证和基于产品的论证。所提出的方法分别定义每种论证类型，尽管它们在论证思路中保持直接关系。产品开发需要既定的工程过程，并由联合论证支持。
1.基于流程的论证
在基于流程的论证中，论证直接与公司特定过程相关联，这些过程源自ASPICE 过程参考模型以及 ISO 26262 安全生命周期。ASPICE 提供了 ISO 26262 所预设的质量要求。在过程执行期间，为特定问题的应用领域选择最合适的工具和方法。这种选择产生了项目特定过程。基于过程的论证提供论证，以证明所定义的过程满足要求的要求。论证基于所需工作产品的存在，但不基于其内容。可用的工作产品是第四节 A 中定义的类型（i）和（ii）。基于过程的论证方法是在过程开发的同时记录支持过程的论证。ISO 26262 要求进行功能安全审计，以评估过程的实施情况，ASPICE 定义了质量保证策略，以确保过程质量。过程论证包含特定过程任务必须按所述方式执行的原因。GSN 要素（如策略和上下文）用于解释目标拆分的决策原因。过程审计需要有关决策的信息，因此应始终记录这些信息。GSN 符号使用不受限制的表述方式，以区分通用过程并强调需要偏差的论证。
2.基于产品的论证
在通用制定的过程中，特定于产品的决策确定了一个分支点。基于特定于产品要求的决策导致需要不同的安全措施。例如，由于化学和电气问题，电池系统的开发需要对具有不同容量和不同电池数量的电池组采取不同的安全措施。安全措施与管理电池系统的不同软件和硬件相关。此时，过程变得由产品需求驱动。
基于产品的论证基于第四节 A 中定义的类型（iii）的可用工作产品的内容制定。借助这些工作产品，必须能够建立论证，证明所开发的产品根据相关标准是安全的。在项目发布生产之前，必须通过功能安全评估，并且论证的准备方式必须使外部评估员能够理解。关注的重点是提供论证，说明为什么做出特定的与产品相关的技术决策，以及为什么使用特定的方法或工具。
D. 模式 ------ 可重用工件的开发
模式提供模板、指南和形式化方法，用于为先前定义的过程或产品创建目标结构。本文使用关于模式和模板的定义，以及定义的模式的其他结构细节。模式的最相关属性如下：
图 2. 验证活动模板
模式的目标是支持符合标准的安全论证以及先前项目的最佳实践。此外，它应设计为可基于经验教训进行扩展和调整。模式通过提供可适应定制需求的预定义要素来协助用户。该模式不存在于最终论证中。
考虑的重点主要是包含论证链的属性 "模板"。模板是图形表示，即论证结构，包含符号和文本，需要实例化。模板基本上可重用于类似的论证思路。GSN 社区标准提供了两种可在模板中使用的抽象概念，即 "结构性" 抽象和 "实体性" 抽象。结构性抽象支持多重性和可选性概念，而实体性抽象提供 "未实例化（UI）" 和 "未实例化且未开发（UU）" 的概念。GSN 的图形实体被标注为未实例化，并且可能包含在实例化过程中需要替换的、置于花括号中的文本表达式。在模板中，工作产品的合规标准名称可能被用作占位符。实例化则使用项目特定名称。为便于说明，图 2 展示了一个与验证活动相关的非常通用的模板。验证被分为三个活动，这些活动仍处于未实例化和未开发状态。目标底部的方块表示需要进一步完善目标并实例化花括号中的术语。
模板有两种用途。第一个方面与反复实施的决策相关，其论证思路始终相同。在这种情况下，实例化就是添加具体的项目和证据描述。这种用法常见于过程论证（例如，用于论证 HARA 的过程）。第二种用途是当产品的各个方面存在差异时。在这种情况下，所提供的模板必须先实例化，然后才能应用（例如，产品特定参数的变化）。
E. 方法引入的工作流程
为了将所提出的方法引入工程项目，我们定义了以下三个后续阶段，如图 3 所示。
图3.创建基于流程和产品的论点的阶段
**阶段 1：开发流程的初始化。**初始化阶段用于准备设计完整的合规标准开发流程所需的所有流程要素。该阶段的活动包括选择相关标准，以及识别适合重用的现有过程和论证模式。公司特定过程和相应的论证模式是该阶段的成果。
**阶段 2：基于流程论证的定制。**从公司特定流程到项目特定过程的定制意味着选择流程要素以形成项目特定的开发过程。这种选择包括模式提供的相应论证模板，以及项目中应使用的方法和工具。创建项目特定过程涉及依赖于 ASIL 的决策和判断，需要专业知识。功能安全审计需要基于流程的论证。
模板能够为流程开发人员提供支持。它们用于两种不同情况。第一种情况为重复使用的通用过程活动提供论证。也就是说，存在提供流程要求已满足的论证的模板。换句话说，模板无需更改即可纳入安全论证中。项目中的高级目标与公司特定论证非常相似（例如，不同项目中用于 HARA 的过程非常相似）。第二种情况是，由于项目特定的开发过程涉及模板之外的活动，因此必须对模板进行实例化。这可能发生在过程因产品或客户需求而发生变化的情况下。例如，一个项目使用 HAZOP 进行危险识别，而另一个项目则要求使用 FMEA（见第五节 B）。图 4 展示了一个实例化的 HARA 流程模板。
图4.HARA的基于流程的论证（D-Case编辑器）
**阶段 3：基于产品论证的实例化。**该阶段通过执行项目特定流程来涵盖产品开发。基于产品论证的模板支持为已定义产品做出特定于产品的决策。这些决策一旦做出，将应用于整个电池系统产品线。通用模板提供通常适用于电池系统的论证（例如电压或温度等特定物理参数）。通过将模板实例化为产品特定环境，可获得完整的论证结构。功能安全评估需要完整的安全档案，这是详细阐述基于产品论证的主要原因。借助工作产品中记录的结果，能够轻松论证产品特定声明的有效性。这种论证是自下而上进行的，从开发过程的结果开始。此外，快速获取证明产品安全的相关证据也很重要。
五、在用例中的应用
本节描述了三个阶段（见图 3）在具体用例中的应用，其中论证建模在 "D-Case Editor" 工具中实现。
A. 电池系统用例描述
混合动力汽车（HEV）动力总成的一个主要组件是高压（HV）电池系统。当前工作重点是汽车动力总成的 HV 电池系统。
在过去几十年中，最先进的技术不断发展，使得各种具有不同特性的电池 cell 技术得以问世（例如镍氢电池、锂离子电池和锂聚合物电池）。HEV 动力总成电池的一些主要目标是低成本、高功率密度（例如，HEV 的功率密度 > 1200 W/kg，以支持 250kW 的动态驱动扭矩）、极高的循环寿命（例如 > 200,000 次充放电循环）、长使用寿命（例如 > 9 年）以及安全性。安全性至关重要，因为随着电池几何尺寸的减小，功率和能量密度不断提高，这在发生严重故障时可能导致危险影响的增加。
电池系统的主要功能是提供电能、存储 / 充电电能以及进行电气和热管理。基于这些主要功能，可能会出现安全关键故障，例如电池 cell 过热、电池 cell 过充和电池 cell 深度放电。这些故障可能导致以下潜在危害：高压出现、电池 cell 化学物质泄漏、有毒气体排放、火灾和 / 或爆炸。
工业项目合作伙伴 AVL 提供了有关 HV 电池系统工程过程和安全方面的相关数据。在以下部分中，我们展示了应用所提出方法期间的初步实验结果。
B. 电池系统开发工作流程的应用
以下描述了第四节中定义的三个后续阶段的应用。
**阶段 1：电池开发流程的初始化。**该方法应用于开发 HV 电池系统。所考虑的用例必须遵循 ISO 26262 和ASPICE 标准。有关电池系统的公司特定过程已存在。论证模式与过程并行制定。这些模式提供通用论证（例如 HARA）。
**阶段 2：电池开发流程的定制。**定制步骤衍生出电池特定过程和所需的论证。与该过程相关的论证涉及已选择的特定方法（例如用于危险识别的 HAZOP）。目标是提供论证，说明 HARA 如何支持必须实现的目标。图 4 展示了有关 HARA 的论证，从目标 "危害已识别并缓解" 开始。以下列表显示了 ISO 26262 要求的有关 HARA 功能安全审计的四个论证路径：
· HARA 已执行
· 危害已缓解
· HARA 的验证已执行
· HARA 的确认评审已执行
经审计的工程过程已准备好执行，以开发 HV 电池系统。
**阶段 3：电池系统论证的实例化。**图 5 示例性地展示了关于混合动力汽车电池系统过热的基于产品的论证。具体而言，它涉及与在 HARA 中识别出的危害相关的论证。已执行危险和情景分析，已定义危害事件并通过 S/E/C 参数进行分类，且已确定 ASIL 等级。对于 "电池系统过热" 这一危害，在电池系统的所有充电情景中确定为 ASIL C 等级。从该危害中导出了安全目标 "防止电池系统过热"。与该安全目标相关的安全措施定义为 "温度监测"。
图5.基于产品的电池系统论证（D-Case Editor）
在本示例中，安全措施被可视化为与子目标相连的 "策略"。已识别的子目标生成功能安全要求，这些要求支持顶部的安全目标。功能安全要求存储在项目特定文件 "HV_Batt_FSR" 中。该文件链接到符合 ISO 26262 的工作产品 "功能安全概念"。它代表证明所导出要求的实施可防止电池系统过热的产品特定论证。该文件包含功能安全评估的证据。
C. 评估结果
所阐述方法的应用表明，所提出的方法对安全档案的创建有益。评估结果确定了以下益处。
· 论证模式和其中包含的结构与 ISO 26262 和ASPICE 合规过程相辅相成。
· 强调了论证目标与标准要求之间的可追溯性。
· 过程和产品特定论证的分离使该方法易于管理和理解。
· 可重用的模式和模板简化了论证并确保了完整性。
· 精心设计的论证结构降低了审计和评估成本。
· 所提出的方法适用于安全档案的不同阶段（见第四节 A）。
六、结论和未来工作
本文提出了一种创建与开发过程和要求直接相关的论证结构的方法。该形式化方法涉及模式和模板，以便更容易建立完整、易懂的论证思路，并防止信息丢失。已定义了用于引入基于过程和产品论证方法的工作流程。项目特定定制用于创建合规标准的开发过程。工程过程提供的模板实例化产生产品特定的安全论证。所提出工作流程的应用产生了完整且结构化的安全论证，这是安全档案所必需的，并支持功能安全审计和功能安全评估。通过在汽车电池用例中的成功应用，已获得初步经验，以确保符合 ASPICE 和 ISO 26262 标准。
下一步计划评估支持 GSN 建模的工具。与 EMC² 项目的工具供应商合作，将增强现有工具以支持所提出方法的论证部分。从长远来看，打算开发一种能够基于所提出的方法支持过程开发、过程执行和过程论证的工具。另一个目标是扩展该方法，以在联合安全和安保方法中涵盖安保论证。