3. 实时控制软件需求分析与规格定义

实时控制软件与普通嵌入式应用最大的区别在于：正确性不仅取决于计算结果，还取决于结果产生的时间。一个电机FOC控制算法即使数学上完全正确，如果控制周期抖动超过PWM载波周期的几个百分点，电流环就可能出现可听噪声、转矩脉动甚至失稳。因此，需求分析阶段必须把时间行为量化为可测量、可验收的指标，而不是停留在“响应要快”“运行要稳定”这类无法验证的描述上。

控制周期：从控制律到定时基准

控制周期是实时控制软件最基础的时序参数，它由被控对象的物理特性和控制算法共同决定。以三相PMSM电流环为例，若PWM载波频率为20kHz，采用中心对齐模式并在每个载波周期采样一次电流，则电流环控制周期为50μs。速度环通常慢一个数量级，可取1ms；位置环再慢，可取5～10ms。这种多速率结构要求需求文档明确写出每个环路的周期、触发源和相位关系。

控制周期的实现依赖硬件定时器。在Microchip dsPIC33系列中，常用PWM模块的周期匹配事件触发ADC采样，ADC转换完成中断触发控制算法。需求规格中应写明：定时器时钟源、预分频、周期寄存器值、触发链路。例如系统时钟120MHz，PWM时基分频后为120MHz，周期寄存器写6000，则载波周期为50μs。这个数值必须与需求中的控制周期一致，任何分频或倍频改动都要重新核算。

抖动、延迟与吞吐量

抖动（Jitter）指实际控制周期相对标称周期的偏差。它分为两类：周期抖动，即相邻两次执行间隔的变化；绝对抖动，即执行时刻相对理想时间栅格的变化。对电流环而言，采样时刻的抖动会直接引入电流测量误差，进而影响转矩。工程上常要求电流环抖动小于控制周期的5%，即50μs周期下不超过2.5μs。抖动来源包括中断响应延迟、高优先级中断抢占、DMA总线竞争和Flash取指等待。

延迟（Latency）指从物理量被采样到控制输出生效之间的总时间。它由采样保持、ADC转换、算法计算、PWM占空比更新四段构成。以50μs电流环为例，ADC转换约0.5μs，算法计算约8μs，PWM更新在下一个周期生效，总延迟约1.5个控制周期。延迟会降低相位裕度，需求中应给出上限，例如“电流环总延迟不超过1.5个控制周期”。

吞吐量（Throughput）在实时控制中通常指单位时间内完成的有效控制迭代次数或通信帧数。它不等于CPU主频，而受限于最慢环节。若控制算法每周期需完成Clarke/Park变换、两个PI调节、SVPWM计算，共约1200条指令，在120MHz下约10μs，则理论吞吐量可达100k次/秒，但受50μs周期约束，实际吞吐量为20k次/秒。需求文档应区分“周期约束下的吞吐量”和“CPU余量”，后者常用空闲时间占比表示，建议保留30%以上余量以应对功能扩展和中断抖动。

可靠性指标与验收标准

实时控制软件的可靠性指标应覆盖功能安全与运行连续性两个维度。常见指标包括：控制环路失稳次数为零、看门狗复位后恢复时间小于一个速度环周期、通信丢帧率低于10⁻⁶、过流保护响应时间小于5μs。这些指标必须可测。例如过流保护响应时间，可用示波器同时观察电流传感器输出和PWM关断信号，从电流超过阈值到PWM输出变为无效电平的时间即为响应时间。

验收标准应写成“条件—动作—可观测结果”的形式。例如：“在母线电压24V、负载转矩0.5N·m阶跃条件下，速度环超调不超过5%，调节时间不超过20ms，稳态误差不超过±1%额定转速。”这样的条目可以直接转化为测试用例，避免验收时产生歧义。

需求文档结构与可追溯性

一份可执行的需求文档至少包含：功能需求、时序需求、资源需求、安全需求、接口需求和验收准则。每条需求应有唯一编号，并标注来源、优先级和验证方法。建议采用如下字段组织：

可追溯性要求每条需求能向下追溯到设计模块和测试用例，向上追溯到系统级目标。例如RQ-T-001追溯到电流环控制任务和定时器配置，测试用例为“在额定工况下连续采集1000个周期，统计周期均值与标准差”。

从需求到验收的闭环

需求分析不是一次性文档工作，而是贯穿设计、实现和测试的基线。在Microchip实时控制项目中，建议把时序需求直接映射到定时器配置和中断优先级表，把可靠性需求映射到看门狗、故障捕获和冗余采样策略。验收阶段则用同一组指标反向验证：周期是否达标、抖动是否在限、延迟是否可接受、余量是否保留。只有需求、设计、测试三者使用同一套量化语言，实时控制软件的质量才可被客观判断。