一家做航空发动机叶片精密加工的工厂，车间里有8台五轴加工中心。3台西门子840D SL，3台发那科30i，2台海德汉TNC 640。每台机器的主轴上都装了测力传感器，进给轴装了光栅尺，刀柄上集成了刀具磨损监测模块。
设备采购花了1.2亿。信息化系统花了2000万。但车间主任老王跟我说的一句话让我印象很深：”数据锁在机床里，像锁在保险柜里一样。”
西门子的数据要通过Operate自带的采集接口走OPC UA，但西门子的OPC UA server是选配功能，需要额外购买授权。发那科的数据要通过FOCAS协议走以太网，但FOCAS API的实时性有限，高频振动数据采不出来。海德汉更封闭， DNC接口只能传NC程序和少量状态数据，要做高频采集得通过海德汉自己提供的数据采集选件，又是一笔钱。
三家厂商，三套协议，三种数据格式。老王为了把8台机床的数据汇到一起，买了三个不同的数据采集网关，光网关软件就花了60万。数据采出来了，但采样频率被压到最低——主轴负载和温度5秒一次，进给轴位置和负载10秒一次。振动数据？根本没采。
为什么没采？因为振动数据采样频率要到1000Hz以上，一天产生的数据量太大。传统的关系型数据库存不起，也不需要实时存——振动分析一般是离线做的，不在线。
但问题是——不实时存的振动数据，就做不了实时刀具状态监测。刀具崩刃了你不知道，下一个工件就报废了。叶片材料一公斤几千块，一个叶片毛坯几万块。报废一个就是真金白银的损失。
CNC数据到底有多复杂
高端CNC的数据来源分为两类：机床内置参数和外部传感器。
数据来源 | 参数类型 | 采样频率 | 日数据量(单台) | 获取难度 |
机床内置 | 主轴转速/负载/温度 | 10-100ms | 864K-8.6M | 厂商协议 |
机床内置 | 进给轴位置/负载 | 10-100ms | 864K-8.6M | 厂商协议 |
机床内置 | 程序执行状态 | 事件触发 | 变化大 | 厂商协议 |
机床内置 | 报警/故障码 | 事件触发 | 变化大 | 厂商协议 |
外部传感器 | 刀具切削力 | 1-10ms | 8.6M-86M | 需加装传感器 |
外部传感器 | 主轴振动 | 1-25.6kHz | 极大 | 需加装传感器 |
外部传感器 | 刀具磨损量 | 1-10ms | 8.6M-86M | 需加装传感器 |
外部传感器 | 工件温度 | 1-5秒 | 17K-86K | 需加装传感器 |
一台五轴加工中心，内置参数可能就有200-300个。加上外部传感器测点，总测点数轻松超过500个。振动传感器如果按10kHz采样，单个传感器一天的数据量就是8.6亿条。一台机床装4个振动传感器——主轴X/Y/Z三个方向加刀尖一个——光振动数据一天就30多亿条。
ms级采样的刀具切削力和磨损数据也不遑多让。10ms采样频率下，单传感器一天864万条数据。一台机床有多个测力点，总量也在千万到亿级。
这就是为什么很多工厂的CNC数据采集系统只做低频——不是不需要高频数据，是存储和管理系统扛不住。
厂商封闭的真实代价
CNC行业的厂商封闭不是什么秘密。西门子、发那科、海德汉三大阵营各自为政，数据接口、通信协议、文件格式互不兼容。
这种封闭的代价不仅是技术上的——多套网关、多套数据格式转换、维护成本高。更大的代价在于：用户对机床数据的掌控力被削弱了。
一个具体场景。老王那家工厂要做刀具寿命管理。理想状态是：每把刀具从装上机床开始，系统记录该刀具所有加工过程中的切削力、振动、温度数据，计算累积切削时间和切削量，预测刀具剩余寿命。到了剩余寿命阈值时提醒更换。
这个需求要实现，需要机床的NC程序执行数据（知道当前在用哪把刀、在加工什么工序）和传感器数据（切削力、振动）在同一时间轴上对齐。NC程序数据从机床内置接口走FOCAS/OPC UA采，传感器数据从外部采集卡走。两路数据的时钟要同步，采样频率要匹配。
如果机床厂商提供统一的高频数据采集接口，这一切就简单了——一个接口搞定机床内置和外部传感器所有数据的同步采集。但厂商不做这个事。理由也”充分”：高频数据采集对机床控制系统的实时性有影响，厂商不开放高频接口是”出于安全考虑”。
说白了就是不想让你拿到太多数据。数据拿得多了，你就可能自己做工况诊断、做预测性维护，不需要买厂商的”增值服务”了。
时序数据库在CNC场景中的切入
时序数据库解决不了厂商协议封闭的问题——那是另一层的事。但一旦数据通过网关采集出来，时序数据库就是管理这些异构、高频、多源数据的合适工具。
高频写入。 刀具切削力1ms采样、振动10kHz采样——这个写入压力对关系型数据库是灾难性的，对时序数据库来说是常规操作。TDengine单节点每秒可以写入百万条以上数据。8台五轴加工中心，即使所有传感器全开高频采样，总写入量也就是每秒几十万条，TDengine一个节点就能扛住。
多源异构数据统一管理。 8台机床来自三个厂商，数据格式各不相同。TDengine的超级表模型可以按机床厂商和机型建立不同的超级表。西门子机床的数据是一张超级表，发那科的是另一张，海德汉的又是一张。每台机床是子表，通过标签标注机床编号、车间、机型、NC程序号。外部传感器数据可以建立独立的超级表，通过机床编号标签和机床内置数据关联。查”3号机床（发那科30i）在加工工序O1001时所有传感器的数据”，通过标签过滤加时间范围查询一条SQL搞定。
振动数据存储。 这是CNC场景中最具挑战的部分。10kHz的振动数据，单传感器一天8.6亿条。TDengine的高压缩比在这种场景下价值极大——振动数据的相邻采样点差异通常很小（正常加工中振动是准稳态的），delta-delta编码可以大幅压缩。实测数据表明，TDengine对工业振动数据的压缩率可达原始数据的3-8%。一天的振动数据从30多GB压缩到1-2GB，一个月存下来也就几十GB。长期保留成为可能。
实时告警。 刀具崩刃是一种突发性事件——正常切削中切削力突然跳变。TDengine的数据订阅机制可以在切削力超限的瞬间触发告警，延迟在秒级。机床可以在收到告警后暂停进给，避免连续报废。这个实时性靠事后查数据库做不到。
刀具磨损预测：从数据到决策
数据存好了，怎么用？刀具磨损预测是CNC场景中最有经济价值的应用。
硬质合金刀具加工高温合金（如Inconel 718）时，刀具寿命可能只有几十分钟到几小时。换刀时间约5-10分钟，加工辅助时间占比不低。如果能在刀具即将到达寿命极限时精准提醒更换——既不提前浪费刀具寿命，也不滞后导致加工质量恶化——对生产效率的提升是直接的。
预测模型通常的输入是：累积切削时间、累积切削量（切削路径长度×切深×切宽）、切削力时域特征（均值、方差、峭度）、振动频域特征（特定频带能量）。输出是刀具后刀面磨损量VB值（后刀面磨损带宽），当VB超过0.3mm（精加工）或0.6mm（粗加工）时需要换刀。
这个模型的训练和推理都需要时序数据库支撑。训练阶段需要调取大量历史加工数据——包括刀具从新到废的完整生命周期数据。推理阶段需要实时获取当前刀具的切削力和振动特征，输入模型，输出预测磨损量。
TDengine在这两个阶段的角色：
- 训练阶段：通过SQL查询拉取历史数据，Python连接器把数据传给训练模型
- 推理阶段：通过连续查询实时计算时域特征和频域特征，写入特征表；模型读取特征表做预测
切削力特征计算比较直接——均值、方差、峭度都是时序聚合统计。振动频域特征稍微复杂——需要FFT变换。TDengine支持通过UDF实现FFT计算，或者把数据拉出来用Python的scipy.signal做。实时性要求高的可以走UDF，离线分析可以走Python。
加工质量追溯
另一个高价值应用是加工质量追溯。
叶片加工完成后，三坐标测量机（CMM）检测尺寸精度。如果某个尺寸超差，需要追溯是哪道工序、哪台机床、哪把刀具、哪个切削参数导致了偏差。
这个追溯需要把CMM测量结果和加工过程中的机床参数、传感器数据关联起来。CMM测量结果是事件型数据——某天某时测量的尺寸值。加工过程数据是时序数据——机床在该时段的运行参数。
在这类数据库里，CMM结果可以作为标签写入对应加工批次的元数据，通过批次号和时间范围关联到加工时序数据。查”2024年3月15日O1001工序在3号机床上加工时切削力是否异常”，直接通过标签和时间范围过滤命中。
这个追溯能力在航空发动机叶片这类高精度、高价值零件的加工中尤其重要。一片叶片的加工成本可能上千元，一个批次几十片，如果尺寸超差需要全部返工甚至报废。精准追溯到问题工序和参数，不仅为了止损，也为了工艺改进。
落地中最难的不是技术
老实说，CNC数据管理项目落地中最难的环节不在数据库，在数据采集。
厂商协议封闭的问题前面说了。实际的解决方案通常是——要么买厂商的数据采集选件（贵但省心），要么用第三方数据采集卡直接从传感器信号端取数据（便宜但要自己搞同步和标定）。
老王那个工厂最终选了后者。他们在每台机床上加装了独立的数据采集系统——NI的cRIO采集卡，直接从测力传感器和振动传感器的模拟信号端取数据。和机床内置数据通过OPC UA/FOCAS采集的低频数据在TDengine里通过时间戳对齐。
这么做的好处是高频数据完整，不受厂商接口限制。坏处是数据采集系统的维护工作量不小——采集卡、传感器、线缆都需要定期校准和维护。8台机床的数据采集系统维护需要一个专职工程师。
值不值得？老王的算账方式很直接：叶片报废一片省下来就是几千到上万元。预测性换刀如果能减少5%的叶片报废率，一年下来省的钱就够覆盖数据采集系统的投入了。
至于TDengine在其中的角色，老王的评价很朴素：”就是个存数据的仓库。但这个仓库比以前那个（SQL Server）快了不知道多少倍，还便宜。”
朴素，但到位。智能制造的数据底座，本质上就是一个”存得住、查得快、不丢数据”的仓库。这类数据库做这件事，比关系型数据库合适得多。剩下的——采集层的打通、分析算法的构建、工艺模型的训练——都是应用层的事了。
数据库不重要，但没有它什么都做不了。
