dispatch.c

源文件路径：logic/dispatch.c 所属模块：logic（能量调度核心 —— 云端 EverGen 系统调度 / FCAS-FFR 调频调度 / 老化测试） 代码行数：1615

1. 文件职责

本文件是 EMS 的「调度」执行中枢，把网络层下发的两类指令翻译成对 g_t_logic_info.t_logic_control_parameter 的功率限值写入：一类是云端 EverGen 系统调度（按 u8ControlMode 分派到 14 个 handle_* 执行体，覆盖光伏优先充电、负载跟随、最大输出、最大消纳、经济模式、电池禁充、西澳 AC/DC 调度、SunSpec 有功调度、老化测试等），另一类是本地调频调度（FCAS/FFR 共 14 种模式，实现阶跃与下垂两种频率响应算法并直接驱动充放电）。它同时负责两类指令的超时退出：超时后清空调度状态、恢复 MPPT 到 100%，让控制权回到 logic.c 的自发自用逻辑。驱动方是 logic 任务：logic.c:2928-2929 每周期调用 frequency_regulation_detection()（调频检测）与 dectect_api_dispatch_comm()（云端通信检测）；logic.c:2314/2318 在 u8_sequencecontrol_mode 为 DISPATCH_FREQ_MODE/DISPATCH_MODE 时分别调用 excute_frequency_regulation_command() 与 excute_system_dispatch_command() 真正落功率。文件还维护老化测试的 6 态循环状态机与上报影子副本，供 net/ems.c 与 net/server.c 读写。

2. 关键数据结构与宏

本文件不定义新类型，全部来自 logic/dispatch.h 与 logic/logic.h。

3. 函数清单

本文件共 40 个函数定义，其中 static 1 个，其余 39 个为全局作用域。logic/dispatch.h 只登记了其中 24 个。

4. 核心逻辑解析

4.1 指令入口与「一个字段、两套语义」的解析

set_dispatch_parameter()（:98）是唯一写入口（由 net/server.c:835 调用）：

if (set_freq_dispatch_parameter(dispatch_cmd) == FALSE) {   /* 不是调频指令 */
    u32CmdGetTick    = OSTimeGet();
    u8Dispatch       = u8_enable;
    u16ActivePower   = f_para[0];
    u16ReactivePower = f_para[1];
    u8ForceSOC       = f_para[2];
    u8ControlMode    = f_para[3];
    u8_pv_on_off     = f_para[7];
    u32_runtime      = u32_runtime;
}

set_freq_dispatch_parameter()（:44）先取 l_s32_mode = f_para[3] 做模式判别，命中 14 种 FCAS/FFR 模式之一才返回 TRUE。因此 f_para[3] 在调频指令里是"调频模式号"，在系统调度指令里是 u8ControlMode——同一个槽位承担两种含义，靠"是否属于调频枚举集合"来区分。这是本文件最容易误改的地方。

调频参数的拆分规则（:66-79）分两类：

两个分支都会写 u8_dispatch_mode、u8_dispatch_enable、u32_dispatch_tick = OSTimeGet()、u32_dispatch_run_time = u32_runtime，返回 TRUE。未命中的模式返回 FALSE（:88），由调用方回落到系统调度分支。

4.2 调频检测状态机：frequency_regulation_detection()（:235）

函数内 5 个 static 状态量：s_u8_fcas_step_mode（阶跃锁存）、s_u32_freq_dispatch_tick（FFR 延时基准）、s_u8_inv_reduce_power_off（降载开关影子）、s_u16_charge_power/s_u16_discharge_power（上次满充放功率，用于检测变化并复位锁存）。执行顺序如下。

步骤 1 — 指令超时退出（:245-256）

if (mode != 0 || enable == TRUE) {
    if ((OSTimeGet() - u32_dispatch_tick) > (u32_dispatch_run_time * 1000))
        memset(&t_freq_dispatch_rundata, 0, sizeof(FREQ_DISPATCH_T));
    else if (u32_dispatch_tick > OSTimeGet())  u32_dispatch_tick = OSTimeGet();
}

u32_dispatch_run_time 单位为秒，OSTimeGet() 单位为毫秒（OS_TICKS_PER_SEC = 1000）。

步骤 2 — 锁存复位与优先级豁免（:258-276）

• 若当前模式不属于三个阶跃模式，s_u8_fcas_step_mode = NORMAL_FREQ_E（:258-263）。
• 若满足以下任一条件，调频被无条件让位：u8_sequencecontrol_mode ∈ {CMD_FORCE_CHARGE_MODE, SYS_FORCE_CHARGE_MODE, BAT_FORCE_CHARGE_MODE, USER_FORCE_CHARGE_MODE, DISPATCH_BAT_MODE}，或 u8_grid_status == FALSE（离网），或 t_config_data.Generator == TRUE（油机运行）。此时 flag = FALSE、s32_ac_dispatch_power = 0、锁存复位（:265-276）。

步骤 3 — 三种响应算法（:277-496）

(a) 阶跃模式（:281-372） 先把单死区/单饱和带展开成"四点"模型，并用逆变器额定输入/输出功率作为满充/满放功率：

u16_ldb = u16_hdb = u16_db;            // 死区
u16_lsb = u16_hsb = u16_sb;            // 饱和带
u16_charge_power    = s32_inv_rated_input_power;
u16_discharge_power = s32_inv_rated_output_power;

若充/放功率发生变化则复位锁存（:291-297）。频率异常保护：freq <= 4500 || freq >= 5500（45 Hz / 55 Hz）时输出 0 并复位锁存（:299-305）。正常区间的锁存迁移：

这是典型的带回差的施密特阶跃：进入动作按饱和带 sb，退出动作按死区 db，两者独立可调；由于阶跃模式 db≠sb 才产生回差。OVER_FREQ_E/UNDER_FREQ_E 的"其余分支只置 l_u8_freq_dispatch_flag_temp = TRUE 而不重写功率"体现了阶跃响应的锁存保持语义（l_u8_freq_dispatch_flag_temp 是本函数唯一输出，:504 再写回全局）。

(b) 下垂模式（:374-413） 线性插值公式，freq 与 5000（50.00 Hz）的偏差在 [db, sb] 区间内按比例出力：

频偏低于下限：
  freq <= 5000 - lsb          → +u16_discharge_power                       (满放)
  5000-lsb > freq > 5000-ldb  → +u16_discharge_power * ((5000-ldb) - freq) / (lsb - ldb)
频偏高于上限：
  freq >= 5000 + hsb          → -u16_charge_power                          (满充)
  5000+hsb > freq > 5000+hdb  → +u16_charge_power * ((5000+hdb) - freq) / (lsb - ldb)
死区内                        → 0（自发自用）

注意高频侧的斜率分母写的是 (u16_lsb - u16_ldb)——低侧的带宽，而不是 (u16_hsb - u16_hdb)。见备注 2。

(c) FFR 模式（:415-489） 这段代码用 C 的 case 穿透（fall-through） 给 l_u32_freq_dispatch_delay 赋不同延时：

case FFR_PRIMARY_MODE:     if (delay == 0) delay = 20*1000;                 /* 落到下一 case */
case FFR_SECONDARY_MODE:   if (delay == 0) delay = 30*60*1000;              /* 落到下一 case */
case FFR_HIGE_MODE:        if (delay == 0) { delay = 1000; s_u32_freq_dispatch_tick = OSTimeGet(); }
case FFR_STEP_TEST1_MODE:  ... /* 8 个测试/实机模式 */
case FFR_Live_Test_MODE:   if (delay == 0) { delay = 1000; s_u32_freq_dispatch_tick = OSTimeGet(); }

因为 delay 是每次调用都重新初始化为 0 的普通局部变量（:239），穿透链的净效果是：FFR_PRIMARY_MODE → 20 s；FFR_SECONDARY_MODE → 30 min；FFR_HIGE_MODE 与 8 个测试模式 → 1 s。代价是只有 FFR_HIGE_MODE 与测试模式那一支会给 s_u32_freq_dispatch_tick 打时间戳（见备注 3）。

动作逻辑与下垂模式相同（线性插值，同样用 (u16_lsb - u16_ldb) 作高频分母），区别在死区内不清零而是保持输出，靠 (OSTimeGet() - s_u32_freq_dispatch_tick) > l_u32_freq_dispatch_delay 延时归零（:476-488）：

else {
    l_u8_freq_dispatch_flag_temp = TRUE;   // 进入 Waiting，电池不充不放，等待下次频率触发
    if ((OSTimeGet() - s_u32_freq_dispatch_tick) > l_u32_freq_dispatch_delay)
        s32_ac_dispatch_power = 0;
    else if (s_u32_freq_dispatch_tick > OSTimeGet())
        s_u32_freq_dispatch_tick = OSTimeGet();
}

(d) default（:491-494） 不支持的调频模式直接 memset 整张调频表，立即退出调度。

步骤 4 — 动作标志变化时恢复 MPPT（:504-512）

if (l_u8_freq_dispatch_flag_temp != u8_freq_dispatch_flag) {
    u8_freq_dispatch_flag = l_u8_freq_dispatch_flag_temp;
    if (u8_freq_dispatch_flag == FALSE) {
        s_u8_pv_off_flag = FALSE;              // 退出调频恢复 MPPT 追踪
        g_t_logic_info.u16_mppt_percentage = 10000;
    }
}

步骤 5 — 调频使能时关闭电压/频率降载（:514-520）

s_u8_inv_reduce_power_off 实际存的是 u8_dispatch_enable 的影子，变化时调用：

inverter_set_p_v_mode_down_load_flag(u8_dispatch_enable == FALSE);
inverter_set_p_f_mode_down_load_flag(u8_dispatch_enable == FALSE);

即调频使能期间关闭逆变器自身的 P-V / P-F 降载，避免与 EMS 调度叠加（:516 注释"开启频率调度关闭电压降载、频率降载"）。

4.3 调频指令执行：excute_frequency_regulation_command()（:529）

由 logic.c:2314 在 DISPATCH_FREQ_MODE 下调用。以 s32_ac_dispatch_power 的符号二分：

收尾统一按 s_u8_pv_off_flag 设置 g_t_logic_info.u16_mppt_percentage = 0 / 10000（:556-563）。注意充电分支只压不抬充电限值（若原限值更小则保持更小），放电分支则完全由 s32_max_feedin_power 承担限流。

4.4 频率读取与单位换算（:598、:620）

get_dispatch_running_freq():                                  // 单位 0.01 Hz
    debug_enable      → u16_debug_freq
    ct_read_frequent(GRID_CT) > 4400 → ct_read_frequent(GRID_CT)
    否则              → parallel_read_system_inv_grid_freq()
get_fast_dispatch_running_freq():                             // 单位 0.001 Hz
    debug_enable      → u16_debug_freq * 10
    ct_read_frequent(FAST_GRID_CT) > 44000 → ct_read_frequent(FAST_GRID_CT)
    否则              → parallel_read_system_inv_grid_freq() * 10

阈值 4400（44 Hz）与 44000（44 Hz）用来判定 CT 读数是否有效——低于 44 Hz 视为 CT 无输出，回落到并机模块汇总的逆变器电网频率。两个函数的调试注入路径都带 t_fm_debug.u8_debug_enable 使能。

4.5 云端调度超时与老化结果：dectect_api_dispatch_comm()（:748）

由 logic.c:2929 每周期调用。三段逻辑：

(a) 超时退出（:753-787） 仅对白名单内的 u8ControlMode（BAT_CHARGE_FROM_PV、CHARGE_CONTROL、LOAD_FOLLOWING、MAX_OUTPUT、NORMAL_MODE、OPTIMISE_CONSUME、MAX_CONSUME、ECO_MODE、BAT_NO_CHARGE、AGING_MODE、SFFR_MODE、CHARGE_CONTROL_2、SUNSPECT_ACTIVE_MODE）生效。条件 (OSTimeGet() - u32CmdGetTick) > (u32_runtime * 1000)：

• 若正在老化，先置 u8_aging_result = AGING_COMPLETE、u8_aging_status = AGING_EXIT；
• 然后把 u16ActivePower/u16ReactivePower 复位为 POSITIVE_VALUE_OFFSET（= 0 W）、u8ForceSOC = 0、u8Dispatch = EVERGEN_FUNC_STOP、u8ControlMode = 0、u8AgingMode = AGING_START、u8_pv_on_off = 0。

(b) u8Dispatch == EVERGEN_FUNC_STOP 的二次复位（:795-821） 再清一遍字段并把 u32_runtime 硬编码为 90 秒；若老化未完成则置 AGING_FAILURE/AGING_END；若调频未在动作则恢复 MPPT（s_u8_pv_off_flag = FALSE、u16_mppt_percentage = 10000）。

(c) 老化结果判定（:823-862）

if (u8ControlMode == AGING_MODE) {
    if (ems_read_fault_code() || bms_read_fault_code() || inverter_read_fault_code() ||
        inverter_read_fault_code_extend() || inverter_read_fault_code_extend2())
        u8_aging_result = AGING_ERROR;                        // 任一故障 → 错误
    else if (s_t_agingmode_data_temp.u8_aging_status != u8AgingMode &&   // 老化步进已推进
             u8AgingMode != AGING_END &&
             u8_aging_result != AGING_FAILURE && u8_aging_result != AGING_COMPLETE)
    {
        u8_aging_result = AGING_SUCCEED;                      // 当前步成功
        if (u8AgingMode != AGING_START) u8_aging_status = u8AgingMode;
    }
    else  u8_aging_result = AGING_ONGOING;
    if ((OSTimeGet() - s_u32_send_data_tick) >= 60 * 1000)     // 每 60 s 翻转一次
        u8_flip_status = (u8_flip_status == FALSE);
}
else  s_u32_send_data_tick = OSTimeGet();

u8_aging_status 相当于"已确认完成的步"，与指令下发的 u8AgingMode 比较即得"步进已推进"。每 60 秒翻转 u8_flip_status，是给上位机做存活/心跳判据用的。

4.6 老化 6 态循环：handle_aging_mode()（:877）

SOC 门限来自功率字段（:879-891）：l_u16_max_chargr_soc = u16ActivePower * 10、l_u16_max_dischargr_soc = u16ReactivePower * 10，为 0 时取默认 800 / 500（即 80% / 50%）。

因此老化循环是 PV_TO_BAT → BAT_TO_GRID → GRID_TO_BAT → BAT_TO_GRID_2 → PV_TO_BAT 的 SOC 往复（PV 充电 / 上网放电 / 电网充电 / 上网放电），直到云端撤销指令。AGING_EXIT 只被 dectect_api_dispatch_comm() 写给 u8_aging_status，不参与这里的状态判断。

4.7 系统调度总分派：excute_system_dispatch_command()（:1392）

logic.c:2318 在 DISPATCH_MODE 下调用。switch (u8ControlMode) 的映射关系（:1410-1467）：

之后有两次收尾覆盖：

if (u8_pv_on_off == 1)      s_u8_pv_off_flag = FALSE;   // 云端强制开 PV
else if (u8_pv_on_off == 2) s_u8_pv_off_flag = TRUE;    // 云端强制关 PV

if (frequency_regulation_flag() == FALSE)               // 调频未动作时 MPPT 由本文件决定
    u16_mppt_percentage = s_u8_pv_off_flag ? 0 : 10000;

MPPT 的赋值刻意加了 frequency_regulation_flag() == FALSE 门控（:1478），避免覆盖调频分支的 MPPT 决策——这是两个子系统之间唯一的显式互斥点。

4.8 各模式执行体的功率限值算法

所有执行体只写三个字段，且限值只压不抬：

• s32_bat_charge_power_limit / s32_bat_dischg_power_limit：写入时一律先比较再取小（if (limit > X) limit = X;），因此上层的更小限值不会被放大。
• s32_pgrid_metert（电网侧电表偏置）、s32_max_feedin_power（馈网上限）、s32_pinvt（逆变器侧偏置）。

4.9 馈网优先级：dispatch_api_maxfeedin_priority()（:210）

s32_max_feedin_power = (get_maxfeedin_priority_flag() == TRUE) ? s32_max_feedin_power
                                                              : s32_inv_rated_output_power;
if (clear_grid_params && get_maxfeedin_priority_flag() != TRUE) {
    s32_pgrid_metert = s32_pgrid_metera = s32_pgrid_meterb = s32_pgrid_meterc = 0;
    s32_pinvt = 0;
}

即：若外部（CSIP/DNSP 等）声明了馈网优先级，则保留既有 s32_max_feedin_power；否则把它放宽到逆变器额定输出功率，并可顺带清空电网侧参数。

4.10 上报表与影子副本

aging_mode_send_data_flag()（:1582）用 memcmp 比较 g_t_dispatch_t.t_agingmode_info 与 s_t_agingmode_data_temp；aging_mode_data_sync()（:1593）在收到云端 CMD_SEND_BURNIN_DATA 确认（net/server.c:7021）后把前者拷入后者。这样 net/ems.c:5092 每 10 秒检查一次 aging_mode_send_data_flag() == TRUE 才发数据，避免重复上报。注意 memcmp 会包含 u8_flip_status 这个每 60 秒必然翻转的位，所以只要老化在跑，aging_mode_send_data_flag() 每 60 秒必然为 TRUE。

get_dispatch_set_power()（:1544）把零偏置去掉后返回；西澳模式（CHARGE_CONTROL_2）只回有效值，否则返回 65535 表示无效。

4.11 定时与 uCOS-II 配合

4.12 g_t_dispatch_t 的读写全景

t_fm_debug 只被测试代码写（外部写入 t_freq_dispatch_rundata.t_fm_debug），本文件只读。

4.13 通信协议帧格式

本文件不直接实现帧收发，但它是 net/server.c 下行 JSON 的消费者，隐含如下协议约定：

• 参数来自下行报文的 Parameter2 字段，用 parse_dispatch_para() 解析成 8 / 7 / 4 个十进制数字填入 DISPATCH_CMD_T.f_para[8]（net/server.c:805/809/813）。
• Parameter3 字段解析为 u32_runtime，且被夹到最小 90 秒（net/server.c:821-824）。
• f_para[3] 是模式选择位（调频模式号或 u8ControlMode）。
• 上报侧没有重传机制：数据攒够（调频 10 个点、系统调度 1000 ms / 间隔个点）后置 g_u8_send_dispatch_data_flag 由网络任务发送（net/ems.c:6349-6545）。

5. 对外接口

导出（供外部使用）：

被调用（本文件引用的外部符号）：

6. 依赖关系

依赖（dispatch.c:13-23）：dispatch.h、inverter.h、bms.h、ct.h、data.h、modbus.h、logic.h、server.h、ac_control.h、sunspec_business.h、meter.h。

被依赖：

• 头文件 dispatch.h 被 logic/logic.c、logic/csip_aus.c、net/ems.c、net/server.c（及 server.h）、midware/interface/modbus（及 modbus.h）、midware/interface/dry_node/dry_node.c、midware/inverter/parallel.c、data/resume_data/flash/flash_data_store.c 引入。
• 函数层面的直接调用方集中在 logic/logic.c、net/ems.c、net/server.c、midware/inverter/parallel.c、midware/bms/bms.c、midware/interface/modbus/*、midware/interface/modbus/sunspec_business.c。

7. 备注与风险点

1. handle_charge_control 与 handle_parallel_charge_control 的映射与命名相反：:1416-1422 里 case CHARGE_CONTROL: 调 handle_parallel_charge_control()，case SFFR_MODE: 调 handle_charge_control()。两个函数名都带 charge_control，但一个按并机偏置充放、一个按目标 SOC 三段充放，极易在维护时改错分支。建议改名或在 switch 处加注释。
2. 下垂/FFR 高频侧的斜率分母用了低侧带宽：:404-405 与 :472-473 的公式 u16_charge_power * ((5000+hdb) - freq) / (u16_lsb - u16_ldb) 分母是低侧的 (lsb - ldb)，而低侧公式 :392-393、:458-459 用的也是 (lsb - ldb)。若高侧带宽 (hsb - hdb) 与低侧不等（CSIP/FCAS 规范允许不对称），高侧的出力斜率会算错。从代码结构看这更可能是复制粘贴漏改。注意：set_freq_dispatch_parameter() 里下垂/FFR 参数是按 ldb=f_para[1]、hdb=f_para[2]、lsb=f_para[4]、hsb=f_para[5] 拆的，低侧带宽 = lsb-ldb、高侧带宽 = hsb-hdb，两者可独立配置，因此这个分母确实是个 bug 而非巧合。
3. FFR 的 fall-through 延时链导致 s_u32_freq_dispatch_tick 未打戳：:415-440 依赖 case 穿透给 l_u32_freq_dispatch_delay 赋值。由于该变量每次调用都重置为 0，穿透链的 if (delay == 0) 只有第一次命中才执行，所以对 FFR_PRIMARY_MODE 与 FFR_SECONDARY_MODE，s_u32_freq_dispatch_tick 不会被打时间戳（只有 FFR_HIGE_MODE 与 8 个测试模式那一支会）。结果是这两个模式在死区内的"延时退出"分支（:480）用的是一个可能为 0 或过期很久的时间戳，(OSTimeGet() - tick) > delay 立刻成立，输出被立即归零——即这两模式的延时保持实际不生效。另外 l_u32_freq_dispatch_delay 不必要地是普通局部变量（每次调用重建），若改成 static 语义会变，改动时须留意。
4. case AGING_END: 穿透到 default 使 AGING_END 无法保持：:969-974

   case AGING_END:
       g_t_dispatch_t.t_stsystemcmdinfo.u8AgingMode = AGING_END;
   default:
       g_t_dispatch_t.t_stsystemcmdinfo.u8AgingMode = AGING_START;

第一句赋的 AGING_END 立即被 default 覆盖成 AGING_START。因此 AGING_END 是一个永远观察不到的状态值，dectect_api_dispatch_comm() 里 u8AgingMode != AGING_END 的判断（:834）也就永远为真。case AGING_START: 穿透到 PV_TO_GRID（:895-907）同理：第一句把模式置为 PV_TO_BAT，但接着执行的是 PV_TO_GRID 的动作体，所以老化开始的第一周期实际是"上网放电"而非"PV 充电"。

1. 限制值"只压不抬"的隐式约定没有注释：全部 16 个 handle_* 都只在 limit > X 时把 limit 改小，从不放大。这意味着限值一旦被上一层（如 logic.c 的 SOC 限值、bms.c 的 get_dispatch_enable() 分支）压低，本文件的模式切换无法把它恢复。加上多个 handle_*（handle_max_output 的 :1141、handle_parallel_charge_control 的 :1094）把"清零某一侧限值"的语句注释掉了，行为差异很难从代码表面读出。
2. handle_optimise_consume 与 handle_max_consume 仅差一个 MPPT 标志：:1174-1202 两函数体除 s_u8_pv_off_flag 外完全相同（前者 FALSE、后者 TRUE）。这是刻意的（优化消纳 vs 最大消纳的差别就是是否允许 PV 发电），但两份 30 行代码重复维护，改动时容易只改一处。
3. s_u8_pv_off_flag 是文件级 static，与调频子系统双向耦合：四个地方读写它（:509、:533、:543、:817、:899…），且 excute_system_dispatch_command() 的 MPPT 赋值被 frequency_regulation_flag() == FALSE 门控（:1478）。若调频标志为 TRUE 但同时收到了系统调度指令（两个指令源并存），系统调度的 PV 开关意图会被静默丢弃。
4. g_t_dispatch_t 跨任务无锁：写者来自 net 任务（set_dispatch_parameter → net/server.c:835）与 logic 任务（所有 handle_*、dectect_api_dispatch_comm），读者还有 modbus、ems、parallel、bms 任务。同步手段只有 g_t_fast_dispatch_flag 事件标志（保证 logic 被唤醒），不对结构体本身互斥。set_dispatch_parameter() 分 8 条语句写 t_stsystemcmdinfo，期间被 logic 任务读走会得到"新模式 + 旧功率"的组合。风险在老化/西澳调度这类功率字段与模式字段强耦合的场景下最明显。
5. 多处 u32/s32 时钟比较未防溢出：:248、:767、:849、:1292 都用 (OSTimeGet() - tick) > X 的形式，tick 有的是 u32（u32CmdGetTick）有的是 s32。s32 承载 OSTimeGet() 返回值在 24.9 天后符号翻转，u32 的减法在回绕时虽能给出正确差值，但 else if (tick > OSTimeGet()) 这类保护只覆盖了"tick 在未来"的情况。
6. u8ForceSOC * FORCE_SOC_MULT ± 4 的三处口径不一致：本文件 :1018/1035/1041 用 u8ForceSOC * 4 ± 4 作 SOC 判据，net/ems.c:774/1491 上报时写 u8ForceSOC * FORCE_SOC_MULT / 10，而 handle_aging_mode() 又把 u16ActivePower * 10 当 SOC 门限（:880）。同一批云端字段被三种单位解释，±4 与 /10 这两个缩放没有任何注释。
7. 硬编码值散落：:418 的 20*1000、:423 的 30*60*1000、:809 的 90、:849 的 60 * 1000、:1292 的 800、:299 的 4500/5500、:1420（SFFR_MODE）、:1565 的 65535。频率阈值 4500/5500 只有注释"频率异常"说明是 45/55 Hz 边界，没有宏；±4、800、90 完全靠读代码推断含义。
8. 调试打印的门控组合可疑：:789 与 :864 写的是 #if (DEBUG == 1) & (DEBUG_EVERGEN == 1)——用的是按位与 & 而不是逻辑与 &&。在 #if 预处理表达式里两者对整型常量结果等价，但写法本身是笔误；同样的模式在 :564、:1400 等 20 余处 #if (DEBUG_EVERGEN == 1) 里也存在。无功能影响，但会让人误以为条件更复杂。
9. excute_system_dispatch_command() 里有引用未定义标识符的调试代码：:1400-1403 的 printf 使用了 l_s32_inv_ac_rated_power、l_s32_allow_charge_power、l_s32_allow_dischg_power、l_u16_bat_total_soc、g_t_dispatch_t.t_stsystemcmdinfo.u8AgingModel——这些都不是本函数的局部变量，u8AgingModel 字段名也不存在（应为 u8AgingMode）。它被 #if (DEBUG_EVERGEN == 1) 包裹，只有开启该宏时才会编译失败。属版本遗留死代码，建议清理。
10. get_dispatch_running_mode() 对调频模式永远返回 NO_DISPATCH_CONTROL：:128-152 的调频分支只有 default: return NO_DISPATCH_CONTROL;，没有任何具体 case。因此只要调频使能，该函数就返回"无调度"，net/ems.c:6492 的 if (get_dispatch_running_mode() != NO_DISPATCH_CONTROL) 也就不会为调频启动数据上报路径（调频上报走的是 net/ems.c:6321 的另一条路径）。看起来是有意为之，但这个"空 switch"很容易被误认为是漏写 case。
11. dispatch_api_maxfeedin_priority 未在头文件声明：它被定义为全局而非 static，却只在本文件内部使用，且不出现在 dispatch.h。属于"既不是内部函数也没有对外契约"的中间态，建议加 static 或补声明。同类情况还有 15 个 handle_* 与 dispatch_Sunspec_ative_power_mode。
12. NEGATIVE_VALUE_OFFSET 与本文件无引用：定义在 dispatch.h，本文件从未使用，属遗留宏。