一块RK3588的板子刷完系统、点亮屏幕、跑通yolov8这不算什么本事真正难的是把它扔到机房里连续跑一个月不重启不计日志、不高温降频、不掉盘、不假死。我做边缘AI设备这么久最深的体会就是demo阶段什么板子都好用一旦进入7×24连续运行RK3588的电源、散热、存储、掉电保护、进程守护全部要重新设计一遍。这篇文章要讲的Guardian守护就是围绕RK3588边缘AI设备打造的一套“防死机体系”。不是简单的看门狗也不是加个散热风扇而是从硬件看门狗到系统服务监控、再到AI推理进程自愈的完整架构。适合正在做RK3588边缘盒子、智慧安防、工业视觉、视频监控硬编码和NPU推理一体机的朋友直接参考。1. 项目由来边缘AI设备的“能跑”和“不死机”是两码事1.1 先搞清楚RK3588承担的是什么样的边缘负载RK3588这颗芯片八核ARM加上6TOPS的NPU放在边缘AI设备里属于非常主流的方案。很多项目拿它做多路视频结构化、实时检测、智慧安防、工业质检进程的典型形态是从摄像头拉RTSP流走RK3588的VPU硬件解码把YUV帧做缩放后再丢给NPU跑模型检测结果写回业务系统同时还要做视频硬编码存储。这一套负载CPU八个核不一定全占满但NPU和VPU基本不会闲着。也正因为如此设备内部的发热、内存分配、文件读写和系统调度的压力是全方位的。我见过太多人拿着正点原子RK3588开发板或者自己画的边缘盒子跑通rknn-toolkit2导出的yolov8模型demo后就觉得大功告成demo跑几分钟出框就发朋友圈。结果真正部署到现场24小时不到就开始各种“抽风”有的温度飙到85度触发降频画面掉帧有的跑了两天日志文件撑爆根分区有的死机后没有任何重启机制现场运维根本进不去。7×24场景下这些问题的出现不是概率而是必然。RK3588是一块高性能芯片高性能意味着高功耗高功耗意味着高热量和更严苛的电源要求。边缘AI部署如果在设计阶段没有把长时间连续运行放进约束条件后面一定会被现场问题追着跑。所以做Guardian守护之前第一步是把“能跑”和“能长久跑”这两件事彻底区分开。1.2 死机不是“突然黑屏”那么简单要分场景在7×24运行环境里死机这个词其实很笼统。我把实际遇到的故障分成四类每一类的处理方式完全不同。第一类是硬件级死机电源纹波大、DDR不稳定、芯片过热导致整机完全没反应第二类是内核级死机内核panic串口最后一行打印卡住系统彻底失去调度能力第三类是用户态假死主进程还活着但NPU推理线程或者视频拉流线程卡死设备从外面看就像瘫痪了一样第四类是存储或系统损坏日志写满根分区、根文件系统变只读、启动流程卡在挂载阶段。这四类故障的可控性差别很大。用户态假死可以通过守护进程自愈存储问题可以通过分区设计和日志轮转规避但硬件级和内核级崩溃软件层面的处理就非常有限只能靠看门狗兜底。这也决定了Guardian不能只做一个“重启大法”必须是一套分层设计每一层解决特定范围内的问题层与层之间互为补充。我经常在排查现场看到的问题是设备表面上看是“死机”了拔电重启又好了所以大家都懒得深究。但实际上不找到死机的类型就盲目重启下一次故障大概率更快出现因为根本原因没有被消除。Guardian的初步设计目标就是要回答一个问题系统什么时候该自愈什么时候该重启什么时候必须拉到救援模式。1.3 Guardian守护不是什么高大上的框架而是工程预案很多朋友听到“守护”两个字以为我要写一个复杂的框架其实不是。Guardian真正做的事情是把RK3588边缘设备在长时间运行中遇到的常见故障全部预设好处理策略。它由几个非常朴素的东西组成硬件看门狗服务和/dev/watchdog节点一组systemd服务单元文件一个AI进程的健康检查脚本以及一套日志、内存、磁盘的“环卫机制”最后再加上异常掉电后的恢复和救援路径。整套方案的定位是“运维底盘”不替代业务代码业务进程该怎么写还是怎么写但有了Guardian以后业务进程崩了、卡了、内存泄漏了系统能够在几秒到几十秒内自动恢复而不是等着现场维护人员去拔电。这样设计的另外一个好处是Guardian自身足够轻状态全部放在内存临时目录不依赖数据库不依赖网络哪怕网络断了、存储出问题了Guardian依然能按照设定好的规则去执行守护动作。所以接下来要讲的重点不是某一个技巧而是把“7×24不死机”这个问题拆成硬件防护、系统加固、应用自愈和救援恢复四个环节来看。理解了这个整体思路后面每个人都能根据自己设备的实际情况去微调参数。2. 整体设计思路三层防线先自愈再重启2.1 第一层防线硬件看门狗最后兜底软件层面的守护再怎么做也改变不了一个事实一旦内核卡死或者电源出问题操作系统本身已经没有能力执行任何逻辑。这时候唯一的兜底就是硬件看门狗。RK3588平台要启用硬件看门狗内核需要开启CONFIG_WATCHDOG系统起来之后能看到/dev/watchdog节点。常见做法是跑一个systemd服务周期性地往这个节点写字符喂狗如果喂狗服务因为系统卡死而停止看门狗硬件就会在规定时间内触发复位。这里有一个非常关键的细节喂狗动作不能放在一个独立空转的进程里。很多初学者喜欢写一个专门的小脚本每隔几秒写一次/dev/watchdog但这样做的效果很差因为系统可能已经接近瘫痪业务全挂了这个专门喂狗的进程却还在跑看门狗永远认为系统是健康的。我在Guardian里的做法是把喂狗和业务心跳绑定AI进程每隔一段时间往/tmp/health写入时间戳喂狗服务同时检查业务心跳只有在业务心跳正常的情况下才喂狗一旦业务心跳超时立即停止喂狗硬件看门狗随后复位整机。看门狗的超时时间需要仔细调太短容易被系统瞬时繁忙误触发太长又起不到保护作用。我这边一般设置在15秒左右喂狗周期是5秒既留够余量又能快速响应。另外还要注意正常关机逻辑系统在优雅关机的过程中要先把看门狗关掉或者停止喂狗否则会出现关机过程中被看门狗强制重启的现象这在生产环境会引发很多脏数据问题。2.2 第二层防线systemd服务监控与自愈第二层防线解决的是用户态服务的崩溃和假死问题。RK3588上跑边缘AI业务进程一般会拆成几个service拉流服务、推理服务、结果上报服务、硬件编解码服务。每一个都建议用systemd unit来管理打开自动重启策略RestartalwaysRestartSec10。这样进程崩溃了systemd会拉起来不需要额外写脚本轮询进程是否存在。但这里有个坑Restartalways遇到一个启动必失败的进程它就会进入无限重启循环把CPU和日志全部打满。所以必须配上启动次数限制比如StartLimitIntervalSec300和StartLimitBurst5意思是5分钟内最多重启5次超出后systemd会放弃不再尝试拉起。这时候由上一层的“业务心跳检查”接管如果健康检查发现核心服务已经停止就主动触发看门狗复位整个设备而不是让一个不可能起来的服务无限空转。另一个容易被忽略的点是启动成功的判定。用Typesimple的服务systemd默认只要fork出进程就算启动成功了但实际上你的Python推理程序可能还在加载模型、初始化RKNN上下文这期间就算没准备好systemd也认为它活着。更好的方式是用Typenotify在业务代码里调用sd_notify发一个READY信号告诉systemd我已经初始化完成了。这样一旦初始化超时systemd会按规则重启服务不会在“半死”状态下傻等。2.3 第三层防线存储、内存与日志的“环卫机制”长期运行的设备很大一部分“死机”不是CPU或NPU挂了而是存储和内存被慢慢耗尽。最常见的问题是日志文件无节制膨胀systemd journal默认把日志写到/var/log/journal内存里挂一个logrotate也经常因为服务一直持有文件句柄导致轮转失败。我在Guardian里把日志目录直接挂成tmpfs重启即清空同时配置journald的SystemMaxUse和RuntimeMaxUse限制最大体积再加上logrotate压缩归档。这样即使日志疯狂刷也不会吃光根分区。内存方面RK3588的DDR虽然通常有4G到8G但NPU推理和视频编解码都要分配大量buffer一旦某个线程没有释放顶多两三天就会出现内存耗尽。我这边会在系统里配一个监控脚本周期性检查/proc/meminfo的可用内存低于阈值时先重启最占内存的业务服务而不是整机重启因为整机重启会导致录像断档和网络重连能局部恢复就局部恢复。文件系统还有个大问题是掉电保护。RK3588设备如果直接断电频繁的ext4元数据写入可能让rootfs受损。Guardian的思路是把日志、临时文件、模型缓存全部放到内存文件系统减少对flash的写入根文件系统在部署完成后可以切换成overlayfs只读层业务数据写到独立数据分区。这样常规运行几乎不对根分区产生写入断电后启动能稳定很多。2.4 为什么“先自愈再重启”是必须坚持的原则有朋友跟我说既然做7×24那最简单粗暴的办法就是在系统里配置一个每分钟检查一次的脚本发现响应超时就自动reboot这样不就行了吗听起来有道理实际执行起来问题很多。频繁重启会导致设备反复出现断网、录像丢失、模型重新加载等连锁反应尤其当业务侧有数据上报时长时间“业务中断”本身就是事故。所以Guardian的故障响应优先级是先尝试局部恢复比如重启某个服务、清理内存、降级某些非关键功能只有在这些手段全部失效或者系统级健康检查判定整机无响应时才走看门狗复位。这套“先自愈再重启”的原则用下来最直观的效果是设备的重启次数大幅减少。通过健康检查日志能看到很多原来会演变成整机死机的小问题在服务级别就被处理掉了。真正需要硬件看门狗出手的场景平均一个月也没几次。对边缘AI设备来说业务连续性比一次重启能解决多少个问题重要得多。3. 核心环节实操Guardian实战落地3.1 硬件基础散热设计与PWM风扇转速监控RK3588的散热问题是7×24稳定运行的第一道坎。这颗芯片满负载功耗不低如果外壳是密封的、没有风扇温度很容易冲到85度以上触发SoC降频。降频之后NPU算力掉得厉害yolov8的推理帧率直接下降表面看起来就是设备“卡死”了。所以散热不能靠运气必须主动管理。我的做法是铝合金外壳做被动散热配合一颗4线PWM风扇主动散热同时利用软件动态调速。RK3588的设备树里一般会配置pwm-fan节点把风扇绑定到thermal zone的cooling device上系统会自动根据温度调节占空比。比如温度超过60度就开一个高速档低于50度就切到低速档。这里需要确认硬件上PWM信号接的是RK3588的哪个PWM控制器否则风扇可能不转。再说读取风扇转速也就是热词里大家常搜的“rk3588 读取风扇转速”。一般4线风扇的测速线输出的是脉冲信号每转一圈输出一到几个脉冲常见的是每转两个脉冲。要把这个脉冲读上来可以在RK3588上用GPIO中断配合定时器计数或者直接用PWM capture功能去量脉冲频率。我先用示波器确认测速线输出的脉冲波形然后写了一个小驱动或者用内核的gpio-keys机制去统计。转速的换算公式很朴素转速RPM 每秒钟脉冲数 × 60 ÷ 每转脉冲数。我见过很多人把测速线和PWM控制线接反结果风扇转但永远读不到转速所以布线的时候一定要对照原理图正点原子RK3588开发板的各个接口丝印要看仔细。风扇转速不是只看有没有转就够了还要监控趋势。风扇用久了会积灰、轴承磨损转速会慢慢下降。我在Guardian里加了一个检查连续几次读到的风扇转速低于设定阈值或者温度持续走高但转速上不来就判定风扇异常直接触发硬件看门狗复位提醒现场人员处理。宁可让它重启也不能让它在超温状态下继续烧芯片。3.2 系统层加固看门狗与关键系统参数先开启内核看门狗。在RK3588的Linux系统里设备节点是/dev/watchdog我写了一个非常简单的systemd喂狗服务每5秒往节点写一次字符。服务单元大概是这样的[Unit] DescriptionGuardian Watchdog Feeder Aftermulti-user.target [Service] ExecStart/usr/local/bin/watchdog_feed.py Restartalways RestartSec5 WatchdogSec15 [Install] WantedBymulti-user.target对应的喂狗脚本可以在Python里写也可以直接用一个while循环加echo。但核心逻辑不是单纯喂狗而是同时检查业务心跳文件的时间戳#!/usr/bin/env python3 import os, time WATCHDOG_DEV /dev/watchdog HEALTH_FILE /tmp/guardian/health def check_health(): if not os.path.exists(HEALTH_FILE): return False mtime os.path.getmtime(HEALTH_FILE) if time.time() - mtime 12: return False return True with open(WATCHDOG_DEV, w) as wd: while True: try: if check_health(): wd.write(w) wd.flush() else: time.sleep(2) except Exception as e: time.sleep(1) time.sleep(5)注意这个脚本里有一个非常重要的细节如果业务心跳异常脚本不喂狗但也不退出只是干等。因为一旦打开过/dev/watchdog如果脚本退出有些看门狗驱动也会触发复位干脆让它空转到硬件超时。这样做比直接打开文件等更可控。系统参数方面在/etc/sysctl.d/99-guardian.conf里我配置了几项kernel.panic 3 kernel.panic_on_oops 1 vm.swappiness 10 vm.min_free_kbytes 8192kernel.panic设置成3内核panic后3秒自动重启swappiness调低避免系统频繁把内存页换到eMMC上既伤性能又伤flash寿命。日志配置方面我把/var/log挂成tmpfs在/etc/fstab里加了一行tmpfs /var/log tmpfs nodev,nosuid,noexec,size64M 0 0这样系统重启后日志不会堆积但代价是历史日志会丢所以生产环境建议把journal同步到远程日志服务器或者把关键日志定期复制到数据分区。搭配logrotate的按天切割压缩基本能做到长时间运行不占盘。3.3 应用侧守护AI推理进程不掉线RK3588边缘设备上的AI推理进程我一般是用rknn-toolkit2或者RKNN的C API来加载yolov8模型然后循环处理视频帧。真正生产环境里单纯跑一次模型推理是没有问题的但一旦涉及到多路视频流、长时间拉流、偶发的NPU错误进程就可能卡住或者崩溃。守护AI进程不能只看“进程存在”这一项因为很多时候进程活着实际已经卡死。我在业务代码里加了一个心跳上报每次成功推理一帧就更新一次/tmp/guardian/health文件同时把当前的推理FPS写进去。Guardian的健康检查脚本会去读这个文件如果心跳超过12秒没有更新就判定AI进程陷入假死先发一个SIGTERM给进程给它几秒钟时间优雅退出再没有响应就直接kill -9并重启服务。AI进程自身也要做容错。用RKNN的Python API时模型初始化、rknn.run()都有可能抛出异常如果设备连续多次推理超时不能在一个死循环里反复重试这样既浪费CPU又可能让NPU越陷越深。我这里的策略是单次异常重试最多3次3次都失败就主动退出进程交给systemd的Restartalways拉起如果拉起后仍然在短时间内连续崩溃就停止喂狗让硬件看门狗复位整机。这比进程内部硬扛要可靠得多。另外强烈建议给AI进程设置内存限制用systemd的MemoryMax和TasksMax字段防止内存泄漏把整个系统拖垮。比如推理服务设置MemoryMax1G超过这个限制就会被系统kill然后自动重启。这样做牺牲了单个进程的续航能力但换来了整机的稳定。如果业务不能接受定期重启那就要好好排查内存泄漏的根源。3.4 现场救援Recovery/MASKROM模式的刷机路径即便Guardian做了这么多防护极端情况下系统还是可能彻底起不来比如固件写坏、rootfs损坏、掉电导致引导异常。这时候必须有现场救援手段。RK3588的烧录机制里最常用的是按住板子上的Recovery或MASKROM键用USB Type-C数据线连接电脑然后给板上电。电脑上的RKDevTool会识别到设备显示处于Loader模式或者Maskrom模式。在Maskrom模式下设备已经是“完全裸奔”状态连loader都没起来需要先烧录引导文件。这里会用到miniloader.bin它是RK3588烧录流程中最底层的引导程序先用它把基本的存储访问能力拉起来再烧写完整的update.img。如果只是Loader模式那直接选择分区烧录或者整体烧录update.img就行。具体参数不用背RKDevTool界面里都有。但我想说的是正常生产环境中不应该依赖频繁刷机解决故障。刷机是最后的急救手段是把设备救回来用的。更可取的方案是给系统做A/B分区系统A和系统B交替升级升级失败自动回滚到另一个分区这样即使固件出了问题也能开机不需要拆机刷板。对没有A/B分区条件的设备至少可以在SD卡里放一套救援系统系统引导失败时优先从SD卡启动再做修复。3.5 关于RKNN demo和模型路径的题外话很多刚接触RK3588的朋友都会去搜索“rk3588的模型demo在哪个文件夹”这一类问题。其实rknn-toolkit2安装包里自带examples里面会有yolov5、yolov8的转换和推理示例路径一般类似examples/onnx/yolov8/。但我想提醒的是demo里的模型路径写得很随意自己部署的时候最好把模型文件固定在数据分区程序启动时用绝对路径加载避免因为工作目录不同导致模型找不到。这个看似不是稳定性问题但在7×24开机自启的场景里路径错误会直接导致服务起不来非常影响现场体验。4. 常见死机现场与排查实录我被“假死”坑过的那些事4.1 最迷惑的现象屏幕黑屏但串口还在跑先说一个我踩过的大坑。设备启动之后串口明明还在打印日志系统也能ping通但接的HDMI显示器黑屏完全看不到画面。很多小伙伴第一反应就是设备死机了直接断电重启。实际上RK3588的日志里如果出现cant find suitable delayline多半不是死机而是HDMI输出在做时钟和延迟线校准时没有找到合适的配置导致显示驱动没能正常出图。这种问题一般和显示器EDID信息、HDMI线材质量、甚至分辨率设置都有关系。排查方法很简单连接串口看dmesg输出搜索hdmi和drm关键字。如果系统其他功能正常那就不是死机问题。解决办法包括换一根质量好一点的HDMI线或用ADB/SSH进去调整输出分辨率或者在设备树里固定一个显示器兼容性更好的时序。千万别一看到黑屏就重刷系统白费功夫。同样容易造成“假死”错觉的还有音频芯片和传感器。比如接了es8388音频codec或者BMI088陀螺仪这类I2C设备如果原理图上的I2C地址冲突或者复位时序不对系统启动时可能会卡在设备初始化阶段。这时候加长复位延时、检查设备树里的地址配置就能解决。现象是启动时看起来卡住了实际上只是外设初始化过程比较慢多等几秒也能起来。4.2 高温假死风扇不转和转速反馈丢失典型场景是设备放在弱电井或者机柜里散热条件差。运行几个小时后业务方反馈画面卡顿、远程登录响应很慢。我第一反应是看温度读取/sys/class/thermal/thermal_zone*/temp发现已经85度了。再查风扇发现PWM风扇的PWM信号是有的但根本没有转动。后来定位到原因是设备树里pwm-fan的pinctrl配置和实际硬件引脚不匹配。PWM控制线接到了另外一个空闲GPIO上系统以为在发控制信号实际上风扇那边什么都没收到。还有一种常见情况4线风扇的测速线没有接到RK3588的输入捕获引脚或者和PWM控制线接反了导致系统读取不到风扇转速温度控制策略直接失效。检查思路分三步第一步用万用表或示波器确认风扇供电正常第二步把PWM占空比手动调到最大确认风扇是否转第三步用示波器看测速线有没有脉冲输出。如果测速线有脉冲但系统读不到大概率是GPIO复用没配置对。这个问题在正点原子RK3588开发板上也很常见不同板子的接口定义可能不一样一定要对照电路原理图查。4.3 连续跑一周后“假死”NPU或内存泄漏另一种非常隐蔽的故障是设备连续运行几天后主进程还在日志还在打印但推理结果不再更新比如检测框停在上一帧的位置。这种情况在dmesg里往往能看到rknpu相关的报错或者内存监控显示某个进程的RSS持续增长直到把系统内存耗尽。内存泄漏在C和Python混合的AI应用里尤其常见。RKNN的Python API底层是C库有时初始化或退出的时候资源没有完全释放长时间运行就会累积。缓解手段是我前面说的给进程设置MemoryMax或者干脆每天定时优雅重启一次推理服务。对于某些版本驱动本身就有的NPU内存分配问题定期重启几乎是必须的。不要觉得重启“丢脸”7×24系统里“有计划地重启”比“意外死机”可靠太多。排查的时候我会在设备上挂一个后台监控记录每个进程的VmRSS和历史曲线。如果看到内存单调增长不回落那基本可以确定是泄漏。先用top找到进程再查看对应进程的/proc/PID/status。如果是推理服务第一怀疑对象就是每次推理循环里分配的numpy数组、rknn输出对象没有释放可以让代码在for循环内用del加gc.collect()做一次主动回收。4.4 断电后起不来根文件系统受损边缘设备被强行断电是家常便饭尤其是现场电源不稳定的时候。掉电最受伤的是rootfs。就算文件系统本身有日志频繁掉电也可能导致关键元数据损坏系统启动卡在挂载rootfs这一步。我在一台设备上遇到过ext4超级块损坏开机直接进了救援模式。Guardian针对这类问题的策略是根文件系统做成overlayfs只读系统运行时不会对底层rootfs产生大量写操作配合数据分区独立挂载大大降低断电损坏概率。如果设备已经出现rootfs无法挂载可以先进救援系统用fsck对根分区做修复绝大多数情况下能救回来。要是超级块损坏严重那就需要用备用超级块做恢复例如fsck.ext4 -b 32768 /dev/mmcblk0p2这种操作。避免这类问题的根本思路还是尽量不写、少写rootfs。临时文件全部放/tmp日志放tmpfs配置变更也不直接改系统分区而是放进数据分区启动时动态加载。这样rootfs就变成了出厂固件的一部分只读即可稳定性自然好很多。4.5 死机快速排查速查表症状可能原因检查命令处理方式整机无响应串口无输出电源电路异常或DDR不稳定串口日志是否停在早期启动阶段检查12V输入和核心供电使用硬件看门狗兜底启动黑屏但系统可登录HDMI delayline配置不匹配dmesg | grep -i hdmi更换线材/显示器调整设备树时序温度高、推理掉帧散热不足或PWM风扇失灵cat /sys/class/thermal/thermal_zone0/temp处理风扇接线调低温度阈值触发看门狗复位进程在但推理不更新NPU卡死或内存泄漏dmesg | grep rknpu; free -m重启AI进程限制进程内存必要时整机复位启动卡在挂载rootfs掉电导致文件系统损坏串口打印挂载失败信息进救援系统fsck或烧录恢复出厂固件日志写满根分区journald未限制或APP刷日志df -h /var/logjournald配置限额/var/log挂tmpfs4.6 还有一类“死机”是程序自己把自己搞死的最后补一个容易忽视的案例。有些AI程序里用了多线程处理视频流但线程之间同步没有用好比如共享队列无锁访问或者条件变量等待超时逻辑写得有误。表面上看是设备死机实际上是用户态程序出现死锁CPU占用率却很低机器看起来“卡住”了。排查这种问题直接看线程状态用top -H能发现多个线程处于uninterruptible sleep或者等待锁的状态再配合gdb导出线程栈就能定位。我的经验是在做7×24设备时能用单进程多线程尽量控制线程数量进程间通信建议走socketpair或消息队列而不是共享大块内存崩溃隔离性更好。AI推理这种对实时性有要求的核心路径尽量保持简单越复杂的同步机制越容易在极端负载下出问题。5. 最后分享几点做7×24设备的个人体会从设计Guardian到现在我在多台RK3588边缘AI设备上验证了这套方案最大的改变不是设备“再也没有死机”了而是我再也不用半夜爬起来跑现场了。稳定性从来不是靠某个单一技术点解决的而是在硬件选型、散热设计、看门狗设置、服务守护、日志管理、错误恢复这些环节里一点一点堆出来的。有一点我想特别强调做边缘AI设备不要把精力全部放在模型优化上。设备运行一个月真正决定你能不能睡好觉的往往是风扇卡没卡、电源稳不稳、日志会不会把盘写满这类“不起眼”的小事。模型精度低一两个点用户可以忍设备整天死机用户真的会暴走。所以我的习惯是每次拿到一块RK3588板子先把串口调试口、看门狗、温度监控、远程日志这几条“生命通道”打通再考虑跑业务模型。守护逻辑越早设计进系统后面翻车的概率就越小。希望这篇文章里记录的思路和踩过的坑能帮你少走一些弯路。 RK3588边缘AI设备7×24守护方案：从硬件看门狗到进程自愈
一块RK3588的板子刷完系统、点亮屏幕、跑通yolov8这不算什么本事真正难的是把它扔到机房里连续跑一个月不重启不计日志、不高温降频、不掉盘、不假死。我做边缘AI设备这么久最深的体会就是demo阶段什么板子都好用一旦进入7×24连续运行RK3588的电源、散热、存储、掉电保护、进程守护全部要重新设计一遍。这篇文章要讲的Guardian守护就是围绕RK3588边缘AI设备打造的一套“防死机体系”。不是简单的看门狗也不是加个散热风扇而是从硬件看门狗到系统服务监控、再到AI推理进程自愈的完整架构。适合正在做RK3588边缘盒子、智慧安防、工业视觉、视频监控硬编码和NPU推理一体机的朋友直接参考。1. 项目由来边缘AI设备的“能跑”和“不死机”是两码事1.1 先搞清楚RK3588承担的是什么样的边缘负载RK3588这颗芯片八核ARM加上6TOPS的NPU放在边缘AI设备里属于非常主流的方案。很多项目拿它做多路视频结构化、实时检测、智慧安防、工业质检进程的典型形态是从摄像头拉RTSP流走RK3588的VPU硬件解码把YUV帧做缩放后再丢给NPU跑模型检测结果写回业务系统同时还要做视频硬编码存储。这一套负载CPU八个核不一定全占满但NPU和VPU基本不会闲着。也正因为如此设备内部的发热、内存分配、文件读写和系统调度的压力是全方位的。我见过太多人拿着正点原子RK3588开发板或者自己画的边缘盒子跑通rknn-toolkit2导出的yolov8模型demo后就觉得大功告成demo跑几分钟出框就发朋友圈。结果真正部署到现场24小时不到就开始各种“抽风”有的温度飙到85度触发降频画面掉帧有的跑了两天日志文件撑爆根分区有的死机后没有任何重启机制现场运维根本进不去。7×24场景下这些问题的出现不是概率而是必然。RK3588是一块高性能芯片高性能意味着高功耗高功耗意味着高热量和更严苛的电源要求。边缘AI部署如果在设计阶段没有把长时间连续运行放进约束条件后面一定会被现场问题追着跑。所以做Guardian守护之前第一步是把“能跑”和“能长久跑”这两件事彻底区分开。1.2 死机不是“突然黑屏”那么简单要分场景在7×24运行环境里死机这个词其实很笼统。我把实际遇到的故障分成四类每一类的处理方式完全不同。第一类是硬件级死机电源纹波大、DDR不稳定、芯片过热导致整机完全没反应第二类是内核级死机内核panic串口最后一行打印卡住系统彻底失去调度能力第三类是用户态假死主进程还活着但NPU推理线程或者视频拉流线程卡死设备从外面看就像瘫痪了一样第四类是存储或系统损坏日志写满根分区、根文件系统变只读、启动流程卡在挂载阶段。这四类故障的可控性差别很大。用户态假死可以通过守护进程自愈存储问题可以通过分区设计和日志轮转规避但硬件级和内核级崩溃软件层面的处理就非常有限只能靠看门狗兜底。这也决定了Guardian不能只做一个“重启大法”必须是一套分层设计每一层解决特定范围内的问题层与层之间互为补充。我经常在排查现场看到的问题是设备表面上看是“死机”了拔电重启又好了所以大家都懒得深究。但实际上不找到死机的类型就盲目重启下一次故障大概率更快出现因为根本原因没有被消除。Guardian的初步设计目标就是要回答一个问题系统什么时候该自愈什么时候该重启什么时候必须拉到救援模式。1.3 Guardian守护不是什么高大上的框架而是工程预案很多朋友听到“守护”两个字以为我要写一个复杂的框架其实不是。Guardian真正做的事情是把RK3588边缘设备在长时间运行中遇到的常见故障全部预设好处理策略。它由几个非常朴素的东西组成硬件看门狗服务和/dev/watchdog节点一组systemd服务单元文件一个AI进程的健康检查脚本以及一套日志、内存、磁盘的“环卫机制”最后再加上异常掉电后的恢复和救援路径。整套方案的定位是“运维底盘”不替代业务代码业务进程该怎么写还是怎么写但有了Guardian以后业务进程崩了、卡了、内存泄漏了系统能够在几秒到几十秒内自动恢复而不是等着现场维护人员去拔电。这样设计的另外一个好处是Guardian自身足够轻状态全部放在内存临时目录不依赖数据库不依赖网络哪怕网络断了、存储出问题了Guardian依然能按照设定好的规则去执行守护动作。所以接下来要讲的重点不是某一个技巧而是把“7×24不死机”这个问题拆成硬件防护、系统加固、应用自愈和救援恢复四个环节来看。理解了这个整体思路后面每个人都能根据自己设备的实际情况去微调参数。2. 整体设计思路三层防线先自愈再重启2.1 第一层防线硬件看门狗最后兜底软件层面的守护再怎么做也改变不了一个事实一旦内核卡死或者电源出问题操作系统本身已经没有能力执行任何逻辑。这时候唯一的兜底就是硬件看门狗。RK3588平台要启用硬件看门狗内核需要开启CONFIG_WATCHDOG系统起来之后能看到/dev/watchdog节点。常见做法是跑一个systemd服务周期性地往这个节点写字符喂狗如果喂狗服务因为系统卡死而停止看门狗硬件就会在规定时间内触发复位。这里有一个非常关键的细节喂狗动作不能放在一个独立空转的进程里。很多初学者喜欢写一个专门的小脚本每隔几秒写一次/dev/watchdog但这样做的效果很差因为系统可能已经接近瘫痪业务全挂了这个专门喂狗的进程却还在跑看门狗永远认为系统是健康的。我在Guardian里的做法是把喂狗和业务心跳绑定AI进程每隔一段时间往/tmp/health写入时间戳喂狗服务同时检查业务心跳只有在业务心跳正常的情况下才喂狗一旦业务心跳超时立即停止喂狗硬件看门狗随后复位整机。看门狗的超时时间需要仔细调太短容易被系统瞬时繁忙误触发太长又起不到保护作用。我这边一般设置在15秒左右喂狗周期是5秒既留够余量又能快速响应。另外还要注意正常关机逻辑系统在优雅关机的过程中要先把看门狗关掉或者停止喂狗否则会出现关机过程中被看门狗强制重启的现象这在生产环境会引发很多脏数据问题。2.2 第二层防线systemd服务监控与自愈第二层防线解决的是用户态服务的崩溃和假死问题。RK3588上跑边缘AI业务进程一般会拆成几个service拉流服务、推理服务、结果上报服务、硬件编解码服务。每一个都建议用systemd unit来管理打开自动重启策略RestartalwaysRestartSec10。这样进程崩溃了systemd会拉起来不需要额外写脚本轮询进程是否存在。但这里有个坑Restartalways遇到一个启动必失败的进程它就会进入无限重启循环把CPU和日志全部打满。所以必须配上启动次数限制比如StartLimitIntervalSec300和StartLimitBurst5意思是5分钟内最多重启5次超出后systemd会放弃不再尝试拉起。这时候由上一层的“业务心跳检查”接管如果健康检查发现核心服务已经停止就主动触发看门狗复位整个设备而不是让一个不可能起来的服务无限空转。另一个容易被忽略的点是启动成功的判定。用Typesimple的服务systemd默认只要fork出进程就算启动成功了但实际上你的Python推理程序可能还在加载模型、初始化RKNN上下文这期间就算没准备好systemd也认为它活着。更好的方式是用Typenotify在业务代码里调用sd_notify发一个READY信号告诉systemd我已经初始化完成了。这样一旦初始化超时systemd会按规则重启服务不会在“半死”状态下傻等。2.3 第三层防线存储、内存与日志的“环卫机制”长期运行的设备很大一部分“死机”不是CPU或NPU挂了而是存储和内存被慢慢耗尽。最常见的问题是日志文件无节制膨胀systemd journal默认把日志写到/var/log/journal内存里挂一个logrotate也经常因为服务一直持有文件句柄导致轮转失败。我在Guardian里把日志目录直接挂成tmpfs重启即清空同时配置journald的SystemMaxUse和RuntimeMaxUse限制最大体积再加上logrotate压缩归档。这样即使日志疯狂刷也不会吃光根分区。内存方面RK3588的DDR虽然通常有4G到8G但NPU推理和视频编解码都要分配大量buffer一旦某个线程没有释放顶多两三天就会出现内存耗尽。我这边会在系统里配一个监控脚本周期性检查/proc/meminfo的可用内存低于阈值时先重启最占内存的业务服务而不是整机重启因为整机重启会导致录像断档和网络重连能局部恢复就局部恢复。文件系统还有个大问题是掉电保护。RK3588设备如果直接断电频繁的ext4元数据写入可能让rootfs受损。Guardian的思路是把日志、临时文件、模型缓存全部放到内存文件系统减少对flash的写入根文件系统在部署完成后可以切换成overlayfs只读层业务数据写到独立数据分区。这样常规运行几乎不对根分区产生写入断电后启动能稳定很多。2.4 为什么“先自愈再重启”是必须坚持的原则有朋友跟我说既然做7×24那最简单粗暴的办法就是在系统里配置一个每分钟检查一次的脚本发现响应超时就自动reboot这样不就行了吗听起来有道理实际执行起来问题很多。频繁重启会导致设备反复出现断网、录像丢失、模型重新加载等连锁反应尤其当业务侧有数据上报时长时间“业务中断”本身就是事故。所以Guardian的故障响应优先级是先尝试局部恢复比如重启某个服务、清理内存、降级某些非关键功能只有在这些手段全部失效或者系统级健康检查判定整机无响应时才走看门狗复位。这套“先自愈再重启”的原则用下来最直观的效果是设备的重启次数大幅减少。通过健康检查日志能看到很多原来会演变成整机死机的小问题在服务级别就被处理掉了。真正需要硬件看门狗出手的场景平均一个月也没几次。对边缘AI设备来说业务连续性比一次重启能解决多少个问题重要得多。3. 核心环节实操Guardian实战落地3.1 硬件基础散热设计与PWM风扇转速监控RK3588的散热问题是7×24稳定运行的第一道坎。这颗芯片满负载功耗不低如果外壳是密封的、没有风扇温度很容易冲到85度以上触发SoC降频。降频之后NPU算力掉得厉害yolov8的推理帧率直接下降表面看起来就是设备“卡死”了。所以散热不能靠运气必须主动管理。我的做法是铝合金外壳做被动散热配合一颗4线PWM风扇主动散热同时利用软件动态调速。RK3588的设备树里一般会配置pwm-fan节点把风扇绑定到thermal zone的cooling device上系统会自动根据温度调节占空比。比如温度超过60度就开一个高速档低于50度就切到低速档。这里需要确认硬件上PWM信号接的是RK3588的哪个PWM控制器否则风扇可能不转。再说读取风扇转速也就是热词里大家常搜的“rk3588 读取风扇转速”。一般4线风扇的测速线输出的是脉冲信号每转一圈输出一到几个脉冲常见的是每转两个脉冲。要把这个脉冲读上来可以在RK3588上用GPIO中断配合定时器计数或者直接用PWM capture功能去量脉冲频率。我先用示波器确认测速线输出的脉冲波形然后写了一个小驱动或者用内核的gpio-keys机制去统计。转速的换算公式很朴素转速RPM 每秒钟脉冲数 × 60 ÷ 每转脉冲数。我见过很多人把测速线和PWM控制线接反结果风扇转但永远读不到转速所以布线的时候一定要对照原理图正点原子RK3588开发板的各个接口丝印要看仔细。风扇转速不是只看有没有转就够了还要监控趋势。风扇用久了会积灰、轴承磨损转速会慢慢下降。我在Guardian里加了一个检查连续几次读到的风扇转速低于设定阈值或者温度持续走高但转速上不来就判定风扇异常直接触发硬件看门狗复位提醒现场人员处理。宁可让它重启也不能让它在超温状态下继续烧芯片。3.2 系统层加固看门狗与关键系统参数先开启内核看门狗。在RK3588的Linux系统里设备节点是/dev/watchdog我写了一个非常简单的systemd喂狗服务每5秒往节点写一次字符。服务单元大概是这样的[Unit] DescriptionGuardian Watchdog Feeder Aftermulti-user.target [Service] ExecStart/usr/local/bin/watchdog_feed.py Restartalways RestartSec5 WatchdogSec15 [Install] WantedBymulti-user.target对应的喂狗脚本可以在Python里写也可以直接用一个while循环加echo。但核心逻辑不是单纯喂狗而是同时检查业务心跳文件的时间戳#!/usr/bin/env python3 import os, time WATCHDOG_DEV /dev/watchdog HEALTH_FILE /tmp/guardian/health def check_health(): if not os.path.exists(HEALTH_FILE): return False mtime os.path.getmtime(HEALTH_FILE) if time.time() - mtime 12: return False return True with open(WATCHDOG_DEV, w) as wd: while True: try: if check_health(): wd.write(w) wd.flush() else: time.sleep(2) except Exception as e: time.sleep(1) time.sleep(5)注意这个脚本里有一个非常重要的细节如果业务心跳异常脚本不喂狗但也不退出只是干等。因为一旦打开过/dev/watchdog如果脚本退出有些看门狗驱动也会触发复位干脆让它空转到硬件超时。这样做比直接打开文件等更可控。系统参数方面在/etc/sysctl.d/99-guardian.conf里我配置了几项kernel.panic 3 kernel.panic_on_oops 1 vm.swappiness 10 vm.min_free_kbytes 8192kernel.panic设置成3内核panic后3秒自动重启swappiness调低避免系统频繁把内存页换到eMMC上既伤性能又伤flash寿命。日志配置方面我把/var/log挂成tmpfs在/etc/fstab里加了一行tmpfs /var/log tmpfs nodev,nosuid,noexec,size64M 0 0这样系统重启后日志不会堆积但代价是历史日志会丢所以生产环境建议把journal同步到远程日志服务器或者把关键日志定期复制到数据分区。搭配logrotate的按天切割压缩基本能做到长时间运行不占盘。3.3 应用侧守护AI推理进程不掉线RK3588边缘设备上的AI推理进程我一般是用rknn-toolkit2或者RKNN的C API来加载yolov8模型然后循环处理视频帧。真正生产环境里单纯跑一次模型推理是没有问题的但一旦涉及到多路视频流、长时间拉流、偶发的NPU错误进程就可能卡住或者崩溃。守护AI进程不能只看“进程存在”这一项因为很多时候进程活着实际已经卡死。我在业务代码里加了一个心跳上报每次成功推理一帧就更新一次/tmp/guardian/health文件同时把当前的推理FPS写进去。Guardian的健康检查脚本会去读这个文件如果心跳超过12秒没有更新就判定AI进程陷入假死先发一个SIGTERM给进程给它几秒钟时间优雅退出再没有响应就直接kill -9并重启服务。AI进程自身也要做容错。用RKNN的Python API时模型初始化、rknn.run()都有可能抛出异常如果设备连续多次推理超时不能在一个死循环里反复重试这样既浪费CPU又可能让NPU越陷越深。我这里的策略是单次异常重试最多3次3次都失败就主动退出进程交给systemd的Restartalways拉起如果拉起后仍然在短时间内连续崩溃就停止喂狗让硬件看门狗复位整机。这比进程内部硬扛要可靠得多。另外强烈建议给AI进程设置内存限制用systemd的MemoryMax和TasksMax字段防止内存泄漏把整个系统拖垮。比如推理服务设置MemoryMax1G超过这个限制就会被系统kill然后自动重启。这样做牺牲了单个进程的续航能力但换来了整机的稳定。如果业务不能接受定期重启那就要好好排查内存泄漏的根源。3.4 现场救援Recovery/MASKROM模式的刷机路径即便Guardian做了这么多防护极端情况下系统还是可能彻底起不来比如固件写坏、rootfs损坏、掉电导致引导异常。这时候必须有现场救援手段。RK3588的烧录机制里最常用的是按住板子上的Recovery或MASKROM键用USB Type-C数据线连接电脑然后给板上电。电脑上的RKDevTool会识别到设备显示处于Loader模式或者Maskrom模式。在Maskrom模式下设备已经是“完全裸奔”状态连loader都没起来需要先烧录引导文件。这里会用到miniloader.bin它是RK3588烧录流程中最底层的引导程序先用它把基本的存储访问能力拉起来再烧写完整的update.img。如果只是Loader模式那直接选择分区烧录或者整体烧录update.img就行。具体参数不用背RKDevTool界面里都有。但我想说的是正常生产环境中不应该依赖频繁刷机解决故障。刷机是最后的急救手段是把设备救回来用的。更可取的方案是给系统做A/B分区系统A和系统B交替升级升级失败自动回滚到另一个分区这样即使固件出了问题也能开机不需要拆机刷板。对没有A/B分区条件的设备至少可以在SD卡里放一套救援系统系统引导失败时优先从SD卡启动再做修复。3.5 关于RKNN demo和模型路径的题外话很多刚接触RK3588的朋友都会去搜索“rk3588的模型demo在哪个文件夹”这一类问题。其实rknn-toolkit2安装包里自带examples里面会有yolov5、yolov8的转换和推理示例路径一般类似examples/onnx/yolov8/。但我想提醒的是demo里的模型路径写得很随意自己部署的时候最好把模型文件固定在数据分区程序启动时用绝对路径加载避免因为工作目录不同导致模型找不到。这个看似不是稳定性问题但在7×24开机自启的场景里路径错误会直接导致服务起不来非常影响现场体验。4. 常见死机现场与排查实录我被“假死”坑过的那些事4.1 最迷惑的现象屏幕黑屏但串口还在跑先说一个我踩过的大坑。设备启动之后串口明明还在打印日志系统也能ping通但接的HDMI显示器黑屏完全看不到画面。很多小伙伴第一反应就是设备死机了直接断电重启。实际上RK3588的日志里如果出现cant find suitable delayline多半不是死机而是HDMI输出在做时钟和延迟线校准时没有找到合适的配置导致显示驱动没能正常出图。这种问题一般和显示器EDID信息、HDMI线材质量、甚至分辨率设置都有关系。排查方法很简单连接串口看dmesg输出搜索hdmi和drm关键字。如果系统其他功能正常那就不是死机问题。解决办法包括换一根质量好一点的HDMI线或用ADB/SSH进去调整输出分辨率或者在设备树里固定一个显示器兼容性更好的时序。千万别一看到黑屏就重刷系统白费功夫。同样容易造成“假死”错觉的还有音频芯片和传感器。比如接了es8388音频codec或者BMI088陀螺仪这类I2C设备如果原理图上的I2C地址冲突或者复位时序不对系统启动时可能会卡在设备初始化阶段。这时候加长复位延时、检查设备树里的地址配置就能解决。现象是启动时看起来卡住了实际上只是外设初始化过程比较慢多等几秒也能起来。4.2 高温假死风扇不转和转速反馈丢失典型场景是设备放在弱电井或者机柜里散热条件差。运行几个小时后业务方反馈画面卡顿、远程登录响应很慢。我第一反应是看温度读取/sys/class/thermal/thermal_zone*/temp发现已经85度了。再查风扇发现PWM风扇的PWM信号是有的但根本没有转动。后来定位到原因是设备树里pwm-fan的pinctrl配置和实际硬件引脚不匹配。PWM控制线接到了另外一个空闲GPIO上系统以为在发控制信号实际上风扇那边什么都没收到。还有一种常见情况4线风扇的测速线没有接到RK3588的输入捕获引脚或者和PWM控制线接反了导致系统读取不到风扇转速温度控制策略直接失效。检查思路分三步第一步用万用表或示波器确认风扇供电正常第二步把PWM占空比手动调到最大确认风扇是否转第三步用示波器看测速线有没有脉冲输出。如果测速线有脉冲但系统读不到大概率是GPIO复用没配置对。这个问题在正点原子RK3588开发板上也很常见不同板子的接口定义可能不一样一定要对照电路原理图查。4.3 连续跑一周后“假死”NPU或内存泄漏另一种非常隐蔽的故障是设备连续运行几天后主进程还在日志还在打印但推理结果不再更新比如检测框停在上一帧的位置。这种情况在dmesg里往往能看到rknpu相关的报错或者内存监控显示某个进程的RSS持续增长直到把系统内存耗尽。内存泄漏在C和Python混合的AI应用里尤其常见。RKNN的Python API底层是C库有时初始化或退出的时候资源没有完全释放长时间运行就会累积。缓解手段是我前面说的给进程设置MemoryMax或者干脆每天定时优雅重启一次推理服务。对于某些版本驱动本身就有的NPU内存分配问题定期重启几乎是必须的。不要觉得重启“丢脸”7×24系统里“有计划地重启”比“意外死机”可靠太多。排查的时候我会在设备上挂一个后台监控记录每个进程的VmRSS和历史曲线。如果看到内存单调增长不回落那基本可以确定是泄漏。先用top找到进程再查看对应进程的/proc/PID/status。如果是推理服务第一怀疑对象就是每次推理循环里分配的numpy数组、rknn输出对象没有释放可以让代码在for循环内用del加gc.collect()做一次主动回收。4.4 断电后起不来根文件系统受损边缘设备被强行断电是家常便饭尤其是现场电源不稳定的时候。掉电最受伤的是rootfs。就算文件系统本身有日志频繁掉电也可能导致关键元数据损坏系统启动卡在挂载rootfs这一步。我在一台设备上遇到过ext4超级块损坏开机直接进了救援模式。Guardian针对这类问题的策略是根文件系统做成overlayfs只读系统运行时不会对底层rootfs产生大量写操作配合数据分区独立挂载大大降低断电损坏概率。如果设备已经出现rootfs无法挂载可以先进救援系统用fsck对根分区做修复绝大多数情况下能救回来。要是超级块损坏严重那就需要用备用超级块做恢复例如fsck.ext4 -b 32768 /dev/mmcblk0p2这种操作。避免这类问题的根本思路还是尽量不写、少写rootfs。临时文件全部放/tmp日志放tmpfs配置变更也不直接改系统分区而是放进数据分区启动时动态加载。这样rootfs就变成了出厂固件的一部分只读即可稳定性自然好很多。4.5 死机快速排查速查表症状可能原因检查命令处理方式整机无响应串口无输出电源电路异常或DDR不稳定串口日志是否停在早期启动阶段检查12V输入和核心供电使用硬件看门狗兜底启动黑屏但系统可登录HDMI delayline配置不匹配dmesg | grep -i hdmi更换线材/显示器调整设备树时序温度高、推理掉帧散热不足或PWM风扇失灵cat /sys/class/thermal/thermal_zone0/temp处理风扇接线调低温度阈值触发看门狗复位进程在但推理不更新NPU卡死或内存泄漏dmesg | grep rknpu; free -m重启AI进程限制进程内存必要时整机复位启动卡在挂载rootfs掉电导致文件系统损坏串口打印挂载失败信息进救援系统fsck或烧录恢复出厂固件日志写满根分区journald未限制或APP刷日志df -h /var/logjournald配置限额/var/log挂tmpfs4.6 还有一类“死机”是程序自己把自己搞死的最后补一个容易忽视的案例。有些AI程序里用了多线程处理视频流但线程之间同步没有用好比如共享队列无锁访问或者条件变量等待超时逻辑写得有误。表面上看是设备死机实际上是用户态程序出现死锁CPU占用率却很低机器看起来“卡住”了。排查这种问题直接看线程状态用top -H能发现多个线程处于uninterruptible sleep或者等待锁的状态再配合gdb导出线程栈就能定位。我的经验是在做7×24设备时能用单进程多线程尽量控制线程数量进程间通信建议走socketpair或消息队列而不是共享大块内存崩溃隔离性更好。AI推理这种对实时性有要求的核心路径尽量保持简单越复杂的同步机制越容易在极端负载下出问题。5. 最后分享几点做7×24设备的个人体会从设计Guardian到现在我在多台RK3588边缘AI设备上验证了这套方案最大的改变不是设备“再也没有死机”了而是我再也不用半夜爬起来跑现场了。稳定性从来不是靠某个单一技术点解决的而是在硬件选型、散热设计、看门狗设置、服务守护、日志管理、错误恢复这些环节里一点一点堆出来的。有一点我想特别强调做边缘AI设备不要把精力全部放在模型优化上。设备运行一个月真正决定你能不能睡好觉的往往是风扇卡没卡、电源稳不稳、日志会不会把盘写满这类“不起眼”的小事。模型精度低一两个点用户可以忍设备整天死机用户真的会暴走。所以我的习惯是每次拿到一块RK3588板子先把串口调试口、看门狗、温度监控、远程日志这几条“生命通道”打通再考虑跑业务模型。守护逻辑越早设计进系统后面翻车的概率就越小。希望这篇文章里记录的思路和踩过的坑能帮你少走一些弯路。