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

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

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

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

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

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

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

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

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

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

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

如图所示，用于实现机器监控和数据预处理的智能控制器硬件据预处理。

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。在那里，系统范围的传感器数据时间戳是通过考虑当前和带注释的计时器值之间的偏移量来确定的。

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

1. 基于用例的评估：本文测量了工业用例中智能控制器的反应时间。

2. 通用评估：本文在一个简单的通用案例中测量了反应时间，并研究了系统负载的影响。

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

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

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

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

1. 智能控制器：智能控制器的实现如第三节D所述。

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

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

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

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

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

评估了以下设置：

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

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

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

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

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

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

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

3. 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，可以在负载下实现更低的平均延迟。

本文的评估表明，在智能控制器架构的 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 毫米的行进距离。

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