垂直农场智能补光算法测试框架：从SIL到HIL的落地实践

最近接了一个垂直农场智能补光项目的测试任务，核心是验证一块自研的LED光照控制算法到底省不省电、控得准不准。说实话，这类项目跟普通嵌入式算法测试差别很大，因为它既要验证控制逻辑正确，又要量化节能收益，还要你懂一点植物生理和光学计量的常识。市面上几乎没有现成的测试框架可以直接拿过来用，只能自己搭。这篇文章把整套测试框架的思路、模块设计、数据构造、踩坑记录一次说透，给同样在搞农业物联网或智能硬件测试的朋友一个参考。

1. 项目背景与测试需求拆解

1.1 垂直农场的能耗结构与光照占比

先交代一下背景。垂直农场通常是在多层种植架上用人工光源替代自然光，植物在完全受控的环境里生长。整个系统的能耗大头有两块：温控（空调、除湿）和补光（LED灯具）。实际统计下来，在密闭式垂直农场里，LED补光能耗通常占到总能耗的60%甚至更多，个别高密度种植场景能到75%。

这意味着什么？光照控制算法稍微优化几个百分点，省下的电费就相当可观，而且直接影响终端的种植成本。这也是为什么这个项目要把“节能测试”单独拎出来做成一个框架，而不是随手写几个测试用例就完事。

1.2 光照控制算法到底在算些什么

这个项目的核心算法不是简单“到点开灯、到点关灯”，而是包含几个层次：

• 光配方调度：根据植物品种和生长阶段，输出特定的光谱组合。常见的是红蓝光配比可调，加上部分白光和远红光，不同阶段切换不同配方。
• 光周期管理：模拟日出日落，光照时长、暗期时长、渐变速度都受算法控制。
• 动态调光：根据传感器反馈的PPFD（光合有效光子通量密度，单位是μmol/m²/s）实时调整PWM或0-10V模拟信号，让光强稳定在目标区间。
• 节能策略：比如在电网峰时自动降光、在植物光饱和点以上主动限光、根据生长模型预测需求提前调整光照强度。

从测试角度拆解，算法本质上是一个“输入环境状态和环境变量 → 输出控制指令”的时序系统。测试的关键就是验证目标PPFD跟实际PPFD的误差、光积分量DLI（每日光照积分，单位mol/m²/d）是否达标、以及整个过程的功耗趋势是否符合预期。

1.3 测试需求的四个维度

我接这个项目后做的第一件事就是把测试需求拆开，跟研发对齐口径。最终拆成四个维度：

• 正确性：控制指令跟预期是否一致，光强误差是否在容差范围（比如目标PPFD±5%），光周期切换时机是否准确。
• 节能性：相同植物产量和光质量的前提下，算法相比传统定时开关方案省了多少电，这个必须量化。
• 稳定性：长时间运行内存是否泄漏、任务调度是否漂移、传感器故障时算法是否兜底。
• 实时性：从传感器数据变化到控制指令输出的延迟是否满足系统要求，通常要求在几百毫秒以内。

这四个维度不是并列的，正确性和稳定性是底线，节能性和实时性是优化目标。测试框架设计时，数据采集、场景仿真、指标计算都要围绕它们展开。

2. 测试框架的整体设计思路

2.1 分层解耦：数据采集层、算法注入层、执行引擎层、报告层

从一开始我就没打算写一个“大而全”的测试套件，而是把它拆成四层，让每一层都可以独立替换：

• 数据采集层：从真实环境（串口/Modbus/Ethernet）或仿真环境（mock数据源）读取环境变量，包括PPFD传感器值、温湿度、CO₂浓度、灯电流电压等。
• 算法注入层：被测对象以动态库或独立服务的形态注入。这个设计很关键，因为算法还在迭代，不能把算法代码和测试代码绑死。
• 执行引擎层：定义测试场景的参数、顺序、次数，控制循环运行，采集数据打上统一时间戳。
• 报告层：把原始数据转成节能指标、误差指标、稳定性指标，输出结构化报告。

分层的最大好处是可以并行开发。我做数据采集和场景构造的同时，算法团队在改调光策略，两边只要接口不变就能对齐。测试框架本身并不是为了自动化而自动化，而是让“每改一版算法，都能用同一套标准重跑一遍”，回归成本被压得很低。

2.2 先软件在环，再硬件在环

这是我在项目里最坚持的一个决定。很多测试工程师拿到这类任务，第一反应就是“直接接灯具去测”，但我强烈建议先搭一套软件在环（SIL）环境，再上硬件在环（HIL）。

软件在环的核心是建一个植物光环境模拟器：输入算法输出目标PPFD，结合灯具功率模型、空间衰减模型、环境光干扰模型，反推仿真PPFD值。算法再根据这个仿真值做闭环调整，整个过程不需要真实灯具。

第一版框架我先用SIL把算法逻辑跑通，抓到了不少明显的时序和边界Bug，比如日出渐变在午夜23:59发生跨天溢出、传感器偶发零值导致PID积分饱和等。这些问题如果直接上硬件测，定位要花十倍时间。SIL阶段跑稳之后，再接上真实灯具做HIL验证，验证点从“算法算得对不对”收敛到“硬件执行和反馈链路有没有偏差”。

2.3 节能指标的测量口径统一

节能测试最怕“口径不统一”。同样一个节电率，算法团队算出来的可能比测试团队高10%，不是谁造假，而是计算方式不同。

我们在框架里统一了几个核心指标：

• 单位光效：μmol/J，即消耗1焦耳电能产生多少微摩尔光合有效光子。这个指标可以直接对比不同灯具和不同算法下的光能转化效率。
• DLI达标率：一整天实际累积光量子数跟目标DLI的比例。节能的前提是DLI达标，否则节电没有意义。
• 节电率对比基准：统一采用“固定时间全功率开关”作为基准方案，算法方案跟它对比。这个基准必须固定，不然每次对比都在跟不同的参照系比。

另外还约定了一个小细节：功率数据必须跟PPFD数据同步采集，时间戳对齐到同一毫秒级，不允许分别采集再手工对齐。否则计算单位光效时，电流和光强对不上，结果就是一团乱麻。

3. 核心测试模块的实现细节

3.1 LED驱动与光照输出链路测试

这个模块测的是从控制指令到光输出的整个链路。具体来说：

• 算法输出目标占空比（PWM）或目标电压（0-10V），驱动板把它转成LED电流变化，最终影响PPFD输出。
• 这个链路里每一级都有非线性。PWM占空比跟电流基本线性，但电流跟PPFD在低电流区域会有非线性，灯具预热后光输出还会缓慢爬升。

我们的测试方法是：在恒温环境下，给驱动系统一组递增的占空比指令，同步采集电流、电压、PPFD。用回归方式建立“指令-PPFD”的映射曲线，放到框架里作为离线校准表。之后算法运行时，它输出的目标PPFD会先查校准表再转指令，避免“算法说对了、灯没做对”的错位问题。

这里有一个特别要提醒的点：LED灯具要充分预热到热平衡状态再测数据。冷态和热态的光输出差异可以达到5%-10%，如果测试时灯具刚点亮就记录数据，校准表直接废掉。我们一般预热30分钟以上才开始正式数据采集。

3.2 光合有效辐射与光积分算法验证

垂直农场控制算法的核心指标之一就是追着目标PPFD做闭环控制，然后累积出DLI。测试这个部分，需要专门验证光积分的计算准确度。

DLI的计算公式是：

DLI (mol/m²/d) = 平均PPFD (μmol/m²/s) × 光照时长 (s) / 1,000,000

但实际运行中PPFD是实时波动的，算法的积分模块每隔一段时间采样一次再累加。如果采样频率不够，或者积分窗口覆盖不完整，DLI算出来就跟实际对不上。

我设计的验证方法是：构造一条标准PPFD时序曲线（比如正弦波叠加白噪声），在框架里给定这条曲线的真实积分值，然后用算法模块去积分，对比两者误差。测试下来发现一个典型问题：当PPFD采样间隔超过30秒时，DLI累积误差就会超出±3%的容差线，说明算法需要提高采样频率，或者用更聪明的积分窗口算法（比如按变化率自适应采样）。

这个测试还顺带验证了光照均匀性问题。同一个种植层不同位置测PPFD，边缘和中心差异可能超过20%。如果控制算法只参考中心点传感器，边缘植物实际接收到的光量就远低于目标，DLI在空间分布上不达标。框架里我用一个多点模拟器接入多路PPFD输入，让算法能看到“空间分布”而不是“单点数据”。

3.3 节能策略验证：调度、渐变与边界

节能算法的三个主要测试方向是：光周期调度准确性、渐变控制平稳性、节能切换的边界处理。

光周期调度：验证一个完整生长周期里，每一天的开关灯时刻是否精确。这里最容易出的问题是时区处理和夏令时切换。系统跑在UTC时间，算法层换算到本地时间展示，如果换算逻辑写错，会有整整一小时的偏差。我直接构造了跨时区、跨闰年的场景来测。

渐变控制：模拟日出时不应该瞬间灯亮，而是缓慢爬升到目标PPFD。爬升速率有上限，太快会让植物应激，太慢会缩短有效光合时长。测试框架里有一个专门的“渐变斜率验证”用例，输入不同目标PPFD和环境光强，记录算法输出的渐变曲线，计算平均爬升速率，跟设计规格对比。

节能切换：节能策略里有一块是“削峰”逻辑，在特定用电高峰时段自动降光或者提前关灯。这个逻辑的正确性直接决定了节电率。我们设计了一个场景矩阵，把高峰开始时刻、当前DLI进度、剩余光照需求三个参数全排列组合，覆盖到“凌晨高峰”“午后高峰”“连续阴天后突然晴天”这些边界情况。

3.4 异常与故障注入

一直没有讲但很重要的部分：故障注入。垂直农场是无人值守环境，传感器漂移、断电重启、通信中断都是常态，算法必须能平稳处理。

我在框架里做了一个故障注入器，可以随时模拟：

• PPFD传感器归零：传感器故障时，算法如果看到PPFD变成0，会误判为“环境全黑”，然后把灯光拉到最高，这就危险了。正确逻辑应该是“连续N次读数为0才判定故障，且触发安全模式”。
• 传感器数据突变：真实世界传感器偶尔会有瞬时尖刺，比如500突然跳到200又跳回500。算法必须过滤掉这种毛刺，否则PID控制会反复震荡。
• 断电重启恢复：断电后算法要从本地持久化存储恢复光周期状态。如果状态没存或者存了损坏数据，恢复后的控制行为会完全错乱。我们用故障注入器在运行中途随机断电，验证重启后DLI是否断点续算。

故障注入测试还有一个好处：它帮我们验证了算法的“安全姿态”。无人工干预时，算法在故障状态下的第一优先级不是节能，而是“不伤害设备和植物”。这几个小时的测试比单纯跑步数更有价值。

4. 测试数据构造与场景设计

4.1 生长周期数据与光配方映射表

光配方的本质是一个映射关系：输入“植物品种 + 生长天龄 + 当前环境状态”，输出“目标光谱组合 + 目标PPFD + 光周期参数”。测试数据构造时需要覆盖整个生长周期。

我从真实种植方案里整理了三个阶段的典型数据：

• 幼苗期：PPFD目标较低，约150 μmol/m²/s，光周期16小时，红蓝比偏蓝，促进叶片形态建成。
• 营养生长期：PPFD目标升高到250-300 μmol/m²/s，光周期18小时，红蓝比均衡。
• 开花/成熟期：PPFD目标最高，可达400-450 μmol/m²/s，红蓝比偏红，适当加入远红光。

测试数据不只要覆盖三个阶段的标称值，还要覆盖相邻阶段的过渡区间。比如第7天到第8天之间的切换，如果映射表是离散的，切换点前后算法输出会有阶跃。有的算法做了平滑过渡，有的没有，这直接影响植物受光的连续性。测试框架专门生成跨阶段连续天龄输入序列，检查输出曲线是否平滑。

4.2 光照时序数据构造

时序数据是测试框架的饲料，构造质量直接决定测试有效性。我们造了三类：

• 干净数据：标准正弦波或梯形波，叠加极少量高斯噪声。用于验证算法在理想条件下的基线性能。
• 抖动数据：加上5%-15%的随机抖动，模拟真实传感器波动。用于验证PID参数是否合适，观察是否存在超调或震荡。
• 漂移数据：整体趋势缓慢偏移，比如传感器校准系数逐渐劣化，PPFD读数慢慢偏低。用于验证算法能否长期跟踪目标，而不是被漂移数据带跑。

我在这里用了一个技巧：这些时序数据不是一次性生成的，而是存成标准场景文件，每次测试回归都回放同一份数据。这样不同版本算法之间的对比才有意义。如果每次重新生成随机数据，指标差距到底来自算法更新还是数据随机波动，根本说不清。

4.3 边界场景与极端工况

前面提到过的边界场景我统一归到一个大类里：

• 午夜跳变：跨天临界点，光周期状态和DLI积分值重置是否正常。
• 长时间阴天：灯光全开还不够达到目标PPFD，算法如何决策。
• 短暂全功率：瞬时功率峰值是否超过供电上限。
• 传感器漂移到极限：PPFD读数为目标的2倍，算法是否错误关灯导致DLI不足。
• 多路传感器冲突：同一层的两路传感器一个读数高一个读数低，控制算法取平均还是取最大值，决定了光均匀性的最终效果。

这个我特别想强调：边界场景不是为了凑测试覆盖率，而是为了把算法里的“决策假设”逼出来。每个算法都有隐含假设，比如“传感器读数可信”“供电能力充足”“环境无明显突变”，边界测试就是逐一打破这些假设，看算法如何接招。

5. 常见问题与排查技巧实录

5.1 问题速查表

把项目过程中踩过的问题整理成一张速查表，应该能帮你节省几个星期的时间：

5.2 三个典型坑详解

第一个坑是时间基准不一致。控制系统用了毫秒级绝对时间戳，但光周期模块里用的是相对时间，比如“日出后2小时”，相对时间的起点取决于每日初始化时机。如果初始化时机因为调度延迟漂移了几分钟，光配方切换点也跟着漂移，DLI就会出偏差。测试框架里我加入了一个“时间对齐检查”，用伪随机延迟强制调度器任务抖动，专门抓这种问题。

第二个坑是冷态灯具数据导致校准表失效。前面提到过LED要预热，但还有一个隐藏问题：不同调光水平下热平衡时间不一样。低占空比下灯具温升小，几分钟就稳定；高占空比下要30分钟以上。如果校准表建立过程里混合了不同热状态的采样数据，校准曲线的中段就会扭曲。后来我把校准流程改成“从低到高逐点调升，每点稳定15分钟再记录”，曲线才真正干净。

第三个坑是对比基准漂移。第一次测节能率时用的基准是“全功率开16小时”，第二次用同一个基准，但室外温度变了，LED驱动器的散热差异导致光效变了，节电率数据跟着变。后来把基准测试也纳入框架，每次算法测试前后都跑一次基准，用最近一次基准做对照，数据才稳定。

5.3 节能指标对比的公平性

最后聊一个容易被忽视但极其重要的点：做节能对比一定要控制变量，否则报告就是废纸。植物生长测试里，相同光照算法在不同环境下的节电结果差异巨大，因为温度和CO₂浓度直接影响植物的光饱和点。

我建议测试报告里必须记录三组数据作为背景信息：

• 环境温度范围和平均温度（温控设备功耗的影响)
• CO₂浓度范围（直接影响植物光合效率阈值)
• 灯具累计运行时长（LED光衰会改变实际PPFD输出）

有了这些背景信息，即使两次测试的节能率有差异，也能判断是算法本身的原因还是环境差异的原因。这个意识在农业智能设备测试里特别重要，因为环境变量太多，不是你控制了一个变量就能说明因果的。我个人不主张用“节能率提高百分之多少”这种单一结论收尾，更合理的做法是给出“在什么环境条件下、相对什么基准算法、达到多少目标DLI的前提下，节电率为多少”。条件写清楚，结论才站得住。

回到框架本身，我个人觉得最有价值的不是某个花哨的自动化脚本，而是把“指标口径、场景基准、数据对齐”这三件琐碎的事情提前定死。测试框架能帮你快速跑回归、覆盖边界、量化节能效果，但真正决定框架质量的，是对被测对象的理解深度和对测量严谨性的坚持。这套框架目前还在扩展中，下一步的计划是把植物生长模型嵌进仿真器，让SIL阶段的模拟反馈更贴近真实生理响应，这样节能测试的置信度还能再上一个台阶。