3. 实时性需求捕获与建模

在航空嵌入式软件中，实时性需求往往不是以“软件需求”的形态首次出现的。它最初隐藏在系统级的功能需求、安全性需求或接口控制文件中，例如“飞控计算机应在传感器数据有效后 20 ms 内完成控制律解算并输出舵面指令”。软件团队要做的第一件事，是把这类系统语言翻译成可验证的软件实时性需求，并建立从系统需求到软件需求、再到测试用例的双向追踪关系。

一、从系统需求到软件实时性需求

系统需求通常描述的是“端到端”的行为，而软件实时性需求必须落到软件可观测、可测量的边界上。以某型大气数据计算机（ADC）为例，系统需求可能写为：“在正常供电条件下，ADC 应在收到 ARINC 429 标签 203 的高度数据后 50 ms 内，向飞行控制计算机输出更新后的气压高度。”这条需求包含三个关键要素：触发事件（收到标签 203）、响应动作（输出气压高度）、时间约束（50 ms）。

软件团队需要把它拆解为软件可承担的时序约束。假设 ARINC 429 接收由中断服务程序完成，数据经队列传递给高度解算任务，解算结果再通过另一路 ARINC 429 发送。那么软件实时性需求至少包括：中断响应延迟 ≤ 5 ms；队列传递延迟 ≤ 2 ms；高度解算任务从就绪到完成 ≤ 25 ms；发送任务从取到结果到写入发送 FIFO ≤ 8 ms。这些分项之和加上硬件与总线传输开销，必须留有余量地覆盖 50 ms 的端到端约束。

二、时序约束的表达方式

时序约束不能只写“尽快”或“实时”，必须用可判定的形式表达。航空嵌入式软件中常用的表达包括：

• 截止期（Deadline）：从触发到响应完成的最大允许时间，如“控制律输出截止期 20 ms”。
• 周期与抖动（Period & Jitter）：周期任务每 10 ms 执行一次，抖动不超过 ±1 ms。
• 最小到达间隔（Minimum Interarrival Time）：用于偶发事件，如“告警事件最小间隔 100 ms”。
• 端到端延迟（End-to-End Latency）：跨多个任务或分区的信号链总延迟。
• 相位与顺序约束：如“导航数据更新必须先于控制律解算完成”。

表达时还要明确参照点。例如“20 ms”是从传感器采样时刻算起，还是从任务释放时刻算起？参照点不同，测量方法和余量分配完全不同。本文统一约定：若无特别说明，端到端延迟从触发事件到达软件边界（如中断入口）开始计时，到响应数据写入输出接口为止。

三、用例与场景建模

用例描述“谁在什么条件下触发什么功能”，场景则进一步展开正常流、备选流和异常流。对实时性验证而言，场景建模的价值在于识别最坏情况执行路径。以“高度数据更新”为例：

• 正常场景：标签 203 以 50 ms 周期到达，队列为空，解算任务立即执行。
• 突发场景：多个标签在同一帧内到达，队列积压 3 条数据，解算任务需连续处理。
• 异常场景：解算任务被更高优先级任务抢占，或发送总线忙导致输出等待。

最坏情况响应时间（WCRT）通常出现在突发场景与抢占叠加时。建模时应记录每个场景的触发条件、参与任务、优先级、执行时间和资源占用，作为后续可调度性分析的输入。

四、需求追踪矩阵的建立

追踪矩阵是实时性需求管理的核心工具。它把系统需求、软件实时性需求、设计元素、实现代码和测试用例串联起来，确保每条需求都有来源、有落实、有验证。矩阵至少应包含以下字段：系统需求编号、软件需求编号、需求描述、时序约束、设计模块、测试用例编号、验证方法、当前状态。

建立时遵循三条规则：第一，每条软件实时性需求必须能追溯到至少一条系统需求；第二，每条系统实时性需求必须被至少一条软件需求覆盖；第三，任何分项时序约束的变更，都要沿矩阵向上检查端到端余量是否仍然成立。

五、一个可填写的追踪矩阵示例

下表给出上述 ADC 示例的追踪矩阵片段，可直接作为项目模板使用。字段中的“验证方法”一栏，A 表示分析，T 表示测试，I 表示检查。

六、常见问题与处理建议

实际项目中，需求捕获与建模最容易出现三类问题。第一类是时序约束缺少参照点，导致测试时各说各话；处理办法是在需求文本中强制写明“从……到……”。第二类是分项约束之和超过端到端约束，却通过压缩测试余量来“通过”；正确做法是回到任务划分或优先级设计，而不是修改测量口径。第三类是追踪矩阵只建不用，需求变更后矩阵未同步；建议把矩阵更新纳入变更控制流程，任何时序参数修改都必须触发矩阵影响分析。

完成本节工作后，团队应能回答三个问题：每条软件实时性需求来自哪条系统需求？它的时序约束如何测量？它由哪个测试用例验证？如果这三个问题都有明确答案，实时性需求捕获与建模就具备了进入下一阶段可调度性分析的基础。