3. 流量规划输入建模
流量规划不是从“配交换机”开始的，而是从“把业务说清楚”开始的。机载网络里真正决定带宽是否够用的，不是链路速率本身，而是每条消息在什么阶段、从谁发往谁、以多快周期发送、每帧多大、必须在多久内到达、以及相对其他消息有多重要。这六类信息构成了流量规划的输入模型。输入模型不完整，后续的带宽计算、优先级分配和时延验证都会失去依据。
一、任务阶段划分：先确定“时间轴”
机载任务通常按飞行剖面划分阶段，例如地面通电、发动机起动、滑行、起飞、爬升、巡航、下降、进近、着陆、地面维护。不同阶段激活的功能集合不同，流量特征也随之变化。例如巡航阶段以航电显示、导航、大气数据、发动机监控为主，数据流相对平稳；起飞与进近阶段则叠加了飞控指令、告警、起落架与襟翼状态等高频、强实时消息，瞬时负载明显上升。
阶段划分的产出不是一张阶段名称表，而是一份“阶段—功能—消息”的激活关系。建模时建议为每个阶段标注三个量：该阶段激活的功能集合、该阶段持续时间或占比、该阶段是否包含峰值事件（如告警、模式切换）。这三个量决定了后续带宽验证是按平均负载算还是按峰值负载算。若忽略阶段差异，用全任务平均流量去验证带宽，很容易在起飞、进近等峰值阶段出现漏判。
二、功能数据流清单：把功能拆成消息
功能数据流清单是输入模型的核心载体。它把“某功能需要通信”这种模糊描述，拆解为一条条可计算的消息。清单的每一行对应一条消息，字段至少应覆盖：消息名称、所属功能、所属阶段、源端、目的端、传输方式（单播/组播/广播）、周期、帧长、截止时间、优先级、允许丢包或重传要求。
采集时常见的误区是只记录“功能级”流量，例如“显示系统需要大气数据”。这无法计算带宽，因为不知道是周期发送还是请求响应、周期多少、帧多大。正确做法是继续下钻到接口控制文档（ICD）或接口清单中的具体消息，例如“大气数据计算机→显示处理机，大气参数帧，周期 50 ms，长度 64 字节”。
三、源目的端与传输方式
源端和目的端决定了流量的方向与扇出。单播是一对一，组播是一对多，广播是一对全部。扇出越大，同一帧在网络中被复制的份数越多，对带宽和交换结构的影响也越大。采集时要明确目的端是单个设备、一组设备还是全部设备，并记录是否需要跨网段或跨交换机转发。
此外，源端与目的端应使用设备标识而非功能名称，例如用“ADC-01”而不是“大气数据”。设备标识才能与网络拓扑中的端口、交换机、VLAN 对应起来，便于后续把逻辑流量映射到物理路径。
四、周期、长度、截止时间与优先级
周期决定消息的发送频率，长度决定每帧占用的字节数，两者相乘得到平均带宽需求。截止时间是消息从源端发出到目的端可用的最大允许时延，它决定了该消息对网络排队和调度的敏感程度。优先级则用于在拥塞时决定谁先发送。四者共同构成一条消息的“实时性画像”。
采集周期时要注意区分周期性与事件性消息。周期性消息按固定周期发送，例如 20 ms、50 ms、100 ms；事件性消息由状态变化触发，例如告警、模式切换，其“周期”应记录为最小间隔或最大突发速率。截止时间对周期性消息通常取周期的一部分，对事件性消息则取事件发生后的允许响应时间。
五、参数采集的实操方法
实际采集可按“功能—接口—消息”三层推进。第一层从任务阶段出发，列出每个阶段激活的功能；第二层对每个功能，查接口控制文档或系统接口清单，找出该功能涉及的所有输入输出接口；第三层对每个接口，逐条提取消息的源、目的、周期、长度、截止时间和优先级。若 ICD 中缺少截止时间或优先级，应回到系统实时性需求或安全等级要求中推导，而不是留空。
采集完成后，建议做一次一致性检查：同一消息在不同阶段是否被重复计数；源端与目的端是否都在设备清单中存在；周期与长度是否与接口类型匹配；截止时间是否小于其周期（对周期性消息而言）。这些检查能提前发现输入模型中的矛盾，避免把错误数据带入带宽计算。
六、从输入模型到可计算数据
输入模型采集完成后，应能直接支撑三类计算。第一类是平均带宽：对每条消息，用“帧长×8÷周期”得到平均速率，再按阶段和目的端汇总。第二类是峰值负载：把同一阶段内所有激活消息的速率叠加，得到该阶段的峰值需求。第三类是时延与优先级校核：检查每条消息的截止时间是否小于其周期，并确认高优先级消息的集合规模是否可控。
以示例参数说明：一条周期 50 ms、长度 64 字节的消息，平均速率为 64×8÷0.05 = 10240 bit/s，即约 10.24 kbit/s。若同一阶段有 40 条类似量级的消息，平均负载约 400 kbit/s；但若其中包含周期 10 ms、长度 32 字节的飞控消息，其单条速率即 32×8÷0.01 = 25600 bit/s，40 条叠加后负载会显著上升。这说明周期对带宽的影响远大于长度，采集时不能只关注帧长。
七、采集成果的检查要点
一份可用的输入模型，应能回答以下问题：每个任务阶段激活了哪些功能；每个功能产生了哪些消息；每条消息的源、目的、周期、长度、截止时间和优先级是否齐全；同一消息是否在不同阶段被重复计数；源端与目的端是否都能在设备清单中找到；周期与长度是否与接口类型一致。若这些问题都能回答，输入模型就具备了进入带宽计算与验证阶段的条件。
最后需要强调，输入建模不是一次性工作。任务阶段、功能集合、消息参数在系统迭代中会变化，输入模型应作为受控文档维护，并在每次变更后重新校核带宽与实时性结论。只有输入模型保持准确，后续的流量规划和带宽验证才有意义。