2020年，机器学习组件的安全性分析及管理的基本步骤与框架的论述

2020年，由作者持有All rights reserv ed.1机器学习组件科林·史密斯橡树岭国家实验室橡树岭，田纳西smithca@ornl.govEwen Denney和Ganesh PaiKBR/ NASA艾姆斯研究中心，加利福尼亚州{ewen.denney，ganesh.pai} @nasa.gov摘要在开发和部署具有嵌入式学习功能组件（LEC）的安全 系 统 所 需 采 取 的 基 本 步 骤 中 ， 使 用 机 器 学 习（ML）的软件组件将分析和理解构成LEC的安全性，并确保这些贡献得到适当的管理。本文通过以下两个步骤来解决这两个问题：首先，引入危险贡献模式（HCM）的概念-LEC的ML元素可以促成危险系统状态的方式的分类;其次，描述论证模式如何捕获可用于确保HCM缓解的推理我们的框架是通用的，在这个意义上，人力资本管理的类别发展i）可以承认不同的学习计划，即，有监督、无监督和强化学习，以及ii）不依赖于嵌入LEC的系统的类型，即，包括网络和网络物理系统。这项工作的目标之一是为系统化LEC安全分析提供一个起点，最终在工具中实现自动化。1引言支持学习的组件（LEC）是利用知识获取和机器学习（ML）过程来实现功能或服务的软件。在过去的十年中，ML算法的能力急剧增加，促使LEC被纳入到更大的系统中，以完成传统上由人类操作员执行的任务（在物理系统的情况下），工程设计（在软件和机械系统的情况下），或执行否则可能不可行的功能。当集成到安全关键环境中时，例如，运输系统或手术机器人，LEC可能直接导致或促成伤害（国家运输安全委员会，2017年）。安全保证论证是将安全声明与电动汽车的可审计和可验证项目联系起来2018年）。安全案例已被广泛用作各种安全关键领域的安全保证手段，最近的标准化工作1将安全论证作为自主安全保证的核心要素。安全配置可以以多种形式获取，其中一种使用图形符号，如目标结构化 注 释 （ GSN ） （ 保 证 案 例 工 作 组 （ ACWG ）2018）。为了实现重用和易于理解，基于GSN的论证结构可以抽象并以论证模式的形式表示。安全分析和保证的关键出发点是系统的危险分析。尽管通常在系统架构的较高层次上进行这种分析，但在组件层次上应用的各种较低层次、自下而上 的 分 析 都 是 支 持 的 。 故 障 模 式 和 影 响 分 析（FMEA）是这种以低级别组件为中心的分析的典型示例（Salay和Czarnecki 2018）表明，确保LEC安全性的困难是由于ML算法和传统软件组件之间的两个明显差异。首先，ML算法所应用的问题通常很难（如果不是不可能）指定。这种情况通常是由设计造成的-如果可以为问题编写规范，那么ML算法可能首先就不是必要的或有用的。其次，机器学习算法及其内部逻辑通常是人类无法解释的，这使得他们的监督变得复杂。这种困难，确保LEC的安全提出了一个缺口，在安全保证的做法，我们试图解决在本文中提出的工作。目标是分析和理解LEC2的ML元素在嵌入到更广泛的系统中时对安全性的贡献，并确保这些贡献得到适当的管理。本文首先介绍了危险贡献模式（HCM）的概念，这是LEC输出导致危险系统状态的方式的分类;其次，描述了如何论证危险贡献模式（HCM）。身份，而且往往是现代安全的核心要素-保险案例--一个系统对于给定应用的安全性的全面的、可辩护的和有效的证明，在定义的操作环境中执行（Denney和Pai1例如，来自Underwriters Laboratories，Inc.的即将出台的用于评估自主产品的安全标准UL 4600。2在本文的其余部分，我们将不区分LEC和它们的ML元素。版权所有© 2020本文由其作者。在知识共享许可署名4.0国际（CC BY 4.0）下允许使用。2心理状态模式可以捕获提供HCM缓解保证的推理。我们框架的这两个方面是通用的，因为所开发的母语教学方法的类别i）可以接受不同的学习计划，即，有监督、无监督和强化学习，以及ii）不依赖于嵌入LEC的系统的类型，即，包括网络和网络物理系统。此外，这项工作是迈向一个连贯框架的第一步，以整合适用的（可能是现有的）分析和验证技术，以及缓解机制，以实现为嵌入LEC的系统开发保证案例的最终目标。另一个目标是为LEC安全分析系统化提供一个起点，最终在我们的保证案例工具AdvoCATE中实现自动化（Denney和Pai 2018）。2危害贡献模式嵌入并集成到更广泛系统中的LEC可以将其迁移到不希望的状态，这些状态通过其输出和与其他系统组件的相互作用以及每个组件在整个系统状态中所扮演的角色构成潜在的危害。LEC对危害的贡献可能有不同的形式，我们称之为（LEC）危害贡献模式（HCM）。因此，HCM根据（可能）可观察到的LEC输出与嵌入LEC的更广泛系统的可预测输出（或行为）之间的关系，表征LEC的安全影响我们确定了两种类型的LEC输出，即预期性能和意外性能（图1）。两种输出类型的LEC输出的特征是相同的，尽管仅针对预期性能完全显示。我们将每种输出类型细化为关于精度和误差的模式（更多说明请参见第2.1节）。正如我们稍后将看到的，图1中“有错误”类别下所示的两种危险模式因此，大致有四类HCM：预期和准确（EA）、预期错误（EE）、意外和准确（UA）以及意外错误（UE）。我们可以独立于嵌入LEC的系统类型来应用HCM物理系统，如公路车辆，或无形的网络系统，如企业软件。认识到LEC输出是从ML过程中产生的-有效地应用了关于一些目标函数的优化算法-我们假设所提出的有监督、无监督和强化学习（RL）。在本节后面的讨论中，我们将给出一些例子来支持这一假设。应用HCM类别可以被看作是一个自下而上的分析类似于FMEA.然而，我们将HCM与失效模式区分开来，因为并非所有失效模式都需要导致危险，而根据定义，所有HCM都是，3.当我们表示危险贡献模式（HCM）时，我们将简单地使用模式，当上下文不清楚时，限制其使用。LEC输出预期产出类型效能意外性能准确准确但有误差并出现错误非-危险不准确失败危险危害贡献模式非-危险非-危险危险危险图1：LEC输出的特征，在突出显示的框中以黑体显示危害贡献模式。尽管某些HCM可能确实是故障模式（见图2）。HCM比故障模式更抽象，从安全的角度来看，它们更广泛，因为它们包括可能是危险的非故障输出。在方法上，我们设想HCM将与FMEA一起使用，而不是作为FMEA的替代品。在详细阐述每个HCM之前，我们首先讨论相关的术语和概念。2.1预赛LEC准确性表示其输出是全局最优的属性，无论是正确分类、近似精确回归还是RL中奖励最大化操作的选择。同样，LEC误差是指LEC输出与参考值之间的偏差，即，或者地面实况（如果可用，例如，如在监督学习中），或者根据损失、成本或优化算法的目标函数产生的最优值（例如，如在RL中使用奖励函数）。LEC准确度和误差是不同的概念，但直观上是相关的：误差越大，准确度越低。然而，确定构成准确输出的内容需要一个用于比较的参考（我们将在本节后面进一步详细说明）。值得将LEC错误与可靠性术语中的（软错误）错误概念进行对比（Avizieniset al. 2004）：虽然两者都捕获了发散（或偏差）的概念，但是用于比较的参考是不同的。具体地，对于后一种偏差，从所需的外部系统状态确定，而对于前一种偏差，参考不需要是需求规范。此外，我们区分LEC的准确性，从分类的准确性。对于分类任务，LEC准确度是指对特定样本输入的分类性能，并且是确定性的，即，要么分类准确，要么不准确。相比之下，分类准确度给出正确分类的频率论概率，并且是基于样本输入的集合表征（预期）分类的度量。3LEC输出准确度安全阈值下限最佳值（Ground Truth）准确度上限要求图2：LEC输出的简化（概念）概念，显示不同的LEC误差幅度。关于准确度的界限，输出要么准确，要么不准确。根据要求，输出失败，而安全性根据安全阈值确定。同时，可以区分预期和准确（EA）以及预期误差（EE）危险贡献模式所示的安全阈值是推导出来的，适用于LEC。根据学习方案，LEC错误可以呈现不同的形式。例如，监督学习中的错误来自模型假设（偏差）、所使用数据的类型和数量（方差）以及噪声的组合。在无监督学习中，错误可能来自不适当指定的优化目标（近似误差）、使不同输入之间的差异复杂化的模型参数选择（可识别性误差）、不适当的数据（估计误差）和算法不确定性（优化误差）（Liangand Klein 2008）。实际上，可以指定各种误差界限。准确度的界限是这样的，落在这些界限内的LEC输出被认为是准确的。换句话说，当LEC误差的幅度不超过准确度的界限时，LEC输出被认为是准确的。当LEC误差幅度超过准确度界限时，输出仍然可以满足适用的要求。这样的LEC输出不准确，但操作上是可接受的，例如，当输出不精确时。4当LEC误差幅度超过根据要求可接受的误差幅度时，可认为已失效。5图2显示了一个概念性的概念，说明了LEC输出的这种特性。如图所示，准确度和要求的界限以及LEC误差的幅度（标记为ε1至ε5）决定了LEC输出何时被视为准确、不准确和失败。例如，具有LEC错误的输出[4]请注意，准确度指的是输出与参考的接近程度，而精度指的是输出的变化。5在这种情况下，来自可靠性术语的误差和LEC误差是等效的。ε1和ε4不准确，具有LEC误差ε2和ε3的输出准确，而具有LEC误差ε5的输出失败。在本文中，我们将考虑那些不准确或失败的输出类型为我们假设可以在更广泛的系统状态上定义安全阈值，例如，使用安全包络方法（Tiwari等人，2014年）。 如图2所示，安全阈值确定LEC输出何时不安全。例如，具有LEC误差ε3、ε4和ε5的LEC输出都是不安全的。所示的安全阈值是任意选择的。实际上，它是从系统级安全阈值中得出的，并适当地分配给LEC;尽管为了说明的目的，我们在这里认为它们是等效的。违反安全阈值可能导致系统从安全状态转换到危险状态（在图2中由标记为不安全的区域表示）。请注意，图2有意简化以说明HCM概念。实际上，我们在此假设可接受的误差范围足以表示要求和安全阈值;相反，边界、区域或更复杂的流形-例如，在分类问题的情况下-可能更合适。确定和表达这些的合适机制不在本文的范围内，尽管我们在这里给出的框架提供了一种原则性的方法来集成它们。LEC输出是否安全，以及其输出类型的组合是我们用来区分HCM的。下一个是我们描述了主要的LEC输出类型和相关的HCM，给出代表性的例子来说明模式是什么，并识别可能的原因。随后，我们将讨论我们设想如何提供保证，使HCM能够以可接受的方式管理，以实现更广泛的系统安全目标。（错误1）不准确和安全安全（错误2）准确和安全不安全预期和准确的HCM（错误3）准确和不安全（错误4.4）不准确和不安全不准确（业务上预期错误HCM可接受）（错误105）失败不安全失败准确42.2预期性能预期性能只是所需的运行时LEC输出或行为。从某种意义上说，对于系统要求中捕获的输入，预期观察LEC输出6，证实其在运行中至少与模型验证和校准期间一样具有性能。这反映了在部署之前，作为LEC开发生命周期的一部分迭代执行的ML模型（重新）训练、验证和校准工作期间学习的输入-输出关系。因此，LEC的预期性能要么是准确的，要么有误差。预期和准确的危害贡献模式LEC的预期和准确（EA）模式是其输出准确且可能导致危险系统状态的模式。从概念上讲，这可以被视为系统的安全操作状态空间被过度近似导致与不安全状态空间重叠的情况在图2中，LEC输出与错误3是代表的EA模式。例如，考虑自动驾驶中的车道保持功能，其实现使用感知LEC来分类和定位车道，同时提供到车道边界的距离估计。在这种情况下，不考虑LEC训练数据中的临时或移除的车道标记7可以导致正确的定位和与错误的（即，移除）车道标记。这是EA模式的一个实例，当未缓解时，该模式又造成意外车道偏离和侵入相邻车道的可能性。当系统安全分析期间识别出危险的已知前兆或促成条件时，EA模式可以显现，例如，传感器故障、非标称环境条件等-在LEC开发过程中没有明确考虑，即，当它们没有i）被包括在用于训练和测试支撑LEC的ML模型的数据中或未被充分表示时，或ii）在所使用的优化算法中反映时。预期错误危害贡献模式LEC的预期错误（EE）模式是LEC错误的幅度使得违反一个或多个安全阈值的模式，由于该安全阈值，潜在危险的系统状态是可诱导的。对于EE模式，主要的问题是是否产生的误差量超出了准确度的界限是这样的输出诱导一个危险的系统状态。如图2所示，当LEC处于EE模式时，它产生的输出误差幅度（标记为104和105）分别为：i）不准确（但操作上可接受）和不安全;以及ii）故障不安全。EE模式可以出现在许多场景中，具有不同的本地和全球影响。再考虑一下我们前面的例子，车道保持功能使用感知6一般来说，可能无法直接观察LEC性能;而是从LEC输出将传播到的系统输出或被测设备中推断。7可能由于道路施工而引入，这种道路环境条件甚至会使经验丰富的人类驾驶员感到困惑。LEC，虽然在标称道路条件下，即，不像以前那样有临时的或被拆除的车道标记。如果物理传感器值中的误差，以及由于传感器放置、场景预处理、传感器融合等引入的其他误差，并且它们对违反系统级安全阈值的影响在LEC开发期间没有被考虑在内，则输出误差可能使得车道被估计为比它们实际上更远。因此，旨在保持当前车道的后续控制动作可能无意中导致车道偏离。因此，输入中的误差（包括对抗性扰动）可以导致LEC输出误差幅度被修改，使得否则安全的输出变得危险。由于LEC设计中涉及的大量错误生成过程以及它们如何解释适用的安全阈值，LEC可能易受EE模式影响。例如由于a) 在准备培训数据时抽样做法不充分。这样做的一个后果可能是不平衡的数据，不足以表示输入、输出和安全阈值之间的关系b) 在构建ML模型时所做的假设。这可以反映在优化目标函数中，该优化目标函数不充分地考虑适用的安全阈值的相关性和影响;c) 在模型验证期间，影响安全阈值或受安全阈值影响的操作环境条件的表示或覆盖不2.3超预期表现意外性能表示系统级别的紧急运行时LEC输出、行为或影响，例如，通过未预料到的特征交互，这在操作中是不希望看到的，并且在模型验证期间也是不希望观察到的。像预期的每一个，意外的LEC输出可以被认为是准确的，或与错误。此外，如前所述（也见图1），与非预期性能相关的HCM反映了为预期性能确定的HCM，即，它们涉及两个都精确的危险LEC输出-即，意外和准确（UA）模式-并且具有错误-即，意外错误（UE）模式。本质上，以及从诱导危险系统状态的影响的角度来看，UA和UE模式与我们之前确定的模式在概念上几乎没有区别。因此，我们预计UA和UE模式的过程和原因将在某种程度上与许多重新定义的过程和原因重叠负责生成EA和EE模式。然而，一般来说，意外的LEC性能是对i）操作环境的性质和ii）部署LEC的系统的误解的操作表现，反映在所使用的ML算法和用于训练它们的数据这与LEC开发步骤中的潜在不足相结合，导致所需的（即，预期的性能），以及运行时的体验（意外的性能）。由此，我们假设两个特定的5UA和UE模式的原因包括数据集移位和验证不足。此外，由于非预期（和可能的危险）LEC输出的固有不确定性，用于缓解和保证的方法是UA和UE模式可能不同于EA和EE模式，分别。特别是，虽然后两种模式可以通过很大程度上预防性的方法来管理，但前两种模式的缓解可能更依赖于运行时检测、恢复和架构级安全机制。意外和准确的危险贡献模式意外和准确（UA）模式表征意外的LEC输出，但这些输出是最佳或准确的，也是危险的。例如，考虑使用使用强化学习（RL）训练的LEC实现的无人飞行器系统中的防撞功能。在这种情况下，可以学习合法的奖励最大化动作，例如向左倾斜然而，在某些碰撞情况下，特别是在另一架飞机在短距离内以迎头航线迅速出现的情况下（例如，在某些类型的无人驾驶通用航空也合作的空域），既定的空中规则要求两架飞机向右倾斜。在这种情况下，否则最佳的控制动作对于操作场景是意外的，并且可能是潜在的灾难性的，即，如果LEC控制的飞机向左倾斜，而其它飞机向右倾斜，则按要求。普遍获得模式可以出现在没有基本事实概念的操作环境中，也可能来自沉淀EA模式的条件和原因也就是说，在LEC定义期间，在训练和验证数据或优化目标函数中，当已知导致已识别危害的条件和事件未得到适当考虑其他差异化原因包括，如前所述，数据集转移，以及部署前模型验证不足。在我们上面的飞机系统示例中，数据集偏移可能表现为不平衡的数据，例如，本身可能由于不适当的采样，或由于在建模环境时所做的假设。同样，各种碰撞几何形状的不完全非预期错误危害贡献模式意外错误（UE）模式对具有一定误差幅度的未预期LEC输出进行分类，从而导致危险系统状态。再次考虑部署在用于检测和跟踪外部实体的自动驾驶场景中的感知LEC，以支持碰撞避免。尽管在训练和验证中，识别和定位干扰素的平均检测性能（如通过灵敏度和特异性度量所测量的）可以指示LEC将在操作中如预期地执行，但是在训练和验证中的假阳性/阴性可能会被忽略。特定的上下文相关的环境情况反映了具有可能潜在危险的误差幅度的意外输出，例如，在有限的可见度环境中，具有深色衣服的行人的假阴性分类可能被同样暗的背景遮挡，由于该假阴性分类，车辆制动器没有接合，可能导致碰撞。在这种情况下，假阴性是边缘情况（Koopman2019），这是一种罕见的情况，代表一种特殊形式的协变量变化，可能无法进行非全面的模型验证。协变量移位是更一般的数据集移位条件的一种特殊类型，其中操作中LEC的输入分布与用于其训练的分布其他形式的数据集移位包括先验移位，其中输出分布在训练和操作之间不同，以及概念移位，其中输入和输出的联合分布在操作中从训练数据表示的更一般地说，如本节前面提到的，UE模式可能由于LEC开发步骤中的各种错误生成过程而发生，包括不充分的训练和验证数据，以及在优化损失、错误或目标函数中编码的假设，以及意外性能的两个特定原因：数据集偏移和不充分的验证。3确保可接受的安全贡献回想一下，首先，EA和EE模式分别与UA和UE模式相似，从以下观点来看：i）它们对系统安全的影响，以及ii）LEC输出的特定方面，即，精度和误差幅度。还应回顾，模式的原因之间存在一定程度的重叠，因此，在处理缓解问题的方式上也存在重叠。第三，我们假设了两个特殊的原因，意外的危险贡献。我们现在描述一些机制，以可接受地管理已识别的危害贡献模式的安全贡献，这也可以被视为通用和高级别的证据要求。3.1管理危险贡献模式准确和危险输出保证可通过以下证据的组合部分地提供可接受地缓解EA和UA模式的保证– 在培训和验证数据中充分反映所有已知和已确定的条件，这些条件既是已知的危险前体，又可能与分配给低排放量国家的功能有关;– 在所使用的优化算法的损失、成本或目标函数作为添加到损失函数的正则化项的参数化变量。LEC的上下文相关的鲁棒性测试可以提供额外的证据，确保修改后的目标函数适合于减少EA模式的发生;– 全面的模型测试和基于验证的EA模式引起的危害的已识别前兆条件的6错误的危险输出为确保EE和UE模式已得到可接受的管理，至少需要以下组合的证据：– 与LEC输出相关的有效安全阈值（或界限），从系统级安全界限（或安全包线和相关条件的规范）导出– 在培训和验证数据中充分反映LEC特定安全阈值;– 在所使用的优化算法的损失、成本或目标函数中适当地反映LEC特定的安全反过来，反映ML出租的适当性与证明其性能和稳健性有关（Ashmore、Calinescu和Paterson，2019年），前提是这些保证属性考虑到适用的安全阈值;– 综合模型测试和验证，考虑与相关安全阈值相关的错误性能。预防和恢复上述建议的缓解措施是预防性的，主要集中在减少EA和EE模式在操作中发生的可能性。在这样做时，想法还在于它们可以防止UA和UE模式的运行时发生，因为相同的过程中的一些为了额外地确保UA和UE模式的特定原因已经被管理，保证机制可以额外地集中于收集以下的组合的证据：– 操作环境和系统上下文的全面定义，例如，通过利 用 系 统 操 作 约 束 的 丰 富 规 范 （ Koop- man和Fratrik 2019）;– 培训和验证数据的充分性，即通过使用的数据相关 、 平 衡 、 完 整 和 准 确 的 证 据 可 以 保 证（Ashmore、Calinescu和Paterson 2019）。– 模 型 验 证 技 术 是 全 面 的 和 上 下 文 相 关 的（Ashmore，Calinescu和Paterson 2019）。在上述内容中，前两项旨在提供管理数据集转移的保证，而第三项则试图提供证据证明所使用的模型验证方法是适当的。分层缓解对于更广泛的安全保证而言，仅显示LECHCM已得到管理是不够的;相反，分层方法是谨慎的，包括减少或掩盖HCM影响的架构机制。因此，从一旦HCM发生就从HCM恢复的角度来看，并且具体地说，为了管理UA和UE模式，在架构级别部署的缓解机制的证据可以提供额外的保证。比如说，– 运行时监控以检测偏离适用安全界限的LEC输出，– 故障安全/故障容限机制，通过利用保证措施（Asaadi、Denney和Pai），断开2019），提供了对特定LEC保证属性的量化信心概念;– 使用LEC实现的功能的冗余和足够多样化的实现，以及用于检测功能不一致的运行时监视器。总的来说，我们认为满足上述通用证据要求可以构成更广泛的基础的一部分，以确保LEC输出的系统级影响是可接受的，并且不会导致HAZ-优选系统状态。在前面介绍的一些母国措施的一般缓解措施中，需要注意的是，其中一些缓解措施有其自身的挑战（我们在本文中没有讨论）。例如，不同的数据通常是有用的，但它的包含需要小心，没有它，用于ML的优化算法可能不会收敛到一个解决方案。同样，如果所检查的风险具有较小的相关概率，则用于稳健性保证的形式分析技术的应用可能具有有限的效用。HCM缓解措施的更完整我们注意到，以前已 经 调 查 了 各 种 各 样 的 这 种 技 术 （ Ashmore ，Calinescu和Pa- terson 2019）。我们这里的重点是，相反，以结构化的方式整理这些缓解措施的框架，以实现LEC保证。3.2安全保证论证模式论元模式表示法我们简要概述了目标结构化表示法（GSN）的句法元素，我们在这里使用它来指定论元模式。关于论证模式及其使用的全面细节，我们参考了我们之前的工作（Denney and Pai 2013）。安全声明使用称为目标节点（或简称为目标）的矩形元素表示。对上下文信息的引用以称为上下文节点的圆角矩形给出。图表是策略节点，指定如何将较高级别的声明发展为较低级别的声明，例如，使用推理规则。 假设记录在用字符“A”注释的省略号中。节点上的三角形和/或菱形装饰指示那些节点可以被实例化，即，通过替换节点描述中大括号“{ }”内指定的抽象参数具体的数据。节点通常由两种类型的链路连接。 实心箭头表示推理关系，解释为“由……支持”，而空心箭头表示抽象关系，解释为“在……上下文中”。链接可以用多重性来注释，用标签填充圆圈，指定链接和连接的目标节点被实例化的次数。此外还有一种特殊类型的链接，用于捕获选择，在源和源之间的链接上使用实心菱形符号显示以及多个目标节点。这样的选择链接也可以用指示要实例化多少目标节点的标签来表示。示例论证模式现在，我们讨论如何以以下形式呈现与前一节中讨论的保证机制相关的推理：7图3：保证特定LEC的EA模式得到可接受的管理的参数模式。保证论证的模式。图3示出了保证参数模式，该保证参数模式捕获了为什么EA模式对于特定LEC（示出为根目标节点G1，引用参数“lecItem“）被可接受地减轻的情况的推理。该声明引用它所贡献的危险系统状态作为上下文元素（节点C6）。然后，该模式基本上提供了两条保证推理来支持根本声明。第一条腿（策略节点S1和向下）的原因，分别对特定的LEC输出，需要证据，要么i）要么每个输出是不危险的，当它是准确的（目标节点G3），或ii）如果每个输出是，实际上是危险的，其值在超过相关联的安全阈值时被屏蔽（目标节点G4），假设该违反可以被检测到（假设节点A1）。策略节点S1和目标节点之间的选择链接G1和G2捕获了这些替代方案。第二个分支（策略节点S2及以下）对HCM（目标节点G5由于LEC可能导致多个系统危害，因此我们将为每个此类危害实例化此模式。还有三种模式，三种模式各有一种，其基本原理类似，但具体针对所确定的特定原因。由于篇幅所限，我们在此不显示这些模式。此外，总体模式（这里也未示出）涉及用于相关模式的四个模式中的每一个的根声明（例如，EA模式的目标节点G1，如图3所示）到更高级别的安全声明，即相关LEC对已识别系统危险的贡献是可接受的。8巧妙地管理。我们用来建立这种联系的推理规则是，LEC对相关系统危害的总体贡献由个体危害贡献模式表征，后者的保证需要前者的保证。这是自下而上分析（如FMEA）的基本推理基础，我们试图复制FMEA，但以安全为重点。我们注意到，事实上，这只是提供了一部分保证，因为实际上，组件的贡献通常取决于其他组件和相关的交互。然而，这种分析不在本文的范围内4相关工作我们对危险贡献模式（HCM）的分类与其他检查ML安全性的工作有一些相似之处：例如，（Varshney和Alemzadeh 2017）将ML输出表征为期望的或不期望的，与我们对LEC输出类型的表征相反。他们的工作还提出了一些高层次的安全策略，包括固有安全设计，安全储备或因素，故障安全和程序保障。这些都与我们在本文前面确定的大多数（如果不是全部）缓解机制保持（Amodei等人，2016年）概述了五种侧重于强化学习的失效模式，（Faria 2018; 2017年）建立在强化学习的基础上，以解决应用于监督和无监督学习的其他失效模式他们的研究还指出了如何管理已识别的故障模式和安全问题相比之下，我们对HCM的分类更广泛，包括失效模式以及对安全有影响的非失效模式。相关的保证基本原理作为论证模式包括在内，可以方便地进行检查、扩充和适当改进。此外，尽管我们确定的证据要求远非全面，但该框架旨在作为为LEC制定更全面的安全保证基础的起点。其他研究已经解决了为ML保证创建GSN模式的问题：（McDermid，Jia和Habli 2019）介绍了一个用于自治系统安全保证的高级框架。这个框架是基于这样的观察，即在现实世界、观察到的世界和想象到的世界之间存在差距。这种差距是由自治系统固有的问题、程序和工程限制造成的。在此拟议框架下的安全保证涉及检查这些差距，并确保对系统安全的负面影响是有限的。这种模型/现实差距方法与我们对由于分布变化和验证而导致的预期和非预期性能的理解之间存在明显的相似性。（Bragg and Habli 2018）提出了一种高级模式，用于确保特定环境中强化学习系统的一般安全性。该模式基于安全配置（模型构造和子系统构造是安全的）和故障安全的概念。（Picardi et al. 2019）提出了一种GSN模式，以确保ML决策系统达到特定的每最后，将该系统应用于医学诊断机器学习，聚合了合适的基准、操作环境、学习模型、训练数据和测试数据的子参数。（Burton et al.2019）建立在这项工作的基础上，提出了一种方法，从测试证据中开发关于模型性能的置信参数，并将这些方法应用于论证自动驾驶车辆行人检测的足够性能的问题我们介绍的论证模式明确地捕获了隐含的推理，该推理构成了对组件级安全贡献的系统的、自底向上的分析我们提出了从分析HCM的初步框架中产生的通用、高级证据要求，但我们没有解决收集或评估所需具体证据项目的方法，也没有解决可能利用的众多保证技术。例如，（Ashmore，Calinescu和Paterson 2019）提出了ML组件开发生命周期中安全考虑的理论框架，定义了组成生命周期阶段的特定保证属性，并概述了产生所需保证证据的最新技术。我们的论文填补了他们工作中的空白，通过HCM将生命周期阶段的保证属性我们的工作旨在将ML安全性的系统组件级评估与论证模式相结合，以捕获相关的保证原理。我们工作的独特之处在于专注于嵌入在更广泛的网络或网络物理系统中的ML：了解这些组件如何导致系统危害，作为创建所需参数的起点，以确保这些贡献得到可接受的管理。5结论在本文中，我们提出了一个框架，了解危险贡献的学习使能组件（LEC）的系统安全性，在危险贡献模式（HCM），其特点是广泛的LEC输出类型，特别是在精度，误差和性能预期。通过举例，我们阐述了一些可能的原因和条件，这些原因和条件是在它们出现的情况下产生的，以及在提供缓解保证时所需要的，力求尽可能通用。然而，HCM的安全效应不能被概括，因为关于特定LEC、其与更广泛系统的接口、系统本身及其操作环境的细节是必要的。因此，我们在此仅给出了HCM对安全性潜在影响的此外，我们对模式的描述并不完整，也不涵盖模式原因和缓解措施的全部范围。因此，不应将其视为所有可能的危险诱发情景的详尽列举，而应将其视为在以组件为中心的危险分析过程中系统思考原因、影响和危险条件（包括故障模式）的指南HCM适用于许多情况，其中软件组件的输出，行为和效果在9系统级可能难以预先规定，因此比LEC更普遍地适用然而，传统的（即，非ML）软件组件有传统的危险分析技术可供使用;因此，在这里我们提出了HCM作为一个通用的分析框架，可以与ML特定的缓解技术相结合。我们已经给出了参数模式（其中一个已详细阐述），它捕捉了不同HCM的上述特征，以及已识别相关原因的此外，我们还详细阐述了将用于将每个模式特定模式组成一个模式的推理，该模式解决了LEC的总体贡献。在实践中，模式特定的模式随后将被细化并增加更多细节，这些细节特定于特定的LEC、所实现的学习方案、其被集成的系统以及LEC及其包含系统被部署的环境。这些也形成了数据源，模式将从该数据源被实例化以给出具体的保证参数。基于我们的保证案例工具AdvoCATE（Denney和Pai 2018）中现有的危险分析和参数生成功能，我们计划开发用于支持HCM（应用程序/ML特定模式库）的分析的模板，实现指导决策过程，以帮助用户进行模式选择，组合和实例化，实现从基本分析到自动化的步骤，创建保证论证。最后，作为未来的工作，我们计划从方法论的角度完善LEC的HCM，将高级别的证据要求细化为可与客观质量证据相关联的低级别要求。致谢这项工作得到了美国航天局航空研究任务理事会空域运行和安全方案中的全系统安全项目的支持引用Amodei ， D.; Olah ， C.; Steinhardt ， J.; Christiano ， P.;Schulman，J.; 和Ma ne'，D.2016年。AI安全的具体问题。arX i v预印本。arXiv：1606.06565v2 [引文AI]。Asaadi，E.; Denney，E.;和Pai，G. 2019.对学习使能组件保证的量化。在2019年第15届欧洲独立计算会议（EDCC）的会议记录中，55美国电气与电子工程师协会。Ashmore，R.; Calinescu，R.;和Paterson，C. 2019年。 确保机器学习的目标：需求，方法和挑战。arXiv预印本。arXiv：1905.04223v1 [cs.LG].Avi zienis，A.; Laprie，J.- C.的; R a ndell，B.; 和Landweh r，C.2004 年 。 可 靠 安 全 计 算 的 基 本 概 念 和 分 类 。 IEEETransactions on Dependency and Secure Computing1（1）：11-33.布拉格，J.E.，和Habli，I. 2018.什么是可接受的安全再强化 学习 ？In Gallina ， B.; Skavhaug， A.; Schoitsch ，E.; 和Bitsch，F.，编辑， 计算机安全性、可靠性和安全性。SAFECOMP 2018.计算机科学讲义，卷11094。瑞士查姆：施普林格。Burton，S.; Gauerhof，L.;塞西湾B.人;哈布利岛;和Hawkins，R. 2019.高度自动驾驶功能机器学习性能证据的置信度参数。在Ro-manovsky，A.;Troubitsyna，E.;加什岛;Schoitsch，E.;和Bitsch，F.，编辑， 计算机安全性、可靠性和安全性。SAFECOMP 2019. 计算机科学讲义，卷11699。瑞士查姆：施普林格。Denney，E.，和Pai，G.2013年。 安全案例专利的形式化基础. In Bitsch，F.; Guiochet，J.; 和Kaamichael，M.，编辑，ComputerSafety ， Reliability and Security （ SAFECOMP2013），Volume 8153 ofLNCS，21Denney，E.，和Pai，G. 2018.保证案例开发的工具支持。自动化软件工程25（3）：435-499。Faria，J.M. 2017年。机器学习中的非确定性和故障模式在2017年IEEE软件可靠性工程研讨会国际专题论文集上。图卢兹，法国：IEEE。Faria，J.M. 2018年机器学习安全：概述。在第26届年度安全关键系统研讨会上。约克，英国：安全关键系统俱乐部。Koopman，P.，Fratrik，F.2019年。有多少操作设计域、对象和事件？在埃斯皮诺萨，H.;余，H.;黄，X.;Lecue，F.;Chen，C.; Hernandez-Orallo，J.; hE′igeartaigh，S.的O.; 和Mallah，R.，编辑，2019年人工智能安全研讨会论文集。澳门，中国：CEUR研讨会论文集。Koopman，P. 2019.边缘案例和自动驾驶汽车安全。在第27届安全关键系统研讨会（SSS）上发表。Liang，P.，和Klein，D. 2008.非监督学习的错误分析。人类语言技术和计算语言学协会（HLT/ACL）会议论文集。McDermid，J. E.;贾，Y.;和Habli，I. 2019.自治系统安全保障框架的研究。在埃斯皮诺萨，H.;余，H.;黄，X.; Lecue，F.;Chen，C.; Hernandel-Orallo ，J.; hE′igeartaigh，S.的O.; 和Mallah，R.，编辑，2019年人工智能安全工作坊的开幕式。澳门，中国：CEUR研讨会论文集。国家运输安全委员会。2017年。 2016年5月7日，佛罗里达州威利斯顿附近，一辆装有自动车辆控制系统的汽车与一辆半 挂车卡 车相撞 。公路 事故报告 NTSB/HAR-17/02 ，NTSB，华盛顿特区。Picardi，C.;霍金斯，R.;Paterson，C.;和Habli，I.2019年。一种模式，用于论证医疗诊断系统中机器学习的保证。InRomanovsky，A.; Troubitsyna，E.;和Bitsch，F.，编辑，计算机安全、可靠性和安全性，165陈：施普林格国际出版社.Salay河，和Czarnecki，K. 2018.在汽车软件中安全使用机器学习：ISO 26262中软件过程需求的评估和适应。保证案例工作组（ACWG）。2018.目标结构表示法社区标准版本2.Ti wari，A.; Dutertre，B.; J ov an o vi c′，D.; deCandia，T.;林肯P. D.; Rushby，J.; Sadigh，D.;和Seshia，S. 2014.安全信封。在第三届高置信度网络系统国际会议论文集，HiCoNSNewYork，NY，USA：ACM.瓦什尼湾R.，和Alemzadeh，H. 2017.机器学习的安全性：网络物理系统，决策科学和数据产品。Big Data5（3）：246-255.