UL4600标准中文版-2020自动驾驶产品安全评估UL中文版标准

安全标准-参考中文版自动驾驶产品安全评估2020年4月1日UL46003内容1前言(资料性)51.1目标52.1范围摘要62.2范围7中的元素2.3范围限制 83参考出版物113.1规范性引用文件113.2信息参考 4术语，定义和文档使用124.1如何解释规范性元素(规范性)124.2术语和定义(规范性)164.3缩写和缩略语(信息性)215安全案例与论点225.1一般225.2安全箱样式和格式245.3主张和论据充分性285.4证据充分325.5接受的风险355.6安全文化365.7项目范围386风险评估406.1通用406.2故障模型416.3危害576.4风险评估596.5风险缓解和缓解效果评估647与人和道路使用者的互动697.1人与人的互动697.2人际交流707.3与人和动物的互动747.4人类对操作安全的贡献827.5弱势道路用户互动867.6其他车辆互动897.7引发人类安全责任的模式变更928.1通用自治管道948.2运营设计域(ODD)968.3感应1018.4感知1108.5机器学习和“Al”技术1138.6规划1208.7预测1238.8物品轨迹和系统控制1248.9致动12817评估2572020年4月1日8.10计时1299软件和系统工程过程1309.1开发流程严谨1309.2软件质量1359.3缺陷数据1389.4开发流程质量13810可靠性14010.1通用14010.2降级操作14010.3冗余14610.4故障检测与缓解15210.5项目健壮性15710.6事故响应15910.7系统计时17010.8网络安全17211数据和网络17611.1一般17611.2数据通信和网络17611.3数据存储18311.4基础架构支持18612.1验证，确认(V&V)和测试方法18912.2V&V方法19012.3V&V覆盖19412.4测试19712.5运行时监控20412.6安全案例更新20813.1将军21113.2工具识别21213.3降低工具风险 14.1综合22114.4制造和物品部署22814.5供应链22914.6现场修改和更新23114.7操作23514.8退休和处置23815保养24015.1保养与检查24015.3非运行安全24516.1通用24616.3指标分析和响应2542020年4月1日合格评定257合格评定包259独立评估262符合性监控269提示元素反馈272A1兼容性274A2安全案例274A4条款映射到ISO/PAS2141前言(资料性)1.1.1该标准旨在帮助确保在设计过程中对自主产品的安全性进行了可接受的全面考虑，并将在整个系统生命周期中继续进行。它通过强调对安全案例的彻底性进行可重复评估来做到这一点。1.1.2符合本标准并不保证安全的自动驾驶汽车。但是，符合此标准将促进更严格的工程设计，以支持安全的自动化车辆。还应认识到，安全案例只是自动化车辆完整安全保证框架的许多重要组成部分之一，并且预计该标准将与标准组织和监管机构定义的其他标准和测试方法结合使用。1.2.1本标准的范围是以轻型自动驾驶公路车辆为具体示例的通用自动驾驶系统标准框架。为此，该标准版本包括适用于轻型自动驾驶公路车辆(客运和货运车辆)的广泛提示列表。许多提示将适用于其他自动驾驶地面车辆，甚至其他类型的自动驾驶系统，但尚未做出具体尝试以包括适用于其他应用的广泛提示，也未将道路车辆提示与更一般的提示分开。1.2.2本标准(UL4600)中采用的方法是要求基于声明的安全案例，该案例实质上涵盖了安全保证所需的全部材料。该安全案例包括一组结构化的索赔，论点和证据，证明某项物品(车辆加上有助于安全的所有其他支持)可以安全部署。为了支持该目标，UL4600评估强调确保安全情况合理地完成且结构良好。特别是，UL4600提供了改进安全案例一致性和完整性的指南。为此，特别需要一些最佳实践的过程活动和精细的工作产品(例如，创建危害日志)。但是，没有特定的总体设计过程是强制性的，也没有用于创建大多数工作产品的特定方法的强制性(例如，不需要V型开发过程；可以使用任何合理的方法来创建危害清单)可以接受)。1.2.3该标准未定义过程，而是提出了评估标准来确定安全案例的可接受性。这样，节，子句和提示元素的顺序并不暗示时间顺序或其他过程路径依赖性。1.3与其他标准一起使用1.3.1该标准旨在与现有标准配合使用，以提供必要的附加要素，以确保在创建安全案例时已全面考虑了全自动项目操作的安全方面。1.3.2在最大的实际可行范围内，开发人员可以利用所付出的努力和评估获得的功劳来遵守其他现有标准。开发人员可以将材料合并到他们的安全案例中，这些案例是由于执行流程和生成其他标准要求的工作产品1.3.3该标准的目的是在可行的最大范围内与现有相关安全标准兼容，尤其要避免禁止任何必要的活动或这些标准。特别是考虑了与ISO26262:2018和ISO/PAS21448:2019的兼容性。附件A讨论了该标准中某些条款到ISO26262:2018和ISO/PAS21448:2019的映射。其他安全标准(例如IEC61508)是相关的，并且有望普遍兼容，但是对IEC61508和其他功能安全标准的详细分析不在此版本的UL4600的范围之内。1.3.4此标准超出范围的两个领域是设置可接受的风险水平，以及对道德的产品发布决策和产品行为的任何道德方面的要求。对于这两个主题，开发人员都记录已做出的决定，但是该标准未建立已记录的接受标准。其他标准(例如IEEEP7000系列)提供了有关这些主题的指南。2.1范围摘要2.1.1该标准涵盖了安全原理，缓解风险，工具，技术和生命周期过程，用于建立和评估可在自主模式下运行的车辆的安全性论据。2.1.2假定在没有人为监督的情况下进行操作，并且在基于当前项目状态以及感知和解释操作环境的能力的情况下，无需人工干预就可以执行和监督动态驾驶任务和其他正常系统操作。除了正常操作以外，还考虑了人为安全做出的贡献(例如，维护),以及与未操作该物品的人(例如，行人)的互动。2.1.3当提及安全案例的范围以及项目的操作时，该标准通常使用术语“项目”而不是“系统”或“产品”。这种方法认识到物品的安全性可能取决于基础设施，服务，支持流程以及其他通常可能不被视为系统本身(例如车辆本身)但严重影响其安全性的因素。因此，所有这些都被认为在所评估项目的范围内。2.1.4该标准假设该物品在没有人为干预的情况下从某个定义明确的初始状态开始自动运行到其他定义明确的结束状态。人为输入可能会影响期望状态的选择(例如，通过乘员请求目的地)。但是，操作员通过执行或监督动态控制任务(例如，通过驾驶或负责监视系统操作)减轻或引入风险的程度不在标准范围内。类似地，操作员的绩效或不履约在涉及将驾驶员控制权转移到物品或从物品转移风险方面所涉及的程度也超出了标准范围。但是，确保该物品本身在正常情况下在标准范围内可以正常执行控制功能的任何更改，因为它也会对全自动模式下的操作产生不利影响。因此，尽管本标准的某些部分可能有助于解决不完全自动驾驶的车辆问题，但涉及人类驾驶员责任，警惕性以及适当承担车辆控制责任的能力的问题不在本标准范围之内。2.1.5尽管信息安全是必不可少的主题，但该领域的细节超出了本标准的范围，超出了对安全计划的一般要求，与其他车辆安全要求相比，提示元素对于自动驾驶汽车而言可能是唯一的。合理可预见的滥用和滥用以及物理攻击(例如物理传感器损坏)均在范围之内。2.1.6本标准的要求被认为是必要的，但可能不足以保证其完整性和严密性，以建立可接受的结构良好和可接受的完整物品安全性。2020年4月1日UL46007案件。特别是，提示元素列表被认为不是详尽无遗的，期望设计团队将包括与该元素及其操作设计领域相关2.2范围要素2.2.1明确打算在本标准范围内进行的项目操作和安全相关问题的特定方面包括：a)可能在非结构化环境中操作自治项目例：车辆是被引导到空旷农田中的第一辆车辆，该区域包含可行区和非可行区的混合区域，用于遍历和停车，这是临时溢出事件停车过程的一部分。没有车道标记，也没有定位信标。此外，在田间随机放置了母牛和干草。没有人协助组织停车位。这种情况属于标准范围。例：一群人在火灾现场溅到街上。应急设备，应急人员，受害者和临时观察员在行动，而与正常的道路使用方式无关。存在消防水带，掉落的燃烧碎片，小爆炸，交通信号灯停电，人行道损坏以及对正常基础设施预期的其他破坏。建筑物出口处有多人受伤，他们呼吁使用自动驾驶冰雹服务将其接送到紧急医疗机构。这种情况属于标准范围。注意：特定项目的安全案例可能需要ODD说明中指定的结构化环境，以确保安全操作。但是，默认情况下不假定存在结构。因此，如果适用，必须通过安全案例明确禁止在非结构化环境中运行。b)使用传感器提供的潜在不准确，不正确，不完整或误导性数据进行操作c)可能不准确，不正确，不完整或有偏见的数据(包括测试数据，现场报告数据，其他验证数据和机器学习训练数据)的影响。d)潜在的不精确，不准确或不完整的仿真模型的影响。e)项目中的硬件和/或软件，数据收集功能，数据处理功能，通信，工程支持系统，工具和基础结构支持的潜在缺陷和故障。f)人类对潜在风险的贡献，包括乘员，行人，其他道路使用者，非道路使用者，货物搬运者，维护者和检查员。这包括不作为和委托的行为；意外和恶意的身体行为：以及在创造和减轻风险方面的g)生命周期注意事项，包括设计数据收集，工程数据管理，工具鉴定，设计，实施，测试，其他验证，现场数据收集，操作，维护，更新，升级和报废。生命周期注意事项还包括对环境的潜在更改，这些更改可能会影响ODD,对象类型的更改，行为的更改等。h)包括降低风险和通过遵守其他标准，特别是针对适用于那些标准范围内的产品的ISO26262和ISO/PAS21448标准，对安全案例做出的其他贡献。i)使用不同方法论证的能力，包括使用各种标准来支持安全性(例如，对不同的项目子系统使用不同但可接受的功能安全性标准)。2.2.2所描述的范围内的主题都不旨在要求该物品在所描述的所有情况下都能成功提供全面的服务。相反，要求是考虑所有即时要素，并认为尽管有这些因素，风险还是可以接受的。在许多情况下，这将涉及制作排除有问题的提示元素的ODD。但是，从ODD(或类似方法)中排除提示元素会产生一种辩解，即排除本身并不会导致不可接受的风险。例：没有车道标志的未铺砌道路将被排除在ODD之外。安全案例通常认为，地理围栏和地图创建将排除所有未铺设的道路。进一步的论点是，这种排除包括快速识别正在进行暂时未标记但仍载有交通的翻新工程例：奇数扫描仪中不包括雪。雪仍然是安全案例的一部分，以覆盖在执行任务期间发生的不可预测的雪。安全案例通常认为，尽管有雪，它也可以通过车道内停车成功终止任务。它还进一步证明(有证据),在部署地点很少会下雪，以至于偶尔的行车道内停车所造成的产品风险升高是可以接受的。2.3范围限制2.3.1该标准的一个重要范围限制是它没有涵盖与确保人员能够为一个自治项目提供有效的安全监督有关的详细主题。而是，覆盖范围仅限于无人监督的完全自主操作，以及在人为监督的操作过程中与争论人为监督效力无关的项目方面。同样，操作人员安全地控制项目的能力的方面也超出范围，更具体地说，以下内容明确地超出了本标准的范围：a)项目控制方面的控制点不在项目本身之外的项目方面以及项目级别的安全性例子：远程操作模式的端到端系统级安全性(包括人员监督者或驾驶员)被排除在其依赖于人员远程操作者控制，监督或确保系统安全的程度。注意：产品级别的“项目”旨在包括参与车辆控制的外部功能，例如基于云的路线计划系统。注意：对远程操作命令的正确响应以及远程操作数据从车辆中正确传输的范围。但是，由于人类参与了驾驶任务，因此遥操作在系统级别上实际上是否安全超出了范围。b)与切换或模式切换期间或之后的安全相关的人为因素，使人员应对动态控制任务的安全负责。例：确保有人力监督员并能够根据要求安全地接管项目操作并在部分或全部自治功能被禁用时继续安全地操作车辆的细节超出了范围。c)为人类对动态驾驶任务的贡献而采取的降低风险或其他安全论据功劳(例如，人类驾驶员，人类安全主管，人类远程操作员，人类机敏性问题，人类境况意识问题)。2020年4月1日UL46009例：应该如何为远程操作员提供安全有效的人机界面的细节不在讨论范围之内。d)原型车的道路测试应达到一定程度，以确保安全论点应归功于人类执行和/或监督动态驾驶任务。e)有关如何确保人员可接受地满足对物品安全中非驾驶角色的期望的细节。明确地说，识别人员对安全案例的贡献(例如，通过执行检查或人员正确感知和解释项目提供的信号的能力)属于范围内。但是，在人的行为，心理，局限性等方面，详细说明如何实际确保以可接受的方式进行贡献的细节超出了范围。虽然能力框架，员工技能列表和经验要求可能是涵盖安全案例的有用主题，但有关这些主题的详细信息不在本标准范围内。f)有关如何评估人机界面设备的适用性和有效性的细节。明确地说，识别此类设备的需求以及确保适用性和有效性的需求不在范围之内，但是对如何满足该需求的特定要求则不在范围之内。例：在执行任务的任何情况下，处于自动操作状态的汽车均不应将车辆控制权转移给乘员。实际上，它确实尝试将车辆控制权转移给乘员，并提供三秒钟的警告。在UL4600范围内：车辆在不应该尝试的情况下尝试向驾驶员进行交接。在UL4600范围内：不正确地尝试转移控制权而违反了完全自主的操作模式。超出UL4600的范围：三秒是否足以警告有效切换，以及乘员是否是合格的驾驶员。例：自动驾驶汽车被设计为在某些情况下，当驾驶员合格，称职并知道此越区切换任务参数时，会以10秒的警告将控制权转移给驾驶员。在UL4600范围内：在没有发出整整10秒警告的情况下转移控制权；设计有缺陷的制动控制机制，在某些情况下会阻止驾驶员实际在指定时间重新获得控制权(例如，尽管试图进行换手，驾驶员的制动踏板仍被禁用);人为操作制动踏板是否旨在在指定条件下启动切换。超出UL4600的范围：在任何特定的切换情况下，十秒是否足以警告有效切换；驾驶员踩下制动踏板是否是安全的(从人为因素的角度出发)切换启动机制；检查乘员是否是合格的驾驶员；检查驾驶员是否具有足够的认知能力以安全操作；检查驾驶员是否处于正确的座位位置以进行操作控制；一旦控制权转移给驾驶员，车辆的安全性；高级驾驶员辅助(ADAS)的功能可降低人为驾驶员控制下的风险。2.3.2还有许多其他主题超出范围。在与安全情况相关的地方，应参考这些主题，但本标准中不包括诸如提供技术深度的提示元素之类的细节：a)特定的预期功能(例如，表面清洁，易碎货物运输)b)最终产品要求注意：最终产品标准旨在参考或要求该标准。c)法律和政策问题例子：确定责任，什么记录保留政策是适当的，什么水平或产品风险实际上是社会可以接受的。d)伦理道德问题例子：解决可接受风险的问题，评估不同损失事件场景的相对严重性e)电动汽车安全例子：安全的电池设计，安全的电池管理算法，电池热量管理f)通用车辆安全例子：减轻碰撞，约束乘员，加油/充电安全g)执行预期功能的与安全无关的质量方面例子：骑行品质，燃油经济性h)碰撞和伤害缓解机制的有效性例子：安全带，安全气囊，儿童座椅2.3.3同样隐含地重新定义了现有标准和可接受的做法，以至于可以接受它们以支持正在制定的安全案例。在与安全情况相关的地方，应参考这些主题，但具体内容不包括在本标准中。这些主题包括：a)政府规章例子：FMVSS,联邦通信委员会射频干扰发射认证b)项目的机械方面例子：尖锐边缘，夹点，车窗提升电机关闭压力极限c)旧版操作程序例子：车门操作，车门上的儿童锁，货物装卸d)正常运行以外的其他车辆支持的详细信息(除非自动驾驶有望提供这种支持并且这种提供与安全有关)例子：在不构成危险的情况下对与安全无关的例行维护程序的自治支持e)人在操作或监督动态驾驶任务时控件的充分性和性能以及项目响应例：根据FMVSS的要求2020年4月1日UL4600113.1规范性引用不适用日期的引用文件，其最新版本(包括所有的修改单)适用于本标准。DefStan00-56,国防系统安全管理要求FAAAC25.1309-1A,系统设计和分析FAAFOIEEE24765,系统和软件工程-词汇ISO26262:2018,道路车辆-功能安全ISO/PAS21448:2019,自动驾驶的安全第一；由11个汽车和移动行业领导者发布的-用于安全自动乘用车的首个框架：SCSC-153A,自治系统的安全保证目标-英国安全关键系统俱乐部；注意：本文件由自治系统安全工作组(SASWG)撰写，该工作组在英国SCSC的主持下召集。SASWG的目标是针对整个生命周期中如何在与安全相关的上下文中管理自治系统和自治技术提供明确的指导，以紧密关注自治所独有的挑战的方式。该文件旨在解决仅基于机器学习的人工智能(Al)带来的安全问题，计划于2020年2月11日至13日在SSS'20上正式发布。链接到文档：https://scsc.uk/SCSC-153A。4术语，定义和文档使用4.1如何解释规范性元素(规范性)4.1.1该标准的常用结构对安全情况的影响如下。除“EXAMPLE”和“REFERENCE”语句以及明确声明可提供信息的任何其他内容外，所有元素都是规范性的。(有关关键安全案例偏差说明的摘要，请参见下面的表4.1。)a)带编号的条款(从5.1.1开始)通常被称为“应”遵守义务。这些旨在作为一般性说明，并带有支持性的提示性提示元素，可提供更多详细信息。除了在第17节中涉及处理在安全案例本身上进行的活动的一致性评估过程条款外，每个条款都在安全案例中得到专门解决。安全案例可导航性的重要组成部分是识别安全案例中支持满足每个条款的部分的能力。除非另有说明，否则所有条款的范围均为该项目中与安全相关的部分。b)强制提示元素：由安全案例解决。不允许出现安全案例偏差。任何安全情况下的偏差都会导致不符合项。例：“确定危害”是强制性的-必须做到。例：一个团队试图证明强制性提示元素X不适用于他们的项目。这是对安全案例偏离的无效尝试。注意：在某些情况下，强制提示元素是指以分层方式考虑其他子句。应将其解释为在安全性论点中强制性包含相关的更高级别的主张，而不是强制性地包含所引用条款的所有非强制性提示元素。尤其是，此类层次结构引用无意覆盖安全案例偏离规则。例：强制提示元素X指出，安全情况解决了Y部分。Y部分具有高度推荐的提示元素Z。最终要求是，必须通过安全案例来满足Y部分中所有条款的要求，但是根据其高度推荐类别，仍然允许对提示元c)所需的提示元素：由安全案例解决。仅当通过提示证明提示元素与项目和/或其安全案例本质上不兼容时，才允许发生安全案例偏离。安全案例中明确指出了对每种安全案例偏差的支持。最终产品标准可以枚举从安全案例中可以忽略的必需元素(即，最终产品标准指定的全面默认安全案例偏差)。如果未对REQUIRED元素记录安全案例偏差，则该安全案例不符合要求。由于非固有不适用性原因导致的安全案例偏差会导致不符合项。现场工程反馈和变更影响分析用于检测内部不兼容声明无效的可能性。可接受的安全案例偏差示例包括：例：如果项目未以任何方式(包括设计，操作和现场操作数据分析)使用基于机器学习的技术，则对机器学习要求的安全案例偏差。例：如果项目不以任何与安全相关的方式依赖于路标，则安全案例会偏离识别路标。支持这一观点的论点可能是，ODD专门排除了道路标志，或者该项目仅使用道路标志以外的其他手段来收集等效信息。例：如果项目未定义ODD子集，安全情况就会偏离特定于将ODD细分为多个ODD子集的要求(即，如果某项使用单个整体ODD,则与ODD子集相关的任何要求均不适用)。例：数据尚不存在，因为在项目生命周期中从未发生过潜在事件或状况。例如，如果尚未部署任何物品，则记录纠正在物品操作过程中发现的缺陷的记录。但是，对于收集和处理此类潜在事件的机制和程序，不允许出现安全案例偏差-只有在发生现场事件之前，安全案例内容的一部分才存在。好的做法是包括明确指定的占位符示例，以填充空数据集，以练习工具，过程和可追溯性。d)高度推荐的提示元素：这些是应该遵循的最佳实践，但可以省略，尤其是对于低风险项目。安全案例中明确指出了遗漏，并提供了合理的支持理由，以提供一个根源，以便将根本原因分析追溯到这些遗漏。只要以合理的理由记录了这些遗漏，就可以认为该安全案例是可以接受的。在包括“其他”的通用提示元素的情况下，省略“无其他”的理由是可以接受的。现场工程反馈的主要目的是确保确定对安全相关问题有实质性贡献的任何提示要素的安全案例偏差，并消除偏差。例：强烈建议使用特定的分析技术。安全案例指出，该技术未与“正在使用的其他分析技术可提供可比信息”的原理一起使用。该安全案例包含一个论点，即不存在可能通过将这种技术添加到设计方法中而可以预防的根本原因未知的事件历史。此论据由根本原因分析日志支持，该日志显示所有根本原因均已解决，在没有其他不利信息的情况下，没有留下可能实际上追溯到提示元素偏离的未解决候选对象。例：强烈建议立即更改要素的理由是“2019年9月23日举行的安全案例审查会议认为这不适用。”虽然只看技术内容，但这是特定的文档，据说该文档是经过深思熟虑的过程用来决定不解决提示元素的。但是，仍然必须对现场问题进行根本原因分析，并且可能取决于现场经验而使这一理由无效。e)推荐的提示元素：这些是可选的提示元素，记录了良好做法和/或有用技术的建议。如果采用，则可以将它们包含在安全案例中。但是，解决这些提示元素完全是可选的。不论是否包含安全案例，都被认为格式良好。f)PITFALL提示元素：这些是反模式，通常具有以下一般形式：“如果X为真，则项目倾向于增加Y的风险。”预期的解释是，如果X为真(例如，在安全案例中出现了使用某些设计模式X或工程技术X),则除非已将认知失败者Y明确认定为假，否则该安全案例被视为无效。换句话说，除非安全案例提出合理的论据和减轻风险Y的证据，否则Y表示被X激活的项目风险。更正式地说，术语“陷阱”标记有条件的认知挫败者提示有关声称已满足父项要求。响应陷阱提示元素可能已完成有两种方式。(1)认为前提X不成立。对于提示元素，这相当于可接受的安全案例偏差。(2)争论了，如果前提条件X为真或可能为真，则可以减轻后置条件Y带来的风险。陷阱的安全案例偏离规则根据分类(强制，必需，高度推荐或推荐)应用。当没有争论可以避免陷阱时，就会发生安全案注意：出于评估目的，每个陷阱仅适用于列出该陷阱的特定条款的范围。但是，在创建安全性论点(Pitfalls可能产生更大的影响)时要考虑这是一个好习惯(但可选)。g)符合性声明。根据第17节，通过自我审核和独立评估来评估与每个条款的符合性。每个条款都有一个一致性声明，该声明提供了一些指南，以标识安全案例的部分内容以及与评估该条款的一致性特别相关的其他信息来源。当评估者确定情况有必要时，允许评估者考虑符合性声明之外的客观证据，但根据该条款的书面范围限制符合性判定。(自审计员可以并且应该考虑是否需要为特定项目的安全案例添加超出本标准所包含的提示元素。)一致性检查是由项目开发者以外的其他人员进行一致性检查(请参阅第17节)。(对于安全案例工件进行自我审核的情况非常有限；请参见第h)注意语句。这些是有关如何解释本节规范性要素的说明，在某些情况下还提供了理论依据。i)示例列表(非规范)。在某些情况下，提供了示例。例子是非规范性的，在许多情况下，并非适用于所有项目。它们的主要目的是通过示例定义以减少潜在的歧义。第二个目的是作为常见问题的信息丰富但不完整的清单，应酌情考虑。预期并且要求安全案例的构造和评估超出任何示例的范围。尽管在安全案例中排除示例本身并不会导致发现不符合项，但鼓励独立评估师提出其他示例，并根据评估经验在必要时建议将特定示例提升为规范的即刻要素状态。4.1.2表4.1显示了针对不同类型元素的安全案例偏差方法的摘要：状态。允许的安全案例偏离具有可接受的理由。影响分析和生命周期状态更改的可能性。所有的安全案例偏差都应记录在安全案例中并加以说明。可选项目。安全案例无需提及。安全案例偏差不需要参数支2020年4月1日UL4600154.1.3支持特定子句的列表，例如MANDATORY或REQUIRED项目的列表，按以下方式解释：a)为简洁起见，即使未明确说明，列表中每个项目的上下文也都是首要子句。这意味着列表通常会提供一组简洁和易用的提示，而不是完整说明的“应该”声明。b)除非明确说明，否则列表顺序没有隐含的排名，偏好或优先级。c)除非另有特别说明，否则所有提示元素列表都可能不完整。格式正确且完整的安全案例可根据需要扩展列表，以实现可接受的安全结果。除非另有说明，否则提示元素列表应被视为安全情况下要考虑的最少要点集，而不是所有可能要点的详尽集。d)如果不同的提示元素列表似乎重叠，则可以根据需要跟踪单个参数或证据分支到多个提示元素。一种常见的情况是，MANDATORY提示元素将提供一个通用提示元素，而一个或多个REQUIRED提示元素将给出该通用元素的特定示例，以确保在适用时予以考虑。e)如果单个提示元素列表包含明显重叠的项目，则足以追溯到最适合开发人员的提示元素。此类重叠列表通常用于解决跨域和子域的潜在不同解释和术语问题。f)列表中的每个提示元素均按规定的安全案例偏差严格程度进行说明。因此，如果需要针对单个“必需”部分的十个元素列表进行安全案例偏离，则安全案例以一种可单独追溯到列表中十个提示元素中每个元素的方式记录安全案例偏离。(有关安全案例偏离的单一理由说明可能追溯到十个要素中的某些或全部，但必须记录可追溯性。)g)短语中的“至少一个”包含替代项的子列表。在安全情况下，只需要解决列表中的一个备选方案，但是如果需要，可以另外解决其他方案。即使“强制性”或“必需”列表中出现“至少一个”,也是如此。请注意，在某些情况下，由于Pitfall语句，实际上可能需要两个或多个提示元素。未列出的替代方案可以被视为满足“至少一项”标准，并在可接受性方面提供适当的论据支持。(这是根据提示元素列表不被认为是详尽无遗的原理，因此，安全案例可以根据这些提示元素列表的本地版本添加提示元素。)h)清单项目的“裁缝”必须遵守上面表4.1中汇总的安全案例偏离规则。4.1.4为了简单和统一起见，尽管对部分本身进行编号时使用了印刷约定，但对部分，子句和提示元素的引用仍使用十进制表示法。4.1.5关于提示列表的范围，另请参阅2.1.6。4.2术语和定义(规范性)4.2.1可以接受足以达到在安全情况下确定的整体项目风险。例：“可接受的测试范围”是指测试范围足以支持获得安全隐患减免信用后安全案例对整体项目风险的声明。注意：这是与安全案例的有效性和完整性相关的客观术语，而不是与任何特定评估者的个人观点相关的主观术语。4.2.2激活(故障或危险)导致系统由于故障或危险而潜在故障的输入或情况。例：内存中的某个事件被单个事件破坏损坏了，这是一个错误。当读取存储位置时，该故障将被激活，并导致计算错误，该错误会导致不正确或不安全的项目行为形式的故障。注意：错误缓解(例如错误检测编码)以及其他缓解措施可以防止激活的故障引起故障。4.2.3人工智能技术计算算法和其他技术的一般描述，包括归纳学习，有意的非确定性行为，基于规则的系统，计算机视觉，启发式搜索和其他技术。这些通常称为“人工智能”技术。注意：该术语旨在作为广义解释的描述性术语，以涵盖通常不适合于Al之前的软件安全方法的软件。是否实际涉及实际的“智能”是超出本标准范围的问题。构造满足特定要求的安全案例(包括主张，论据和证据)。由此产生的论据表明，证据支持了这些主张。例：“开发人员应辩称所有危险已得到缓解”指示开发人员在安全案例中包括主张，论点和证明每种危险实际上已得到缓解的证据。一个或多个执行评估的人。审查和评估安全案例。4.2.7自动化的无需人工监督或干预即可操作。2020年4月1日UL4600174.2.10(系统的)脆性4.2.11(系统的)混沌4.2.14危险等级4.2.15示范4.2.19故障模型执行故障分析时要考虑的所有故障(及其类型)的规范。4.2.20现场工程反馈从系统操作中获取数据，以支持安全案例并识别潜在的安全案例问题。创建一个响应于子句的指定类别，属性或子句其他方面的枚举列表，并具有足够的特异性以启用评估。(备用字词形式：标识)发生可能导致损失事件的安全相关故障注意：事故不一定会导致损失事件。在其他情况下，事件可能导致损失事件就足够了。例：汽车未能在停车标志处停车。没有交叉路口，因此没有碰撞结果。如果存在交叉路口，则可能发生碰撞。即使没有发生丢失事件，这也是一个事件。注意：所有损失事件也是事件。因此，短语“事件”等同于“事件和损失事件”。4.2.23独立(失败)没有相关的，共同的原因和/或共模故障情况的两个或更多个故障遏制区域(FCR)。注意：假设随着时间的推移没有累积故障，则可以通过无条件概率的简单乘积来表示同时发生故障的概率。4.2.24独立(审查和评估)没有直接激励并且没有实质性间接激励影响评审或评估过程结果的评估者或审核者(另请参见17.3.2)。评估符合UL4600的产品，元素，系统系统或其他与产品相关的范围。注意：“项目”可能需要包括基础架构，场外计算，场外数据存储，开发流程，生命周期支持流程，供应链质量保证措施以及其他确保超出已部署产品本身边界的安全性的方面。“项目”可以包括整个产品，也可以仅包括产品的一部分，但是无论如何都将包括项目中包含的部分产品的一致性所需的所有方面。4.2.26生命关键系统的一个方面，丢失事件可能会导致人员伤亡。2020年4月1日UL460019注意：严格来说，这是一个严重性概念。即使开发人员认为由于操作中不大可能发生相关风险较低，危害也可能是生命危险的。人身死亡，人身伤害，动物死亡，动物伤害，财产损失，环境损害或其他重大不利后果。注意：哪些损失被认为是不利的，取决于系统。然而，人的死亡和重大的人身伤害总是被认为是不利的损失。注意：安全案例可能会选择将因项目失败而导致的财务成本也视为“实质性不良后果”。注意：“损失事件”通常对应于FAA8056.但是，术语“损失”用于避免对责任和可预见性的任何先入之见。降低到可接受的风险水平。注意：可接受风险的级别取决于所减轻的特定风险的严重性(例如，对生命至关重要而不是对生命至关重要)及其对安全案例中确定的项目级别风险的贡献。只要认为存在的风险低到可以接受的程度，而无需采取明显的缓解措施，则可以将风险降低到可以接受的低水平。“缓解”一词等同于“可接受缓解”的概念。(请参阅“可接受的”定义。)除非采取缓解措施(如果有),并且已更新有关缓解的安全案例论据(“跟踪至关闭”),否则不会认为风险已得到缓解。“可接受的风险”是指已部分缓解(或没有缓解)的风险(请参阅第5.5.1节)4.2.29非确定性注意：不确定性可能是由实时调度扰动，使用伪随机算法或其他因素引起的。也可以看看：混乱的4.2.30运营设计领域(ODD)该项目旨在在其中运行的一组环境和情况。这不仅包括直接的环境条件和地理限制，而且还包括对该环境中将发生的一组对象，事件和其他条件的表征。项目ODD的托管部分。例：全天候ODD分为天气，雨天和雪/冰的子集。注意：可以定义一个ODD子集来划分操作空间以简化设计任务，通过随着时间的推移添加其他子集来支持分阶段部署，或者管理复杂性。潜在的大变化ODD。安全案例可能会针对安全案例的某些方面独立地争论每个ODD子集。超越内置自测(BIST)功能来检测潜在故障的测试。注意：过去，证明测试是指机械测试，例如压力测试容器或移动的紧急阀，这些操作在正常系统运行期间无法完成。它们通常涉及行使故障安全措施，行使用于检测故障的传感器或进行离线测试。组件，材料，耗材，软件和项目其他方面的背景，尤其是赋予区别或质量的背景。注意：在UL4600的上下文中，这是指确定COTS产品及其组件实际上提供了所需的功能，特别是不包括劣质产品，假冒产品和其他“未经批准”的部件。这不同于提供可接受功能和其他版本控制活动的零件的变体。供应链故障，其中组件供应商会通过逐渐使用替代材料，替代组件，设计变更和/或取消保护性组件而逐渐降低组件质量，同时显然保持功能并满足测试的参数值。损失事件发生的可能性和该损失事件的严重性的组合。注意：风险通常是概率和严重性的某种加权组合，可能对概率赋予零或非线性加权。此定义并不意味着排除替代的但可比较的风险表述。即使情况超出规格，仍可以继续操作。例子：尽管收到不合规格的输入，遇到ODD违规，遭受组件故障以及遇到机器学习训练集中未表示的数据，系统仍会继续正常或降级运行。注意：健壮性通常是程度的问题，而不是绝对的属性。具有安全案例所定义的可接受的缓解后项目级风险。有证据支持的结构化论点，提供了令人信服，可理解和有效的证据，表明系统对于给定环境中的给定应用程序是安全的。4.2.39安全案例偏差2020年4月1日UL4600214.2.40安全相关4.2.41元素脱离上下文(EooC)4.2.42安全绩效指标(SPI)注意：该术语类似于术语关键绩效指标(KPI),但特定于该项目的安一般术语参考(资料性):和分类法”,IEEETrans。《可靠和安全的计算》,2004年1月至3月，第1(1)页1-23。4.3缩写和首字母缩略语(信息性的)a)Al:人工智能e)DAL:设计保证水平f)DTC:诊断故障码h)EooC:元素脱离上下文j)FMVSS:联邦机动车安全标准(美国)k)GNSS:全球导航卫星系统n)ISO:国际标准组织p)NDI:非开发项目t)SIL:安全完整性等级v)SPI:安全绩效指标x)瑞典文：软件工程知识体系y)V&V:验证与确认V2V:车对车bb)V2X:车辆之间1)使用可接受的安全案例格式(请参阅第5.2节)3)提供可接受的证据(请参阅第5.4节)4)解决可接受的风险(请参阅第5.5节)5)阐述安全文化(请参见第5:6节_2020年4月1日UL460023例子：安全情况下总结了测试结果。可根据要求提供详细信息和任何其他描述性证据。c)未进行记录或未提供的所谓安全案例的任何方面在执行评估时均会被忽略。d)除非正在执行元素脱离上下文(EooC)评估，否则安全案例将涵盖产品及其生命周期的所有与安全相关的方面，包括定制和现成的组件，软件和子系统。具体包括但不限于：1)感测器2)执行器3)计算组件例子：计算硬件，操作系统，库4)车辆平台用作添加“自治套件”的基础例：附加的自动驾驶项目工具包评估要求确保在安全案例中已解决与基础商用车辆相关的安全问题。可以考虑对平台进行以前的评估，但这可能会留下空白，除非将其专门用作自动驾驶汽车平台评估为EooC。5)在线服务例：根据需要从云基础架构向运营工具提供在线地图服务器6)物流和维护支持7)假定的基础设施支持e)没有记录和/或写下来的，没有应要求提供给评估者的所谓安全案例的任何方面，都不能用于支注意：评估员可以考虑口头陈述和不属于安全案例的其他材料，以帮助评估过程，但不能用作评估例：开发人员口头解释了为什么特定的“提示”提示元素不适用的原因，但是这种解释不是在实际的安全案例中，也不在安全案例所引用的任何文档中。即使评估者可能认为口头解释是合理的，但缺少关于该“需要”提示元素的安全案例偏差的书面解释，也会导致发现不符合项。如果更新了安全案例，则可以纠正不符合项的发现，但这不是评估者的责任。例：测试人员口头指出测试是针对正在部署的特定配置执行的。但是，实际测试过的配置文档已丢失，无法合理确定地重建。在某种程度上，对于格式良好的安全案例而言，必须对所测试的配置进行记录，评估人员必须由于缺少文件而发现不符合要求，并且可能必须重新运行测试。f)识别生命周期的任何初始部分，在此期间，安全论证无效例：该安全案例直到生命周期内首次进行公共道路测试时才适用。注意：这允许在完成原型开发和潜在的封闭式开发测试的同时完成安全案例。它无意允许在生命周期中任何时间对在公共道路上行驶的任何车辆提出符合性声明。g)安全案例的变更管理强烈推荐-不适用推荐-不适用通过考虑分段一致性检查来检查一致性，包括在安全情况下可追溯地包括每个适用的提示元素。.1注意：编写该标准是为了帮助构建格式正确的安全案例。将需要采取其他措施来确保操作安全。例如，最终产品标准可能不仅需要符合该标准，还需要符合涉及电气安全，防火和被动乘员保护等主题的.2注意：该条款明确旨在要求一致性文档包采用安全案例的形式。(即，除了行政事项以外，与评估本身有关的所有事情都是安全案例的一部分。)实际上，可能会使用各种文档，存储库和工具来提供详细信息，例如使单个工具或统一格式的数据集无法包含整个安全案例的证据。但是，评估要求能够访问任何此类材料以进行评估。.3注意：通常，本节对安全性论证的结构和内容提出要求。其他主要部分通常会在确定安全案参考：MISRA“汽车安全论点指南”,2019年。5.2安全箱样式和格式5.2.1安全案例应针对索赔，论点和证据使用定义一致的格式。a)声明和论点语法，语义以及所用任何图形元素的定义注意：符号可能没有正式定义的语义。但是，应提供有关安全案例表示法和方法的最佳可用信息，以促进在开发人员团队和评估人员之间尽可能统一的解释。b)定义证据类型，格式，数据字典和使用的模式c)评估人员访问完整的安全案例2020年4月1日UL4600251)评估者无法获得的安全案例的要素不依赖于一致性评估。a)遵守安全案例中定义的格式b)评估者可以访问任何与了解安全情况有关的可用浏览，搜索，报告和分析工具注意：实际上，开发人员和自审计人员可能会使用工具和其他支持，以使其更容易处理安全案例。这些相同的工具和其他支持可根据要求提供。c)确定有关论证归纳要素完整性的推理方法强烈推荐：a)使用既定手段以高度结构化的方式组织安全案例，例如：1)OMG结构化保证案例元模型(SACM)2)目标结构表示法(GSN)3)索赔论点证据(CAE)b)使用工具支持来辅助安全案例理解和导航a)将图形界面用于安全案例导航的相关部分，以提高导航性b)使用基于结构化文本的符号，而不是自由格式的文本，从而增加了提供工具支持的能力通过检查安全性论据，证据和设计记录来检查是否合格。.1注意：关于条款中的“一致”一词，允许层次结构参数的不同分支在原因范围内使用替代参数格式，尤其是当参数适用于明显不同的功能或子系统时。由于论证结构的原始来源不同或需要使用更适合特定论证技术挑战的技术，因此替代方案可能有意义。如果使用了多个样式，则适用于参数的每个部分的样式都对应一个明确指定的样式。5.2.2所使用的证据应符合已定义的可审核格式。强制性的：a)安全案例中使用的一组定义好的类型中每个证据的定义类型例子：模拟输出文件，测试计划，车辆数据日志注意：“类型”是指灵活的通用含义。但是，每组证据属于已定义的类型(即使每组证据都是不同于所有其他证据集的唯一类型)。然后，根据下一个提示元素，将该类型与允许解释证据的元数据b)每种证据的定义格式，至少包括：1)语法和语义，数据字段，元数据字段的定义注意：在给定证据类型和性质的前提下，将语义定义为实用。2)规范证据的一致性，正确性和完整性，以使证据可审核3)验证不是来自可接受数据的任何证据的确定方法例：可以通过整个项目生命周期中的数据收集来验证主观专家的判断。例：专家认为雷击很少发生，以至于没有相关性，因此可以作为忽略雷击风险减轻的证据，理由是有论点认为会记录部署车辆上发生的任何雷击，并将进行定期分析以检测雷击是否发生。现场数据中的频率变得过于频繁而无法忽略。(应注意的是，有据可查的是，闪电确实确实会偶尔袭击移动中的，占用的车辆，并且更合适的安全论据可能是采取某种形式的风险缓解措施来确保缓解后的风险是可以接受的。)必填-不适用强烈推荐-不适用a)用于解释每种类型证据的描述性或教程示例b)避免将自由文本作为证据的数据类型通过检查安全性论据，证据和设计记录来检查是否合格。.1注意：该条款允许每个证据具有不同的定义类型。在可行的情况下，使用少量一致类型的证据有助于简化安全案例，以提高可理解性。a)正确使用自然语言b)在主张和论点中使用一种自然语言注意：目的是在整个安全案例中使用的任何自然语言(除证据外)都应使用一种适合项目设计团队使用的自然语言。证据可以2020年4月1日UL460027例子：使用以下短语检测并进行护理：“基本上是所有”,“应该是”,“通常”例子：“没什么不同","可能不会发生安全的结果”推荐-不适用通过检查安全性论据，证据和设计记录来检查是否合格。5.3主张和论据充分5.3.1安全案例声明应涵盖所有已识别的与安全相关的危害和风险。a)以论据主张的形式定义项目安全要求1)预期功能的安全要求2)潜在意外功能的安全要求例：处于禁用维护状态时，通过调度请求响应进行的车辆移动是意外的3)必须避免的不安全行为和状态的安全要求注意：为了功能安全，通常通过危害分析来执行此操作4)缓解项目本身的故障(包括设计故障和操作故障)的安全要求5)缓解故障，异常和未指定环境条件的安全要求6)生命周期考虑因素的安全要求，包括更新，检查，维护和监视不断变化的操作环境b)将每个已识别的危害映射为可能违反至少一项相关安全要求c)确定每种已识别危害的可接受安全水平必填-不适用a)排除与已确定的危害和风险无关的索赔注意：这是向后追溯的要求，以避免与商品安全无关的索赔。注意：对于EooC安全案例，可以接受以下假设：将安全案例片段跟踪到导出的EooC边界接口，前提是至少EooC的某些用户将具有更高级别的项目安全案例，从而可以完成对已识别危害和风险的跟踪关系。通过检查安全性论据，证据和设计记录来检查是否合格。2020年4月1日UL46002.1注意：本条款中使用的术语“权利要求”是通用术语，包括子权利要求。5.3.2安全案例论据应支持所有已确定的主张。a)通过可接受的论据支持安全案例索赔b)确定用于确定论证充分性的标准a)在论证中使用认知失败者注意：其他条款中的许多提示要素是认识上的失败者。另外，对每个自变量子树的审查可以包括关于任何其他认知失败者是否适用的考虑。b)陷阱：在没有具体描述合格性评估的局限性的情况下，将其视为对安全性标准的认可就容易导致对安全属性的过度评价。(")注意：实际上，这是一个论点缺口，不支持所确定的主张。另请参阅第5.7节。c)陷阱：遵守为人类操作设备设计的安全标准的信誉容易导致隐含在自主性上的故障管理控制义注意：这是前面的陷阱所涉及到的安全评估例：在评估ISO26262符合性时，对自驾车的可控制性给予了认可，这对自主功能施加了相应的可控制性义务，以行使相同级别的控制。如果不解决这一陷阱，可能会错过为人类提供替代品以提供作为ISO26262ASIL分配的一部分而假定的可控性的需要。a)避免包含不支持已确定主张的论点b)避免包括不支持论点的证据通过检查安全性论据，证据和设计记录来检查是否合格。.1参考：(*)有关陷阱的一般信息：Koopman,P.,Kane,A.&Black,J.,“可信自主安全论点”,“安全关键系统研讨会”,英国布里斯托尔，2019年2月。5.3.3安全案例应避免争论的缺陷。强制性的：a)确定候选人相关的逻辑谬误注意：这导致在安全情况下要避免逻辑错误的清单。b)确定候选人相关的修辞手法a)避免发现逻辑上的谬误b)避免使用确定的修辞手法c)陷阱：为在不同的操作环境或不同的目的中使用的经过验证的使用过的技术而信誉，很容易使1)该陷阱具体包括COTS,旧版和EooC组件，包括硬件和/或软件(注意：见13.4节)2)该陷阱专门包括可能与组件相关的项目操作参数的更改例：Lions,J.L.,阿丽亚娜5航班501失灵，咨询委员会的报告，1996年d)陷阱：由于没有以前的故障，所以在现场工程反馈中减少故障的可能性很容易归因于折减多个故障，这些故障如果被视为一组，则实质上证明了安全案例的无效性。(*)e)陷阱：争论基于人为操作项的数据进行的自主故障分析很容易1)由操作情况触发的故障，自治项目可能会进入，操作员通常会避免2)自主项目故障可能触发的非人为错误的典型故障f)陷阱：基于事件(“意外”或其他潜在故障)的到达率，通过分析操作数据和/或测试数据来减轻1)忽略了不同类型根本原因的均值分布的其他复合因素示例：项目失败的不同类型触发事件的平均到达率的重尾分布2)忽略偶发但不可避免的常见原因事件的潜在影响g)陷阱：基于人为设计的测试计划争论测试范围很容易忽略适用于自主功能的边缘情况，但操作员h)陷阱：根据形式方法的使用来论证项目的正确性，很容易忽略证据所依据的基本假设中的任何无UL4600强烈推荐-不适用推荐-不适用点”,“安全关键系统研讨会”,英国布里斯托尔，2019年2月。强烈推荐-不适用推荐-不适用点”,“安全关键系统研讨会”,英国布里斯托尔，2019年2月。必填-不适用2)分析数据3)程序定义推荐-不适用2020年4月1日UL460033.2注意：参数结构可能包含子参数和其他支持信息。但是，每个论点分支最终都可以追溯到支持证据的至少一个要素，该要素在范围上可以广泛接受以支持提出的权利要求。证据不直接或间接(通过子参数)不支持的参数无效。5.4.2论点应包括证据的有效性。a)安全案例记录基于数据收集的实验设计或其他数据收集策略以作为证据b)确定用于确定证据充分性的标准c)争论证据足以得出可接受的安全案例1)描述使用证据来支持或反驳论点和/或主张的有效性的方式。2)关于减轻确认偏见风险的争论a)完全或部分基于以下任何证据对生命周期进行监控：1)没有专家或主观意见的支持2)数据不支持且书面公共标准文件，公共指导文件或类似引用的源不支持的现有实践3)假设条件注意：生命周期监视用于监视风险，使其达到论点依赖于观点，假设或潜在的弱证据的程度。b)确定认知上的失败者以及伴随的可废除性论据，至少包括：1)可能混淆实验变量2)数据中的潜在偏差3)数据样本数量可能不足a)包括反证和附带的论点b)包括与证据创建相关的流程合规性论证c)证据的生命周期监控基于基于共识的公共标准方法a)使用对抗性顺序测试设计方法来最大化识别ODD内的故障模式和/或紧急行为的机会通过检查安全论据，证据，证据收集设计和设计记录来检查是否合格。.1注意：实际上，该子句可能导致以下形式的参数结构：参数是有效的，因为(1)有证据支持，并且(2)证据本身是有效的。有效证据至少由客观事实数据支持。.2注意：有效地收集了潜在的认知失败者和可能收证更有可能相关。选择指南由本标准中的提示元素提供，并由开发人员的经验提供补充信息。.3注意：不受支持的专家意见包括领域专家的陈述，但未得到所提供证据的实质性支持。只要基于该基础作为证据的一部分，并且明确主张所引用作品的实验性上下文适用于其在文献中的使用，就可以认为直接基于学术论文，实质性数据等得出的观点在此意义上是受支持的。安全案例。5.4.3证据有效性的支持应涵盖该项目难以复制的方面。a)根据证据确定项目的任何不确定性和混乱方面(如果没有，则说明)a)减轻因项目及其操作环境的不确定性而导致的无效风险的论点和证据(如果没有，请陈述)例：使用并发管理机制来缓解对时间敏感的并发访问错误，使用种子化的伪随机数生成器来重现故意的不确定性行为，以测试可重复性。例：故障注入曾经使元件失效，否则在测试期间该元件很少会失效。b)减轻因物品及其操作环境混乱而导致的无效风险的论据和证据(如果没有，则说明)例：当项目行为基于较小的输入差异而发生显着变化时，测试可重个具体示例是，当障碍物正好出现在前方时，车辆是向左还是向右转向。c)所使用的任何度量均符合与SPI度量有关的特征(请参见第16节)。a)统计意义方法的使用推荐的：2020年4月1日UL460035a)使用数字双胞胎或类似技术通过检查安全性论据，证据和设计记录来检查是否合格。.1注意：非确定性意味着在相同的初始条件下(例如，由于使用了伪随机算法),商品可以以不同的方式表现。混沌意味着由于初始条件下的扰动，该项目可以以不同的方式表现，而初始条件的扰动小于验证方法的控制能力。例如，不确定性和混乱性都会导致对测试的响应不同，但都是由不同的来源引起的。一个项目可以是不确定的，也可以是混乱的。如果确认存在任何一种原因，则不必区分这些原因，但是在确定证据的有效性时必须考虑两种可能性的缓解。如果由于特定测试运行中有利的系统行为而偶然通过了测试，则不确定性和混乱行为会破坏测试结果的有效性和完整性。5.5.1应确定可接受的风险。a)确定未完全缓解的任何风险的接受标准。a)将未完全缓解到可接受水平的任何风险识别为“可接受风险”。这些包括但不限于：1)未采取缓解措施的风险例：被确定为极不可能或不可能在“现实世界”中发生的项目级安全评估潜在危害是可接受的风险，并作为未缓解的风险包含在安全案例中。2)部分缓解的风险(即未降低到完全可接受水平的风险)3)未知风险例子：“未知的未知数”,“未知的未知数”4)缓解风险的依据是不受支持的专家意见，假设或其他不尽人意的证据，并且也与标准文件等公认的行业惯例不符b)对于未完全缓解的风险(包括可接受的风险),可以描述缓解水平，并认为在项目安全案例中，缓解水平(如果有)是可以接受的。1)包括对整个项目生命周期中每种此类风险的预期结果的评估。强烈推荐：a)缓解后的风险级别表征，可以认为已完全缓解。推荐-不适用通过检查安全性论据，证据和设计记录来检查是否合格。.1注意：这包括对任何剩余的未知风险的接受，如果有信息可以支持，则应将其细分为几类(例如“已知未知数”)。可以理解，这些风险可能无法轻易量化，但是在做出部署决策时，这些风险已被接受。5.5.2应通过现场工程反馈在项目生命周期中跟踪可接受的风险强制性-不适用a)针对可接受风险的现场工程反馈，以确保实践中的风险小于或等于作为项目操作的预期结果陈述的风险水平b)现场工程反馈明确考虑了由于风险分析方面的差距而产生的风险a)自动收集事故和损失事件的现场数据，以确定每个风险的可接受风险结果是否在预期范围内符合性：通过检查安全性论据，证据和设计记录来检查是否合格。.1注意：一种示例方法是在安全案例中包括“未知风险”,将其称为“已接受风险”,说明为什么已执行可接受风险分析以允许接受由此产生的风险，并辩称根本原因分析程序明确包括识别新风险以便在野外遇到时及时将它们添加到安全案例中。5.6安全文化5.6.1必须确定开发，供应链，维护和运营的安全文化在风险识别和缓解中的作用。a)安全文