Cloud-Direct NC：新一代数控技术

《JOURNAL OF MANUFACTURING SYSTEMS》：Cloud-Direct NC: A new generation of numerical control technology

　　Shivam Garg | Liang Tung Chen | Aryan Shroff | Ricardo Toro | Shiv G. Kapoor | Jorge E. Correa | Placid M. Ferreira
伊利诺伊大学厄巴纳-香槟分校机械科学与工程系，美国伊利诺伊州厄巴纳

**摘要**
人工智能/机器学习、工业物联网（IIoT）和云制造技术，以及快速发展的计算基础设施，要求重新审视已有五十年的数控（CNC）架构，以更好地满足制造业自动化从程序化向感知化转变的需求。本文介绍了云直接数控（Cloud-Direct Numerical Control, C-DNC）架构，该架构利用不同的计算资源（云、边缘计算和嵌入式/实时计算）来匹配数控工作流中的各种任务。它引入了“编译运动程序”的概念，通过消除解释G代码和执行实时轨迹插值的重复性任务，减轻了实时计算资源的负担。释放出的部分实时资源带宽用于演示数控嵌入式监控和IIoT服务，这些服务不仅提供了高带宽的数据收集，还确保了数据与机器指令之间的紧密时间对齐。剩余的带宽可用于实时推理和高级控制，以实现真正智能的数控系统。最终，这种云集成版本的直接数控通过高效共享计算资源降低了投资成本，通过订阅和按使用量付费的模式实现了数控的普及，并与上游设计和规划软件工具进行了集成。

**1. 引言**
数控（NC）技术由John T. Parsons在20世纪40年代末开创，并通过美国空军与MIT的合作项目得到了进一步完善，可能是现代制造业中最成功和最广泛应用的自动化技术[1]。如今的计算机数控（CNC）技术将伺服控制的精确性、逻辑控制的通用性和高级运动编程语言的灵活性结合在一起，形成了一个高效、可靠且易于使用的系统，用于自动化复杂的制造过程和机器。结合计算机辅助设计（CAD）和计算机辅助制造（CAM）软件，CNC为从抽象设计到实际零件的快速转化提供了数字路径，因此成为汽车、工业设备、医疗保健和消费电子等多个制造业领域的基石[2]。这项技术不仅应用于制造业，还扩展到了建筑、牙科、骨科手术等使用3D打印技术的行业[3]、[4]、[5]。

在其发展过程中，数控系统通过开发新的格式（如直接数控（DNC）[6]和CNC [7]）以及增强板载服务（包括可视化、编程、图形界面、程序管理和过程计量[8]）来适应技术变革。然而，网络基础设施最近经历了革命性的变化，混合边缘-云计算使得能够无缝访问广泛的专用计算资源[9]。此外，传感器技术和工业物联网（IIoT）实现了对机器和过程数据的实时访问，结合机器学习（AI/ML）技术，开启了新一代自动化——感知自动化[10]。鉴于这些快速发展，有必要重新审视数控系统的角色和架构，以便（1）整合新的技术进步，（2）将数控技术从程序化引向感知化。

在本文中，我们提出了基于云的C-DNC架构，该架构利用混合边缘-云技术在云、本地客户端和本地实时计算资源之间分配服务，以实现：（1）为高级控制、数据收集和实时推理提供适当的计算资源，并释放带宽受限的实时资源；（2）将机器和过程与基于云的工具（如Autodesk Fusion [11]、SAP [12]）无缝集成，以创建适用于任何操作环境的软件栈；（3）通过订阅和按使用量付费的模式，使不同服务水平的用户能够使用数控技术；（4）促进计算资源和软件的高效、灵活和共享使用，替代低效且难以维护的专用使用方式；（5）将IIoT数据收集和 curation 服务集成到软件栈中，以支持集成的机器学习和AI应用。

第2节将描述C-DNC架构及其关键特性的理由。第3节提供了架构各组件的实现细节和分析。第4节描述了集成软件栈的工作原理，第5节讨论了可靠性、安全性和性能方面的考虑。第6节总结了本文并提出了C-DNC的未来改进计划。

**2. C-DNC：感知自动化的重要构建块**
数控技术可能是制造业中最广泛部署和最成功的可编程自动化技术之一。然而，感知自动化需要当前数控系统中尚未提供的新服务，以及对现有服务的重新优先排序和重新设计。尽管出现了适用于低成本机器的开源数控控制器（如LinuxCNC、GRBL），工业数控技术仍然主要封装在专有的、封闭的独立系统中[13]。这带来了深远的影响，包括：
- 数控系统本身与工厂操作在操作上保持分离和孤立；
- 从系统中收集高分辨率状态信息非常困难，即使能够收集到数据，也难以将检测到的事件与当时执行的指令精确对齐[14]；
- 必须通过程序修改来进行调整，而这些修改只能在执行周期之间进行；
- 任何实时智能代理几乎不可能与系统进行有意义的交互。

最重要的是，这种独立封装方式阻止了数控系统无缝访问分布式计算资源，从而无法实现生成规划和机器学习等高级服务。

大多数数控系统通过解释G代码块来执行RS-274指令，设置并运行实时插值器，以生成每个轴的伺服电机的即时命令或在可编程逻辑控制器中启动逻辑序列。这种架构有两个主要缺点：首先，在基于G代码块的程序执行中，指令的执行时间可能很长且不稳定（取决于轨迹长度和进给速度等因素），从而延迟或阻止了必要的调整或干预；其次，数控插值器是确定性的，即给定相同的输入会产生相同的输出。因此，每次程序执行时重复运行插值器并不是对数控系统有限实时带宽的有效利用，这些带宽本可以用于更关键的功能，如传感器监控、高级控制算法、实时误差补偿等。

当今的数控系统通过MTConnect [15]和OPC UA [16]、[17]等系统提供程序文件管理和一些数据服务。数控栈中很少有服务用于监控外部传感器或系统的实时内部状态。即使收集到了数据，也没有机制将其与机器执行的特定命令或指令精确对齐。最后，数控栈中没有用于数据整理、curation和聚合的服务，而这些是新兴感知自动化技术所必需的功能。

如图1所示，C-DNC架构在四个计算资源层之间分配服务：用户端或特定应用的计算在用户浏览器环境或应用程序内的前端（C-DNC/FE）进行；C-DNC的核心服务在云端的后端（C-DNC/BE）执行；与特定机器相关的边缘服务在机器客户端（C-DNC/MC）中实现，该客户端将机器连接到C-DNC云；实时监控和控制由负责机器控制和数据收集的嵌入式计算系统（C-DNC/RT）处理。

**3. C-DNC的实现**
C-DNC架构由四个组件组成：后端（云）、机器客户端、实时组件和应用前端。本节将讨论这些组件的内部组织和功能。

**3.1. C-DNC云（C-DNC/BE）**
C-DNC的后端负责将单个机器和用户集成到共享服务网络中。如图3所示，C-DNC/BE负责用户管理、认证和授权等行政服务，以及与机器、程序和数据相关的所有用户服务。C-DNC/BE维护一个文件系统，用于存储机器配置文件、程序文件、编译后的字节码文件和其他与C-DNC系统相关的资源。这些文件与机器、程序和用户等系统实体之间的关系通过关系数据库（MySQL [26]）维护，并通过对象关系映射器（ORM）如SQLAlchemy [27]进行访问。

虽然后端提供了维护和操作数据及文件的传统服务，但C-DNC有两个特定于自身的服务：程序编译器和在程序执行期间为机器客户端提供的字节码流服务。这两种服务都依赖于数控程序的长度。为了实现可扩展性，因为许多用户可能同时编译程序，许多机器也可能同时执行程序，这些服务与后端解耦，作业请求通过RabbitMQ的发布-订阅（pub-sub）代理进行排队[28] [29]。在这种实现中，后端运行在一个配置适中的Linux服务器上（8 GB内存，500 GB硬盘）。

3.1.1. 编译的运动程序
C-DNC的一个基本概念是将G代码程序解析并编译成字节码文件，这些文件指定了增量轴运动，否则这些运动将由每个时钟周期中的实时DDA插值器生成。这项服务由一个名为Multi-Axis Motion Compiler（MAMC）的后端云服务执行。编译后的字节码文件存储在C-DNC/BE文件系统中，并与G代码程序文件、机器及其配置文件的版本关联起来。这个过程是离线的，并且对C-DNC用户来说是透明的。
在执行过程中，字节码文件被分页并流式传输到机器上，在那里被缓冲，字节码被插入到机器的伺服系统中，就像它们由实时插值器插入一样。这种方法中至关重要的是（a）生成的字节码文件的大小和（b）编译所需的时间。

3.1.1.1. 编译文件的大小
字节码指定了数控机床在每个采样周期中的状态变化。状态变化可能发生在每个时钟周期中，可能涉及轴位置的增加或减少。或者，它可能涉及模式切换、进给速度变化、刀具规格变化或各种功能变化。后者仅在G代码块的开始处指定。因此，字节码只需要为每个G代码块包含这些信息一次。一旦这些信息被编码，每个时钟周期中唯一变化的状态信息就是增量轨迹插值。对于一个三轴机器，这些信息可以用6位（BLU/NoBLU，每个轴的增量/减少）或大约1字节来编码。单个字节（8位）也足以编码各种动作、模式和刀具。指定主轴速度需要两个字节。进给速率信息已经嵌入在轨迹插值字节中。因此，编译后的字节码长度取决于G代码文件中的行数或块数以及该文件在机器上的运行时间。如果Bblock是编码模式和各种指令所需的位数，Btraj编码轨迹插值信息，fclock是机器的指令采样频率，L是G代码程序的行数/小时，那么每小时的总位数（B）由以下公式给出：
B = 3600 * fclock * Btraj + L * Bblock
例如，对于一个采样时钟频率为10 kHz的G代码程序，如果该程序每小时消耗10,000行，则每小时的总位数（B）为：
B = 10,000 samples/sec * 8 bits/sample * 3600 seconds/hour + 10,000 lines/hour * 40 bits/line
B ≈ 300 Mbit/h
R ≈ 40 MB/hour
这个保守的估计比任何美国州的最低互联网服务快两个数量级，甚至远低于典型的Wi-Fi 3速度[30] [31]。因此，1小时的数控机床操作的编译后的字节码指令可以存储在一个最多40 MB的文件中，并在10-15秒内通过标准互联网连接传输。这清楚地表明，将数控机床作为服务（NCaaS）进行流式传输是实用且高效的。
请注意，在图4所示的实现中，方向字节与命令字节是分开的。这种设计允许存储需求独立于机器上的轴数（最多8轴），其中Btraj中的每个位独立代表一个不同的轴。

3.1.2. G代码编译时间
编译G代码程序的复杂性包括解析G代码块的复杂性和为每个采样间隔生成BLU插值轨迹的复杂性。在其基本形式下（没有变量和参数等），RS274 [32]是一个有限状态语法[33]，可以在O(n)时间内解析，其中n是块中的单词数。对于一个程序来说，这大致等于程序中的总单词数。因此，解析/解释G代码文件不应该是编译运动文件所需时间的主要因素。实际上，这通常是用于仿真和实际执行的常规操作。
为了生成包含插值轨迹的字节，我们回到图5中的DDA结构。考虑到通过预先计算的交错无运动采样间隔来处理进给DDA，生成插值轨迹只需要计算在产生运动的采样间隔中应该发送哪个轴的运动请求以及方向。这可以通过模拟轴的DDA操作来实现（即，尽可能快地完成所有计算），以产生这些字节，通常期望至少有一个轴在每个采样间隔产生一个运动指令。每个DDA周期需要一个整数加法和一个比较（或寄存器溢出检测）。对于一个三轴系统，这会导致六个整数运算用于线性插值（圆形DDA插值需要两个加法整数增量）。因为每个DDA周期对应于至少一个产生运动的采样间隔，我们可以从G代码程序的路径长度（PL）估计总周期数C，即C = PL/BLU，其中BLU是机器的基本长度单位。因此，如果模拟一个插值周期的计算时间（tc）已知，tp是每个单词的解析时间，Nword是G代码程序中的总单词数，则编译时间可以计算为：
T = PL * BLU / tc + tp * Nword
预计编译时间将由第一项（DDA计算的模拟）主导。
通过在Windows 11计算机（?Intel Core i7–10510U，4核/8线程 @ 1.8 GHz，8 MB L3缓存）处理器上运行G代码编译器，对一系列具有已知线性和圆形路径长度的G代码块进行测试，得到了tc的保守估计。每个周期的平均时间被记录在图6中。
图6. 模拟线性和圆形插值的每个周期的计算时间（tc）的概率分布。
线性 và 圆形轨迹的平均模拟时间约为2.75 μs。这表明，对于一个BLU为1 μm的机器，一个路径长度为1 m的G代码程序将在2.75秒内编译完成。通常，我们期望程序路径长度在几十米范围内，这意味着典型程序的编译时间将在30秒到几分钟之间。为了在REST（表述性状态传输）框架中处理这些较长的计算时间，C-DNC/BE使用RabbitMQ创建微服务来处理G代码文件的编译。

3.2. 字节码流服务
在C-DNC架构中，一个考虑因素是高效地在云中共享资源，并通过只为机器提供必要的计算资源来降低成本。因此，在执行程序时，C-DNC后端将编译后的字节程序分割成1 MB的页面，并使用RabbitMQ发布-订阅服务将它们发送到机器。只有当最后一个页面通过认证的REST API被C-DNC/MC（机器客户端）确认后，才会向pub-sub接口发布新页面，如图7所示。这种方法实现了a) 减少机器上所需的数据存储量，b) 根据机器上可用的资源在运行过程中自定义编译后的运动文件的大小，以及c) 通过要求两端认证来解决安全性和来源问题，而不会将完整的编译可执行文件释放给供应商。

3.2. 机器客户端（C-DNC/MC）
机器客户端构成了数控机床的边缘资源，执行所有非实时任务并协调：a) 与C-DNC/BE的通信和数据处理，b) 与C-DNC/RT的通信和数据传输，以及c) 图形用户界面服务，使操作员能够与机器交互、监控其状态，并与C-DNC/BE通信以管理机器的程序。C-DNC/MC的服务和连接性如图8所示。机器客户端编写为在Linux环境中运行（Raspberry-PI 5，运行Debian 12）。为了支持根据不同用户需求定制GUI，C-DNC/MC运行一个本地FastAPI服务，通过该服务可以访问登录、配置管理、机器操作（即程序选择、修改、编译和执行）以及监控和紧急服务。由于与C-DNC/BE的通信已经在前面描述过，与C-DNC/RT的通信将在下一节中描述，因此这里不再赘述。

3.3. 实时监控和控制模块（C-DNC/RT）
该模块主要负责C-DNC中的实时（伺服和逻辑控制）功能。此外，它还提供内部状态（例如，错误跟踪、主轴扭矩等）和外部传感器输入的数据收集和转发服务。该模块运行在一个Teensy 4.1微控制器[34]上，并维护一个用于与C-DNC/MC通信的TCP套接字，其中它作为客户端，而C-DNC/MC作为服务器。
启动时，C-DNC/RT从C-DNC/MC接收一个配置文件，并进入运行模式，其主要逻辑由三个中断服务例程（ISRs）和一个主循环驱动。它维护两个主要的本地循环缓冲区，一个用于命令，另一个用于数据日志。
如图9所示，当用户执行程序时，C-DNC/MC上开始一个多线程进程。该系统与C-DNC/RT类似，采用了两个缓冲区：一个命令缓冲区用于向C-DNC/RT发送字节码指令，另一个日志缓冲区用于接收遥测数据。(a) 缓冲处理：一个专门的线程负责读取下载的编译后的运动文件页面，提取字节码，并填充命令缓冲区，以确保有足够的指令可供执行。(b) 通信线程：另一个线程负责管理与C-DNC/RT的通信。它遵循请求-执行-确认的协议。当C-DNC/RT发送“需要字节码”的请求时，该线程会从命令缓冲区中取出下一个字节码数据包并通过TCP套接字发送，等待确认并在必要时重试。这种机制保证了不会遗漏任何字节码，这对于维持正确的运动轨迹至关重要。该线程还从C-DNC/RT接收遥测数据并将其放入日志缓冲区。(c) 数据记录：一个单独的线程监控日志缓冲区以防止其溢出。当缓冲区达到其容量的某个比例时，它会将数据传输到本地文件中，也可以将其转发到GUI或C-DNC/BE进行进一步处理和存储。

下载：高分辨率图片（181KB）
下载：全尺寸图片

图9. 多线程（C-DNC/MC）和中断驱动（C-DNC/RT）执行模型的示意图。机器客户端使用多线程系统进行数据处理，而实时控制器则使用高频中断服务例程（ISR）进行伺服控制，并使用两个低频ISR处理通信。C-DNC/RT在主循环和三个中断服务例程（ISRs）中运行。高频、高优先级的ISR（ISR1）执行伺服和逻辑控制：(a) 从命令缓冲区读取并解码字节码；(b) 如果字节码是指定G代码块中的模式、杂项或其他PLC类型指令，则执行这些指令；(c) 如果字节码是轨迹插值代码，则更新目标位置等参数，读取编码器和其他输入数据，评估PI(D)伺服函数，并向电机放大器输出相应的控制电压；(d) 将位置数据、遥测数据和其他传感器读数写入数据日志缓冲区。

当ISR1执行编译程序时，两个低频ISR（ISR2和ISR3）监控命令缓冲区和数据日志缓冲区的状态，通过设置标志来指示是否需要更多字节码数据包或日志数据已准备好上传到C-DNC/MC。主循环作为低优先级的后台任务处理器运行，检查ISR2和ISR3设置的标志。这种设计将非时间敏感的通信任务从高频伺服循环中分离出来。当命令标志被设置时，主循环向C-DNC/MC发送数据请求并填充命令缓冲区；同样，当数据日志标志被设置时，主循环将日志缓冲区的内容发送回C-DNC/MC。这种顺序、逐步的通信方式确保每次只进行一次数据传输，防止竞争条件或数据损坏，并保持可靠的双向通信。

估计运行C-DNC/RT的实时控制器的可用计算带宽非常重要。我们假设典型的BLU为1微米，系统时钟频率为20 kHz（即采样间隔为50 μs）。C-DNC/RT执行循环中的关键路径包括三个主要任务：从主机C-DNC/MC传输数据（t1）、从内部缓冲区读取数据（t2）以及执行伺服控制逻辑（t3）。在Teensy系统上进行的实验表明，当不进行数据记录时，分四次传输5KB的数据块（总共20KB），最坏情况下的传输时间为4.1 ms，即每个字节的最坏情况时间为0.2 μs。考虑到每个采样周期可能需要7字节的数据（见图4，新G代码块执行开始时的字节码数据包），因此每个时钟周期必须分配1.4 μs用于从机器客户端获取数据。同样，命令缓冲区的最大读取时间约为0.5 μs。最耗时的操作是3轴伺服和逻辑控制的计算，最坏情况下的时间为2.05 μs。这些实验的结果记录在图10中。单个采样周期的总最坏情况执行时间为：
ttotal = t1 + t2 + t3 = 1.4 + 0.5 + 2.05 = 3.95 μs

下载：高分辨率图片（123KB）
下载：全尺寸图片

图10. 用于确定C-DNC/RT可用计算带宽的概率分布图。图表测量了：(a) 数据传输时间，(b) 缓冲区读取时间（解码字节码），以及(c) 伺服循环执行时间。分析显示，组合后的最坏情况执行时间约为每个周期3.95 μs。在50 μs的采样间隔（20 kHz）下，系统带宽平均只有8%用于数控目的，大约92%的带宽可用于其他服务，如IIoT数据记录、高级控制算法和实时推理以及误差补偿。

由于采用了编译后的运动控制方法，对实时计算资源的需求较低，因此C-DNC能够以与执行字节码相同的采样速度记录数据。正如所讨论的，我们实现了一个数据记录系统，其工作方式与字节码命令缓冲系统对称，信息从C-DNC/RT流向C-DNC/MC。每个周期记录8个4字节的数据包，即三个轴的目标位置和实际位置（6个值）以及两个额外的传感器值（例如温度和湿度），每个周期生成32字节的记录。将数据推入日志缓冲区的时间约为86 ns，97%的样本情况下如此；观察到的最大延迟为103 ns。从C-DNC/RT到C-DNC/MC的遥测传输速率也测量为每个字节< 0.2 μs。因此，对于32字节的记录，传输时间为0.2 μs/字节 × 32字节 = 6.4 μs。加上最大0.103 μs的推送延迟，每个周期的总时间约为6.5 μs。因此，高分辨率数据记录仅消耗了约13%的可用带宽，证明了C-DNC实时内核可以同时执行实时运动控制和高频遥测，而不会影响控制性能。

3.4. C-DNC/FE：Autodesk Fusion插件
C-DNC的云实现提供了一个API服务，允许用户为应用程序定制接口或将C-DNC服务嵌入现有应用程序中。这里我们描述了C-DNC与Autodesk Fusion的集成，通过创建一个插件，实现从设计到制造计划再到生产的无缝过渡。该插件的主要目的是用现代API驱动的数字线程替换CAM工作流程中的手动文件转换/后处理/传输过程，从而将设计与实际制造过程及其生成的数据无缝连接起来。图11展示了Fusion插件的模块化架构，包括认证、G代码和C-DNC服务（编译、编译状态、机器列表和程序列表等）。用户可以从Fusion会话的任何阶段登录C-DNC。插件管理认证过程，存储并管理成功认证后收到的JSON Web令牌（JWT），以保持Fusion会话期间的认证状态，并在C-DNC/BE的所有受保护路由中使用该令牌。认证通过后，用户可以访问其被授权的所有C-DNC资源（例如，用户有权操作的机器列表、G代码程序等）。当用户通过插件调用C-DNC的服务，将设计零件路径中的操作分配给特定机器时，插件会与C-DNC/BE通信以检索机器的配置文件。该配置文件中的信息由模板化的后处理模块使用，生成针对该机器的临时、一次性使用的后处理程序（在C-DNC的更广泛架构中，配置文件用于灵活地定义数控机器的行为）。这使得该过程成为了一个主动的、机器感知的生成步骤，而不仅仅是简单的转换。生成的后处理（G代码）文件随后存储在C-DNC的文件系统中，并编译成字节码。G代码和编译后的字节码文件都与用于后处理和编译的机器配置文件相关联。

下载：高分辨率图片（61KB）
下载：全尺寸图片

图11. C-DNC Fusion插件的模块化架构，用于与C-DNC/BE通信，支持用户认证、机器管理、G代码生成和编译。

总之，C-DNC Fusion插件通过生成和管理与特定机器或一组机器的功能/操作的直接关联，实现了设计与制造之间的无缝功能集成。需要注意的是，出于安全考虑，C-DNC仅允许从机器客户端操作机器，而不允许从前端操作。

4. C-DNC测试与演示
前面章节中描述的整个C-DNC堆栈完全功能齐全，正在运行两台3轴台式铣床。在测试C-DNC之前，首先使用标准的PI（比例-积分）控制方案调整了机器的轴精度，以确保轴级的稳定性和准确性。图12展示了一个简单的零件设计及其上的Illinois Block I。图中还展示了C-DNC/FE（Autodesk Fusion插件）接口、C-DNC台式铣床和加工后的零件。零件是用蜡加工的。选择蜡和台式平台是为了专注于验证C-DNC的架构能力，而不是机械切割动态。演示验证了整个C-DNC堆栈的功能性。加工操作在Fusion中规划，在后处理过程中，通过C-DNC插件调用C-DNC后端生成一次性使用的后处理程序来生成G代码。当程序保存在C-DNC中时，后端调用了编译程序MAMC，并生成了编译后的运动字节码文件。测试验证了用于编译的机器配置文件、G代码程序和编译后的运动字节码文件通过C-DNC后端正确链接。在执行过程中，C-DNC机器客户端访问了编译后的运动文件，解码后由C-DNC实时控制器执行。如图12所示，C-DNC忠实地再现了编程的运动（在机器伺服能力的限制范围内）。在这些加工测试之前，还进行了单轴线性插值和多轴平面轨迹（例如三角形和圆形路径）的测试，以确保C-DNC软件堆栈正确编码和解码G代码程序。此外，通过将MAMC预测的执行时间与实时控制器中的硬件计数器测量的实际运行时间进行基准测试，确认了运动调度器的时间准确性。

下载：高分辨率图片（249KB）
下载：全尺寸图片

图12. (a) CAM设置和嵌入在Fusion中的C-DNC/FE接口，用于用户认证、G代码生成和通过MAMC在C-DNC/BE中的编译。(b) 用于测试的C-DNC/MC和C-DNC/RT机器设置。(c) 用蜡制成的最终加工零件。

为了评估3D运动和数据记录能力，执行了一个验证轨迹，包括X-Y平面上的圆形路径、Z轴上的线性平移以及随后在平行平面上的相同圆形路径。图13展示了从上方看到的命令轨迹（红色）和高分辨率编码器反馈（蓝色）的BLU视图。系统的周期同步数据记录功能可以观察到每个BLU的运动分辨率，即0.5 μm。

下载：高分辨率图片（74KB）
下载：全尺寸图片

图13. (a) 示例刀具路径（蓝色）和插值轨迹（红色）的俯视图，以及(b) 和 (c) 分别为1000 × 1000 BLU和30 × 30 BLU部分的放大视图，展示了亚微米级别的数据记录能力。

5. 可靠性、安全性、部署和性能
像C-DNC这样的架构除了引入新的功能组件（例如网络通信、云计算、运动编译等）到操作环境中外，还引入了一些需要考虑但容易在技术细节中被忽略的辅助方面。本节总结了C-DNC技术设计中的一些重要方面。

5.1. 网络通信
C-DNC通过使用云存储来存储可能较大的编译后运动（字节码）文件，从而减少了数控机器的存储需求。在执行过程中，这些文件分页传输到机器，然后通过双缓冲方案传输到实时控制器。基于标准的TCP/IP堆栈构建，这确保了以下几点：
a) C-DNC在TCP/IP堆栈的应用层运行，该层涉及其他三个层，这些层能够可靠地处理数据包丢失、排序和位级损坏问题。
b) 通过命令缓冲克服了网络抖动。在C-DNC中，一个150 KB的命令缓冲区以20 kHz的采样率工作，为机器提供了7.6秒的操作时间。即使通信存在几百毫秒的不确定性，这也允许机器继续运行。
c) 在C-DNC的实现中观察到的最大伺服抖动为2.05 μs；见图10(c)。这与任何高性能嵌入式控制器相当。
d) 命令的缓冲传输导致C-DNC的启动延迟为几毫秒，以填充命令缓冲区。然而，这对其实际运行没有影响。

5.2 可靠性和容错性
C-DNC可以被视为一个多组件系统，不仅要分析每个组件，还要考虑组件之间的交互，以理解和分析故障模式，并制定策略来缓解这些问题。在执行过程中，从后端到机器的信息传输、从机器客户端到命令缓冲区的进一步传输以及在实时系统中执行命令都是关键过程。如果任何通信过程失败，C-DNC被设计为在安全模式下暂停，并尽可能无缝地恢复。
a) 从应用层故障中恢复：通过RabbitMQ使用“停止并等待”确认协议，以1 MB页面的顺序将页面从后端传输到机器。在收到前一个页面的确认之前，不会发送下一个页面。此外，页面传输过程的状态始终作为数据库记录维护。这保证了传输和执行的正确顺序，并且数据库状态记录使系统能够处理长时间的中断（无论是由于操作暂停还是子系统故障）。
b) 机器上的故障安全行为：尽管云系统被设计为高可用性，但必须安全地处理断开连接和中断。在C-DNC中，此类事件最终会导致命令缓冲区变为空（“饥饿”）。在这种情况下，实时内核默认进入故障安全模式：它保持最后一个有效的轴位置和机器状态（“进给保持”），同时等待来自缓冲区的下一个命令或响应人机界面（HMI）的中断。

5.3 安全性
C-DNC本质上是一个软件即服务（SaaS）系统，同时还提供与物理机器交互的功能。
a) 机器数据安全：C-DNC使用RabbitMQ（RMQ）发布-订阅服务将编译好的运动字节码传输到机器。页面传输使用通道隔离。每台机器都被分配了自己的交换机，并通过唯一的密钥访问。此外，每台机器还有一个单独的唯一ID和密码来访问后端服务。因此，机器周围有两层安全防护。机器必须使用其RMQ凭据来访问发送给它的字节码页面，并使用其后端凭据根据维护的页面状态请求释放后续页面。这种双重认证系统可以防止中间人攻击。
b) 用户数据安全：后端使用JWT令牌来认证和管理系统中的用户会话。C-DNC使用标准的SaaS密码哈希和通信加密方法。机器和人类用户有不同的密码，并在系统中被视为具有不同权限的两个不同实体，提供了额外的安全层。

5.4 性能与可扩展性
考虑到我们正在测试的是一种新的架构，而不是特定的控制器或控制算法，我们已经验证/测量了几个性能/可行性指标。其中许多指标无法与现有系统进行比较，因为要么我们无法获取这些指标，要么它们不适用于标准的CNC架构。分析和实验表明：
a) 分析估计了字节码编译后的运动文件的大小，并通过实验证明它们可以通过易于访问的带宽在互联网上传输。
b) 估计了编译时间，包括路径长度和总字数，并表明编译可以在合理的时间内完成（平均速度为2.75 μs/字节码）。
c) 通过实验证明了带宽节省，显示字节码解释和运行三个伺服循环仅消耗Teensy 4.1微处理器8%的带宽。
d) 验证了亚微米级的分辨率，如图13所示的真实传感器数据，证明了离线轨迹与实时插值生成的轨迹等效。
e) 展示了实际位置与字节码命令之间的时钟周期同步对齐。

关于扩展到更多轴（例如5轴机器）的能力，第3.1.1节报告称，所使用的字节码格式无需修改即可支持最多八个轴。然而，支持5轴机器的旋转轴需要扩展基于云的运动编译器（MAMC）以生成5轴轨迹，以及C-DNC/RT上的额外硬件接口来收集来自额外编码器的反馈。此外，还需要额外的带宽用于伺服循环计算和实时数据传输。
如第3.3节所示，当前的数据收集能力包括目标位置和实际位置以及两个额外的传感器值。添加新的传感器（例如表面传感器）涉及将传感器连接到Teensy 4.1，并将其映射到可用的数据记录槽之一。

5.5 技术定位和工作流程
C-DNC引入了一种新的数控执行架构，补充并实现了多种相关和新兴技术。例如，STEP-NC是一种任务级数控编程语言（例如“加工口袋”），能够根据工件的几何设计生成数控指令，但由于本地控制器不够强大而难以普及。C-DNC可以通过云运动编译和字节码分页到机器来解决这个问题。与Fusion360的测试和集成（使用RS-274后处理）展示了这种实现的途径。
C-DNC还使得创建更高保真的CNC机器数字孪生成为可能，因为它提供了一种离线方法来生成和执行精确的BLU分辨率轨迹，这些轨迹将发送到CNC机器的伺服系统中。在云监控和工业物联网（IIoT）的背景下，C-DNC提供了获取高分辨率、与机器指令对齐良好的机器状态和传感器数据的框架和基础设施。最后，关于工作流程，与Fusion360的集成表明，可以以完全透明的方式部署C-DNC，同时最小化信息的手动处理（例如文件传输、配置设置、工具规格等）。

在上面讨论的每个问题中，显然都有改进的空间。例如，在信息交换过程中使用加密技术和地理围栏；从应用层故障中自动恢复；以及更好的压缩和通信协议。随着C-DNC能力的进一步增强和发展，这些问题将得到解决。

6. 结论与未来工作
本文介绍了C-DNC，这是一种基于云的CNC系统架构，它将数控服务分布在云、边缘和实时计算资源上。其服务分布的核心概念是“编译运动程序”，其中G代码被编译成字节码，指定程序执行期间每个采样周期内发生的情况。这种编译作为云服务在离线完成，消除了实时控制器执行G代码解释和轨迹插值的需要。这种方法的一个直接好处是减少了实时控制器所需的计算量。分析显示，核心数控伺服和逻辑任务仅使用了8%的可用处理带宽。这为其他服务（例如我们在数控堆栈中实现的IIoT数据服务）留下了92%的带宽。这些服务允许高分辨率（20 kHz）的数据收集，这些数据在每个伺服周期内与机器指令时间对齐。通过在一台3轴桌面铣床上加工测试零件，展示了整个C-DNC软件堆栈（包括C-DNC/FE、C-DNC/BE、C-DNC/MC和C-DNC/RT）的集成运行。

未来的工作将集中在开发C-DNC平台上。首先，可以通过并行化多轴运动编译器来增强C-DNC/BE服务。基于G代码块的相对独立性，编译器可以更新为首先解析G代码块以找到每个G代码块结束时的中间机器状态。之后，可以并行生成每个运动块的字节码，以加快编译速度。还计划正式实现PLC（可编程逻辑控制器）服务，以便与现有的伺服控制功能一起运行。
此外，C-DNC架构使得所有计算层中的“堆栈内”AI/ML集成成为可能。在云层，C-DNC/BE API结构可以扩展，以便直接与第三方服务集成，例如NVIDIA的数字孪生生态系统用于设计、仿真和验证，用于预测性维护的机器学习（LLM），以及基于当前机器状态修改G代码的主动后处理器。在边缘层，C-DNC/RT上的大计算带宽为高级实时控制和过程中检查算法提供了可能性。例如，系统维护每个轴未来增量移动的缓冲区（每1 KB数据约1000次）的能力可以用于实现前馈和模型预测控制方法。此外，字节码级别的指令访问使得能够精确地实时注入补偿，以应对准静态（热和弯曲）机器误差。这些对C-DNC的扩展将实现完整的数据连接性和可追溯性，完成设计和制造之间的数字线程，并在制造车间引入真正的感知自动化。
最后，C-DNC为更广泛的潜在最终用户提供了新的数控交付方式。例如，对于大型用户，现场部署将使他们能够创建具有标准化接口的智能数控机器网络（适用于人类和数据），这些接口嵌入在紧密集成的设计和制造工作流程中，从而完成计划、执行、监控和数据收集、学习和适应的循环。对于小型用户和爱好者，它可以通过公共云中的SaaS实现共享昂贵的基础设施，从而访问灵活的先进自动化服务。

CRediT作者贡献声明
Aryan Shroff：数据整理、软件、写作——原始草稿、写作——审阅和编辑。
Liang Tung Chen：数据整理、方法论、软件、验证、可视化。
Toro Ricardo Santamaria：数据整理、软件、写作——审阅和编辑。
Jorge E. Correa：概念化、软件、写作——审阅和编辑。
Shiv G. Kapoor：调查、监督、写作——审阅和编辑。
Placid M. Ferreira：概念化、形式分析、项目管理、资源、监督、写作——原始草稿、写作——审阅和编辑。
Shivam Garg：概念化、数据整理、形式分析、方法论、软件、验证、写作——原始草稿、写作——审阅和编辑。