内容提要：本文提出了一种基于ROS架构证据的认证方法，该架构符合ISO 26262及其SEooC组件定义。这种基于ROS的架构正在接受测试，以确定在整个开发生命周期、安全档案定义，特别是在认证阶段使用的特征和阈值。

摘要

机器人操作系统（ROS）开始在汽车行业中使用，成为部署在汽车上的组件。然而，它的使用根据参数而变化，并且其可靠性取决于这些数值和使用模型。本文提出了一种基于ROS架构证据的认证方法，该架构符合ISO 26262及其SEooC组件定义。这种基于ROS的架构正在接受测试，以确定在整个开发生命周期、安全档案定义，特别是在认证阶段使用的特征和阈值。最后，我们概述了此类组件基于ISO 26262的认证流程。

1.简介

如今，所谓的自动驾驶汽车正在流行。它们的核心功能依赖于先进的软件和硬件能力。媒体和科学文献正在报道自动驾驶汽车的经验。一些汽车制造商正在使用机器人操作系统（ROS），例如BMW1。ROS是一组用于构建机器人应用程序的开源软件库。文献报道了在多个领域，甚至在汽车行业应用机器人操作系统的经验。

安全认证目前是业界的热门话题，尤其是在安全关键软件系统中。汽车电子元件（特别是嵌入式软件）的认证是汽车行业试图实现的关键目标。从这个意义上说，ISO 26262正在成为汽车行业覆盖整个开发生命周期的参考模型。我们已经开发了一些工具来支持此生命周期，例如REANA。安全认证通过满足安全标准合规所需的目标来证明软件系统具有可接受的安全性。为了成功通过认证流程，组织必须证明其开发流程及其最终产品满足一组相关标准或其参考模型。由论证和证据组成的安全档案(参考资料1，关注牛喀网公众号，后台咨询下载)提供足够的信心，表明给定的系统符合这些要求。有符合ISO 26262的安全档案经验中，讨论了使用安全档案的优点和缺点(参考资料2，关注牛喀网公众号，后台咨询下载)。CertWare也与安全关键领域的认证保持一致，并建议使用安全档案(参考资料3，关注牛喀网公众号，后台咨询下载)。

可以为汽车领域定义基于ROS的架构。机器人系统可以处理多种功能，ROS可以是开源特定组件。事实上，ROS可以用作ISO 26262第10部分定义的脱离上下文的安全元件(SEooC)，并在多个系统中重复使用。然而，为了利用这个组件，我们需要确定需求和设计假设，如图1中突出显示并由ISO 26262描述。这些假设会影响SEooC的要求和设计。

因此，我们需要表征这个基于ROS的组件，例如时序约束，以便将其用于汽车行业并满足ISO 26262要求。由于基于ROS的架构非常灵活，因此可以修改一些参数以产生不同的操作配置文件。

图1：假设与SEooC之间的关系

本文提出了一种基于ROS架构证据的认证方法，该架构符合ISO 26262及其SEooC组件定义。这种基于ROS的架构经过测试，以确定在整个开发生命周期、安全档案定义，特别是在认证阶段要使用的特征和阈值。最后，我们概述了此类组件基于ISO 26262的认证流程。事实上，该组件可以根据一组基于ROS的架构进行参数化，这些方面可能会影响其汽车安全完整性等级(ASIL)。

本文涉及以下研究问题（RQ）：

• RQ1：基于ROS架构的时序行为是什么？基本上该组件包括传感器、控制器和执行器。我们需要了解这些元素之间如何相互作用，确定哪些阈值是可以接受的。从这个意义上说，我们需要为基于ROS的架构定义一个操作配置文件。

•RQ2：在安全档案定义过程中应考虑哪些安全方面？在对被视为SEooC的操作系统组件进行安全分析期间，我们需要确定假设和论据，以支持和推断基于ROS架构的特定实例是可接受且安全的。

•RQ3：在基于ROS架构的认证过程中，应该强调哪些方面？我们需要了解和澄清哪些证据与基于ISO 26262的认证过程最相关。

本文的其余部分的结构如下。首先提供背景分析，然后我们定义了用于汽车行业的基于 ROS 的架构，接下来我们描述ROS组件的认证过程，以及这些实验的主要结果。在讨论主要结果和研究问题后，我们总结了我们的文章。

2.背景

本节分析了在此背景下各个重要方面的背景：ISO26262认证中的SEooC、软件可靠性工程和认证、ROS和安全档案。

2.1 ISO 26262认证和SEooC

ISO 26262作为涵盖道路车辆功能安全相关所有活动的标准。SEooC概念在“ISO 26262 第10部分”中定义。

基本上，该标准支持整个开发生命周期阶段。所有这些阶段都定义了系统、硬件和软件级别的产品开发最佳实践。众所周知，汽车行业不需要基于ISO 26262的认证，但有一些文献提到了认证流程，它正在成为汽车行业的参考模型。此外，自动驾驶汽车的出现将增加该认证的相关性。在我们的背景下，我们专注于软件组件认证，特别是所谓的SEooC组件，包括硬件和软件方面。关于软件方面，ISO 26262规定了考虑时序约束等的软件安全要求规范。所有这些要求都会影响一系列广泛的ISO 26262条款，例如软件安全要求规范、软件单元设计和实现以及软件单元测试。

Jeff Voas定义了现成组件的认证流程，该流程基于质量特性分析，将组件视为黑匣子。如果组件的质量特性得到满足，则该组件被认为是可认证的。Voas的方法没有定义高质量的含义，而我们的方法通过基于ROS架构扩展了他的方法。他还认为封装可以限制其组件的行为，以及对其操作系统的分析，这也会影响组件的行为。

2.2 软件可靠性工程

Musa和Everett将软件可靠性工程定义为预测、测量和管理基于软件的系统的可靠性，以最大限度地提高客户满意度的应用科学。如今，有一些基于软件的系统，例如ROS，为关键系统提供适当的功能。软件在这些系统上发挥着相关作用。事实上，软件工程作为一门学科是基于软件的系统开发的基石。许多方面都与这些场景相关，例如调试、早期错误检测、快速恢复、长期支持、动态和静态分析以及演进。一个关键特征是它们必须在某种程度上可靠。否则，最终的产品将不能满足客户的需求，并且会影响客户的满意度。

软件可靠性理论由Musa定义，多种方法都基于该理论，例如软件可靠性增长模型 (SRGM)。从这个意义上说，有两种类型的模型：黑盒模型和白盒模型。

(1) 黑盒软件可靠性模型假设系统是整体系统。

(2) 白盒软件可靠性模型提供系统的详细视图。

基本上，软件可靠性改善模型用于故障预防、故障消除、容错和故障/失效预测。黑盒模型通常在这些测试阶段应用，这在开发过程中可能被认为为时已晚。

2.3 软件可靠性认证

定义了实现软件可靠性的基本步骤，其中主要步骤是：列出相关系统，实施操作配置文件，定义必要的可靠性，准备测试，执行测试和指导测试。类似的方法是软件可靠性工程流程，一旦确定了可靠性目标并开发了操作配置文件，我们就会继续进行软件测试、失效数据收集等。关于认证，证明软件的可靠性并不是一件容易的事，所有这些方法都需要建立操作配置文件。事实上，认证过程将考虑这些操作概况作为基础。在这种情况下，安全证据用于支持认证过程，它们也是软件组件认证的基石。Wholin和Regnell定义了针对不同使用情况的软件组件的可靠性认证（见图2）。在我们的上下文中，我们识别并描述SEooC组件的使用情况及其可靠性。这是必要的，因为在认证过程中，审核员/评估员通过可测量的属性来检查最终产品的这些特性。

图2：组件、使用模型、使用概况及其相关可靠性

2.4 机器人操作系统（ROS）

由于软件库缺乏标准化、互操作性和重用性，机器人软件长期以来一直面临工业界和学术界的问题。阻碍机器人社区产生健康的软件生态系统的最关键问题是：（1）缺乏代码重用；(2)对组件集成更高的需求；(3)在效率和鲁棒性之间找到适当的权衡。作为一种解决方案，自由软件和开源软件（FOS）计划得到推广，如机器人操作系统（ROS）计划。

特别是，ROS提供了类似操作系统的工具和软件包工具。ROS定义了不同的实体，包括节点、消息主题和服务。节点是进程或软件模块，可以通过TCP或UDP上的发布者/订阅者机制传递简单消息（或数据结构），来与其他节点进行通信。在ROS中，服务被建模为一对消息，一个用于请求，另一个用于回复。ROS有多个用不同语言（例如C++、Python、Octave或Java）实现的客户端库，以便创建ROS应用程序。它的主要优点是代码重用和共享。

ROS已成功应用于不同类型的机器人，例如自动导引车，甚至汽车行业。例如，ROS被提议支持高度自动化车辆的副驾驶系统；当系统要求时，驾驶员应在一定的时间内接管控制权，否则系统会安全地靠边停车。ROS还用于为自动驾驶任务建立防撞系统。

2.5 安全档案

目前存在一个争论，安全档案是否足以提供信心，从而认为系统是安全的。我们与其他作者一起认为安全档案是一种有用的方法，可以在安全关键应用中使用结构化论证和证据来提供足够的信心。在我们的方法中，安全档案用于在认证过程中收集主要资产。

安全档案已应用于航空电子设备等多个领域。OMG正致力于建立一个特别工作组和一个可靠性保证框架。他们发布了一个用于表示保证档案的元模型，即所谓的结构化保证档案元模型（SACM）。

3. 用于认证测试的SEooC架构

本节简要介绍所使用的ROS架构和进行的实验。

3.1 ROS描述：通过操作配置文件

需要设计软件架构，以便通过连接允许代码重用的组件来改进软件工程过程，同时在效率和可靠性之间保持平衡。这些架构应根据ISO 26262标准进行适当认证。

我们使用ROS技术实现的组件封装，旨在通过两级架构隐藏传感器和执行器：

1. 高级处理（ALP），在具有更高计算和连接能力的更高处理设备上实现

2. 低级处理 (LLP)，在功能有限的设备上实现

因此，虽然ALP节点通常通过标准接口（例如AUTOSAR 接口）与类似节点进行通信，但APL和LLP节点之间的通信可以使用专有机制。采用ROS，是为了避免低级编程细节。为了测试该架构，使用两种不同且易于使用的设备来实现：Raspberry Pi板作为ALP节点，处理从LLP节点获取的数据，使用Arduino板实现，两者都通过USB串行连接进行连接。图3提供了该架构的UML图。图4提供了该架构实现的详细表示，该架构部署在如图5所示的车辆中。

图3：UML部署图显示了我们的SEooC中的主要元素

图4：使用Raspberry Pi和Arduino实现架构

3.2 实验中使用的架构

由于这种架构的目的是构建可以连接到更广泛的系统的组件，通常用于测量或驱动目的，因此它们必须通过一组有限的选定参数在外部表示。为了简化组件的集成，至关重要的是这些参数仅代表组件行为最相关的方面，同时最大限度地包装所涉及的内部现成组件（即ROS框架）的特征，ALP和LLP层的设备。所选参数为：

1. 周期：描述ALP（Raspberry Pi）和LLP（Arduino）节点之间通信的时间间隔，单位为毫秒。

2. 粒度：表示与ROS消息传递机制相关的消息传递更新频率参数。以kHz为单位表示。

3. 队列：ROS遵循发布者/订阅者范例，将消息存储在固定长度的队列中。该参数是这些队列的内部大小。

图5：我们的Raspberry Pi和Arduino在自动驾驶汽车原型中的应用

4. 认证SEooC组件

我们基于ROS的组件的认证流程，认证过程的主要活动描述如下（图6）：

1. 范围：本活动主要与我们认证流程的范围定义相关。事实上，我们的范围主要集中在ROS以及基于ISO 26262的SEooC。

2. 主要文档：该活动的重点是提供主要认证文档，例如安全要求规范、安全架构和安全档案。我们的重点是强调为基于ROS架构构建安全档案的主要论点，以及用于认证目的的ISO 26262 SEooC定义。

3. 评估：该活动由三个子活动组成：

a. 组件使用模型定义：组件的使用，可以根据我们的ROS架构确定的一组属性来改变其可靠性。

b. 可测量属性：上述属性是将要测量的属性。

c. 结果：分析结果以确定我们的ROS组件行为是否相关。

4. 报告和证书：基本上，此活动是我们的ROS组件主要结果的总结，并提出了一组用于与其他系统集成的使用模型。

图6：认证流程

以下小节描述了此过程的每项活动。

4.1 范围

第一项活动的重点是确定认证的主要范围。从这个意义上来说，需要分析一下基于ISO 26262开发SEooC的步骤：

1. 对SEooC范围的假设：确定我们组件的目的、边界和功能。

2. SEooC功能安全要求的假设：考虑到我们的ROS组件的功能安全要求。

3. 执行SEooC开发：此步骤致力于组件的整体开发。

4. 工作产品的识别：这些工作产品验证假设的功能安全要求，并且假设得到满足。

5. SEooC集成：验证SEooC假设，包括ASIL能力，并且假设的安全要求与系统的其余部分正确集成。

这些假设和边界描述了我们的ROS架构，并确定了可测量的属性。因此，我们将专注于识别它们。一个组件对于不同的可靠性有不同的使用配置文件。事实上，我们不知道最适合我们的ROS架构的使用配置文件。因此，我们需要确定这些边界，这有助于我们定义假设。我们通过组合基于ROS架构的三个参数来定义一组实验（测试）：(1) 消息之间的时间（周期）、(2)粒度和(3)队列大小。这些元素改变了我们架构的行为，从而改变了其可靠性。每个实验或测试都会修改架构的一个参数（表1）。这些参数表征了我们的SEooC的行为。设计人员有责任根据特定应用的要求接受或拒绝特定配置。

4.2 主要文件

认证过程中的一个相关方面是在认证期间收集主要资产。明确的论点是安全认证的基础，它们帮助我们构建主要文档。所有这些信息都由一个安全档案来表示，该档案用于通过论证和证据来证明，我们基于ROS的组件是安全的并且符合 ISO 26262。然后这个目标被分成几个子目标，这些子目标满足这些场景中传统上使用的一些ISO 26262条款。除了危害分析之外，还确定了一组与SEooC相关的目标，例如考虑所有安全要求的设计。确定措施以表明安全要求的正确实施。不过，包含安全档案的文档细节以及我们使用GSN表示法的表示不属于本文的讨论范围。

4.3 评估

我们的评估过程（图7）用于确定哪些ROS属性将被用于认证的代表和测试。以下各节详细介绍了该流程的活动。

图7：评估流程

4.3.1 组件使用模型定义

我们的认证方法与ISO 26262和SEooC定义（ISO 26262 第10部分）保持一致，因为它考虑了它们的特定条款，并将它们收集在我们的安全档案中。我们基于ROS的架构定义了组件使用概念模型（图8）。这意味着每个使用模型都由三个先前定义的参数配置：周期、粒度和队列。每种配置都与基于测试结果的特定可靠性有关（表1）。因此，我们可以根据不同的配置导出不同的可靠性。

4.3.2 可测量的属性

我们需要识别不同的配置文件来使用我们的SEooC组件。至少我们需要确定基于ROS的架构的可靠性行为。分析运行时行为的定量技术采用工作负载测试。我们通过发送消息来测试基于ROS的架构。从这个意义上说，压力测试过去已经被使用过，并且它是安全关键软件中的一项重要活动。

图8：组件使用概念模型

软件可靠性模型需要失效强度测量才能发挥作用。因此，我们需要在我们的上下文中定义什么是失效。ISO26262第1部分将故障定义为可能导致元件(1.32)或项目(1.69)失效的异常情况。误差是计算的、观察的或测量的值或条件，与真实的、指定的或理论上正确的值或条件之间的差异。最后，失效是元件（1.32）执行所需功能的能力的终止。

在我们的定义中，我们只是将故障视为丢失消息。例如，丢失消息意味着发送到执行器的信息未被接收，因此未被处理。在这种情况下，这些故障也可以被视为相对误差。根据文献中报告的一些经验，其中包括失效次数、概率和平均值，我们将为每个实验测量以下方面：

• 故障：未传送的消息数或在特定延迟阈值后到达的消息数。

• 平均值：所有到达消息的平均延迟。

• 中值：所有到达消息的中央延迟。

• 标准偏差：到达消息的变化。

• 最小值：所有到达消息的最小延迟值。

• 最大值：所有到达消息的最大延迟值。

• 置信区间(CI) 95%（下限和上限）：界定异常值的阈值。我们只考虑异常值潜伏时间高于95%置信区间上限。

• 未传送密度：未传送消息数与已发送消息总数之比。

• 离群值密度：到达消息总数中离群值的数量。

• 参考间隔(RI) 99%（下限和上限）：界定99%到达消息的阈值。

4.3.3 黑盒测试性能

根据Voas的建议，我们的目标是确定组件质量是否足够高。图9描述了测试我们的SEooC组件所执行的步骤。测试基于对SEooC组件属性的分析：周期、粒度和队列大小。对于每个属性值组合，平台都会执行，记录每个到达消息的延迟。作为实施决策，未到达的消息（未传递）被标记为零延迟。尽管它不是有效的延迟值，但在视觉上很容易发现。

需要分析的一个方面是这些数据是否遵循正态分布或SRGM，以便评估由这些测量确定的实验的可靠性：平均值、中值、标准差、最小值、最大值、CI 95%（下限和上限）、故障密度和RI 99%（下限和上限）。

图9：黑盒测试流程

4.3.4 结果

我们需要基于强调我们的架构来评估软件操作质量。因此，我们为SEooC组件确定了40种不同的配置(5x2x4=40)，作为它们的输入变量和值：

• 周期值：2、3、4、5和8毫秒。

• 粒度值：5和10 kHz。

• 队列大小值：1、2、10和100。

每个实验组合在10分钟内执行24次，因此总共执行了960次。这些经验案例概述了SEooC组件在压力条件下的行为。

在初步数据分析中，我们确定哪些实验是有意义的。图10描述了SEooC组件两次执行的延迟。X轴代表执行时间（以秒为单位）（总共10分钟）。Y轴表示每条消息随时间的延迟（以毫秒为单位）。未传送的消息显示为具有零延迟。图10 (a) 显示了在6到12毫秒延迟范围内传递的高密度消息。靠近X轴（零延迟值）的4个点对应于未传递的消息。在粗条纹的上部区域，松散的点表示具有非常高的延迟的消息。图10 (b) 描绘了一个完全不同的场景。一开始，一些消息以极高的延迟（超过150秒）传递。进一步到给定点（大约300秒执行时间）消息不再到达，因此它们都保持为null（表示未传递的消息）。显然，在这种情况下，该组件不能被视为可靠，因为消息大多仍未传递。周期为2毫秒的整个实验集表现相似。此外，它们不具有可比性，我们把它们排除在我们剩余的研究之外。这使得我们的数据集减少到768个（4x2x4=32个实验的24次执行）。

图10：SEooC组件两次执行的数据图

对于整个768个有效执行集，获得了与图11中提供的类似的图，一般而言，它们都类似于图11 (a)。我们直观地对比了相同实验条件下24次执行的数据，结果是一致的。所有汇总信息均已收集，并在具有两种不同排序视图的电子表格中进行比较：(1)每个实验条件下24次执行的模块，以及(2)相同执行次数下所有实验的模块。所有这些信息均可在附件中查阅。

我们的分析中使用的另一种视觉表示是密度图。图11显示了我们的SEooC的执行实例。在这张图中，我们将一些提取的上述测量值与本例的值相结合。

图11：执行19的密度图，周期3毫秒，粒度5kHz，队列大小1

为了正式分析实验结果，我们需要检查它们是否遵循正态分布以应用中心极限定理。当样本量为8至29（在我们的案例中为24）时，我们需要验证是否满足Shapiro-Wilk和Kolmogorov-Smirnov正态性检验。由于平均延迟值不违反正常假设，因此可以按照公式 (1) 计算置信区间 (CI) 95%。

表1通过结合每个实验条件下所有24个执行测量的平均值来综合此信息。

4.4 报告及证书

认证过程的最后一项活动涉及生成一份报告，其中包含过程详细信息、安全档案、ROS架构描述、使用模型和最终结果。

5. 讨论

ROS是一组开源软件库。它在多个领域变得流行，但它还处于起步阶段，其成熟度值得商榷。

正如本文所演示的，它可以在不同的特定使用模型中进行配置，以便每个使用模型可能与特定的可靠性级别相关。事实上，我们的测试揭示了一些取决于这些属性的相关行为：周期、粒度和队列大小。

表1：SEooC组件执行摘要

我们基于ROS架构行为以时间为特征，因此，我们的研究问题1（RQ1：基于ROS架构的时间行为是什么？）得到了回答。不同的传感器、控制器和执行器配置可以产生其他值，因此需要其他可靠性。然而，了解单个ROS配置如何与其他成分相互作用，并了解其可接受的阈值是有用的。使用模型代表不同的配置和可靠性，设计者有责任决定他/她想要运行的可靠性。

我们的安全档案为支持ISO 26262和SEooC概念提供了一系列论证和断言推论。所有这些假设和支持目标的断言证据都认为，基于ROS架构的特定实例化是可接受且安全的，并且符合一些ISO 26262条款。因此，我们的第二个研究问题（RQ2：在安全档案定义过程中应该考虑哪些安全方面？）就完成了。

认证过程是一把双刃剑，应该定义活动的平衡。拟议的认证过程涉及与SEooC相关的具体ISO 26262实践。认证过程应澄清哪些证据是最相关的，但也应澄清SEooC认证涉及的ISO 26262主要方面是什么。本文提供了一个关于在这种情况下使用的论点、断言和证据的例子。这使我们得出结论，我们的第三个研究问题（RQ3：在基于ROS架构的认证过程中应该强调哪些方面？）已经达成。然而，这些论点、断言和证据可能因情况和背景而异。如果将ROS成分整合到更复杂的场景中，则应定义额外的论据和证据。

我们基于ROS架构在一个基本平台上进行了测试，该平台不是几个ROS和其他组件相互作用的复杂情况。需要对复杂的基础设施和机制进行更多的研究。例如，当前的总线通信器是通用串行总线（USB），传统上汽车领域的通信使用所谓的CAN总线。然而，它可以与USB一起用于连接其他汽车部件。此外，应进一步研究CAN总线系统中未涉及的安全问题，这是一个主要弱点。

所提出的方法有助于我们确定设计者可以定义ROS组件的哪些用途。事实上，设计者有责任根据特定的应用需求接受或拒绝特定的配置。我们的ROS表征提供了考虑置信区间（95%）和参考区间（99%）的可接受值的概述。在认证过程中，这些值被视为参考值。这些方面在ISO 26262 SEooC组件定义过程中使用。

6. 结论和未来工作

软件在汽车工业中发挥着关键作用，ROS在特定活动中占有一席之地。本文对基于ROS的体系结构进行了表征，并根据三个参数：周期、粒度和队列大小，对其行为进行了深入分析。认证汽车行业的第三方组件应考虑ISO 26262 SEooC概念定义。我们的ROS被定义为SEooC组件，用于车辆上进行测试。所提出的方法定义了符合ISO 26262和SEooC概念的认证过程。定义了一组参考值，以便在评估活动中使用。这些值表示使用模型，并且每个使用模型关联特定的可靠性。

这种认证方法依赖于使用安全档案来表示主要文件。该文档必须包括SEooC组件的参考值，这些值在本文中提供。我们的安全档案为支持ISO 26262和SEooC概念提供了一系列论证和断言推论。所有这些假设都认为，基于ROS架构的特定实例化是可接受且安全的，并且符合一些ISO 26262条款。最后，我们提供了一个基于ROS的体系结构分析及其对ISO 26262 SEooC的符合情况。

作为未来的工作，一个相关的方面是将ROS行为建模为SRGM，但应进一步分析以定义该SRGM模型。从这个意义上说，我们目前正在制定一项初步提案，但需要一些形式化来呈现这种模式。此外，我们还发现了改变ROS内核的行为改善。从这个意义上说，有一些有趣的举措，如Linux for automotive，以及ROS如何与该操作系统集成。

详询“牛小喀”微信：NewCarRen

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！