目前，自动驾驶汽车的发展在大力推进，尤其是在德国汽车行业，投入了巨额资金。铁路行业、造船业、航空业和机器人制造也在努力将其产品（火车、船舶、无人机、机器人等）进一步发展为自动驾驶或自主系统。因此，本章讨论未来自主系统的测试在哪些方面将与当今基于软件的系统的测试有所不同，并为测试程序的相应进一步发展提供一些建议。
1. 背景
全球领先的研究和咨询公司高德纳在其《2019 年十大战略技术趋势》报告中给出了如下评估：自主事物[1]：
• 到 2025 年，超过 12%的新生产车辆将具备美国汽车工程师学会国际标准 J3016 的 3 级或更高级别的自动驾驶硬件能力。
可以假设，在未来 10 年内，移动系统将征服公共空间，并在那里实现自主（或至少部分自主）“行驶”。
这些系统的自主程度取决于制造商多快能够成功地为其各自的产品配备实现自主行为所需的传感器和人工智能。
这里的主要挑战是确保这些系统足够安全，并且其设计方式能够使其在公共空间（道路交通、空域、水道）中获得使用批准。新兴系统的可接受性及其基本的社会接受度取决于这些系统对人类、动物和财产构成的潜在危害是否能够最小化并限制在可接受的水平。
必须就合适的批准标准达成共识，并且必须补充现有的批准程序或开发并采用新的批准程序。无论批准程序的具体细节如何，制造商都必须证明其自己的产品符合批准标准。
在此背景下，对这类产品进行系统且充分考虑风险的测试将发挥重要作用。欧盟委员会人工智能专家组和德国联邦交通与数字基础设施部设立的“自动化和网络化驾驶”伦理委员会在其指南中明确提出了相应的测试要求[3,4]。
因此，本章讨论未来自主系统的测试在哪些方面将与当今基于软件的系统的测试有所不同，并为测试程序的相应进一步发展提供一些建议。
2. 自主系统
在本章中，我们将“自主系统”一词理解为对能够在空间中以自我控制的方式移动（无需人类直接干预）的各种形式的车辆、交通工具、机器人或设备的统称。
这类系统的一个较早的术语是“无人系统（UMS）”[5]。这个术语强调了与需要驾驶员或飞行员在船上的传统系统的对比，也包括非自主的远程控制系统。
现代术语是“自主事物（AuT）”[6]。这个术语基于“物联网（IoT）”一词，因此传达了自主系统可以相互联网以及与互联网上的 IT 系统联网的方面，同时也传达了向（物理上）越来越小的自主事物发展的趋势。
这类系统有：
• 机动车（汽车、卡车），完全接管驾驶员的功能。
• 无人驾驶运输车辆，例如用于物流任务或生产设施中。
• 远洋船舶、船只、内河船舶和其他水上交通工具，例如用于货物运输。
• 无人驾驶水下车辆或水下机器人，例如独立在水下执行检查或维修任务。
• 无人驾驶火车、市郊火车、地铁或用于客运或货运的火车系统。
• 无人驾驶或无飞行员的飞机、直升机或无人机。
• 移动机器人、步行机器人、类人机器人，用于装配、运输、救援或辅助任务。
• 移动服务或家用机器人，例如自动割草机或吸尘器，在家庭中执行服务工作，并在必要时与“智能家居”进行通信。
尽管所有这些系统都非常不同，但它们有一些共同的特点：
• 这些是信息物理系统，即它们由“信息、软件技术组件与机械和电子部件的组合”组成。
• 它们在其操作环境中是可移动的，即它们可以自我控制其运动并自主导航。它们可以执行特定任务（例如割草）或前往特定目的地（例如“开往汉堡”），而无需事先指定任务的细节或确切路线。
2.1 自主性和自主等级
“自主”（对于无人系统）在[5]中被定义为：“无人系统通过设计的人机界面（HRI）由其人类操作员分配的任务，或通过无人系统与之通信的另一个系统分配的任务，实现其目标的综合感知、认知、分析、通信、规划、决策和行动/执行的自身能力。”
自主系统实现这些属性（感知、认知、分析等）的程度可能非常不同。为了能够根据自主程度对系统进行分类，定义了各种分类系统。
这种分类的一个著名尺度是根据美国汽车工程师学会标准 J3016 对自动驾驶的自主等级进行分类（见[2]）。下表是基于[7]
对这些等级的简化表示：美国汽车工程师学会的等级是根据驾驶员和车辆之间的任务分工来构建的。对于机器人和其他基本上无人驾驶的自主系统，需要一个更通用的定义。[5]为“无人系统自主等级（ALFUS）”定义了一个通用框架，该框架适用于所有类型的无人系统或自主系统，具有三个评估维度：
1. 任务复杂性（MC）
2. 环境复杂性（EC）
3. 人类独立性（HI）
该框架描述了如何在这些维度中的每一个维度内进行基于度量的分类，以及如何由此确定整体系统评级（“情境自主能力”）。
2.2 完全自主系统的能力
完全自主系统应该能够在无需人类干预的情况下完成预定的任务目标。对于服务机器人，这样的一个目标可能是“从厨房给我拿一瓶水”。完全自主的汽车应该能够将乘客“开往汉堡”。
该系统必须能够在其各自的环境中自主导航。并且它必须能够检测到以前未知的或临时出现的障碍物，然后避开它们（例如，通过自动驾驶汽车识别出被堵塞的道路，然后绕行），或者移除它们（例如，通过服务机器人打开挡住通往厨房道路的关闭的门）。
更一般地说，这意味着完全自主系统必须能够在一定的空间和时间半径内识别和解释情况或事件。在已识别的情况的背景下，它必须能够评估可能的行动选项，并根据任务目标选择适当或最佳选项，然后将其作为措施实施。
3. 自主系统的安全性
很明显，自动驾驶汽车或自主机器人会对其附近的人、动物、物体和基础设施构成危险。根据系统（或系统部件，例如机器人抓取臂）的质量和运动速度，危险可能是相当大的，甚至是致命的。可能的危险类别有：
自主移动系统对无关第三方的侵犯。
• 对自主系统的直接用户、操作员或乘客的侵犯。
• 系统对其轨道或操作半径内的动物造成伤害或对物体或基础设施造成损坏。
• 由系统处理或已处理的物体对其他物体造成的损坏。
• 对系统本身的损坏，例如由于操纵错误。
由于在危险情况下人类干预可能发生得太晚，或者（对于具有高自主等级的系统）根本没有计划，因此自主系统本身必须足够安全。在自主系统的整个生命周期（从开发到部署到退役）中，“安全”这个主题因此具有极高的优先级。
相关的安全等级（SIL 等级）在一系列标准[8]中进行了定义。“安全”一词在那里被定义为：
• 不存在对人造成身体伤害或对人的健康造成损害的不可接受的风险，无论是直接的，还是由于对财产或环境的损害而间接造成的。[9]。
为了确保足够的安全，系统必须具有“功能安全”：
• 功能安全是整体安全的一部分，它取决于系统或设备对其输入做出正确响应而运行。功能安全是对潜在危险情况的检测，导致激活保护或纠正装置或机制，以防止危险事件发生或提供缓解措施以减少危险事件的后果……
•……功能安全的目的是将风险降低到可容忍的水平，并减少其负面影响。[9]。
3.1. 正常运行中的安全
上述危险主要源于系统或系统部件（例如抓取臂）的运动。危险程度或相关的损坏风险取决于系统的速度和质量以及其环境的复杂性和可变性（环境复杂性）。以下例子说明了这一点：
• 对于半自主的自动割草机，例如，要割草的区域由信号线围起来。运动空间花园是一个受控环境。机器人的运动速度和运动能量较低。基于接触的碰撞检测对于障碍物检测就足够了。旋转切割刀带来的风险通过外壳和检测机器人抬起或刀片堵塞的传感器被保护在可接受的水平（对于在受控环境中操作）。
• 对于完全自动驾驶的汽车，运动范围是开放的。运动速度和动能可能非常高。汽车在有限的空间内与许多其他道路使用者同时行驶。任何类型的障碍物都可能随时“出现在”路线上。规避是“正常运行”的必要部分。为了安全驾驶并遵守交通规则，需要极其可靠、快速、具有预测性的障碍物检测。
当机器人与物体相互作用时，除了损坏物体或机器人的危险之外，还可能间接造成损坏。以下来自[10，第 77 页]的例子说明了这一点：
• 服务机器人被指示将盘子拿到厨房水槽。为了将盘子放在水槽附近，它认为现代陶瓷炉灶面是更好的表面，并将盘子放在那里……如果现在一个烹饪盘仍然很热，并且例如盘子中有一个塑料沙拉碗或一个切菜板，显然会出现一些风险。当塑料或木制物体非常靠近或在烹饪盘上的情况可以被认为不再安全，因为存在由燃烧的塑料或木材产生有毒蒸汽或火灾的潜在风险。
最坏的情况事故可能是住宅火灾，导致人员伤亡。如果这些物体与烹饪盘有一定的安全距离（有一定的安全余量），并且与烹饪盘的状态无关，那么风险就不存在。
• 服务机器人被指示“给植物浇水”。在这种情况下，假设一个电源插头掉进了花盆里……如果机器人正在给植物浇水，就会对人和机器人产生触电的风险。风险因素可以考虑如下：物体识别在握住水壶（或任何植物浇水设备）时再次识别到电源插头，此外，可以检测到水壶（或类似设备）中有水。因此，应该集成一条规则，指示机器人不要拿着水壶太靠近电源插头等，以避免被水射流击中。
为了在功能上安全，高度或完全自主的系统因此必须具有适当的能力和策略，以识别潜在危险的情况，然后对情况做出适当的反应，以避免迫在眉睫的危险或尽可能地将损坏最小化。烹饪盘和给植物浇水的例子清楚地表明，仅仅进行障碍物检测并不总是足够的。在具有复杂可能任务的自主系统的复杂操作环境中，只有在对因果关系有一定“理解”的情况下，才能识别某些危险。
这样的能力和策略必须是高度自主系统“智能”的一部分。预期的系统功能和必要的安全功能不能分开实现，而是同一枚硬币的两面。
3.2. 故障模式下的安全
如果自主系统的部分部件出现故障、损坏或不能按预期运行（由于硬件故障，例如传感器的污染或故障），那么系统造成损坏的危险自然比在正常运行时更大。
如果出现软件“未预期”的（罕见）环境情况，或者导致系统中迄今未被检测到的软件缺陷生效，这可能会将原本无害的情况转变为危险情况，并且/或者使现有的安全功能失效。
对于传统的非自主安全关键系统，通常可以通过“故障安全”策略实现足够安全的行为。这意味着系统的设计方式是，在发生技术故障时，系统关闭或其操作停止，从而大大减少或消除直接危险（对用户或环境）。
这种方法对于自主系统来说是不够的！如果一辆自动驾驶汽车在一个重要传感器出现故障时“停在路中间”，那么汽车会增加而不是减少它所构成的危险。因此，自主系统应该具有适当的“故障运行”能力（见[12]）。一辆自动驾驶汽车应该像人类驾驶员一样行动：驶向路边，停在那里，并通知故障服务。
4. 测试自主系统
自主系统的测试在哪些方面与当今基于软件的系统的测试不同？为了回答这个问题，我们考虑以下子问题：
• 需要涵盖哪些测试主题？
• 需要哪些新的测试方法？
• 对测试过程的哪些要求会变得更加严格？
4.1. 质量特性和测试主题
测试的目的是建立对产品满足其利益相关者（客户、制造商、立法者等）要求的信心。“那些利益相关者的需求（功能性、性能、安全性、可维护性等）正是在质量模型中所代表的，质量模型将产品质量分类为特性和子特性。”[13]。这个 ISO 25010 [13]产品质量模型区分了以下八个质量特性：功能适用性、性能效率、兼容性、可用性、可靠性、安全性、可维护性和可移植性。
在为测试自主系统创建测试计划或测试用例目录时，可以将这些质量特性作为起点。当然，在这些质量特性中的每一个特性中，都必须单独分析被测试系统应该满足哪些具体要求，以及因此应该通过测试用例详细检查什么。
利用这种方法，2018 年作为 imbus AG 和德国人工智能研究中心（DFKI）合作项目的一部分，为德国人工智能研究中心的移动机器人“Mobipick”创建了一个测试计划。测试内容记录在基于云的测试管理系统[15]中，并提供给 DFKI 的科学家和项目团队。以下列表参考这个案例研究，以说明在测试自主系统时需要考虑哪些主题和问题：
• 功能适用性：必须检查系统的功能特性是否“完整”、“正确”和“适当”地实现。系统的每个单独组件的功能都会受到影响（在较低级别）。在最高级别，应测试整个系统完成其任务的能力。例如，“Mobipick”的测试用例集中在“导航”和“抓取”功能以及由此产生的任务模式：接近目的地的物体，抓取它，在另一个位置捡起并放下它。测试功能还必须包括测试系统的负载限制！例如，抓取的限制可能是机器人在处理重物时翻倒或偏离其行驶方向。这样的边界情况以及系统在这种边界情况下的行为也必须被考虑和检查。
• 性能效率：必须检查系统及其组件的时间行为和资源消耗。
– 关于时间行为的可能问题是：在特定时间段内或以特定（最小/最大）速度执行功能（例如障碍物检测）或任务（物体接近、抓取和捡起）是否是预期的？
– 关于资源消耗（例如电池电量）的可能测试是：在充满电的情况下运行最长的应用场景以检查电池的续航能力；在电池电量低的情况下启动任务以检查电量耗尽的行为；在电池电量低且距离充电站不同距离的情况下启动任务以检查充电站位置并估计到充电站的功耗。
• 兼容性：这涉及系统自身组件（传感器、控制器、执行器）之间的互操作性以及与外部系统的兼容性。可能的问题是：最初或更新后带到机器人上的控制软件能否正确接收传感器数据、处理它并控制执行器？机器人组件之间或与外部系统的通信协议是否兼容？
• 可用性：用户有哪些操作机器人或与机器人通信的可能性？如何向机器人下达命令？在操作错误和无法理解命令的情况下是否有反馈消息？机器人如何传达其状态？使用哪些通道和媒体进行传输：通过机器人上的触摸屏、通过 WLAN 上的应用程序还是通过语音控制？这也包括物体的处理：机器人能否足够准确地将抓取的物体交给用户？
可靠性：可靠性是系统在一定条件下在固定时间段内保持其曾经达到的质量水平的能力。测试主题可以是：机器人能否连续多次重复一种行为而不出错，或者在连续运行中关节是否会错位？机器人能否在一定程度上容忍/补偿（硬件）错误？
• 安全性：检查系统对不想要的访问或对系统或其用户的数据或整个系统本身的犯罪攻击的抵抗力。问题可以是：
– 操作员需要密码才能打开吗？这有多安全？对于像“Mobipick”这样的自主机器人，最高的安全风险来自控制模式。对给予系统的命令进行操纵越容易，恶意接管或关闭系统就越容易。机器人是通过 WLAN/无线电操作的吗？系统与系统内部的数据交换是否加密？第三方是否可以读取、可能接入数据流量并操纵甚至接管系统？自主系统的未经授权接管可能会产生严重后果，在极端情况下可能被用作武器。因此，安全功能始终是与安全相关的功能！
– 为了能够在发生事故时澄清责任问题，立法者已经要求自动驾驶车辆在运行期间记录使用数据。在德国，这些数据必须保存 6 个月（见[16]）。预计其他自主系统也会有类似的要求。因此，系统符合 GDPR 的数据安全，以及相关的（基于云的）计费或管理系统，是另一个重要问题。
• 可维护性：如果软件和硬件是模块化的，并且各个组件是可重用且易于更改的，那么就具有良好的可维护性。在这种情况下的问题是：如何管理软件和硬件之间的依赖关系？软件是否识别它需要哪些硬件？更新机制是如何工作的？是否定义了在更改后要执行哪些回归测试？
• 可移植性：乍一看，机器人的软件在很大程度上只能非常有限地转移到其他机器人类型，因为它是针对硬件平台和相应固件的特定条件进行了强烈调整。
– 另一方面，单个软件组件（例如用于导航）是通用的或基于库的。必须测试在具体机器人（例如“Mobipick”）中使用的库在这个特定平台上是否实际无误地工作。
– 自主系统本身也可以“移植”或修改以用于其他（非最初预期的）环境。例如，通过安装额外的传感器和相关的评估软件。
这些例子表明测试一个自主系统是多么复杂和耗时。“功能安全”不只是“功能适用性”的一个子项！ISO 25010 [13]中的八个质量特性中的每一个都包含一些方面（尤其是在存在弱点的情况下），这些方面会影响系统是否能够被评估为“功能安全”。对于“安全性”这个主题来说尤其如此。
4.2. 机器学习的影响
高度自主系统的智能将在很大程度上基于学习算法（机器学习）。学习将不仅限于系统的开发阶段（学习系统）。从一定的任务复杂性和环境复杂性开始，自主系统将有必要从其在正常运行期间收集的数据中学习（自学习系统），从而不断改进其行为或使其适应罕见情况。这给此类系统的开发、测试和批准带来了全新的问题：
如果要求机器人能够学习，这就揭示了在确保机器人安全行为方面的其他问题。学习能力意味着学习系统会因学习过程而发生变化。因此，系统行为不再仅仅由其初始（设计）结构决定，并且不再仅仅是由于出现故障而导致的结构偏差才值得关注。学习改变了系统结构；因此，其行为也可以由新学到的方面决定。与安全相关的知识的剩余不完整性在于系统与最初设计的版本不同。[10，第 131 页]
测试部门面临新的问题：如何测试一个系统正在学习正确的东西？检查某些事实是否被正确学习的测试用例是什么样子的？如何测试一个系统通过例如忘记错误或过时的信息或抽象其他信息来正确处理所学知识？如何测试（例如对于机器人汽车）自学习软件遵循特定的道德规则？如何制定测试策略和测试用例，使其能够处理人工智能系统行为的“模糊性”？[17]
关于自学习系统的引入，保护用户的身体完整必须是重中之重……只要没有足够的确定性表明自学习系统能够正确评估这些情况或遵守安全要求，就应该规定将自学习系统与安全关键功能分离。因此，在当前技术水平下，自学习系统的使用仅可用于与安全不直接相关的功能。[4]
4.3. 新测试方法：基于场景的测试
自主系统的特点是它能够独立地朝着给定的任务目标前进并实现该目标。系统为此必须解决的子任务可以表述为测试任务，如下所示：
• 感知：系统能否捕获与其任务相关并在其环境中出现的信号和数据？认知：它能否根据信号和数据识别模式或情况？
• 分析：它能否识别适合相应情况的行动选项？
• 规划：它能否选择适当或最佳的行动选项？
• 行动：它能否正确且及时地实施所选行动？
对这个任务链的系统测试需要一个尽可能全面的相关情况目录。这些情况必须能够在许多参数上进行变化（类似于在测试经典 IT 系统时的不同等价类）：例如，“Mobipick”服务机器人应该能够在不同的光照条件（日光、明亮的阳光、夜间）和不同的门材料（木门、玻璃门、金属门）下将关闭的门识别为障碍物。
必须能够将这些情况链接到场景中（连续的情况），以便有针对性地产生特定情况，以便能够检查替代行动路径，也以便能够检查特定情况随时间的发展以及自主系统的及时、前瞻性行动。
这种对系统在一系列情况中的行为的测试被称为“基于场景的测试”。[4]提出“……将相关场景转移到中立权威机构的中央场景目录中，以创建相应的普遍有效的规范，包括任何验收测试。”正在致力于此类场景交换格式的标准化。ASAM OpenSCENARIO“……定义了一种用于描述驾驶和交通模拟器动态内容的文件格式……。该标准在情节串联图板中描述车辆操作，情节串联图板被细分为故事、行为和序列。”[18]。
基于场景的测试要求在大量不同的测试环境变化中重复相同的测试过程。然而，在测试经典软件或 IT 系统时，测试环境是恒定的或仅限于少数预定义的变体。如果 IT 系统在这些环境中成功通过测试，它可以被认为适合使用，风险较低或可接受。
如果一个机器人或自动驾驶汽车仅在一个或几个测试环境中通过测试，该系统可能仍然完全不适合实际操作，甚至构成极大的安全风险。因此，在测试自主系统时，系统地改变测试环境是测试策略的一个重要且决定性的部分。
4.4. 对测试过程的要求
“复杂的信息物理系统”与“任务复杂性”和“环境复杂性”的结合导致了潜在可测试场景的天文数字。这些场景中的每一个又由情况序列组成，在各自的系统状态、环境情况和系统的潜在行动选项方面都有变化的可能性。由于安全要求不是孤立的“测试计划的子章节”，而是存在于所有场景中，因此通过确定优先级和省略场景来减少测试工作量是困难且有风险的。
在实际中仅测试一个这样的场景可能需要巨大的努力（需要一个安全的测试场地，并且改变测试设置以及随后在该场地进行的重复测试运行需要大量的努力和时间）。很大一部分必要的测试必须并且将以模拟的形式进行。然而，一些场景总是必须在实际中另外进行。因为模拟可能容易出错，并且它们通常在物理上不完整。
为了节省时间和确保安全，一个重要的措施是将测试一致地向左移到尽可能低的测试级别，并在开发过程中在所有测试级别上并行进行持续测试：在每个单独组件的级别、每个子系统的级别以及系统级别。测试驱动开发和对安全关键组件的形式验证将发挥越来越重要的作用。对运行中的系统进行持续监测（“向右移”），并在必要时对现场问题快速做出反应，也将是不可或缺的。在欧盟委员会可信赖人工智能伦理准则中明确提出了相应的要求：“系统的测试和验证应尽早进行，确保系统在其整个生命周期中，特别是在部署后按预期运行。它应包括人工智能系统的所有组件，包括数据、预训练模型、环境以及系统整体的行为。”[3]。
所有测试级别的测试内容和测试结果以及来自车队运行的数据必须由测试管理持续进行监测、评估和检查，以便能够识别测试覆盖范围中的差距，同时也减少冗余。独立第三方的测试将被赋予显著更高的重要性。在这方面，[3]也提出了建议：“测试过程应由尽可能多样化的人群设计和执行。应开发多种指标，以涵盖从不同角度进行测试的类别。由可信赖且多样化的‘红队’进行的对抗性测试，故意试图‘破坏’系统以发现漏洞，以及‘漏洞赏金’，激励外部人员检测并负责任地报告系统错误和弱点，可以被考虑。”。
5. 展望
来自经典软件和 IT 系统测试以及传统安全关键系统或车辆部件领域的程序和最佳实践，对于自主系统的测试仍然有效。一个核心问题是如何保证和测试自主系统的功能安全。预期的系统功能和必要的安全功能不能分开实现，而是同一枚硬币的两面。
因此，在测试过程中不可能将功能和安全方面分开。
自主系统的制造商需要程序和工具，借助这些程序和工具，他们可以无缝地测试此类产品的功能和安全性，但同时又要以经济上合理的努力进行测试，并向批准机构证明。
一种方法是基于场景的测试。场景可用于对自主系统的使用情况和任务过程进行建模和描述。然后，这些场景可以用作在模拟或实际中进行测试的测试指令。
除了场景格式或场景语言的标准化之外，还需要工具来捕获和管理场景。需要开发此类场景编辑器、模拟工具、测试台和测试管理工具之间的集成。这样的工具或工具链还应有助于系统地创建场景变体，并自动评估场景和测试，例如关于安全相关性和实现的测试覆盖范围。
References
Gartner “Top 10 Strategic Technology Trends for 2019: Autonomous Things”, Brian Burke,David Cearley, 13 March 2019
Taxonomy and Definitions for Terms Related to Driving Automation Systems for OnRoad Motor Vehicles, SAE - On-Road Automated Driving (ORAD) committee, https://
saemobilus.sae.org/content/J3016_201806/Independent High-Level Expert Group on Artificial Intelligence – set up by the European Commision, Ethics Guidelines for Trustworthy AI, 04/2019. https://ec.europa.eu/futurium/en/ai-alliance-consultation/guidelines
Automatisiertes und Vernetztes Fahren - Bericht-der-Ethik-Kommission, Bundesministerium für Verkehr und digitale Infrastruktur. https://www.bmvi.de/SharedDocs/DE/Publikationen/DG/bericht-der-ethik-kommission.html (2017)
Autonomy Levels for Unmanned Systems (ALFUS) Framework Volume I: Terminology,
Version 2.0, Autonomy Levels for Unmanned Systems (ALFUS) Framework Volume II:
Framework Models Version 1.0, https://www.nist.gov/el/intelligent-systems-division-73500/cognition-and-collaboration-systems/autonomy-levels-unmannedhttps://en.wikipedia.org/wiki/Autonomous_things
https://de.wikipedia.org/wiki/SAE_J3016
IEC 61508:2010, Functional safety of electrical/electronic/programmable electronic safetyrelated systems - Parts 1 to 7, https://www.iec.ch/functionalsafety/
IEC 61508 Explained, https://www.iec.ch/functionalsafety/explained/
Safety of Autonomous Cognitive-oriented Robots, Philipp Ertle, Dissertation, Fakultät für Ingenieurwissenschaften, Abteilung Maschinenbau der Universität Duisburg-Essen (2013)
Eimler, S., Geisler, S., Mischewski, P., Ethik im autonomen Fahrzeug: Zum menschlichen Verhalten in drohenden Unfallsituationen, Hochschule Ruhr West, veröffentlicht durch die Gesellschaft für Informatik e. V. 2018 in R. Dachselt, G. Weber (Hrsg.): Mensch und Computer 2018 – Workshopband, 02.–05. September 2018, Dresden
Temple, C., Vilela, A.: Fehlertolerante Systeme im Fahrzeug – von “fail-safe” zu “fail-operational”.https://www.elektroniknet.de/elektronikautomotive/assistenzsysteme/fehlertolerante-systeme-im-fahrzeug-von-fail-safe-zu-fail-operational-110612.html (2014)
https://iso25000.com/index.php/en/iso-25000-standards/iso-25010
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH (DFKI), Robotics Innovation Center, Robotersystem Mobipick. https://robotik.dfki-bremen.de/de/forschung/robotersysteme/mobipick.html
Cloudbasierten Testmanagementsystem der imbus AG. https://www.testbench.com
Deutscher Bundestag, Straßenverkehrsgesetz für automatisiertes Fahren, Drucksache
18/11776 vom 29.03.2017. https://www.bundestag.de/dokumente/textarchiv/2017/kw13-deautomatisiertes-fahren-499928,http://dip21.bundestag.de/dip21/btd/18/113/1811300.pdf
Flessner, B.: The Future of Testing, imbus Trend Study, 3rd edition. https://www.imbus.de/downloads/ (2017)
ASAM OpenSCENARIO. https://www.asam.net/standards/detail/opensce nario/
