1. 智能工厂的底层逻辑为什么是Linux在跑1.1 从一条产线停机说起去年冬天我去拜访一家做精密减速器的工厂。车间主任老周拉着我看他的MES看板上面有一条曲线突然掉到零旁边标注着“#3线体 14:23:07 停机 47秒”。他问我“你知道这47秒值多少钱吗”我摇头。他说“这条线一分钟产出12件一件毛利80块47秒就是750多块。一天要是停个十几次一辆车就没了。”这47秒的根因后来查出来是工控机上的一个采集进程被系统调度延迟卡住了。那台机器跑的是某个定制Linux发行版内核没打实时补丁网络中断处理优先级又低赶上数据库写入高峰采集线程直接被挤到后面去了。老周不懂什么叫“实时内核”但他懂一件事底层系统不稳上面所有智能都是假的。这就是我想聊的话题。智能工厂这个词被说烂了但真正在车间里跑的东西其实就三样Linux在跑数据库在扛高端制造在加速。这三句话不是口号是每天在产线上真实发生的事。Linux负责把硬件管住数据库负责把数据存住高端制造负责把价值做出来。三者缺一个智能工厂就是PPT上的概念。这篇文章适合谁看如果你是刚入行的工控运维、想了解工厂数字化的软件工程师、或者正在选型数据库的技术负责人那接下来的内容应该对你有用。我会把Linux在工厂里的真实角色、数据库选型的坑、实时内核的配置细节、时序数据库的落地经验全部拆开讲。不堆术语只说人话。1.2 Linux在工厂里的三个身份很多人以为Linux在工厂里就是“操作系统”这个理解太粗了。实际跑下来Linux在智能工厂里至少扮演三个角色每个角色的要求完全不同。第一个身份是设备抽象层。产线上的PLC、传感器、扫码枪、视觉相机这些设备接口五花八门有走Modbus TCP的有走EtherCAT的有走OPC UA的还有一堆串口设备。Linux要做的是把这些设备统一抽象成文件或者网络端点让上层软件不用关心底层是RS485还是以太网。这就是为什么工厂里的边缘网关几乎清一色跑Linux——/dev/ttyS0、/dev/ttyUSB0这种设备文件模型比Windows的COM口管理要干净得多。第二个身份是实时任务调度器。这是最容易被忽视的部分。工厂里有些任务是有硬实时要求的比如运动控制卡的插补周期、视觉检测的触发信号、安全PLC的响应。这些任务如果延迟超过几毫秒轻则产品报废重则设备撞机。标准Linux内核的调度延迟在几十毫秒到几百毫秒之间波动根本扛不住。所以工厂里的Linux通常要打PREEMPT_RT补丁把内核变成可抢占的把最坏延迟压到几百微秒以内。第三个身份是数据采集与转发中枢。一台边缘网关可能同时要采集几十个点位的数据做初步的清洗和聚合然后转发到上层数据库。这个过程涉及大量I/O操作和网络通信Linux的epoll机制、零拷贝技术、多队列网卡支持在这里优势很明显。我见过一台跑Linux的边缘盒子同时处理2000个Modbus点位CPU占用不到15%换成Windows至少翻三倍。这三个身份决定了Linux在工厂里的选型逻辑不是选最新的是选最稳的不是选功能最多的是选可控性最强的。后面我会详细讲怎么选、怎么配。1.3 国产Linux在工控场景的现状这两年国产Linux在工控领域的存在感明显强了。我经手的项目里麒麟、统信、欧拉都出现过。说几个实际感受。麒麟在政务和能源行业推得猛工控场景也有不少落地。它的优势是安全合规做得扎实等保测评容易过。但坑也有主要是实时性支持不够。标准版麒麟的内核调度延迟跟Ubuntu差不多要做实时任务还得自己打补丁或者换实时版。我试过在麒麟V10上跑EtherCAT主站不改内核的情况下周期抖动能到2毫秒以上后来换了实时内核才压到200微秒以内。统信UOS的桌面体验好但工控场景用得相对少。它的优势是生态兼容性好很多Windows下的工控软件能通过Wine跑起来。不过Wine跑实时任务不靠谱只能用于HMI展示这类非实时场景。欧拉在服务器端强边缘网关场景也有应用。它的内核版本比较新对新型硬件的支持好比如2.5G网卡、NVMe SSD这些。但欧拉的工控定制版不多很多配置要自己从头做。选国产Linux做工控先问三个问题实时补丁有没有官方支持内核版本能不能锁定出问题有没有原厂兜底三个都是“是”再上否则后期运维会很痛苦。2. 实时内核把Linux改造成能扛硬实时的系统2.1 标准Linux为什么扛不住硬实时先解释一个概念。硬实时不是“快”是“确定性”。一个任务要求5毫秒内必须执行完你平均1毫秒完成没用只要有一次超过5毫秒系统就失败了。标准Linux的问题就在这——它的平均延迟可能只有几十微秒但最坏延迟能到几百毫秒。原因有几个。第一内核不可抢占。标准Linux内核在系统调用期间是不能被抢占的一个慢速的系统调用比如磁盘I/O会把高优先级任务堵在后面。第二中断处理不分优先级。网卡中断来了不管当前在跑什么任务都得先处理中断。第三自旋锁保护范围太大。内核里很多临界区用自旋锁保护持锁期间其他CPU只能空转等待。打个比方。标准Linux就像一个没有叫号系统的银行谁先挤到窗口谁先办。VIP客户高优先级任务可能被前面一堆普通客户低优先级任务堵住。PREEMPT_RT补丁做的事情就是给银行装一套叫号系统VIP来了随时插队普通客户办到一半也得让位。2.2 PREEMPT_RT补丁的核心改动PREEMPT_RT不是一个小补丁它改了内核里几千个地方。核心改动可以归纳成四条。第一把自旋锁换成可睡眠的互斥锁。标准内核里自旋锁持锁期间不能睡眠所以持锁时间必须极短。RT补丁把大部分自旋锁换成了rt_mutex持锁期间可以睡眠高优先级任务可以抢占。代价是锁的开销变大了吞吐量会降一些。第二中断线程化。标准内核里中断处理函数在中断上下文执行不能被抢占。RT补丁把大部分中断处理程序变成内核线程可以像普通任务一样被调度。只有少数真正紧急的中断比如时钟中断还保留在硬中断上下文。第三优先级继承。这是解决优先级反转的关键。假设低优先级任务A持有一把锁高优先级任务C在等这把锁中优先级任务B在跑。标准内核里B会把A挤走C就一直等。RT补丁让A临时继承C的优先级B就挤不走A了A尽快释放锁C就能继续。第四高精度定时器。标准内核的定时器精度受限于时钟节拍通常250Hz或1000HzRT补丁用高精度定时器把精度提到纳秒级。这对运动控制里的插补周期很重要。2.3 实时内核的配置实操配置实时内核不是打个补丁就完事编译选项和启动参数都要调。我以5.15内核为例把关键步骤列出来。# 下载内核源码和RT补丁 wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.15.100.tar.xz wget https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.15/patch-5.15.100-rt63.patch.xz # 解压并打补丁 tar -xf linux-5.15.100.tar.xz cd linux-5.15.100 xz -d ../patch-5.15.100-rt63.patch.xz patch -p1 ../patch-5.15.100-rt63.patch # 配置内核 make oldconfig # 基于当前配置会问RT相关选项make oldconfig会问几个关键问题必须选对Preemption Model选Fully Preemptible Kernel (Real-Time)High Resolution Timer Support选YTimer frequency选1000Hz实时任务多的话可以选更高CPU Frequency scaling选N变频会引入延迟抖动CPU idle PM support选N省电状态会影响唤醒延迟编译安装make -j$(nproc) make modules_install make install update-grub启动参数也要调。在/etc/default/grub里加GRUB_CMDLINE_LINUXisolcpus2,3 nohz_full2,3 rcu_nocbs2,3 intel_pstatedisable processor.max_cstate1 idlepoll这几个参数的含义isolcpus把CPU 2和3从通用调度器里隔离出来专门跑实时任务nohz_full让这两个CPU不参与时钟节拍rcu_nocbs把RCU回调也移走intel_pstatedisable关掉Intel的变频驱动processor.max_cstate1限制CPU不能进深度睡眠idlepoll让空闲CPU忙等而不是睡眠降低唤醒延迟。注意idlepoll会让空闲CPU功耗升高散热不好的工控机慎用。如果功耗敏感可以改成idlemwait延迟略高但功耗低。2.4 实时性能的验证方法配完不是就完了得验证。最常用的工具是cyclictest来自rt-tests包。# 安装 apt install rt-tests # 跑测试4个线程优先级80跑1小时 cyclictest -t4 -p80 -m -n -i1000 -l3600000输出里关注Max那一列。合格线普通工控场景最大延迟控制在100微秒以内运动控制场景控制在50微秒以内高端伺服控制控制在20微秒以内。我实测过一台研华的工控机i7-8700配5.15 RT内核隔离两个核cyclictest跑8小时最大延迟18微秒。同一台机器用标准内核最大延迟能到800微秒以上。差距就是这么明显。如果最大延迟不达标排查顺序是先看BIOS里C-State和SpeedStep关了没再看isolcpus生效没cat /proc/cmdline确认然后看有没有其他进程在抢隔离核taskset -pc pid查最后看中断是不是都绑到了非隔离核cat /proc/interrupts查。3. 数据库在扛从关系型到时序库的选型逻辑3.1 工厂数据的三层结构工厂里的数据不是一种是三种存储需求完全不同。第一层是配置数据。比如产品型号、工艺参数、设备台账、人员权限。这类数据量小但一致性要求高改一条要保证所有相关方都看到。适合用关系型数据库MySQL、PostgreSQL、人大金仓都行。第二层是业务数据。比如工单、批次、质检记录、物料流转。这类数据量中等有事务要求经常要做关联查询。还是关系型数据库但要注意分库分表单表超过5000万行就要考虑拆了。第三层是时序数据。比如温度、压力、振动、电流每秒采一次一台设备一天就是86400条一条产线100台设备就是864万条。这类数据写入量极大查询模式固定按时间范围查、按设备查、做聚合用关系型数据库扛不住。必须用时序数据库。我见过一个反面案例。某工厂把所有数据都塞进MySQL一张表存传感器数据三个月后表到了80亿行查询慢到没法用磁盘也快满了。后来拆出来用时序数据库同样的数据量查询从几十秒降到几百毫秒压缩后磁盘占用只有原来的十分之一。3.2 时序数据库选型对比市面上时序数据库不少我列几个在工控场景常见的做个对比。数据库开发语言写入性能压缩率查询能力部署复杂度适用场景InfluxDBGo高高强低中小规模快速上线TimescaleDBC高中极强中需要SQL复杂查询TDengineC极高极高中低大规模国产化要求IoTDBJava高高中中工业物联网国产化OpenTSDBJava中中弱高老系统HBase生态选型的核心考量是三个写入吞吐、查询模式、运维成本。写入吞吐方面TDengine和InfluxDB是第一梯队单节点能到百万点每秒。TimescaleDB稍低但也能到几十万点每秒。OpenTSDB依赖HBase写入延迟高新项目不建议选。查询模式方面如果只需要按时间范围查原始点或者简单聚合所有时序库都行。如果需要复杂的关联查询、窗口函数、自定义聚合TimescaleDB优势明显因为它本质是PostgreSQL的扩展SQL能力完整。运维成本方面InfluxDB和TDengine单机部署简单集群版要商业授权。TimescaleDB基于PostgreSQL运维体系成熟但集群方案要自己搭。IoTDB和OpenTSDB依赖Java生态内存占用高小规模场景不划算。我的经验中小工厂点位10万InfluxDB或TDengine单机足够大型工厂点位100万TDengine集群或TimescaleDBPatroni有国产化硬要求的TDengine和IoTDB优先。3.3 时序数据库的建库建表实操以TDengine为例讲一下建库建表的实操。TDengine的模型是“一个设备一张表”这个设计跟传统数据库不一样但非常适合工控场景。-- 创建数据库保留365天每10天一个数据文件 CREATE DATABASE factory KEEP 365 DURATION 10 BUFFER 256 WAL_LEVEL 2; -- 创建超级表定义所有传感器的公共schema USE factory; CREATE STABLE sensors ( ts TIMESTAMP, value DOUBLE, quality INT ) TAGS ( device_id NCHAR(32), line_id NCHAR(16), sensor_type NCHAR(16) ); -- 为每个设备创建子表 CREATE TABLE dev_001 USING sensors TAGS (DEV001, LINE01, TEMP); CREATE TABLE dev_002 USING sensors TAGS (DEV002, LINE01, PRESS);这个模型的好处是写入时自动按设备分片查询时按设备过滤极快。比如查DEV001过去一小时的数据SELECT ts, value FROM dev_001 WHERE ts NOW - 1h;TDengine会自动只扫描dev_001对应的数据文件不会全表扫描。这就是为什么它写入和查询都快。KEEP 365表示数据保留365天超期自动删除。DURATION 10表示每10天的数据存一个文件这个参数要根据数据量调。数据量大就调小比如1天一个文件数据量小就调大减少文件数。BUFFER 256是写入缓存大小单位MB。写入量大就调大但别超过物理内存的50%。WAL_LEVEL 2是预写日志级别2表示写WAL但不fsync性能和可靠性的折中。如果数据不能丢改成1。3.4 数据库同步与高可用工厂数据库最怕两件事数据丢了和查询挂了。前者靠备份和同步后者靠高可用。同步方案分两种。实时同步用数据库自带的复制功能MySQL的主从复制、PostgreSQL的流复制、TDengine的副本机制。准实时同步用CDC工具比如Debezium、Canal把变更日志抽出来写到另一个库。实时同步延迟低但配置复杂准实时同步灵活但有延迟。我推荐工控场景用数据库原生复制定期逻辑备份的组合。原生复制保证高可用逻辑备份防止误删。逻辑备份用mysqldump或pg_dump每天凌晨跑一次保留30天。高可用方案看规模。单机场景用keepalivedvip做故障切换主库挂了VIP漂到备库。集群场景MySQL用MGRPostgreSQL用PatroniTDengine用多副本。MGR和Patroni配置复杂但切换自动化程度高适合无人值守的工厂环境。一个容易忽视的点数据库连接池要配好。工厂里的采集程序可能开几百个连接不配连接池的话数据库会被连接数打爆。MySQL的max_connections默认151要调到1000以上同时应用侧用HikariCP或Druid做池化。4. 高端制造在加速从数据到价值的最后一公里4.1 数据采集的实时性要求高端制造跟普通制造的区别很大程度上在数据采集的粒度和实时性。普通产线可能1秒采一次就够了高端产线要10毫秒甚至1毫秒采一次。举个例子。做航空发动机叶片加工五轴联动机床的刀具轨迹偏差要控制在微米级。这要求每个插补周期的位置、速度、电流数据都要采下来插补周期通常是1毫秒。一台机床一天跑16小时就是5760万个数据点。一个车间20台机床就是11.5亿个点。这个数据量没有时序数据库根本扛不住。采集的实时性还影响闭环控制。比如视觉检测发现缺陷要在100毫秒内把剔除指令发给执行机构。这100毫秒里图像采集占30毫秒算法推理占40毫秒通信占20毫秒留给数据库写入的时间只有10毫秒。如果数据库写入阻塞了整个闭环就断了。所以高端制造场景的数据库配置写入路径必须短。TDengine的WAL_LEVEL 2、InfluxDB的wal-fsync-delay、TimescaleDB的synchronous_commitoff都是为了缩短写入路径。代价是极端情况下可能丢最后几条数据但换来了实时性。4.2 边缘计算与云端协同高端制造的数据不能全传云端带宽扛不住延迟也扛不住。所以架构通常是边缘做实时处理云端做长期分析。边缘侧跑Linux时序数据库负责三件事数据采集与清洗、实时告警与闭环、数据压缩与上传。采集上来的原始数据先在边缘做异常值剔除、单位换算、时间对齐然后写本地时序库。同时跑规则引擎超过阈值就触发告警或停机。最后把压缩后的数据比如1秒聚合值上传云端。云端跑大数据平台负责长期趋势分析、多工厂对比、模型训练。边缘上传的聚合数据在云端做跨工厂的OEE对比、设备健康度评分、工艺参数优化。训练好的模型下发到边缘做实时推理。这个架构的关键是边缘和云端的数据模型要一致。边缘的超级表结构、标签定义、时间戳精度云端要能直接对接。否则数据上传后还要做ETL延迟就上去了。TDengine和IoTDB都支持边缘到云端的原生同步这是它们相比InfluxDB的优势。4.3 一个高端制造项目的落地复盘去年我参与了一个精密轴承工厂的数字化项目算是高端制造的典型场景。简单复盘一下。背景工厂有8条磨装线每条线12台设备关键设备是磨床和装配机。原来靠人工巡检每2小时记录一次温度、振动、电流。问题发现滞后经常是设备已经异常了才报警。目标实现关键参数的秒级采集异常在10秒内告警设备故障提前2小时预警。方案边缘侧8台工控机每台跑Ubuntu 20.04 PREEMPT_RT内核采集本线设备数据。采集协议用Modbus TCP和OPC UA采集频率1秒。数据库每台工控机跑TDengine单机版存本线数据。中心机房跑TDengine集群存所有线的聚合数据。告警边缘跑Python规则引擎阈值告警走本地声光报警趋势告警走企业微信推送。分析云端跑Python脚本每天做一次设备健康度评分评分低于阈值的设备推送到维修工单系统。踩过的坑时间同步。8台工控机的时间没同步数据上传后时间戳对不齐聚合结果全是错的。后来上了NTP每台机器跟中心机房对时误差控制在1毫秒内。Modbus采集阻塞。一台工控机采12台设备串行采集的话一轮要3秒达不到1秒频率。后来改成多线程并发采集每个设备一个线程才压到800毫秒一轮。TDengine的标签设计。一开始把设备型号、产线、工位都做成标签结果标签太多写入性能下降。后来精简到3个标签设备ID、产线ID、设备类型。磁盘写满。TDengine默认不限制磁盘使用跑了3个月磁盘满了数据库挂了。后来配了KEEP参数和磁盘配额超期数据自动删。效果上线6个月设备非计划停机时间下降42%质量缺陷率下降18%维修响应时间从平均4小时降到30分钟。4.4 常见问题速查表把工控场景里Linux和数据库的常见问题整理成表方便排查。现象可能原因排查方法解决措施采集数据时间戳乱序多机时间不同步date对比各机器时间配NTP统一时间源实时任务延迟大内核未打RT补丁uname -a看内核版本换RT内核调启动参数数据库写入慢磁盘IO瓶颈iostat -x 1看%util换SSD调WAL参数查询超时未建索引或数据量过大EXPLAIN看执行计划建索引加缓存分表连接数打满连接池未配或泄漏show processlist看连接配连接池查泄漏数据丢失WAL未开或fsync关闭查数据库配置开WAL调fsync策略磁盘写满未配数据保留策略df -h看磁盘配KEEP加磁盘配额网络中断丢数据采集程序无重传查采集日志加本地缓存断点续传这张表里的每一条我都在实际项目里遇到过。最坑的是“时间戳乱序”因为数据看起来是有的但聚合结果不对排查起来很费劲。建议项目一开始就把NTP配好别等出问题再补。5. 从选型到运维一些掏心窝子的经验5.1 硬件选型的三个原则工控场景的硬件选型跟互联网场景完全不一样。互联网追求性价比工控追求确定性。原则一网卡选Intel别选Realtek。Intel的i210、i350系列网卡Linux驱动成熟中断处理稳定支持多队列。Realtek的网卡便宜但驱动质量参差不齐高负载下容易丢包。我见过一个项目用Realtek网卡采EtherCAT周期抖动大得没法用换了Intel i210立马稳了。原则二SSD选企业级别选消费级。消费级SSD的写入寿命短工控场景7x24小时写入几个月就能把盘写坏。企业级SSD有断电保护、更高的TBW、更稳定的写入延迟。贵是贵但省下的停机损失远超差价。原则三内存要带ECC。工控机常年不关机内存位翻转的概率比消费场景高。ECC内存能纠正单比特错误避免数据静默损坏。时序数据库对内存错误特别敏感一个位翻转可能导致索引损坏。5.2 运维的日常检查清单工控系统的运维核心是预防性检查。等出问题再修损失已经造成了。我整理了一个日常检查清单每天花10分钟过一遍。磁盘df -h看使用率超过80%要清理。smartctl -a /dev/sda看SSD健康度。内存free -h看可用内存低于20%要查泄漏。dmesg | grep -i oom看有没有OOM杀进程。CPUtop看负载实时核的负载要单独看。mpstat -P ALL 1看各核使用率。网络ip -s link看丢包和错误。ss -s看连接数。数据库show status看慢查询、连接数、缓冲池命中率。实时性cyclictest跑短测试看最大延迟有没有劣化。日志journalctl -p err -since today看错误日志。这个清单看起来简单但坚持做能避免80%的突发故障。我见过太多项目平时不检查等磁盘满了、内存泄漏了才发现那时候已经晚了。5.3 关于国产化的几点实在话国产化是趋势但落地要务实。我的建议是分层推进。边缘层可以先用国产Linux。麒麟、统信、欧拉在边缘网关场景已经够用了实时补丁也有社区支持。边缘层出问题影响范围小可以容忍一些不完善。数据库层看场景。如果只是存配置和业务数据人大金仓、达梦都能替代MySQL。如果是时序数据TDengine和IoTDB是国产里最成熟的选择性能和生态都跟上了。应用层别急着换。很多工控软件只有Windows版强行换Linux要么用Wine不稳定要么重写成本高。建议先用虚拟机或容器过渡等国产替代方案成熟了再迁移。国产化的核心不是“换”是“可控”。只要代码可控、数据可控、供应链可控用谁的都行。为了换而换最后吃亏的是自己。5.4 给新入行者的学习路径如果你刚入行想往智能工厂的底层技术方向走我给一条学习路径。第一阶段Linux基础。把《鸟哥的Linux私房菜》过一遍重点学文件系统、进程管理、网络配置、Shell脚本。然后在虚拟机上装个Ubuntu Server手动配一遍静态IP、NTP、防火墙。第二阶段实时内核。找一台旧电脑编译一次RT内核跑cyclictest看效果。理解isolcpus、nohz_full这些参数的作用。这一步会踩很多坑但踩完就懂了。第三阶段数据库。先学MySQL把增删改查、索引、事务、复制搞明白。然后学一个时序数据库推荐TDengine因为它中文文档全、部署简单。建库建表、写入查询、保留策略都手动做一遍。第四阶段工控协议。学Modbus TCP和OPC UA用Python的pymodbus和opcua库写个采集程序。理解寄存器、线圈、节点这些概念。第五阶段项目实战。找一个开源SCADA项目比如ScadaBR或FUXA部署起来接模拟数据跑通。然后自己写一个采集存储告警的小系统。这条路径走下来大概需要6到12个月。不用急工控这行经验比速度重要。5.5 最后分享几个小技巧技巧一用systemd管理采集程序。别用nohup或screen用systemd配Restartalways程序挂了自动拉起。配CPUAffinity把采集程序绑到隔离核减少调度干扰。技巧二数据库写入用批量。单条写入的开销是批量写入的几十倍。采集程序攒够100条或等100毫秒批量写一次。TDengine的INSERT INTO ... VALUES (...), (...), ...支持多值写入性能提升明显。技巧三日志分级。采集程序的日志分DEBUG、INFO、WARN、ERROR四级生产环境只开INFO以上。DEBUG日志写入量大会拖慢程序。用logrotate做日志轮转别让日志把磁盘写满。技巧四备份要验证。备份文件不验证等于没备份。每次备份后在测试环境恢复一次确认数据完整。我见过备份文件损坏恢复时才发现那时候哭都来不及。技巧五文档要写。配置参数、网络拓扑、密码、故障处理流程全部写下来。别信自己的记忆力三个月后你肯定忘。文档放在团队共享的地方别只存自己电脑。这些技巧看起来琐碎但都是实际项目里用血泪换来的。智能工厂的底层技术没有什么高深的理论就是把每一个细节做扎实。Linux在跑数据库在扛高端制造在加速——这三句话的背后是无数个参数、配置、检查、复盘堆出来的。把基础打牢上面的智能才有意义。
