航电系统时序预算：从IMA架构到多核干扰的完整指南

做航空电子系统开发这些年，我越来越觉得“时序预算”是一个被低估的关键词。很多人一听到这个词，下意识以为它是某个文档里的表格，或者系统联试时验证工程师才翻的东西。但实际上，时序预算在项目初期就决定了这个阶段能不能跑通、分区调度表能不能定下来、端到端延迟会不会在集成阶段突然失控。我见过太多团队在实验室阶段一切正常，一到和真机传感器、执行机构联动时，控制律性能就崩了，排查到最后往往就是一个毫秒级的时序余量算错了。这篇文章我想好好聊聊航空电子系统开发中时序预算这件事——它包含哪些层级、怎么一步步推导、如何写在需求里、以及在多核处理器进入航电之后，这个复杂度又上了一个什么样的台阶。

1. 为什么“时序预算”正在成为航电开发的隐形瓶颈

1.1 从联邦式架构到IMA架构，时间变成了共享资源

早期航空电子系统是联邦式架构：一个功能一个计算机，计算机之间用离散线或者低速总线通信。那时候所谓的时序预算其实非常简单，每个盒子单独工作，只需要保证自己内部的采样周期、计算周期和输出周期满足控制律需求，剩余的时间哪怕全部浪费掉都没关系。因为彼此不共享资源，时间上的“抢占”和“干扰”几乎不存在。

但现在是综合模块化航空电子（IMA）的时代。一个通用计算模块（LRM）上同时跑着飞控、机电管理、座舱显示、健康监测等多个功能分区，它们共享同一个CPU、同一片内存和同一条通信网络。这个时候时间就变成了一种真正意义上的共享资源。你在某一个分区里多占一个毫秒的CPU时间，隔壁分区可能就错过自己的帧周期；某一路总线上的突发流量如果抵掉了约束，另一路虚拟链路的数据就没有办法在要求的延迟窗口内到达。

IMA带来的好处是硬件数量大幅减少、重量功耗降低、可维护性更好。但代价是，原来用物理隔离实现的时间确定性，现在只能靠调度策略、分区机制和预算管理来维护。而在适航审查视角下，DO-178C、ARINC 653背后的安全目标要求你能证明“所有功能在最坏情况下依然满足时间需求”。所以时序预算不只是开发期的一个设计工具，它直接关系到你最后能不能拿出足够证据完成系统级的验证。

1.2 多核处理器进场，让时序分析复杂度再上一个台阶

前几年大家还在双核、四核的芯片上做IMA移植时，我听到最多的争论就是：同一个Cache、同一个内存控制器，两个核上的分区会不会互相影响？答案是肯定的，一定会互相影响。只是影响的程度在不同架构上差别很大，而且这种干扰很难靠简单的静态分析就彻底看透。我见过一个项目把原本在单核上跑得好好的飞行告警功能移植到多核平台的隔离核上，回头做最坏情况时序测试时发现，告警响应时间比单核时多了将近20%。原因不是功能本身变慢了，而是共享内存控制器被另一核的DMA密集型分区拖住了。

多核给时序预算带来的真正变化是：预算的边界变得模糊了。单核时代你可以把CPU时间精确地切成若干个窗口，因为永远只有一个执行单元在跑。多核时代，CPU执行时间依然可以精确切分，但Cache命中率、内存带宽这些原来不需要操心的资源，变成了需要纳入预算考量的干扰源。CAST-32A这些行业指导文件的出现，其实就是在迫使我们在时序预算里对多核干扰给出明确上限和实测证据。

1.3 时序预算的本质：把时间当成系统级资源来管理

如果用一句话概括时序预算的本质，我认为是：把“时间”这个不可再生的系统级资源，在功能需求和技术实现之间建立起可量化、可审计、可验证的对应关系。它像一条从需求到成品之间的时间链：传感器采样时刻，到总线传输、分区调度、任务执行、数据处理、网络输出、执行器响应，每一步都要在项目开始时估算一笔时间账。后面所有软硬件实现，其实都是在兑现这笔账。

成熟的做法是把这个预算写成一个可配置、有版本控制的时间参数模型，并把它放在系统需求文档等级联管理的一环里。任何一个参数发生变化——比如控制律从50Hz改成100Hz、某个传感器数据延迟增大、某个分区预留给高完整性功能的时间被压缩——都需要走一轮完整的变更影响分析。这很难，但也是航空电子系统区别于普通嵌入式系统最根本的地方：普通产品超时了最多用户体验差一点，航电系统超时了可能要拿飞行安全去扛。

2. 时序预算到底在预算什么：四层结构完整拆解

2.1 任务级预算：周期、截止期与最坏执行时间

最底层的是任务级预算。这一层的内容对于所有实时嵌入式开发者都不陌生：每个周期性任务有它的采样周期T，有它的相对截止期D，以及在不同输入条件下执行一次所需的执行时间C。这个C，即WCET（最坏执行时间），是整个预算里最基础也最核心的参数。普通软件工程里你关心平均性能就够了，但航电里的时序分析必须盯着最坏情况，哪怕那个最坏情况要在特定缓存状态和特定数据输入组合下才出现。

这里特别提醒一点：WCET不是拿现代处理器的时间计时器对着典型用例掐表算出来的。它要综合考虑指令流水线、缓存命中率、分支预测、总线周期、中断抢占甚至DMA干扰。拿静态WCET分析工具结果和实测对比，经常能差出20%到50%，因为实测时很难构造出“所有缓存全部未命中且总线正好被占满”的组合。没有这个意识的话，你在任务级预算上从一开始就会吃大亏。

2.2 分区级预算：ARINC 653窗口与主帧分配

再往上一层是分区级预算。IMA环境下，多个分区按ARINC 653调度机制共享处理器。系统把时间轴划分成一个固定长度的主帧（MAF），每帧（通常是毫秒级）内为每个分区分配一到多个时间窗口。时序预算在这一层要回答的问题非常明确：每个分区在MAF里拿多少个窗口、每个窗口多长、窗口之间切换开销是多少、分区内任务能不能在自己的窗口内完成。

做分区窗口分配时特别容易漏算的是两个东西：一个是分区切换（context switch）本身的CPU开销，它的时长取决于底层OSEK/分区操作系统和硬件上下文保存的范围；另一个是窗口粒度带来的“碎片时间”。比如把一个20ms的MAF切成8个窗口，如果有些分区只需要1.3ms的工作量，那0.7ms的碎片就被浪费了，哪个分区都拿不到。预算做得好不好，体现为同样一个MAF长度，你的有效利用率能排到多高，以及你为高完整性分区预留了多少余量防抖动。

2.3 网络级预算：虚拟链路、BAG与端到端帧延迟

系统里不可能只有一个IMA模块。模块之间通过航电网络（比如AFDX/ARINC 664或1553B总线等确定性网络）通信，那么时序预算还需要覆盖通信链路。AFDX网络里有虚拟链路（VL）和带宽分配间隙（BAG）的概念：每一条VL按配置的BAG周期，计算自己一个帧的最大传输延迟，包括发送端排队、交换机转发、接收端缓存和协议栈处理。这些网络延迟通常比计算侧更有“确定性”的感觉，但依然有抖动，尤其当多个VL的帧同时到达同一交换机端口时，存在仲裁和排队。

在这个层次上，时序预算的重点是延迟上界的计算。链路上每一跳都会增加一个固定或变动的延迟，逐跳相加后得到端到端的最大传输延迟。很多工程师最初觉得AFDX带BAG约束，延迟应该非常稳定，但实际上交换机端口FIFO共享、冗余管理、帧分片都会引入额外的延迟项。不在预算阶段把这些项列出来，后面网络联调时哪个数据晚到了，会很被动。

2.4 端到端级预算：从传感器到执行器的完整时间链

最后的端到端级预算属于“终极目标”。飞控系统关心的不是某一个任务执行了多久，而是从IMU采样到一个姿态数据，到这个数据经过总线到达飞控计算机、参与控制律计算、生成舵面指令、再到指令传递给伺服系统开始动作，整个过程加起来是多少毫秒。航天航空里的相位延迟分析、稳定裕度计算，用的都是这个端到端延迟。如果这个延迟超过控制律设计时的假设值，闭环控制性能就会变差，严重情况下连稳定性都会出问题。

端到端预算的推法其实不复杂，就是把前面几层的预算项全部串联起来，逐项累加。但要小心一个问题：各项延迟的初始时间基准可能并不对齐。比如传感器在时间T采样，经过一段固定延迟在T1到达数据总线，但接收端分区的调度周期是从接收中断触发开始算的，那么输入数据的“年龄”会把计算延迟和通信延迟搅在一起。预算表里最好把每个环节的延迟都标注成相对于同一个时间主轴的时间戳形式，尽量避免简单相加导致的时间基准错位。

3. 从需求到调度表：一次飞控功能时序预算的完整推导

3.1 算一笔没有余量的初始账：可以设定一个姿态控制分区的例子

光讲概念很难落地，我拿一个虚拟但非常典型的例子来走一遍完整推导过程。假设新项目要在某个IMA通用模块上实现一个姿态控制功能（这里不针对任何具体型号，只作为方法演示）。传感器的输入来自惯性测量单元（IMU），IMU以400Hz的采样率提供姿态角速率数据，刷新周期2.5ms。控制律算法以50Hz运行，周期20ms。驱动指令要以50Hz的速率输出到伺服控制器。此外，同模块上还驻留着一个实时监控分区，负责采集模块健康状态数据，周期为100ms。

系统设计阶段给姿态控制链路设的端到端预算指标是：从IMU采样时刻到舵面指令到达伺服控制器的总延迟不得超过35ms。另外还限制了一个抖动指标：相邻两个周期端到端延迟的变化幅度不得超过2ms。这两个指标是我们推导的终点，也是验证阶段的合格判据。

3.2 逐段推导：采样、通信、调度、计算的累加过程

先把整条链路拆开，逐段估算延迟。

第一段是IMU内部的采样与封装延迟。IMU采集原始陀螺信号到完成内部数据处理并准备好发送数据帧，这段时间通常由传感器厂商给出，假设是0.5ms到1ms，取上界1ms。接下来数据传输到IMA模块，假设走一条BAG为2ms的AFDX虚拟链路，那么从帧开始排队到接收处理完成，延迟可以控制在2.5ms以内（包括发送端排队0到2ms、线上传输与交换机处理约0.3ms、接收端协议栈0.2ms）。这样，从物理采样到数据进入模块内存，最大延迟是3.5ms左右。

第三段是软件分区的调度等待。由于姿态控制分区以20ms为周期运行，而IMU数据是在任意时刻到达的，分区可能最多等待约20ms才轮到下一个窗口开始处理。为了让控制器使用最新数据，通常用ARINC 653的采样端口机制：数据到达时更新端口缓冲，分区下一次周期开始时读取。于是调度等待这一段的延迟上界约等于MAF中的最长调度间隔。在我们的例子里，MAF是20ms，分区窗口长度为3ms，处于主帧的靠前位置。调度等待最大就是分区两次运行开始时刻之间的间隔，假设是19.5ms。

第四段是控制律任务本身。输入读取、数据有效性检查、状态估计、控制律解算、输出打包，在目标处理器上跑完这些流程，经过静态WCET分析得到最大执行时间为2ms，再加上分区内任务间切换和RTOS调度开销0.2ms。最后是输出方向的数据传输：控制指令通过另一条AFDX虚拟链路发往伺服控制器，发送端准备与排队占0.5ms，网络传输0.3ms，接收端伺服控制器处理0.5ms，合计1.3ms。

现在把各段加起来：1ms + 3.5ms + 19.5ms + 2.2ms + 1.3ms = 27.5ms。相比于35ms的需求指标，这条预算链看似有7.5ms的余量。如果我们直接把27.5ms当作最终结果，这个预算账其实还不够负责任。它漏掉了最坏情况下的缓存和总线干扰，也没有考虑数据在多个周期上叠加造成的相位延迟。按我的经验，预算里至少要再叠加上10%到20%的“不可精确建模的干扰余量”，同时通过实测来验证，并把最坏情况下的实测值作为最终预算依据。

3.3 抖动预算其实是更隐蔽的约束

很多人只盯最大延迟，忽略了抖动。刚才的例子中，端到端延迟上下界之间的摆幅来自几个部分：IMU数据到达时刻相对分区调度时刻的相位差，这个可以变成0到2.4ms的变化；网络队列长度不同造成的0到1ms变化；以及任务因缓存状态不同导致的执行时间在1.5ms到2ms之间浮动。这三项叠加，区间大约在1.5ms到4.4ms之间，已经明显超过了需求里给到2ms的抖动指标。想满足抖动指标，就不能只是在预算表上加余量，而是要动架构：比如把控制律的输出时刻强制对齐到网络发送窗口，或者在IMA模块内部把IMU数据的接收锁存到分区帧开始的采样端口上。这是时序预算最有价值的地方——它让你提前发现直接堆余量解决不了的竟然是系统级的参数匹配问题。

预算推导出来后，还要形成一份可以直接判定的验证方法表，也就是把每个延迟项对应到一种验证手段上：采样到网络由协议分析仪测，调度等待由分区调度trace测，WCET由静态分析和目标板叠加测，端到端延迟则在系统联试时用专门的测试激励和回采设备来测。每项数据要有记录，要能追溯。

4. 写进预算表的五个不可控延迟项：抖动、中断与多核干扰

4.1 中断抢占与任务切换的优先级倒置

在单核处理器上做实时调度时，预算表里最容易漏掉的是中断延迟。航电系统里通常会有多个中断源：外设数据到达中断、定时器中断、健康监控警报中断、DMA完成中断。如果某个高频率的中断处理程序占用了较长时间，它会抢占正在运行的分区任务。更麻烦的是优先级倒置：低优先级中断触发频繁，高优先级任务只能等它退出临界区。这个时间账在硬件设计阶段就要折算进每一个任务的可执行时间内。

我做过的一个项目里，外设数据到来中断服务程序里做了一大堆数据校验和格式转换，执行时间接近250微秒。最初预算里只给这个中断分配了100微秒，结果直接导致一个周期为5ms的任务在最坏情况下被中断占掉15%的CPU时间。后来把中断处理里的大数据处理全部挪到任务上下文里做，中断只做“登记数据就绪”的轻量操作，中断占用的预算才回到合理范围。

4.2 DMA和内存带宽竞争：数据搬运也会抢执行时间

DMA的存在让预算变得微妙起来。一方面DMA帮你搬数据，减轻CPU负担；另一方面DMA每做一次批量搬运，都要占用总线周期，影响CPU取值和Cache填充。尤其是在IMA模块上同时存在大量串口、网络接收、内部高速总线流量时，DMA和CPU之间的总线仲裁延迟会变得不可忽略。预算阶段如果只按CPU理想情况计算WCET，到实测阶段偶尔会冒出几个“解释不通”的超时帧，原因往往就是某一段总线上恰好有大量DMA流量。

对这种干扰，我的习惯是在任务WCET里额外加一个介质访问竞争余量系数。具体加多少取决于总线和内存控制器的仲裁策略，一般取5%到15%，如果是多核共享内存控制器且带宽紧张，可能要加到20%以上。重要的是这个余量不是拍脑袋拍出来的，而是要把总线占用率和最大占用时间建模出来，再做最坏情况叠加。

4.3 缓存污染：现代处理器给WCET分析出的最大难题

缓存是这个时代WCET分析里最容易让人头疼的东西。一段代码在冷缓存状态下执行和热缓存状态下执行，耗时可能差好几倍。时序预算里如果用热缓存的执行时间作为WCET，一旦出现任务切换后冷缓存、数据流连续翻转缓存，实际执行时间立刻超标。行业里常见的做法是用现有工具做静态WCET分析，工具本身会尝试估计缓存行为。但工具经常只能处理单核场景，到了多核共享L2的场景，工具出来的WCET是否涵盖了对侧核的缓存污染，必须具体分析。

我踩过一个非常典型的坑：某个任务反复遍历一个大容量表格来做查询补偿计算，理论上数据表格6KB，L2缓存4MB，怎么都该全命中。但同一时间另一个分区也在做视频叠加处理，不断冲刷L2，导致这个任务实际执行时间比静态分析的WCET高出了将近30%。从那以后我要求在系统联试阶段的时序验证里必须构造“相邻分区最高负载并发”的测试场景，而不能只单独跑某一个分区加一个模拟假负载。

4.4 调度器窗口边界：分区切换开销不是无穷小的量

ARINC 653的调度器本身也有开销。当硬件上下文很重、寄存器组很多、浮点单元状态要保存时，一次分区切换可能在几十微秒到数百微秒之间。如果MAF是20ms，里面有8个分区，每个切换算100微秒，那一个MAF里仅切换开销就是0.8ms，占4%。这个比例在一个设计紧凑的分区调度表里绝对不能忽视。

更隐蔽的是窗口边界的精度问题。有些分区操作系统在实现ARINC 653调度时，窗口切换的时刻并不是严格对齐到固定时间点，而是在前一个分区任务系统调用返回时触发。如果前一个分区任务有一点超时，就会把延迟传导到下一个分区。时序预算里必须给窗口边界设置一个安全裕度，同时要求分区内任务在窗口结束前主动让出执行权，而不是依赖调度器强杀。

4.5 时钟同步误差：多模块系统的“看不见的起步线”

最后一个不可控项是时钟同步误差。航电系统里不同模块各自维持本地时间，即使有IEEE 1588这样的大系统时间同步协议，也不可能做到完全零偏差。端到端延迟分析里如果传感器模块和计算模块的时钟基准差了几十微秒，那你的延迟测量都会有系统性偏差。关键还不是绝对值偏差，而是随时间漂移导致的抖动。你把两个模块的启动时间对齐了，但晶振频率偏差造成时钟漂移，测试时数据看起来很好，隔一段时间再看，误差方向可能就反了。

所以我建议在时序预算的验证策略中，把同步误差作为一个独立的预算项明确列出来，最好在联试时保留同一份高精度外部时间基准去比对各模块的本地时间。每一轮端到端延迟实测，都要附带当时的同步偏差读数，把数据校准回同一根时间轴上。这个问题在系统级联试时非常常见，但常常被当成“测试环境问题”而不是系统设计问题，其实它本身就是时序预算的一部分。

5. 验证时序预算的实战工具链：静态分析、目标板实测与持续监控

5.1 静态分析工具能做什么，不能做什么

实际项目中验证时序预算，第一步是静态WCET分析。这个领域常见的商业工具包括AbsInt的aiT、Rapita的RapiTime等。它们通过在源码和二进制层面建立控制流、数据流和硬件行为模型，计算出任务在最坏情况下的执行时间上界。这些工具最大的价值是把“最坏情况”从一种猜测变成一个可量化、可论证的数，它输出的是逻辑分析意义上的上界，不依赖你是不是能造出那种缓存翻转的巧合场景。

但静态分析工具只能分析单个执行单元（一个核上的一个任务），多核场景下的干扰走廊分析（Contention Corridor Analysis）通常要结合实测数据来做。而且工具通常假定一个确定的缓存替换策略和总线仲裁模型，如果芯片的数据手册里没有明确描述这些细节，分析结果就带有不确定性。这时候只能在预算里透明地注明：这个WCET值是基于XX硬件配置、XX缓存策略下的分析上界，实测验证时如果超出，要做来源追踪。

5.2 目标板实测：搭建能覆盖最坏情况的测试环境

实测验证是时序预算落地的最重要一关。我这里说的不是对着模拟器跑一遍功能就算完，而是要搭一个能制造人为负载和外部扰动的时间测量环境。系统联试时我们会在目标机上插桩，记录每个分区窗口的开始与结束时间、每个任务的入口和出口时间戳、每次网络帧的排队到离队时间，形成一个完整的时间追踪序列。然后把正常飞行工况、故障降级工况、最大外部数据负载工况都跑一遍，看实际延迟和最坏延迟会不会突破预算。

实测这里有两个经验：第一，测试时间必须足够长，至少要覆盖到缓存冷热状态反复翻转、多个虚拟链路帧对齐周期稍微错开导致的最大排队情况，几个小时的连续跑才能收集到真正极端的时间点。第二，要对比实测分布和预算法则之间的差距。如果实测最坏值明显小于预算上界，先别高兴，要确认所有干扰项都已经被实际激发过，而不是因为测试工况没有覆盖到才显得余量很大。

5.3 把时序监控变成常态化：CI里检查调度表的“超限”

产品一旦进入后期测试阶段，时序预算就不该再靠人工去翻trace文件了。我们的做法是把时序验证集成到日常构建和测试流程里：每次软件构建或者分区参数变更，自动跑一轮时序回归测试。工具收集每个任务的执行时间、分区窗口利用率和网络延迟数据，自动比对预算表，一旦出现某个指标接近或超过预算上界，立刻报错，触发变更审查。

这个机制初期有一点额外工作量，但价值极大。有一次我们只是调换了一个分区的窗口顺序，表面上看每个分区总时间没变，但自动测试发现某个延迟项因为调度相位变化从9ms涨到了13ms。如果靠人工审查，这种间接影响很可能要到系统联试才会浮现。所以时序预算管理本质上是一个持续的过程，不是设计期写一份文档就结束了。

5.4 文档与追溯：时序预算表是需求，不是行政材料

最后强调一个很容易被忽视的实践：时序预算表本身必须纳入配置管理和需求追溯链。每个延迟项要有唯一标识，要能追溯到上层功能需求的相应指标，在下层则关联到具体任务、分区配置、网络配置或硬件约束。需求变更时，影响分析里必须包含一个“时间影响列”，要能自动找出哪些预算项受影响、哪些测试用例需要重跑。没有这个追溯关系，时序预算就只是一堆没人执行的数字。

时序预算表里字段至少要包括：延迟项名称、所属层级、预算上界、实测上界、验证方法、验证用例标识、责任人、版本号、备注。格式可以是电子表格，也可以用数据库工具管理。团队大了之后，我建议做成一个小型看板式的管理系统，用颜色标记预算消耗状态（正常/接近上限/超限），每周同步一次。

6. 我在项目中反复踩过的坑和最后沉淀下来的习惯

6.1 坑一：只测典型工况就宣布“时序预算满足”

这是最常见也是后果最隐蔽的坑。测试时大家的习惯是优先级最高的事先保证功能正确，时间数据随手记一下，看到几十次运行都没有超时，就认为工作完成了。但航电系统里最坏情况不是平均意义上的，是“最不利的缓存状态、最不利的总线排队、最不利的输入数据”同时碰在一起的那个瞬间。你跑一个月也未必碰得到，但它一旦发生，可能就是系统保护或降级逻辑被误触发，影响飞行任务。我现在要求团队把“构造最坏情况”列为测试用例设计的标准动作，而不是靠运气遇见。

6.2 坑二：把中断服务和DMA的时间成本从WCET里漏掉

打断任务的不是只有其他任务，还有硬件中断和DMA。如果中断服务程序本身执行时间不明确，或者DMA流量没有被建模，那任务级WCET再准确也是假的。我处理这个问题的习惯是在项目早早期就做一个“CPU时间占用审计”：把所有周期中断的执行时间、DMA占用总线的带宽上限、异步事件的最高发生频率全部统计出来，算一笔“硬件开销占CPU时间的比例”。如果这个比例超过15%，在设计评审时就要重点讨论是不是要精简中断处理或调整DMA优先级。通过提前审计，后面预算里的WCET才经得起推敲。

6.3 坑三：分区窗口分配没有留出“降落跑道”

做分区调度表时，总想把每个窗口填满，让CPU利用率看起来很高。但窗口内任务的执行时间是有抖动的，窗口末尾如果没有预留降落余量，一旦某个周期任务执行时间比平均值高一点，就会顶到窗口边界，甚至被调度器强切。强切导致的后果不只是这个分区逻辑被截断，还可能让下一个分区的启动时刻被推迟，形成连锁延迟。我现在的习惯是每个分区窗口预留10%到20%的尾部余量，宁可让CPU利用率报表难看一点，也要保证调度表的稳定性。

6.4 坑四：多核带来的干扰被当成“异常现象”而不是预算项

多核平台的干扰问题不是偶发故障，它是系统固有的统计特性。第一次在四核处理器上做IMA迁移时，我在一个共享内存控制器的分区上测量到间歇性延迟尖峰，起初以为是测试设备的问题，后来才发现是对侧核的以太网DMA突发导致的固定带宽竞争。把这类问题从“现象分析”挪到“预算建模”之后，解决方法反而简单：要么降低共享流量峰值，要么在预算表中给这一项分配一个明确的延迟上限窗口。很多做航空电子的同事一听到多核就紧张，觉得WCET不可测、验证不可做，但我的经验是，预算模型建得好，多核也就是多几个干扰项而已，关键是不要在遇到问题时才去分析，而是要提前写进预算里“默契地”预留那部分余量。

6.5 一个让团队少走弯路的清单习惯

最后分享一个我在新项目开工时一定会做的小事：建立“时序预算一页纸”，把它贴在需求审查和联试晨会的投影区。一页纸上列清楚当前版本的端到端预算分配、各分区窗口占用率、认证关键路径的延迟上界上限、以及上一轮实测发现的所有时间异常点。不需要很复杂，它起的作用是让每个人的脑子里都挂着一根时间弦。当软件工程师想加一个耗时操作、系统集成工程师想调整BAG参数、验证工程师在规划极限测试用例时，他们都会不由自主地先跟这一页纸对一下。这样做下来，我在多个项目里都明显感到“时序问题”的发现时间点，从系统联试的中后期前移到了设计定型之前。航电系统开发里，把时间当成和重量、功耗、可靠性并行的第一等资源来对待，这个项目的时序预算才能真正在系统验证时站得住脚。