摘要：证明可靠的嵌入式系统满足重要的质量属性，例如符合相关标准，可能具有挑战性。对于新兴且日益复杂的功能，如互联自动驾驶（CAD），还需要确保同时满足功能安全性、网络安全性和可用性等属性。此外，此类系统通常使用现有零件（包括第三方组件）进行设计，这些零件必须包含在质量保证中。本文讨论了如何在考虑这些因素的情况下，在Assurance Case的核心构建论点，并提出了帮助完成这项任务的模式。这些模式被应用于一个汽车功能示例的案例研究中。虽然目标主要是CAD的功能安全和网络安全防护，但它们的通用性使这些模式与一般的多关注点保证相关。
原文作者：Fredrik Warg，Martin Skoglund
原文标题：Argument Patterns for Multi-Concern Assurance of Connected Automated Driving Systems
编译：猿东东，猿西西
在市场上发布嵌入式可靠性关键电气/电子（E/E）系统时，通常需要证明它们足够安全。这通常是通过证明符合功能安全标准来实现的。成功证明产品安全的一个关键设计策略是使系统的安全相关部分尽可能小和简单。虽然这仍然是可取的，但技术发展正无情地朝着更高的复杂性发展，即使是与安全相关的功能。一个例子是自动驾驶系统（ADS），即实现通常所说的自动驾驶或自动驾驶车辆的功能。对于此类功能，很难保持安全相关部件的小型化和隔离化，因为该功能的目标是安全驾驶，这项任务必然涉及车辆的许多传感、控制和执行器子系统。
由于这种复杂性，很难令人信服地证明产品是安全的。另一个复杂因素是，在存在可能影响安全特性的其他质量属性（QA）的情况下，不能孤立地处理安全问题。例如，预计大多数配备ADS的车辆也会连接起来，以提高功能性能，例如，与周围车辆和路边基础设施（交通灯、标志、路边传感器）交换信息的ADS将具有更好的世界模型，能够做出更好、更不具防御性的驾驶决策。然而，增加连接以实现联网自动驾驶（CAD）也会增加安全风险。黑客可能会远程入侵ADS，例如绕过其安全机制。因此，为了证明该功能是安全的，还需要证明所有可能危及安全的安全风险都已得到处理。这延伸到任意许多相互关联的问题，例如，可能有必要考虑功能的可用性，以确保功能安全和网络安全机制不会以使商业案例不可行的方式降低功能的可用度。
车辆E/E功能的安全性通常通过显示符合ISO 26262标准来证明，通过一个由符合其所有规范要求而产生的人工制品组成的安全档案。隐含的论点是，标准一致性本身就是安全性的证明。然而，在标准的总体框架内明确论证产品特定的安全原理可以帮助开发工程师和安全评估员。对于这项工作，我们的前提是，当复杂性增加时，这样的论点甚至更重要——即使标准可能没有强制要求——例如，当同时符合多个标准时，每个标准代表不同的质量保证，也称为多关注点保证，或者当包括第三方供应商在上下文之外开发的组件时。
我们在本文中的贡献是在多关注点Assurance Case的论证中，讨论并提出了同时涵盖以下维度的模式：（1）多关注点，（2）标准一致性，（3）脱离上下文的元素，以及（4）系统生命周期。这种多维论证的一个危险是，它变得难以处理和不可理解，从而无法实现其基本目的，而我们试图用清晰和规则的结构来克服这一点。我们还在一个与CAD相关的案例研究中提出了这样的论点。
在与我们相关的工作中，其他人提出了ISO 26262参数的模式。其中大多数提供了更详细的模式，可以与我们的建议相结合，但在某些情况下，也有一些不同的组织论证的方式。然而，这些只是为了安全。有研究人员讨论并展示了整合功能安全和网络安全的不同方式的模式，这可以通过将这两个问题结合起来，完全分开处理，或者以不同的方式处理相互依赖性来实现。在这项工作中，我们使用田口所说的双向参考过程模式作为多关注点模式，但也将其与我们讨论的其他维度相结合。还完成了关于协同工程以及如何在论证中捕捉关注点之间的权衡的工作。相比之下，我们的工作是构建Assurance Case，以捕获有关相互关注的依赖关系以及其他提到的参数维度的信息，而不是如何处理权衡或协同工程。
在这里，我们详细阐述了考虑第1节中提到的四个维度的含义。当我们关注可靠性方面和标准一致性时，许多功能安全标准中使用的概念V模型用于说明生命周期。在图1中，显示了一个三重V模型，突出了标称功能、功能安全和网络安全方面。虽然一些标准和工作流程更喜欢其他模型，例如更清楚地突出迭代方面，但我们注意到，被解释为依赖链而不是时间线，V模型中表达的概念通常是适用的，即有一个整体功能概念，它被细化为可实现的组件，并在多个集成级别进行测试。当产品的一个版本完成时，重复该过程为下一个版本添加新功能，而当前版本则进入生产和维护阶段。在ISO 26262等功能安全标准中，所有设计和验证步骤的结果都收集在一个安全档案中，每个产品版本的安全档案都必须完整一致。在处理几个问题时，使用了一般术语“Assurance Case”。在本节中，我们将讨论四个维度背后的基本原理，并在下一节中返回模式。
图1：具有功能安全和网络安全属性的V模型以及多关注点Assurance Case
2.1生命周期
由于标准和/或公司特定的工作流程通常规定了特定的开发生命周期，因此在论证中明确生命周期阶段可以更容易地将论证与设计过程联系起来，从而表明在整个生命周期中引入系统故障的风险得到了充分降低。换句话说，在论证中显示生命周期可以降低由于论证和实际开发工作之间的错误映射而导致的误解和遗漏所带来的风险。此外，标准中通常会对产品和流程论证进行区分。过程参数还包括例如与产品没有特别联系的管理实践。在我们的模式中，为了提高清晰度，我们将它们分开。
2.2标准一致性
论证最好还应反映Assurance Case是否符合标准（也称为一致性案例）。我们的模式旨在与许多功能安全标准中使用的V模型兼容。虽然模式为参数创建了一般结构，但必须为特定的质量属性实例化声明，并由更低级的声明和支持证据支持。在许多情况下，这些子要求可以直接来自标准。因此，一致性不是一个单独的模式，而是我们模式中使用的阶段和模块适合与标准需求相结合。使用允许标准要求和论证之间进行合规性映射的工具，例如OpenCert，甚至可以跟踪所有标准要求是否在论证的框架内得到满足。
2.3关注点及其相互作用
如果两个质量属性是独立的，即满足一个属性永远不会影响另一个属性，那么与单独符合关注点相比，多关注点保证的唯一方面是可能的协同作用，以减少保证工作，例如使用相同的测试框架进行联合测试（图1中的共同验证）。然而，关注点之间通常存在潜在的依赖关系、冲突或协同作用，必须在多关注点论证中加以识别和解决。同样，对关注点之间相互作用的分析必须涵盖整个产品生命周期，以确保在任何设计阶段甚至生产后都不会出现冲突。例如，出于安全考虑，可能需要进行空中下载（OTA）更新，以便在产品发布后很长时间内发现的安全漏洞可以得到修复，但这使得有必要确保OTA更新不会危及安全。因此，我们在我们的模式中加入了相互作用的论点。应该指出的是，如果处理了许多依赖问题，相互作用论点可能会变得难以处理，因为可能的组合会随着质量保证数量的增加而迅速增长。基于经验，我们还声称，在关注点之间指定定义良好的交互点（图1中的共同分析）比集成多个关注点的过程更可取。
2.4组件结构
在包括汽车在内的许多领域，构建新功能的最常见方法是集成供应商的零件或重用现有组件。这些必须包含在新功能的Assurance Case中。供应商也可能将同一零件出售给多个客户，甚至在OEM提出任何要求之前对其进行开发。然后，供应商可以使用对其使用的假设，即假设的上下文，为自己构建Assurance Case。在ISO 26262中，这被称为断章取义的安全要素。我们概括了这个概念，并使用了术语元素断章取义（EooC），这可能为多个问题提供了保证。在将EooC集成到完整功能中时，功能和EooC Assurance Case之间必须有一座桥梁，解释为假设环境开发的零件如何在真实环境中满足实际功能的要求。
3.1图案符号
我们使用ISO/IEC 15026-2:2011中定义的论证结构，如图2左侧所示。在本标准中，论证由一个或多个顶层主张组成，子主张、证据和/或假设通过论证详细说明这些基础组件如何支持顶层主张。次级主张必须以同样的方式得到支持；论证可以是任意多个层次，其中证据和假设作为叶子节点。顶级声明的选择必须有理由支持，论点（在任何级别）也必须有理由证明基础组件如何支持（子）声明。该标准对如何表示论点持不可知论态度。在本文中，我们使用GSN符号来展示我们提出的模式，该符号提供了一个说明性的图形表示。图2中右侧显示了与15026-2概念相对应的GSN符号；在GSN中，一个主张被称为目标，一个论点被称为策略，证据被称为解决方案。
图2: ISO/IEC 15026-2:2011论证和相应的GSN符号
除了基本符号外，我们还对GSN进行了一些扩展。模块化扩展有助于管理大型参数的复杂性，允许抽象的扩展用于表达通用参数模式。图3显示了本文中使用的GSN元素。（a）模块用于表示一个单独的子参数，该子参数可以在模块视图中使用，模块视图是GSN中的一个特殊概览图，仅显示这些模块之间的关系，也可以显示一个单独模块中包含的整个参数支持一个目标。（b）当一个目标将在一个尚未指定的模块中得到支持时，使用合同，并用于提供解耦。合约模块本身用于提供一个粘合参数，显示模块中的参数（例如，可以为可重用组件提供）如何实现合约支持的目标。（c）客场进球在本地模块的论证中重复了另一个模块中的进球，以显示不同模块中的目标之间的依赖关系。客场进球还标识了可以找到原始进球的模块。（d）InContextOf箭头以AMASS项目提出的方式使用，表明一个问题中目标的实现取决于另一个问题的目标的实现。（e）选项用于表示满足关系的替代方案，而（f）可选箭头用于可选关系，（g）多箭头表示一对多关系，其基数显示在箭头旁边。目标也可以是（h）无实体的，这意味着它是一个抽象的元素，需要被一个具体的实例所取代。参数中{括号}内的单词是要实例化的标记，例如{Goal}可以实例化为LaneKeepingAssist作为车道保持辅助车辆功能的安全参数中的顶级目标是可接受的安全。（i）未开发是指一个尚未得到充分支持的目标，即需要通过完成其下的论证来开发。目标可以同时是未开发和未具体化的。最后，（j）上下文是基本GSN符号的一部分，用于提供解释所附目标或策略所需的上下文信息。这些概念在GSN社区标准版本2中有更全面的描述。本文其余部分中的所有GSN数据都是使用OpenCert工具生成的。
3.2总体论证结构和生命周期
我们按照图4中的GSN模块视图组织整体论证。最高级别的声明是，系统（或我们在第3.5节中返回的EooC）满足为其定义的所有质量属性。图5显示了图4中最顶层模块的模式；此模式引用了与产品相关的所有QA和相互作用参数的模块。概念阶段是定义初始概念（例如ISO 26262中的项目定义）和进行风险评估（例如ISO 26262中的危害分析和风险评估（HA&RA）以及安全目标定义）的阶段。在概念阶段，每个质量保证以及所有相关质量保证之间的相互作用将有单独的模块，例如功能安全和网络安全不是独立的，因此如果它们是两个定义的质量保证，则应该有一个相互作用模块。其余的论证是按照生命周期组织的，在功能概念阶段每个逻辑元素一个模块，在技术概念/系统设计阶段每个组件一个模块以及每个组件的软件和硬件开发模块。有单独的模块来处理管理和开发后问题，如生产、维护和退役。这些阶段是V型车的典型阶段。抽象级别的数量可能会有所不同，但很容易适应，因为每个级别的基本结构都是相同的。
3.3关注点
对于每个质量属性，在概念阶段发展这种关注的模式如图6所示。该策略是使用指定的生命周期，通常来自标准，并为质量保证提供足够的措施。根据质量保证的不同，子目标是可选的，但论证的典型组成部分是：通过使用分析方法和引入指定要避免的风险的要求来降低风险（在许多标准中，风险降低的水平用完整性水平来量化）；适当的管理、运营和维护（OaM）实践；以及确认措施，例如审查分析结果。
为了降低图6中某个叶子节点的{QA}风险，引入了目标{QA}要求，如图7所示，以确保这些质量属性要求也得到了正确实施。这种模式提供了一种围绕每个QA需求创建基本原理的方法，表明它已经得到了正确的改进、实施和验证。该模式包含将QA需求细化到下一个抽象级别的目标，在该级别上，该模式将对所有细化的需求再次重复。细化目标是可选的，因为它们显然不适用于最低的细化级别，而经过验证的目标适用于（并且是强制性的）所有级别。
3.4互动
根据每种情况下最适合相互作用的方法，可以在每个相互作用模块中的两个或多个QA之间进行相互作用。然而，很明显，所有相关的质量保证组合都被考虑在内。图8所示的模式表明，相互作用的管理实践已经到位，质量保证需求层次结构中发现并引入了质量保证之间的依赖关系。这在图7中显示为需求的客场目标，表明了相互作用的依赖性。与处理QA需求的方式类似，图9中的模式确保这些相互作用的依赖关系也在设计的较低抽象级别中得到细化。
3.5元素脱离上下文
最后一种模式是第2.4节中提到的上下文内特征和上下文外元素之间的粘合剂。如图10所示，这种模式只是将上下文中的QA与EooC的相同QA连接起来，但确定了需要开发一个显示其兼容性的论证。类似的模式（未显示）可用于相互作用，即也有必要确定EooC中涵盖了相关的相互作用依赖关系。任何抽象级别中的组件都可以是EooC，这意味着EooC将包含从该抽象级别向下的参数。
图10：系统/组件与脱离上下文的元素之间的契约模式
作为一个案例研究，我们使用了CAD的定位元素（PE），该元素需要符合功能安全和网络安全标准。PE被设计为脱离上下文（EooC）的元素，因此可用于各种功能。
图11（插图）显示了PE的硬件，其中包含一个卫星导航接收器，该接收器与校正数据结合使用以提高精度。为了完成用例，PE与ADS功能的假设上下文相匹配——高速公路自动驾驶仪，用于提供准确的绝对（即在地图上）位置。图11还显示了自动驾驶模型车的演示环境。
对该功能的详细描述超出了本文的范围；然而，它有功能需求，根据这两个标准对功能安全和网络安全风险进行分析，从而产生安全目标（顶级安全需求）和安保目标。一个功能要求的简化版本是：自动驾驶模式只能在经过ADS车辆认证的道路上激活。ISO 26262 HA&RA为ADC制定了安全目标。与所述要求相关的安全目标是：ADC只能在经过认证的道路上激活。
由于该功能仅设计为在功能需求中给出的参数范围内工作，因此如果在其他任何地方启用，其行为是未定义的，从而导致高伤害风险。对于网络安全，威胁分析和风险评估（TA&RA）用于引出安全目标。一个依赖于上述安全目标的安全目标是：只有在经过认证的道路上才能激活针对欺骗的完整性保护，以实现ADC。
由于篇幅原因，无法显示案例研究的全部论点。然而，图12显示了一些有趣的部分：（a）上述功能安全和网络安全目标之间的依赖关系；（b）将相同的依赖关系细化到功能级别，（c）将ISO 26262的要求与Assurance Case联系起来的示例（HA&RA形成了一个以标准要求结尾的树，该树已自动生成到一个模块中），以及（d）参考功能和定位EooC之间的合同。
在本文中，我们的目标是提出一种结构化的方法来构建复杂可靠性关键系统（如CAD功能）的多关注点Assurance Case的论证，并通过一个例子证明其可行性。我们的主张是，复杂性可以通过一个可追溯的论证结构来管理，每个分支都附有一个基本原理，以跟踪设计背后的推理。通过这种结构，整体设计也可以聚合并包含可重用的组件。该结构遵循每个关注点，在某些交互点具有依赖关系。这种相互作用是可以预测的，因为论证结构也反映了关注点的发展生命周期。
正如我们所建议的那样，当关注点之间的相互作用被计划和限制时，也很有可能保持协同工程的好处，而不需要功能安全和网络安全等不同学科之间高频互动的额外努力。应该指出的是，即使结构化方法使管理大型复杂系统变得更加容易，该方法仍然需要良好的工具支持才能可行，因为参数可能会变得非常大。可追溯性和合规性管理、参数模块的管理以及参数完整性检查的自动化都是工具有用的例子。自动化有很多机会，例如检测尚未开发或实例化的节点，或者没有参考实际证据的解决方案节点。与目标/要求的半形式符号相结合，可以更好地控制结构，并对可能的遗漏进行更多检查，这是增加自动化机会的另一种可能性。一些工具，如OpenCert，已经包含了许多这些功能。我们在论文中没有讨论的另一个问题是如何在实际的开发工作流程中包含保证。例如，如今许多组织正在采用敏捷实践，以允许更频繁的产品更新。这是我们目前正在继续工作中探索的一个问题。
免责声明：文中观点仅供分享交流，文章版权及解释权归原作者及发布单位所有，如涉及版权等问题，请您联系alpha.yuan@houwa-tech.com告知，我们会在第一时间做出处理。
