【Jailhouse 文章】Evaluation of a Hypervisor-Based Smart Controller for Industry 4.0 Functions in ...

【Jailhouse 文章】Evaluation of a Hypervisor-Based Smart Controller for Industry 4.0 Functions in ...

文章目录

​​1. Introduction​​​​2. Related Work​​

​​2.1 Use Case And Peoposed Architecture​​​​2.2 Industry 4.0 Testbed​​​​2.3 Retrofitting Industry 4.0 Functionality​​​​2.4 Proposed System Architecture​​​​2.5 Proposed Smart Controller Architecture​​

​​3. Evaluation​​

​​3.1 Measurement Setup​​​​3.2 Use-case-based Evaluation​​​​3.3 Generic Evaluation and the Effects of System Load​​

​​4. Discussion​​​​5. Conslusion​​

在工业4.0场景下的基于Hypervisor的智能控制器性能评估

在机床中，预测性维护和过程监控可以提高机器可用性以及产品质量，早期故障检测还能够帮助优化生产系统的效率。使用虚拟机管理程序能够实现对传感器传入数据的快速反应以及在单一平台上对驱动程序的灵活支持。本文使用 COTS 单板计算机，将主轴监控传感器与工业边缘设备集成，研究了端到端的延迟。

1. Introduction

第四次工业革命（工业4.0）和智能工厂愿景旨在增强生产系统的自动化、通信和监控，以提高其效率和灵活性。提高效率的常用方法包括预测性维护和过程监控。预测性维护的特点是长期监控传感器数据和检测表明需要维护的模式，例如，通过机器学习的方法。过程监控是加工过程的在线监控。传感器数据捕获和监控系统响应之间的低延迟与启用在线流程优化或故障检测和紧急关闭等功能高度相关。将所需要的传感器集成到新的生产系统时，硬件和软件接口可能并不总是可用的。为了实现接口的轻松适配、数据预处理以及低延迟监控功能，本文提出了一种用于数据通信和计算的模块化智能控制器架构。

本文介绍了如何在商用现成单板计算机上使用智能控制器概念，以及在工业用例中集成传感器。本文深入了解系统和控制器软件架构，并确定用例和通用案例中可实现的延迟。本文评估端到端延迟，即控制器的外部输入与相应输出信号之间的延迟，从而可以估计实际应用中的性能。

2. Related Work

对于检测到故障时的紧急停止功能，[1] 中提出了一种智能控制器软件架构，基于 Jailhouse，并且运行 Linux 和实时操作系统并将它们彼此隔离。在 Banana Pi上的虚拟机管理程序的性能评估工作[10]、[11]。与原生 Linux 相比，评估了管理程序的性能开销。在他们的评估中，Jailhouse 虚拟机管理程序显示最低的开销为 0.04%，而 Xen 虚拟机管理程序设置显示出更高的值（21.6% 和 7.4%，具体取决于调度程序）。丹尼尔森等人提出了一种量化处理器内核之间性能隔离的方法。他们使用它来比较 Jailhouse 中的 Guest cell 和仅仅使用 Linux 的开销和隔离，没有考虑混合操作系统系统。相比之下，本文的工作评估了基于虚拟机管理程序的混合操作系统的延迟，并将它们与本机 Linux 设置进行了比较。

2.1 Use Case And Peoposed Architecture

2.2 Industry 4.0 Testbed

2.3 Retrofitting Industry 4.0 Functionality

为了改进加工中心主轴的过载检测和预测性维护功能，应集成一个新的传感器，测量主轴位移和倾斜。该数据可用于推导出影响附在主轴上的刀具的力。

过载检测机构旨在保护机器，特别是主轴和工件免受损坏。过载可能是由于与障碍物的意外接触（即碰撞）、不利的工艺参数或先前对工具的损坏。由于编程刀具路径或物理设置机器（夹具和工件的手动定位）时的错误，这些情况在单个零件或小批量的制造中尤其频繁发生。过载的特征是影响工具的力超过了定义的阈值。由于该力与主轴位移有关，因此对于该评估，可以将其简化为位移值的阈值比较。当检测到过载情况时，应触发机器紧急停止。由于过载情况是可能导致损坏的意外操作条件，因此需要在过载情况开始后尽快触发紧急停止。如 [1] 中所述，可接受的延迟大约为几毫秒。

预测性维护方法（例如剩余寿命预测）具有更宽松的延迟要求。可以长时间获取数据，然后离线或离线分析（例如使用云服务）。

在本文的用例中集成的传感器是 Schaeffler SpindleSense 传感器 [16]。它测量连接到主轴外壳的传感器环和连接到主轴的测量环之间的轴向和径向位移。它的分辨率约为 1 µm，测量数据以 1 kHz 采样并通过 CAN 总线（控制器局域网）提供。由于 CNC 单元和边缘单元都没有直接提供 CAN 总线接口，因此需要一个协议转换单元。虽然传感器可以为主轴监控提供内部数据处理，但本文的设置中并未使用它来最大限度地提高灵活性。

2.4 Proposed System Architecture

如图显示了加工中心的整体系统架构。机器由 CNC 单元控制，它通过机器内的本地以太网网络连接到工业边缘单元。边缘设备连接到车间网络，可用于将信息转发到制造执行系统 (MES) 和云服务。

新添加的主轴传感器安装在机器中，它通过 CAN 总线连接到智能控制器单元，后者又连接到机器本地以太网网络，并通过专用数字信号线连接到机器控制系统，以发出过载信号并触发紧急停止。

智能控制器实现协议转换和数据预处理，高效地将主轴传感器数据提供给边缘单元，并运行低延迟数据处理以进行主轴过载检测。它检查过载情况并在必要时向机器控制发送停止信号。同时，它根据从边缘单元接收到的配置过滤和聚合传感器数据，然后将聚合数据转发到该单元。

2.5 Proposed Smart Controller Architecture

如图显示了用于实现机器监控和数据预处理的智能控制器硬件和软件组件及其关系。

Lemaker Banana Pi M1 [17] 用作智能控制器单元的硬件平台。它采用 Allwinner A20 SoC，包括两个 ARM CortexA7 CPU 内核、1GB DDR3 RAM 和集成 CAN MAC 外设等。为了连接 CAN 总线，使用了 SN65HVD230 CAN 收发器。

正如智能控制器概念中所提出的，jailhouse 管理程序用于管理 Linux OS（操作系统）和 FreeRTOS 实时操作系统 (RTOS) 的并发执行，并控制它们对系统资源的访问。操作系统在 Jailhouse cell 内运行，每个 cell 专门分配一个 CPU 内核。Jailhouse 被配置为授予 RTOS 分区对 CAN 控制器、GPIO（通用输入/输出）寄存器以发出停止信号以及时钟控制单元的相应寄存器的独占访问权限。为了调试和评估，它还被授予访问 UART 外设（通用异步接收器发送器）和更多 GPIO 寄存器的权限。相关的 CAN 和 UART 中断被路由到 RTOS 分区。剩余的硬件资源分配给 Linux 分区。用于数据交换的硬件定时器模块和内存在 Linux 和 RTOS 分区之间共享。

在 FreeRTOS 中，本文实现了一个控制 Allwinner A20 CAN 外围设备的 CAN 驱动程序。数据采集任务使用它来接收传感器发送的 CAN 消息。它解析传感器数据，运行过载检测，然后将其转发到 Linux 分区。如果主轴在任何方向上的位移超过定义的阈值，则过载检测会发出过载情况的信号。在这种情况下，设置一个 GPIO 引脚来指示过载情况。该信号可由机器控制解释以停止机器。在此，可能需要将电压电平从 Banana Pi 的 3.3V 电平转换为机器控制数字 I/O 电平。如果沿所有轴的位移值均低于阈值，则复位 GPIO 引脚，表示正常运行。

RTOS 和 Linux 之间的通信是使用 RPMsg 协议的简化变体实现的。 本文的实现基于 RPMsg-Lite 组件 [18]。它使用共享内存进行数据交换，并使用 Jailhouse 提供的 ivshmem 接口来表示新数据的可用性，后者是基于虚拟 PCI 的接口，可用于触发分区间中断 (IPI)。在 Linux 上，数据聚合应用程序包含 RPMsg 实现，并通过 Linux 用户空间 I/O (UIO) 驱动程序接收这些中断。然后它过滤和聚合传感器数据，然后通过以太网 (ETH) 将其发送到边缘单元。聚合周期以及过滤参数可以由边缘单元使用配置命令来定义。

当组合来自多个来源的信息时，例如多个传感器，数据同步很重要。在 Linux 下，这可以使用 NTP 或 PTP 等时钟同步协议来实现。在本文的设置中，一个通用的 NTP 服务器用于边缘单元和智能控制器之间的时间同步。但是，由于传感器数据是由 RTOS 获取的，因此需要 Linux 和 RTOS 之间的时间同步。这是通过共享硬件计时器单元作为分区之间的公共时间基准来实现的。传入的传感器数据在接收时使用计时器值进行注释，然后转发到 Linux。在那里，系统范围的传感器数据时间戳是通过考虑当前和带注释的计时器值之间的偏移量来确定的。

3. Evaluation

这项工作的一个目标是确定 Banana Pi M1 平台上智能控制器概念可实现的端到端延迟。本文考虑了两种情况进行评估：

基于用例的评估：本文测量了工业用例中智能控制器的反应时间。通用评估：本文在一个简单的通用案例中测量了反应时间，并研究了系统负载的影响。

在这两种情况下，都将智能控制器架构与原生 Linux 方法进行了比较，其中原生 Linux 直接在 CPU 上运行，无需管理程序或 RTOS。

3.1 Measurement Setup

为了测量智能控制器的反应时间，本文使用了一个外部测量单元，它为智能控制器生成输入信号并接收其输出信号。本文使用 Xilinx Zynq UltraScale+ ZCU102 评估板，其中包括 FPGA、处理器内核、硬件定时器单元、CAN MAC 外设和 CAN 收发器等，它支持 3.3V I/O，因此可以直接连接到 Banana Pi。测量单元连接到智能控制器 CAN 接口以及两条数字 I/O 线，如图所示。

3.2 Use-case-based Evaluation

为了确定工业用例中智能控制器的端到端延迟，本文将智能控制器单元连接到测量单元（信号发送单元），而不是真正的主轴传感器和机器控制。测量单元通过发送与传感器相同的 CAN 消息来模拟主轴传感器。对于每次测量，测量软件首先触发测量单元的 CAN 外设发送传感器消息，指示位移超过阈值。CAN 外设通过 TX OK 中断确认传输成功。在测量软件的相应中断处理程序中，启动硬件定时器。然后，测量软件轮询反馈线并在看到指示过载的信号值时停止计时器。根据计时器滴答计数，计算延迟。

为了将智能控制器概念与本机 Linux 实现进行比较，研究了两种设置：

智能控制器：智能控制器的实现如第三节D所述。本机 Linux：使用本机 Linux 实现。为了充分利用 Linux 功能，用户空间应用程序使用 libgpiod 库控制 GPIO 引脚，即停止信号。它使用 SocketCAN 库与 CAN 外设进行交互。收到 CAN 消息后，将完成阈值检查并根据结果设置停止信号。

如图显示了 1000 次测量的结果。智能控制器设置显示的延迟明显低于 Linux 设置。这可以通过以下事实来解释：与 Linux 用户空间应用程序相比，RTOS 任务在访问 GPIO 和 CAN 外设时具有较低的开销，因为上下文切换和精简驱动程序以及等待调度的其他线程较少。对于 Linux 应用程序，这些方面以及内核和用户模式之间的上下文切换等都会导致高延迟。

3.3 Generic Evaluation and the Effects of System Load

本文将智能控制器实现与不同的本地 Linux 实现进行比较，以了解在对外部事件做出反应时可实现的延迟以及不同负载情况对该延迟的影响。该评估使用了一个基本功能，作为输入数据处理的通用最小示例：一旦在外部数字输入线路（TRIG 线路，例如来自光栅）上接收到上升沿，上升沿应在输出线（RESP 线，例如停止信号）上输出。虽然此功能在大多数实际应用程序中是多余的，但它可以作为由操作系统开销、调度效果和硬件引起的端到端延迟的基准。

为了测量延迟，测量单元在 TRIG 线上发送一个上升沿，该上升沿由 Banana Pi 的 GPIO 外设接收，从而触发中断。当应用软件检测到边缘时，即执行中断处理程序时，它会在 RESP 线上输出一个上升沿。这由测量单元检测到，它确定发送和接收边沿之间的延迟。

在本次评估中，使用了高精度测量系统，在测量单元的 FPGA 中实现了测量功能。测量电路由一个状态机组成，它直接连接测量线并控制一个计数器。它的时钟频率为 500MHz，因此可实现 2ns 的时间分辨率。为了确定测量系统本身的延迟，测量线直接相互连接。这导致了 18 ns 的测量，因此可以忽略测量结果。使用基于 FPGA 的设置是在类似应用中进行延迟测量的既定方法，例如 OSADL 延迟盒 [19]。

评估了以下设置：

Smart Controller:RTOS 任务用于监视 TRIG 信号并设置 RESP 信号。

a) RESP 信号直接在 IRQ 处理程序中设置。

b) RESP 信号由由 IRQ 处理程序唤醒的高优先级 RTOS 任务设置。

Native Linux:Linux 直接（本机）在 CPU 上运行。

a) 内核驱动程序用于监视 TRIG 信号，RESP 信号直接在 IRQ 处理程序中设置。

b) 内核驱动程序用于监视 TRIG 信号，RESP 信号设置在线程 IRQ 处理程序中。

c) 用户空间应用程序用于监视 TRIG 信号并设置 RESP 信号。 它使用 libgpiod 库与内核的 GPIO 框架及其事件循环交互以检测 TRIG 边缘。

Native Linux(Preempt-RT)

带有 Preempt-RT 补丁的 Linux 直接在 CPU 上运行。评估的实现与设置 2 中的相同。但是，实现 2a 不能与 Preempt-RT 补丁一起使用。它与 Preempt-RT 的概念不匹配，Preempt-RT 包括将 IRQ 处理程序作为线程处理。

本文测量了所有设置在 Linux 操作系统上加载和不加载的延迟。负载是使用应力应用引起的[20]。使用 stress -c 10 -m 10 --vm-bytes 80000000 -i 10。

如图显示了每种设置和负载情况下 1000 次测量的结果。在空闲状态下，智能控制器实现和 Linux 内核模块实现显示出相似的延迟。对于 IRQ 处理程序实现，它们大约为 90 µs，对于任务/线程 IRQ 处理程序实现，大约为 137 µs。同时，智能控制器设置的最大延迟明显低于本地 Linux 实现（49% 的 Linux 延迟用于 IRQ，27% 用于任务/线程 IRQ）。

在高负载下，智能控制器设置中的平均延迟仅增加几微秒，而对于 Linux 内核驱动程序设置，它们增加了 12%（IRQ 处理程序）和 102%（线程 IRQ）。这可能是由于 Linux 内核代码和模块在 IRQ 上下文中运行或禁用中断一段时间，从而延迟了对 TRIG 信号的反应。对于线程化 IRQ，延迟可能由额外的调度开销和其他线程争夺 CPU 时间来解释。使用 Preempt-RT，可以在负载下实现更低的平均延迟。

关于本文测量期间遇到的最大延迟，在某些情况下，智能控制器设置显示的延迟高于原生 Linux 设置。这是在负载下的 IRQ 处理程序实现中看到的，并且是可重现的。这可能是由 Allwinner A20 芯片的硬件细节引起的。后续实验表明，这种影响与内存子系统有关，因为它仅在涉及内存压力时才会发生。在没有内存压力的情况下，测量了类似的最大延迟。

如第 IV-B 节所述，将用户空间实现与智能控制器或 Linux 内核模块实现进行比较时，延迟存在很大差异。虽然智能控制器和内核实现导致平均延迟约为。90 µs 到 160 µs 无负载和 90 µs 到 280 µs 在负载下，用户空间实现导致在无负载时几十毫秒和负载下数百毫秒范围内的延迟。本文的实验表明，使用 Preempt-RT 补丁可以显着降低系统负载对用户空间实现延迟的影响，例如将它们对平均延迟的影响从 167 毫秒降低到 357 微秒。

4. Discussion

本文的评估表明，在智能控制器架构的 RTOS 中实现的功能与作为原生 Linux 用户空间应用程序实现的相同功能相比，反应延迟显着降低。这可以通过 Linux 引入的开销来解释。为了避免这种开销，可以将功能实现为 Linux 内核模块。这允许直接访问外围设备，而无需在内核和用户模式之间进行上下文切换，并在系统空闲时导致相当的延迟。

但是，在内核中实现功能允许完全访问本机 Linux 设置中的所有内存，这打破了在 CPU 上运行的应用程序之间的内存隔离。出于安全或 IP 保护的原因，这可能是不可取的，例如如果来自不同供应商的软件集成在一个系统中。使用管理程序可以在 RTOS 分区中集成低延迟软件，同时将其与以内核模式在 Linux 上运行的软件隔离开来。

在负载下，与 Linux 内核模块实现相比，智能控制器概念导致更低的平均延迟（使用原生 Linux 测量的延迟的 50%–89%）。软实时应用程序因此受益于管理程序提供的隔离。但是，RTOS 延迟仍然受到 Linux 分区上的负载的影响。这是由于共享硬件资源（例如缓存和总线）导致硬件平台的 CPU 内核之间的干扰造成的。后续实验表明，这种干扰主要与内存负载相吻合，表明共享缓存和内存总线可能是主要原因。这可以通过在内存分区中应用缓存感知技术在管理程序级别解决，例如 [21] 中提出的缓存着色方法。

关于工业应用，本文展示了一种架构，本文成功地使用该架构将主轴传感器集成到现有的工业 4.0 测试台中（第 III 节）。本文在第 IV-B 节中展示了基于管理程序的智能控制器架构实现了平均 130 µs 和最多 182 µs 的端到端延迟，而本机 Linux 实现的延迟高达 12.9 毫秒。因此，与基于 Linux 的解决方案不同，基于管理程序的架构能够满足应用程序的要求（在几毫秒内做出反应）。在这个用例中考虑的加工中心的最大行进速度为 40m/min，在这些条件下，最大延迟对应于第一次设置中高达 0.121 毫米的行进距离和第二次设置中高达 8.61 毫米的行进距离。

5. Conslusion

在这项工作中，本文演示了如何将 [1] 中提出的智能控制器架构集成到工业用例中。然后，本文在这个真实世界的应用程序和通用测试中对其进行了评估，以确定对外部事件的端到端延迟，并将其与本机 Linux 实现进行比较。虽然与具有相同功能的本地 Linux 用户空间实现相比，智能控制器概念的延迟显着降低，但本文发现，只要系统大部分时间处于空闲状态，基于 Linux 内核模块的实现就可以实现相似的平均反应时间。然而，当系统处于负载状态时，与 Linux 内核模块实现相比，智能控制器方法显示出更低的平均延迟，从而使其对软实时应用程序有利可图。此外，虽然在内核模块中实现功能可能会打破原生 Linux 设置中的应用程序隔离要求，但在应用智能控制器概念时仍然可以实现低延迟应用程序与其他应用程序之间的隔离。对于硬实时应用程序，最大延迟是相关的。在这里，关于智能控制器概念相对于 Linux 内核模块实现的潜在好处的结果尚无定论。因此，接下来的步骤包括进一步调查硬件平台上 CPU 内核之间的干扰原因以及缓存感知分区技术的适用性。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。