尧图网站建设 
1. 从“德前行”到“蓄势待发”一个工控运维小组的真实画像“德前行 # 蓄势待发”——第一次看到这个标题我脑子里蹦出来的不是口号而是一幅很具体的画面宁德基地的车间里产线还在跑PLC柜里的指示灯有节奏地闪着工控机风扇嗡嗡作响而运维小组的几个人正盯着屏幕上的报警日志一边啃着已经凉了的盒饭一边讨论某个PMC通讯超时的根因。这个标题背后其实是一个很典型的工业现场运维团队的状态既要“德前行”把日常的运维基本功做扎实又要“蓄势待发”随时准备应对产线突发故障和系统升级带来的挑战。我干运维这行十多年从桌面运维一路做到工控系统运维踩过的坑比走过的路还多。宁德基地这个工控系统运维小组核心工作围绕的就是工控系统的稳定运行涉及的关键模块包括PMC生产设备控制层、RC这里在工控语境下通常指远程控制或速率控制相关的回路/模块也常与RC滤波电路、RC延时电路等硬件信号调理相关、AVI自动视觉检测Automated Visual Inspection。这几个词放在一起基本勾勒出了一个现代化制造基地的工控运维全貌底层信号采集与调理、中层逻辑控制与通讯、上层视觉检测与数据回传。这篇文章适合谁看如果你是刚入行或者准备转岗到工控运维的工程师尤其是面对PMC、RC、AVI这些模块不知道怎么下手的人那这篇内容就是给你写的。如果你已经有一定经验但想看看别人家的运维小组是怎么组织工作、怎么排查故障、怎么把Linux常用命令和运维效率工具真正用到产线环境里的那也能找到不少共鸣。我不打算讲太多虚的就从实际工作出发把工控系统运维这件事拆开揉碎讲清楚每个环节为什么这么做、怎么做、做的时候要注意什么。2. 工控系统运维的核心模块拆解与选型逻辑2.1 PMC、RC、AVI三者的角色定位与协作关系在宁德基地这样的制造场景里PMC、RC、AVI不是孤立存在的。你可以把它们理解成一条流水线上的三个关键岗位PMC是“大脑”负责逻辑判断和指令下发RC是“神经末梢”和“信号调理器”负责把现场传感器的微弱信号或者高频干扰信号处理成PMC能识别的干净信号AVI是“眼睛”负责对产品外观、尺寸、缺陷进行自动检测并把结果反馈给PMC做分拣或报警。为什么要把这三个放在一起讲因为实际运维中很多故障不是单一模块的问题而是三者之间的协作出了问题。比如AVI检测到缺陷通过通讯把结果发给PMCPMC再控制执行机构剔除不良品。如果中间RC环节的信号调理没做好或者PMC的通讯周期设置不合理就会出现“AVI明明看到了但PMC没动作”或者“动作了但延迟太大”的情况。我见过最典型的一个案例AVI的触发信号经过一段长线缆传输后因为RC滤波参数没匹配好导致信号边沿变缓PMC读到的触发时刻比实际晚了十几毫秒结果高速产线上连续漏检。后来把RC滤波的截止频率重新算了一遍问题才解决。所以运维小组在分工上不能把PMC、RC、AVI完全割裂给不同的人管。理想的状态是每个人对这三个模块都有基本了解同时有一个人牵头负责跨模块的联调与故障定位。宁德基地这个小组的做法是日常巡检按模块分工但每周有一次联合巡检专门看三者之间的信号流和通讯质量。2.2 为什么工控运维越来越依赖Linux和自动化工具早年的工控运维很多老师傅靠的是万用表、示波器和一本设备手册走天下。但现在不一样了。工控机越来越多地跑Linux系统PLC和上位机之间的通讯大量走以太网AVI系统本身就是一台高性能工控机加相机加算法。你如果不会Linux常用命令连日志都找不到更别说排查网络问题了。我自己的经验是工控运维工程师需要掌握的Linux技能不需要像互联网运维那么深但以下几类必须熟练文件和目录操作ls、cd、cp、mv、rm、find、文本处理grep、awk、sed、tail、head、进程管理ps、top、kill、systemctl、网络排查ping、netstat、ss、tcpdump、ip、权限管理chmod、chown、sudo。这些命令在排查PMC通讯中断、AVI服务异常、RC数据采集卡驱动问题时使用频率极高。至于运维自动化工具工控现场和互联网机房不一样不能随便上Ansible、SaltStack这种重型工具因为很多工控机是Windows CE或者老版本Linux而且产线网络隔离严格。但轻量级的自动化还是可以做的比如用Shell脚本定时采集设备状态、用Python写简单的日志分析工具、用cron做定时任务。宁德基地小组的做法是先把重复性最高的巡检工作脚本化比如每天自动检查各工控机的磁盘空间、关键进程状态、网络连通性生成一份简报发到工作群。这样人只需要看异常项效率提升非常明显。2.3 RC滤波电路在工控信号链中的实际作用热词里出现了“rc滤波电路”“rc滤波传递函数”“一阶高通rc”“rc延时电路”“电流采样rc滤波”这些其实都指向同一个东西RC电路在工控信号调理中的应用。很多做运维的人觉得电路是硬件工程师的事但实际工作中信号质量问题导致的“软故障”往往需要运维去定位。举个实际例子宁德基地某条产线上PMC偶尔会收到错误的计数信号导致产量统计偏差。查了很久最后发现是电流采样电路上的RC滤波参数不合适工频干扰没滤干净导致ADC采样值跳动。运维小组需要理解的是RC低通滤波的截止频率 ( f_c \frac{1}{2\pi RC} )如果R取1kΩ、C取100nF截止频率大约是1.59kHz对于滤除50Hz工频干扰来说绰绰有余但如果信号本身是1kHz以上的脉冲就会被衰减。所以选RC参数时既要考虑干扰频率也要考虑有用信号的最高频率。RC延时电路则常用于消除按键抖动或者防止信号毛刺触发误动作。比如AVI的触发信号如果现场有振动导致触点抖动就可以加一个RC延时让信号稳定后再被PMC读取。延时时间 ( t RC )但实际还要考虑门电路的阈值电压通常取 ( t 0.7RC ) 到 ( RC ) 之间。这些计算不需要运维人员天天做但至少要能看懂硬件工程师给的参数并在故障排查时提出合理的怀疑方向。3. 工控运维实操从日常巡检到故障排查的完整流程3.1 日常巡检把80%的故障消灭在萌芽状态工控运维和互联网运维最大的区别是互联网服务挂了可以重启产线停了就是真金白银的损失。所以日常巡检不是走过场而是要把可能引发停线的隐患提前找出来。宁德基地小组的巡检清单我看了之后觉得挺实在这里结合我的经验展开讲。PMC巡检要点检查PLC的CPU负载、通讯模块指示灯状态、电池电压如果有、背板总线错误计数。这些数据有的可以直接在PLC编程软件里看有的需要通过网络读取。我习惯用一条简单的脚本定时抓取PLC的通讯状态寄存器如果发现错误计数在短时间内快速增长就说明通讯链路有问题可能是网线接头松动、交换机端口故障或者电磁干扰。RC相关巡检检查信号调理板的供电电压是否稳定、滤波电容有没有鼓包、接线端子有没有氧化。这些看起来是硬件的事但运维如果不看等信号漂移了再查就晚了。我遇到过好几次因为端子氧化导致接触电阻变大RC滤波特性改变信号幅值下降PMC读不到的情况。后来养成习惯每次巡检都用万用表量一下关键节点的电压记录下来做趋势分析。AVI巡检检查相机镜头是否清洁、光源亮度是否衰减、工控机磁盘空间和内存占用、检测算法有没有报错。AVI系统对光照条件很敏感镜头上一粒灰尘就可能导致误判。我建议每天开班前用无尘布擦一下镜头光源亮度用照度计量一下记录数值。如果发现亮度下降超过10%就要考虑更换光源或者调整曝光时间。注意巡检记录一定要电子化不要用纸质表格。纸质表格容易丢、难统计、无法做趋势分析。用简单的Excel或者开源的日志工具都行关键是坚持记录。3.2 故障排查从现象到根因的系统方法工控故障排查最忌讳的就是“头痛医头”。我总结了一个四步法确认现象、缩小范围、验证假设、根因修复。下面用一个真实案例来说明。现象某天下午产线突然报“AVI通讯超时”PMC收不到检测结果产线自动降速。第一步确认现象。先看AVI工控机是否还在运行检测软件是否卡死。登录AVI工控机Linux系统用top看CPU和内存发现检测进程CPU占用100%但内存正常。用tail -f看日志发现大量“image buffer overflow”错误。第二步缩小范围。问题出在AVI本身还是网络在AVI工控机上pingPMC的IP延迟正常丢包率为0。说明网络没问题问题在AVI内部。第三步验证假设。怀疑是图像处理来不及导致缓冲区溢出。检查相机触发频率发现比平时高了20%。问产线原来是在试产新产品速度调快了。AVI的算法处理单张图像的时间是固定的触发频率提高后处理速度跟不上缓冲区就溢出了。第四步根因修复。短期方案是降低产线速度或者提高AVI工控机性能换CPU、加内存。长期方案是优化检测算法或者增加相机数量分担负载。最后小组决定先优化算法把一些不必要的全图检测改成ROI区域检测处理时间下降了30%问题解决。这个案例里用到的Linux命令就是最基础的top、tail、ping但关键在于排查思路。很多新手一上来就重启设备重启后暂时好了过一会儿又出问题就是因为没找到根因。3.3 网络运维在工控环境中的特殊考量工控网络和办公网络不一样不能随便接外网不能随便装软件交换机很多是工业级的配置界面和商用交换机不同。但网络运维的基本功是一样的IP规划、VLAN划分、端口镜像、流量分析。宁德基地小组的做法是把工控网络分成几个独立的VLANPMC、RC、AVI各在一个VLAN之间通过工业防火墙或者三层交换机做受控通讯。这样做的好处是一个模块的网络风暴不会影响其他模块。我见过一个厂区所有设备都在一个扁平网络里结果一台工控机中毒后广播风暴整个产线瘫痪。后来重新规划了VLAN问题再没出现过。网络排查工具方面tcpdump和wireshark是必备的。在工控机上抓包分析PMC和AVI之间的通讯报文看是否有重传、乱序、延迟抖动。有一次我们怀疑AVI的检测结果偶尔丢失抓包后发现是PMC的通讯周期设置成了100ms而AVI的检测周期是120ms导致PMC有时候在AVI还没准备好结果的时候就发请求自然拿不到数据。后来把PMC的请求周期改成200ms问题解决。这种问题不看报文是永远查不出来的。提示工控网络抓包要注意不要在生产高峰期抓全流量否则可能把交换机CPU打满。建议用端口镜像加过滤条件只抓特定IP和端口的报文。4. 常见问题与排查技巧实录4.1 工控运维高频问题速查表下面这张表是我根据多年经验整理的涵盖了PMC、RC、AVI以及Linux系统层面的常见问题。你可以直接拿去当巡检和排查的参考。问题现象可能原因排查方法解决措施PMC通讯超时网线松动、交换机端口故障、IP冲突检查物理连接、ping测试、arp -a看IP冲突更换网线、重启端口、重新分配IPRC信号漂移滤波电容老化、端子氧化、供电不稳万用表测电压、示波器看波形更换电容、清洁端子、加稳压电源AVI误判率高镜头脏污、光源衰减、算法参数漂移清洁镜头、测照度、检查算法阈值调整曝光、更换光源、重新标定工控机磁盘满日志未清理、临时文件堆积df -h、du -sh *清理日志、设置logrotate进程卡死内存泄漏、死锁、CPU过载top、ps、strace重启进程、优化代码、加看门狗网络延迟大广播风暴、环路、带宽不足tcpdump、netstat -i划分VLAN、启用STP、限流数据采集丢点采样周期不匹配、缓冲区溢出检查采样配置、看缓冲区状态调整周期、增大缓冲区、优化算法4.2 那些文档里不会写的避坑经验坑一不要迷信“重启大法”。重启能解决很多问题但也会掩盖问题。我要求小组里每个人重启设备前必须做两件事一是记录当前状态日志、进程、网络连接二是问自己“如果重启后问题复现我下一步查什么”。这样才能把重启变成排查的一部分而不是逃避。坑二工控机的USB口不要随便插。产线工控机经常有人插U盘拷数据这是大忌。U盘带毒导致工控机中毒的案例我见过不止一次。宁德基地的做法是工控机的USB口用物理锁锁住需要拷数据时通过内网的文件服务器中转文件服务器有杀毒软件。坑三RC滤波参数不要随便改。有些新手看到信号有毛刺就想着把滤波电容加大。电容加大确实能滤得更干净但也会让信号边沿变缓导致PMC读到的信号延迟增加。改参数前一定要算一下截止频率和延时时间最好用示波器实际看一下波形变化。坑四AVI的标定不是一劳永逸的。相机、镜头、光源都会随时间变化标定参数需要定期更新。我建议至少每季度做一次完整标定每月做一次快速校验。校验方法很简单拿一个标准样品看检测结果是否和标准值一致。如果不一致就要重新标定。坑五Linux日志要会看更要会管。工控机的磁盘通常不大日志写满了就会导致系统异常。用logrotate做日志轮转是最基本的但要注意工控环境的日志可能包含大量重复的通讯报文轮转周期要设置合理。我一般设置每天轮转一次保留7天压缩存储。4.3 运维效率工具的真实使用体验热词里提到了“it运维效率工具”“桌面运维工具集”“运维自动化工具对比”我结合工控场景说几个真正好用的。Shell脚本工控Linux上最可靠的自动化工具。不需要装任何东西写个脚本就能定时巡检、清理日志、监控进程。我写过一个check_plc.sh每5分钟跑一次检查PLC通讯状态、磁盘空间、关键进程异常就发邮件告警。脚本很简单但省了每天手动检查的半小时。Python适合做日志分析和数据处理。比如AVI的检测结果日志是CSV格式用Python的pandas读进来统计误判率、漏检率生成趋势图。比Excel手动操作快得多而且可以定时自动跑。tmux在工控机上远程操作时tmux可以保持会话避免网络断开导致命令中断。尤其是升级固件或者跑长时间诊断脚本时tmux是必备的。htop比top更直观的进程监控工具工控Linux上如果能装强烈建议装一个。看CPU、内存、进程树一目了然。ncdu磁盘空间分析工具比du更直观能快速找到哪个目录占空间最多。工控机磁盘满的时候用ncdu几分钟就能定位到大文件。至于Ansible、SaltStack这些工控环境里我一般不推荐。一是很多工控机不支持Python或者版本太老二是产线网络隔离部署Agent很麻烦。轻量级脚本加cron对大多数工控运维场景已经够用了。5. 团队协作与能力建设让“蓄势待发”不只是口号5.1 运维小组的知识管理怎么做才有效工控运维有个特点很多经验是“师傅带徒弟”口口相传的一旦人员流动知识就断了。宁德基地小组的做法是建一个内部Wiki把常见故障、排查步骤、参数配置、供应商联系方式都记进去。但Wiki最大的问题是没人写、没人看。他们的解决办法是每次故障处理完必须写一份简短的故障报告格式固定现象、排查过程、根因、解决措施、预防建议直接贴到Wiki对应分类下。这样积累一年就是一个非常实用的知识库。我自己的经验是故障报告不要写太长一页A4纸足够。关键是“预防建议”这一栏要写清楚下次怎么提前发现这个问题。比如“建议每周检查一次RC调理板端子温度超过60度就要紧固或更换”。这种可操作的预防措施比长篇大论的分析有价值得多。5.2 从“救火”到“防火”运维工作的进阶路径很多工控运维小组大部分时间都在救火今天PMC通讯断了明天AVI误判了后天RC信号漂移了。救火当然重要但一直救火说明系统本身有问题。进阶的路径是先通过巡检和监控把常见故障管住然后分析故障数据找出高频故障的根本原因做系统性改进。比如如果发现PMC通讯超时每个月都发生几次就要统计一下是同一台设备还是不同设备是同一段网线还是不同位置是特定时间段还是随机发生统计之后往往能发现规律。宁德基地小组曾经统计了半年的通讯故障发现70%发生在下午2点到4点进一步排查发现那个时间段车间温度最高某台交换机的散热不好导致端口不稳定。后来给交换机加了散热风扇故障率下降了90%。这就是从救火到防火的典型例子。5.3 工控运维工程师需要学什么热词里“运维工程师需要学什么”“运维工程师面试题”“网络运维7天上岗”这些说明很多人关心入行和进阶。我结合工控场景给一个学习路径建议。基础阶段Linux常用命令、网络基础IP、子网、VLAN、路由、电气基础电压、电流、信号、接地。这些是吃饭的家伙必须熟练。进阶阶段PLC编程基础至少能看懂梯形图、工业通讯协议Modbus、Profinet、EtherCAT等、数据库基础SQL查询、脚本编程Shell或Python。高级阶段系统架构设计冗余、容错、灾备、数据分析故障预测、趋势分析、项目管理改造项目、升级项目。面试的时候工控运维岗位最常问的不是命令怎么拼而是“你遇到过最难的故障是什么怎么解决的”。所以平时一定要积累案例把每次故障的排查过程记下来面试时就是最好的素材。6. 一些个人体会工控系统运维这个活说到底是跟“不确定性”打交道。产线在跑设备在老化环境在变化你永远不知道下一个故障什么时候来。但正是这种不确定性让这份工作有了挑战和乐趣。宁德基地这个小组用“德前行 # 蓄势待发”作为口号我觉得挺贴切德前行是基本功是日常的巡检、记录、学习蓄势待发是状态是随时准备应对突发情况的底气和能力。我自己的体会是工控运维工程师的价值不在于会多少命令、懂多少协议而在于能不能在产线停摆的压力下快速定位问题、给出方案、恢复生产。这种能力需要技术积累更需要心态磨练。每次故障都是一次学习机会每次解决都是一次经验沉淀。时间长了你会发现那些曾经让你焦头烂额的故障都变成了你脑子里的“病例库”下次遇到类似现象直觉就会告诉你往哪个方向查。最后分享一个小技巧在工控机上建一个/root/notes目录每次处理完故障用echo把关键信息追加到一个文本文件里格式就是“日期 现象 根因 解决”。不需要很正式但坚持半年你就有了一本自己的故障字典。这个习惯我保持了十年受益无穷。 工控系统运维实战：PMC、RC、AVI模块故障排查与Linux工具应用
1. 从“德前行”到“蓄势待发”一个工控运维小组的真实画像“德前行 # 蓄势待发”——第一次看到这个标题我脑子里蹦出来的不是口号而是一幅很具体的画面宁德基地的车间里产线还在跑PLC柜里的指示灯有节奏地闪着工控机风扇嗡嗡作响而运维小组的几个人正盯着屏幕上的报警日志一边啃着已经凉了的盒饭一边讨论某个PMC通讯超时的根因。这个标题背后其实是一个很典型的工业现场运维团队的状态既要“德前行”把日常的运维基本功做扎实又要“蓄势待发”随时准备应对产线突发故障和系统升级带来的挑战。我干运维这行十多年从桌面运维一路做到工控系统运维踩过的坑比走过的路还多。宁德基地这个工控系统运维小组核心工作围绕的就是工控系统的稳定运行涉及的关键模块包括PMC生产设备控制层、RC这里在工控语境下通常指远程控制或速率控制相关的回路/模块也常与RC滤波电路、RC延时电路等硬件信号调理相关、AVI自动视觉检测Automated Visual Inspection。这几个词放在一起基本勾勒出了一个现代化制造基地的工控运维全貌底层信号采集与调理、中层逻辑控制与通讯、上层视觉检测与数据回传。这篇文章适合谁看如果你是刚入行或者准备转岗到工控运维的工程师尤其是面对PMC、RC、AVI这些模块不知道怎么下手的人那这篇内容就是给你写的。如果你已经有一定经验但想看看别人家的运维小组是怎么组织工作、怎么排查故障、怎么把Linux常用命令和运维效率工具真正用到产线环境里的那也能找到不少共鸣。我不打算讲太多虚的就从实际工作出发把工控系统运维这件事拆开揉碎讲清楚每个环节为什么这么做、怎么做、做的时候要注意什么。2. 工控系统运维的核心模块拆解与选型逻辑2.1 PMC、RC、AVI三者的角色定位与协作关系在宁德基地这样的制造场景里PMC、RC、AVI不是孤立存在的。你可以把它们理解成一条流水线上的三个关键岗位PMC是“大脑”负责逻辑判断和指令下发RC是“神经末梢”和“信号调理器”负责把现场传感器的微弱信号或者高频干扰信号处理成PMC能识别的干净信号AVI是“眼睛”负责对产品外观、尺寸、缺陷进行自动检测并把结果反馈给PMC做分拣或报警。为什么要把这三个放在一起讲因为实际运维中很多故障不是单一模块的问题而是三者之间的协作出了问题。比如AVI检测到缺陷通过通讯把结果发给PMCPMC再控制执行机构剔除不良品。如果中间RC环节的信号调理没做好或者PMC的通讯周期设置不合理就会出现“AVI明明看到了但PMC没动作”或者“动作了但延迟太大”的情况。我见过最典型的一个案例AVI的触发信号经过一段长线缆传输后因为RC滤波参数没匹配好导致信号边沿变缓PMC读到的触发时刻比实际晚了十几毫秒结果高速产线上连续漏检。后来把RC滤波的截止频率重新算了一遍问题才解决。所以运维小组在分工上不能把PMC、RC、AVI完全割裂给不同的人管。理想的状态是每个人对这三个模块都有基本了解同时有一个人牵头负责跨模块的联调与故障定位。宁德基地这个小组的做法是日常巡检按模块分工但每周有一次联合巡检专门看三者之间的信号流和通讯质量。2.2 为什么工控运维越来越依赖Linux和自动化工具早年的工控运维很多老师傅靠的是万用表、示波器和一本设备手册走天下。但现在不一样了。工控机越来越多地跑Linux系统PLC和上位机之间的通讯大量走以太网AVI系统本身就是一台高性能工控机加相机加算法。你如果不会Linux常用命令连日志都找不到更别说排查网络问题了。我自己的经验是工控运维工程师需要掌握的Linux技能不需要像互联网运维那么深但以下几类必须熟练文件和目录操作ls、cd、cp、mv、rm、find、文本处理grep、awk、sed、tail、head、进程管理ps、top、kill、systemctl、网络排查ping、netstat、ss、tcpdump、ip、权限管理chmod、chown、sudo。这些命令在排查PMC通讯中断、AVI服务异常、RC数据采集卡驱动问题时使用频率极高。至于运维自动化工具工控现场和互联网机房不一样不能随便上Ansible、SaltStack这种重型工具因为很多工控机是Windows CE或者老版本Linux而且产线网络隔离严格。但轻量级的自动化还是可以做的比如用Shell脚本定时采集设备状态、用Python写简单的日志分析工具、用cron做定时任务。宁德基地小组的做法是先把重复性最高的巡检工作脚本化比如每天自动检查各工控机的磁盘空间、关键进程状态、网络连通性生成一份简报发到工作群。这样人只需要看异常项效率提升非常明显。2.3 RC滤波电路在工控信号链中的实际作用热词里出现了“rc滤波电路”“rc滤波传递函数”“一阶高通rc”“rc延时电路”“电流采样rc滤波”这些其实都指向同一个东西RC电路在工控信号调理中的应用。很多做运维的人觉得电路是硬件工程师的事但实际工作中信号质量问题导致的“软故障”往往需要运维去定位。举个实际例子宁德基地某条产线上PMC偶尔会收到错误的计数信号导致产量统计偏差。查了很久最后发现是电流采样电路上的RC滤波参数不合适工频干扰没滤干净导致ADC采样值跳动。运维小组需要理解的是RC低通滤波的截止频率 ( f_c \frac{1}{2\pi RC} )如果R取1kΩ、C取100nF截止频率大约是1.59kHz对于滤除50Hz工频干扰来说绰绰有余但如果信号本身是1kHz以上的脉冲就会被衰减。所以选RC参数时既要考虑干扰频率也要考虑有用信号的最高频率。RC延时电路则常用于消除按键抖动或者防止信号毛刺触发误动作。比如AVI的触发信号如果现场有振动导致触点抖动就可以加一个RC延时让信号稳定后再被PMC读取。延时时间 ( t RC )但实际还要考虑门电路的阈值电压通常取 ( t 0.7RC ) 到 ( RC ) 之间。这些计算不需要运维人员天天做但至少要能看懂硬件工程师给的参数并在故障排查时提出合理的怀疑方向。3. 工控运维实操从日常巡检到故障排查的完整流程3.1 日常巡检把80%的故障消灭在萌芽状态工控运维和互联网运维最大的区别是互联网服务挂了可以重启产线停了就是真金白银的损失。所以日常巡检不是走过场而是要把可能引发停线的隐患提前找出来。宁德基地小组的巡检清单我看了之后觉得挺实在这里结合我的经验展开讲。PMC巡检要点检查PLC的CPU负载、通讯模块指示灯状态、电池电压如果有、背板总线错误计数。这些数据有的可以直接在PLC编程软件里看有的需要通过网络读取。我习惯用一条简单的脚本定时抓取PLC的通讯状态寄存器如果发现错误计数在短时间内快速增长就说明通讯链路有问题可能是网线接头松动、交换机端口故障或者电磁干扰。RC相关巡检检查信号调理板的供电电压是否稳定、滤波电容有没有鼓包、接线端子有没有氧化。这些看起来是硬件的事但运维如果不看等信号漂移了再查就晚了。我遇到过好几次因为端子氧化导致接触电阻变大RC滤波特性改变信号幅值下降PMC读不到的情况。后来养成习惯每次巡检都用万用表量一下关键节点的电压记录下来做趋势分析。AVI巡检检查相机镜头是否清洁、光源亮度是否衰减、工控机磁盘空间和内存占用、检测算法有没有报错。AVI系统对光照条件很敏感镜头上一粒灰尘就可能导致误判。我建议每天开班前用无尘布擦一下镜头光源亮度用照度计量一下记录数值。如果发现亮度下降超过10%就要考虑更换光源或者调整曝光时间。注意巡检记录一定要电子化不要用纸质表格。纸质表格容易丢、难统计、无法做趋势分析。用简单的Excel或者开源的日志工具都行关键是坚持记录。3.2 故障排查从现象到根因的系统方法工控故障排查最忌讳的就是“头痛医头”。我总结了一个四步法确认现象、缩小范围、验证假设、根因修复。下面用一个真实案例来说明。现象某天下午产线突然报“AVI通讯超时”PMC收不到检测结果产线自动降速。第一步确认现象。先看AVI工控机是否还在运行检测软件是否卡死。登录AVI工控机Linux系统用top看CPU和内存发现检测进程CPU占用100%但内存正常。用tail -f看日志发现大量“image buffer overflow”错误。第二步缩小范围。问题出在AVI本身还是网络在AVI工控机上pingPMC的IP延迟正常丢包率为0。说明网络没问题问题在AVI内部。第三步验证假设。怀疑是图像处理来不及导致缓冲区溢出。检查相机触发频率发现比平时高了20%。问产线原来是在试产新产品速度调快了。AVI的算法处理单张图像的时间是固定的触发频率提高后处理速度跟不上缓冲区就溢出了。第四步根因修复。短期方案是降低产线速度或者提高AVI工控机性能换CPU、加内存。长期方案是优化检测算法或者增加相机数量分担负载。最后小组决定先优化算法把一些不必要的全图检测改成ROI区域检测处理时间下降了30%问题解决。这个案例里用到的Linux命令就是最基础的top、tail、ping但关键在于排查思路。很多新手一上来就重启设备重启后暂时好了过一会儿又出问题就是因为没找到根因。3.3 网络运维在工控环境中的特殊考量工控网络和办公网络不一样不能随便接外网不能随便装软件交换机很多是工业级的配置界面和商用交换机不同。但网络运维的基本功是一样的IP规划、VLAN划分、端口镜像、流量分析。宁德基地小组的做法是把工控网络分成几个独立的VLANPMC、RC、AVI各在一个VLAN之间通过工业防火墙或者三层交换机做受控通讯。这样做的好处是一个模块的网络风暴不会影响其他模块。我见过一个厂区所有设备都在一个扁平网络里结果一台工控机中毒后广播风暴整个产线瘫痪。后来重新规划了VLAN问题再没出现过。网络排查工具方面tcpdump和wireshark是必备的。在工控机上抓包分析PMC和AVI之间的通讯报文看是否有重传、乱序、延迟抖动。有一次我们怀疑AVI的检测结果偶尔丢失抓包后发现是PMC的通讯周期设置成了100ms而AVI的检测周期是120ms导致PMC有时候在AVI还没准备好结果的时候就发请求自然拿不到数据。后来把PMC的请求周期改成200ms问题解决。这种问题不看报文是永远查不出来的。提示工控网络抓包要注意不要在生产高峰期抓全流量否则可能把交换机CPU打满。建议用端口镜像加过滤条件只抓特定IP和端口的报文。4. 常见问题与排查技巧实录4.1 工控运维高频问题速查表下面这张表是我根据多年经验整理的涵盖了PMC、RC、AVI以及Linux系统层面的常见问题。你可以直接拿去当巡检和排查的参考。问题现象可能原因排查方法解决措施PMC通讯超时网线松动、交换机端口故障、IP冲突检查物理连接、ping测试、arp -a看IP冲突更换网线、重启端口、重新分配IPRC信号漂移滤波电容老化、端子氧化、供电不稳万用表测电压、示波器看波形更换电容、清洁端子、加稳压电源AVI误判率高镜头脏污、光源衰减、算法参数漂移清洁镜头、测照度、检查算法阈值调整曝光、更换光源、重新标定工控机磁盘满日志未清理、临时文件堆积df -h、du -sh *清理日志、设置logrotate进程卡死内存泄漏、死锁、CPU过载top、ps、strace重启进程、优化代码、加看门狗网络延迟大广播风暴、环路、带宽不足tcpdump、netstat -i划分VLAN、启用STP、限流数据采集丢点采样周期不匹配、缓冲区溢出检查采样配置、看缓冲区状态调整周期、增大缓冲区、优化算法4.2 那些文档里不会写的避坑经验坑一不要迷信“重启大法”。重启能解决很多问题但也会掩盖问题。我要求小组里每个人重启设备前必须做两件事一是记录当前状态日志、进程、网络连接二是问自己“如果重启后问题复现我下一步查什么”。这样才能把重启变成排查的一部分而不是逃避。坑二工控机的USB口不要随便插。产线工控机经常有人插U盘拷数据这是大忌。U盘带毒导致工控机中毒的案例我见过不止一次。宁德基地的做法是工控机的USB口用物理锁锁住需要拷数据时通过内网的文件服务器中转文件服务器有杀毒软件。坑三RC滤波参数不要随便改。有些新手看到信号有毛刺就想着把滤波电容加大。电容加大确实能滤得更干净但也会让信号边沿变缓导致PMC读到的信号延迟增加。改参数前一定要算一下截止频率和延时时间最好用示波器实际看一下波形变化。坑四AVI的标定不是一劳永逸的。相机、镜头、光源都会随时间变化标定参数需要定期更新。我建议至少每季度做一次完整标定每月做一次快速校验。校验方法很简单拿一个标准样品看检测结果是否和标准值一致。如果不一致就要重新标定。坑五Linux日志要会看更要会管。工控机的磁盘通常不大日志写满了就会导致系统异常。用logrotate做日志轮转是最基本的但要注意工控环境的日志可能包含大量重复的通讯报文轮转周期要设置合理。我一般设置每天轮转一次保留7天压缩存储。4.3 运维效率工具的真实使用体验热词里提到了“it运维效率工具”“桌面运维工具集”“运维自动化工具对比”我结合工控场景说几个真正好用的。Shell脚本工控Linux上最可靠的自动化工具。不需要装任何东西写个脚本就能定时巡检、清理日志、监控进程。我写过一个check_plc.sh每5分钟跑一次检查PLC通讯状态、磁盘空间、关键进程异常就发邮件告警。脚本很简单但省了每天手动检查的半小时。Python适合做日志分析和数据处理。比如AVI的检测结果日志是CSV格式用Python的pandas读进来统计误判率、漏检率生成趋势图。比Excel手动操作快得多而且可以定时自动跑。tmux在工控机上远程操作时tmux可以保持会话避免网络断开导致命令中断。尤其是升级固件或者跑长时间诊断脚本时tmux是必备的。htop比top更直观的进程监控工具工控Linux上如果能装强烈建议装一个。看CPU、内存、进程树一目了然。ncdu磁盘空间分析工具比du更直观能快速找到哪个目录占空间最多。工控机磁盘满的时候用ncdu几分钟就能定位到大文件。至于Ansible、SaltStack这些工控环境里我一般不推荐。一是很多工控机不支持Python或者版本太老二是产线网络隔离部署Agent很麻烦。轻量级脚本加cron对大多数工控运维场景已经够用了。5. 团队协作与能力建设让“蓄势待发”不只是口号5.1 运维小组的知识管理怎么做才有效工控运维有个特点很多经验是“师傅带徒弟”口口相传的一旦人员流动知识就断了。宁德基地小组的做法是建一个内部Wiki把常见故障、排查步骤、参数配置、供应商联系方式都记进去。但Wiki最大的问题是没人写、没人看。他们的解决办法是每次故障处理完必须写一份简短的故障报告格式固定现象、排查过程、根因、解决措施、预防建议直接贴到Wiki对应分类下。这样积累一年就是一个非常实用的知识库。我自己的经验是故障报告不要写太长一页A4纸足够。关键是“预防建议”这一栏要写清楚下次怎么提前发现这个问题。比如“建议每周检查一次RC调理板端子温度超过60度就要紧固或更换”。这种可操作的预防措施比长篇大论的分析有价值得多。5.2 从“救火”到“防火”运维工作的进阶路径很多工控运维小组大部分时间都在救火今天PMC通讯断了明天AVI误判了后天RC信号漂移了。救火当然重要但一直救火说明系统本身有问题。进阶的路径是先通过巡检和监控把常见故障管住然后分析故障数据找出高频故障的根本原因做系统性改进。比如如果发现PMC通讯超时每个月都发生几次就要统计一下是同一台设备还是不同设备是同一段网线还是不同位置是特定时间段还是随机发生统计之后往往能发现规律。宁德基地小组曾经统计了半年的通讯故障发现70%发生在下午2点到4点进一步排查发现那个时间段车间温度最高某台交换机的散热不好导致端口不稳定。后来给交换机加了散热风扇故障率下降了90%。这就是从救火到防火的典型例子。5.3 工控运维工程师需要学什么热词里“运维工程师需要学什么”“运维工程师面试题”“网络运维7天上岗”这些说明很多人关心入行和进阶。我结合工控场景给一个学习路径建议。基础阶段Linux常用命令、网络基础IP、子网、VLAN、路由、电气基础电压、电流、信号、接地。这些是吃饭的家伙必须熟练。进阶阶段PLC编程基础至少能看懂梯形图、工业通讯协议Modbus、Profinet、EtherCAT等、数据库基础SQL查询、脚本编程Shell或Python。高级阶段系统架构设计冗余、容错、灾备、数据分析故障预测、趋势分析、项目管理改造项目、升级项目。面试的时候工控运维岗位最常问的不是命令怎么拼而是“你遇到过最难的故障是什么怎么解决的”。所以平时一定要积累案例把每次故障的排查过程记下来面试时就是最好的素材。6. 一些个人体会工控系统运维这个活说到底是跟“不确定性”打交道。产线在跑设备在老化环境在变化你永远不知道下一个故障什么时候来。但正是这种不确定性让这份工作有了挑战和乐趣。宁德基地这个小组用“德前行 # 蓄势待发”作为口号我觉得挺贴切德前行是基本功是日常的巡检、记录、学习蓄势待发是状态是随时准备应对突发情况的底气和能力。我自己的体会是工控运维工程师的价值不在于会多少命令、懂多少协议而在于能不能在产线停摆的压力下快速定位问题、给出方案、恢复生产。这种能力需要技术积累更需要心态磨练。每次故障都是一次学习机会每次解决都是一次经验沉淀。时间长了你会发现那些曾经让你焦头烂额的故障都变成了你脑子里的“病例库”下次遇到类似现象直觉就会告诉你往哪个方向查。最后分享一个小技巧在工控机上建一个/root/notes目录每次处理完故障用echo把关键信息追加到一个文本文件里格式就是“日期 现象 根因 解决”。不需要很正式但坚持半年你就有了一本自己的故障字典。这个习惯我保持了十年受益无穷。