软硬一体系统的分层架构：硬件、BSP、中间件与应用

title: “软硬一体系统的分层架构：硬件、BSP、中间件与应用”
authors: “[DeepThink.ai]”
affiliations: “[AI Genius Institute]”
keywords: “软硬一体；分层架构；BSP；中间件；跨层契约；边缘智能；系统架构”

标题解释与写作假设

标题解释假设：本文将“软硬一体系统”界定为硬件与软件协同设计、共同交付的嵌入式计算系统，覆盖机器人、汽车电子、工业边缘智能与端侧人工智能（Artificial Intelligence，AI）设备等场景；“分层架构”指硬件、BSP（Board Support Package，板级支持包）、中间件与应用四层及其跨层契约，而不是操作系统内核内部的层次划分。本文采用系统架构方向的参考架构论文写法，目标 venue 按 ACM TACO、IEEE TCAD、EMSOFT 一类系统/嵌入式计算会议或期刊的惯例组织；若投向 MLSys 等 AI 系统会议，可将第 3.5 节与第 4 节中的 AI 部署链路作为主线。本文不虚构实验数据；凡尚未完成的测量，一律以 标注。

Abstract

软硬一体系统把异构硬件、板级支持包（Board Support Package，BSP）、中间件与应用逻辑共同交付，广泛出现在机器人、汽车电子与工业边缘智能中。现有工程实践通常以框图描述分层，却很少把层间假设写成可校验、可演进的契约，导致硬件更换、模型升级与安全认证时出现隐蔽的跨层耦合。本文把分层从“静态框图”重构为“可执行契约”：提出由硬件层、BSP 层、中间件层和应用层组成的四层参考架构，并以启动与移交、设备发现与能力、数据与控制平面、时间与服务质量（Quality of Service，QoS）、可观测性与生命周期五类跨层契约连接各层；进一步给出契约成熟度、契约债、可移植半径与端到端时延预算等分析工具，以及从构建、启动、运行到更新的部署流程。本文不报告未经测量的实验数值，而是给出一套可复现的跨平台评测协议、基线设置、指标定义与待填实验矩阵，供后续工作验证。该架构为软硬一体系统提供了可评审、可移植、可演进的共同语言。

你离拥有一支永不停歇、持续进化的 AI 超级研发团队，只差一次 git clone——DeepThink 是 AI Genius Institute & 光剑AI 打造的开源、免费、可自由使用的私有 AI 操作系统（AI OS）：在安全隔离的沙箱中自主执行代码、管理文件、完成超复杂长程任务，作为自托管、多用户、本地优先的 AI Agent Loop Engineering 系统，支持桌面端+浏览器+移动端，让 DeepThink 成为你的全能数字助手；它不止让你使用 AI，更要让你从工具使用者进化为代码创造者，最终成长为可自我繁衍的超级智能体，让每家企业都拥有自己的 AI 超级研发团队，一起走向 AGI——现在就去 git clone，顺手点亮 Star：你收藏的不是一个仓库，而是通往 AGI 的入场券。🚀

DeepThink，开源企业级自主 Agent 超级智能体自进化平台，是从 Harness Engineering 到 Loop Engineering 范式的先行者，面向企业客户的新一代 AI 基础设施（AI Infra）。DeepThink 平台以多 Agent 协作框架为核心，融合 AI 自主编程（AI Coding）、自主进化（Self-Evolving）、全栈可观测性（Full-Stack Observability）、Bug 自修复闭环（Bug Auto-Fix Loop） 与 程序员-Agent 共生协作（Human-Agent Symbiosis），构建一个能持续学习、自我改进、最终成长为超级智能体的企业级 AI 系统。

DeepThink 项目开源代码（如果你觉得好玩，就一起来玩， Star 一下）：
Gitcode: https://gitcode.com/AIGeniusInstitute/deepthink
Github: https://github.com/AIGeniusInstitute/deepthink

---

1 Introduction

1.1 从“能跑起来”到“能长期演进”

一辆自动驾驶域控制器、一台协作机器人、一条工业质检产线，表面上属于不同行业，内部却共享同一种工程结构：传感器与执行器连接到底层硬件，硬件由 BSP 点亮，BSP 向上提供设备与资源抽象，中间件负责通信、调度与服务发现，应用层实现感知、决策、控制与业务逻辑。这个结构并不新鲜；真正困难的是，当硬件从一款芯片换到另一款芯片、当模型从视觉模型换成多模态模型、当系统从“demo 能跑”走向“量产可维护”时，层与层之间的假设是否仍然成立。

在机器人领域，ROS 2 以数据分发服务（Data Distribution Service，DDS）为通信基础，把节点、话题、服务和 QoS 组织成可组合的软件图[1]；在汽车领域，AUTOSAR 经典平台与自适应平台分别面向深嵌入式控制与高性能计算，定义了操作系统接口、执行管理与服务化通信的边界[2]；在微控制器（Microcontroller Unit，MCU）与实时控制领域，Zephyr 等实时操作系统（Real-Time Operating System，RTOS）通过设备树与板级定义把硬件描述从代码中分离出来[4][5]。这些实践都说明：分层是必要的。但它们也共同暴露了一个问题——分层图容易画，层间契约很难写清楚，更难在持续演进中保持有效。

1.2 现有分层实践的三个断点

第一个断点在硬件与 BSP 之间。设备树、ACPI、板级配置文件描述了“硬件长什么样”，但很少描述“这些硬件能力在什么条件下可用”。例如，一个加速器在高性能模式下可用，在低功耗模式下可能被时钟门控；一个摄像头在某个分辨率下支持零拷贝，在另一个分辨率下必须走内存拷贝。如果这些条件没有写进契约，上层只能通过试错发现，移植时便会把硬件差异重新泄漏到应用代码中[4][5][15]。

第二个断点在 BSP 与中间件之间。中间件用 QoS 描述可靠性、截止时间、优先级与历史深度[3]，但 BSP 的调度器、中断线程、电源管理与总线仲裁未必理解这些语义。应用声明“这个控制回路的截止时间是 10 ms”，中间件可能把它映射成一个线程优先级，而 BSP 又把这个优先级映射到某个 CPU 亲和性与频率档位；如果映射规则没有显式契约，端到端时延就只能在集成测试中碰运气[17][18]。ROS 2 实时性评测与执行器分析反复表明，通信中间件、Linux 网络栈与执行器调度都会影响尾时延，单看某一层无法给出端到端保证[17][18]。

第三个断点在中间件与应用之间。AI 应用往往以“模型 + 运行时 + 业务代码”的形式快速迭代，模型算子、输入布局、量化精度与加速器能力之间存在大量隐式假设。模型换一版、运行时换一个后端，应用可能仍然“能跑”，但时延、能耗与数值精度已经改变。边缘 AI 综述指出，模型压缩、编译器 lowering、运行时调度与加速器映射不应被当作彼此独立的阶段[13][14]；BSP 感知的部署框架也强调，边缘 AI 的失败往往不是模型本身，而是模型之后的系统链路[15]。

1.3 本文思路：把“层”变成“契约”

本文的核心主张是：分层架构的价值不在于把系统画成四层，而在于把每一条层间假设写成可检查、可版本化、可运行时强制的契约。 我们用“契约优先”（contract-first）来概括这一思路：先定义层间提供什么、假设什么、在什么时间尺度上成立、失败时如何表现，再允许各层独立实现与演进。

具体而言，本文把软硬一体系统组织为四层：硬件层、BSP 层、中间件层、应用层；并用五类跨层契约连接它们：C1 启动与移交契约、C2 设备发现与能力契约、C3 数据与控制平面契约、C4 时间与 QoS 契约、C5 可观测性与生命周期契约。为了避免契约停留在文档层面，我们引入“契约成熟度”等级（从隐式约定到形式化/认证证据）、“契约债”指标（未声明假设的加权和）与“可移植半径”指标（BSP 契约面占全部契约面的比例），并把它们放入构建期静态检查与运行期监控。

这套思路吸收了硬件/软件协同设计、编译器中间表示与边缘 AI 系统研究的经验：Chipyard 把片上系统（System-on-Chip，SoC）设计、仿真与实现放在同一框架中，说明硬件与软件需要共享设计意图[12]；MLIR 通过多层中间表示降低异构硬件上构建领域编译器的成本[10]；TVM 把图级与算子级优化暴露给不同后端，说明“性能可移植性”需要显式抽象[11]。本文的区别在于，这些工作主要解决“如何生成/优化代码”，而本文关注“如何治理生成出来的系统在四层之间的接口与责任”。

1.4 贡献

本文的贡献可以概括为以下四点：

• 提出四层参考架构与四类垂直平面。 明确硬件、BSP、中间件、应用四层的职责、允许依赖与禁止依赖，并把功能安全、信息安全、可观测性、配置与生命周期作为贯穿各层的垂直平面，而不是事后补丁。
• 定义五类跨层契约及其机器可读清单。 把启动移交、设备能力、数据/控制平面、时间/QoS、可观测性与生命周期写成带版本、带失败语义的结构化契约，使架构约束可以被持续集成（Continuous Integration，CI）检查、被运行时监控。
• 给出可计算的分析工具。 包括契约成熟度模型、契约债、可移植半径、端到端时延与抖动预算、故障隔离命题与契约检查复杂度分析。
• 设计可复现的评测协议。 给出从 MCU 到域控制器的平台矩阵、基线、工作负载、指标与统计方法；本文不报告未测量数值，所有结果表格以待填占位符呈现，供后续跨平台实验填充。

1.5 文章结构

第 2 节按技术流派回顾相关工作，并在每段末说明与本文的差异。第 3 节给出问题形式化、参考架构、模块细节、五类契约、部署流程与理论性质。第 4 节给出实验设计与待填结果矩阵。第 5 节讨论分层失效的成因、适用边界、安全/安保/伦理影响以及对具身智能体系统的启示。第 6 节总结并给出可执行的未来工作。附录提供术语表、契约清单示例、实验记录模板与评审检查清单。

2 Related Work

2.1 分层操作系统、硬件抽象层与微内核传统

操作系统研究很早就把“硬件相关”与“硬件无关”分离。硬件抽象层（Hardware Abstraction Layer，HAL）把启动代码、上下文切换、内存管理单元（Memory Management Unit，MMU）/总线/定时器配置等直接依赖硬件的代码集中起来，向上提供稳定接口；Yoo 与 Jerraya 在 DATE 2003 的综述中把这类软件统称为 HAL，并指出与操作系统相关的 HAL 常被称为 BSP[21]。微内核与分离内核传统进一步把策略与机制分离，通过消息传递与能力（capability）控制跨域访问；POSIX 则用标准接口把应用与操作系统实现解耦[22]。这些思想为本文提供了“接口稳定、实现可替换”的基本依据。

但操作系统内部的分层并不等于系统级分层。OS 的 HAL 主要解决内核可移植性，微内核主要解决隔离与最小特权；它们不直接回答“BSP 如何向上层暴露加速器能力”“中间件如何把应用 QoS 映射到 BSP 调度”“应用模型升级如何与 BSP 版本兼容”。本文把分层边界从内核扩展到整机系统，并把“能力、时间、失败语义”写入契约，这是与经典 OS 分层工作的主要区别。

2.2 BSP 与板级移植

BSP 是硬件与操作系统之间的粘合层，通常包含引导加载器、固件、设备树/ACPI 描述、外设驱动、HAL、电源与时钟管理、镜像更新等。设备树规范把硬件描述从内核代码中分离出来，使同一内核可以支持不同板卡[4]；Zephyr 的板级移植指南用 board.yml、.dts 与 Kconfig 把板级元数据、硬件描述与软件默认配置分开[5]；Yocto 项目则用层（layer）与配方（recipe）管理 BSP 与发行版的组合[28]。在异构多核场景中，OpenAMP 通过 remoteproc、RPMsg、VirtIO 与资源表（resource table）管理 Linux 与 RTOS/裸机核之间的生命周期和共享内存通信[6]。

这些工作提升了 BSP 的可复用性，但多数仍以“让板子跑起来”为目标。BSP 感知的边缘 AI 框架指出，工业边缘部署应把 BSP/OS 适配、运行时与加速、应用/推理、运维/验证放在同一系统中考虑[15]；这与本文的问题意识一致。本文与它的区别有三点：第一，本文把中间件作为独立一层，而不是把通信与调度隐含在运行时中；第二，本文用五类契约把层间假设显式化，并给出成熟度与契约债指标；第三，本文把运维/验证视为垂直平面，而不是与业务层并列的第五层，从而避免“运维只是部署后的事情”这一误解。

2.3 中间件、服务化与实时通信

中间件层负责把分布式组件连接起来，并提供调度、发现、类型系统与 QoS。DDS 以数据为中心的发布/订阅模型为核心，提供主题、键、QoS 策略、动态发现与去中心化数据空间[3]；ROS 2 在 DDS 之上构建节点、话题、服务、动作与执行器，成为机器人与自动驾驶软件的重要基础设施[1]。AUTOSAR 自适应平台面向高性能计算，定义基于 POSIX PSE51 的操作系统接口、执行管理与服务化通信，支持动态部署与面向服务的架构[2]。软件定义汽车（Software-Defined Vehicle，SDV）研究进一步把服务编排、虚拟化、确定性网络与车辆抽象层放在一起讨论[16]。

实时性方面，已有工作从不同角度揭示中间件的边界。San Vicente Gutiérrez 等人在 PREEMPT-RT Linux 上评测 ROS 2.0 通信，指出网络栈、中断线程与软中断会影响最坏时延[17]；Sobhani 等人对 ROS 2 多线程执行器给出响应时间分析，说明回调组、互斥与执行器结构会影响可调度性[18]；Betz 等人评估容器化 ROS 2 自动驾驶软件栈的端到端时延，说明部署形态本身也是系统变量[19]。这些工作为本文的 C4 契约提供了证据：时间语义必须跨层声明，不能只在应用层写一个 deadline。

与上述工作相比，本文不试图替代 DDS、ROS 2 或 AUTOSAR，而是给出一个“契约层”来描述它们与 BSP、应用之间的责任边界。换言之，本文的架构可以承载不同的中间件实现；它要求的是中间件必须把 QoS 映射、时钟域、失败语义和可观测性暴露出来，而不是把差异隐藏在默认配置里。

2.4 软硬件协同设计与异构加速

软硬件协同设计（Hardware/Software Co-Design）强调在系统设计早期同时考虑硬件架构、软件映射与性能约束。Chipyard 把可组合的 RISC-V SoC 生成、仿真与实现流程集成起来，使硬件设计意图可以贯穿仿真、现场可编程门阵列（Field-Programmable Gate Array，FPGA）与专用集成电路（Application-Specific Integrated Circuit，ASIC）流程[12]；MLIR 通过多层中间表示支持不同抽象层次的优化与转换，降低异构后端上的编译器构建成本[10]；TVM 把图级与算子级优化、调度与硬件后端分离，用自动调优获得跨平台性能可移植性[11]。在边缘侧，TinyML 综述讨论了在内存、时延与能耗约束下联合设计模型与硬件的方法[13]；认知边缘计算综述则把模型优化、系统架构与自适应智能放在统一框架中，覆盖端侧大模型与智能体部署[14]。

这些工作共同说明：硬件与软件之间的抽象不是免费的，抽象层次的选择直接决定了优化空间与可移植性。本文与它们的区别在于关注对象不同：协同设计工作通常关注“如何设计一颗芯片/一个编译器/一个模型”，本文关注“如何把一个已经存在的异构系统组织成可治理的四层，并使层间契约可检查”。本文不提出新的加速器或编译器，而是把加速器能力、模型运行时与 BSP 约束纳入同一契约体系；这使得第 3.6 节的时延分解可以覆盖从传感器到执行器的完整链路，而不仅是算子级性能。

2.5 功能安全、信息安全与生命周期

软硬一体系统往往同时受到功能安全、信息安全与可更新性的约束。ISO 26262 面向道路车辆功能安全，IEC 61508 面向通用电气/电子/可编程电子安全相关系统，DO-178C 面向机载软件；这些标准都要求需求可追溯、接口有定义、验证证据可审计[23][24][25]。信息安全方面，安全启动、可信执行环境、最小特权、签名更新与供应链安全是常见基线；SDV 安全综述系统梳理了空中更新（Over-the-Air，OTA）、车联万物（Vehicle-to-Everything，V2X）、应用程序编程接口（Application Programming Interface，API）、第三方软件与供应链风险，并指出混合关键性架构需要分层防御[20]。生命周期方面，A/B 分区、回滚、版本兼容矩阵与远程诊断是量产系统的基本能力[30][20]。

本文把这些要求视为垂直平面，而不是某一层的附属功能：功能安全平面要求每个安全目标都能追溯到至少一条契约；信息安全平面要求每条跨层通道都有身份、完整性与最小权限约束；可观测性平面要求关键路径上的事件可关联；生命周期平面要求契约版本、镜像版本与回滚策略一致。与仅讨论“安全启动”或“OTA 流程”的工作相比，本文强调的是安全与更新证据必须沿契约传播，否则认证材料与运行系统会脱节。

2.6 小结

技术流派	代表工作	主要贡献	与本文的差异
OS/HAL/微内核	HAL[21]、POSIX[22]	接口稳定、机制与策略分离	聚焦内核可移植性，不覆盖 BSP-中间件-应用治理
BSP/板级移植	设备树[4]、Zephyr[5]、Yocto[28]、OpenAMP[6]	硬件描述与板级配置解耦，异构核通信	以“点亮板卡”为目标，契约多为隐式
中间件/服务化	DDS[3]、ROS 2[1]、AUTOSAR AP[2]、SDV[16]	通信、QoS、服务发现、实时调度	关注层内能力，缺少跨层契约与成熟度评估
软硬件协同设计	Chipyard[12]、MLIR[10]、TVM[11]、TinyML[13]、边缘 AI[14]	硬件/编译器/模型协同优化	关注生成与优化，不关注整机层间责任边界
安全与生命周期	ISO 26262[23]、IEC 61508[24]、DO-178C[25]、SDV 安全[20]	安全论证、威胁建模、更新与回滚	将安全/更新作为独立流程，未与架构契约统一

3 Method

3.1 Problem Formulation

3.1.1 系统模型

本文把一个软硬一体系统表示为六元组

$$S=(H,B,M,A,\mathcal{C},\mathcal{V}),$$

其中 $H$、$B$、$M$、$A$ 分别表示硬件层、BSP 层、中间件层与应用层；$\mathcal{C}$ 是跨层契约集合；$\mathcal{V}$ 是垂直平面集合。各层进一步表示为

$$H=(R_H,{\Phi }_H),B=(F_B,D_B,O_B),M=(K_M,{\Sigma }_M,Q_M),A=(G_A,{\Pi }_A).$$

这里 $R_H$ 是硬件资源集合（计算单元、存储、互连、外设、传感器、执行器、电源域、时钟域、安全岛等），${\Phi }_H$ 是硬件能力描述（Hardware Capability Descriptor，HCD），用于声明“有什么能力、在什么条件下可用、错误如何表现”。$F_B$ 是固件与引导组件，$D_B$ 是设备发现与驱动集合，$O_B$ 是操作系统适配与资源管理策略。$K_M$ 是通信机制，${\Sigma }_M$ 是调度与服务发现机制，$Q_M$ 是 QoS 策略集合。$G_A$ 是应用任务图，${\Pi }_A$ 是应用策略（包括 AI 推理管线、控制律、业务规则与降级策略）。

层边界记为 ${\partial }_{\ell }$，其上承载接口集合 $I_{\ell }$。本文要求：任何跨边界的状态改变都必须经过一个已声明的接口，并受至少一条契约约束。 这条要求是后文故障隔离与可移植性分析的基础。

3.1.2 契约的形式化

本文把一条跨层契约定义为八元组

$$c=(p,q,I,{\mathcal{A}}_p,{\mathcal{G}}_p,\tau ,\varphi ,\nu ),$$

其中：

• $p$ 是提供方（provider），$q$ 是消费方（consumer）；
• $I$ 是接口签名与数据模式（包括类型、编码、方向与调用语义）；
• ${\mathcal{A}}_p$ 是提供方对运行环境与消费方行为的假设（assumptions）；
• ${\mathcal{G}}_p$ 是提供方对消费方的保证（guarantees）；
• $\tau$ 是时间语义（时钟域、周期、截止时间、抖动预算、排序保证）；
• $\varphi$ 是失败语义（fail-stop、fail-degraded、fail-safe、fail-operational、restart、ignore 等）；
• $\nu$ 是契约版本及其兼容性规则。

一条契约是良构的（well-formed），当且仅当满足以下五个条件：

1. 邻接性：$p$ 与 $q$ 位于相邻层，或其中一方属于垂直平面；禁止应用层直接与硬件层签订实现契约。
2. 蕴含性：在 ${\mathcal{A}}_p$ 成立时，${\mathcal{G}}_p$ 必须覆盖 $q$ 在 $I$ 上所需的最小保证；不得出现“提供方保证 A、消费方假设 B、而 A 不蕴含 B”的情况。
3. 时间可解释性：$\tau$ 必须声明时钟源、时间单位与时钟域转换规则；跨时钟域的契约必须给出同步误差上界。
4. 失败可判定性：$\varphi$ 必须给出可观测的失败条件与至少一个恢复或降级动作；不允许“未定义行为”。
5. 版本可兼容性：$\nu$ 必须遵循语义化版本规则，并声明向前/向后兼容窗口；破坏性变更必须提升主版本号。

在性能关键路径上，本文允许受控旁路（controlled bypass）：应用或中间件可以绕过常规调用链直接访问由 BSP 导出的缓冲区或寄存器窗口，但必须同时满足两个条件：第一，旁路使用的资源句柄由 BSP 通过 C2/C3 契约显式导出；第二，旁路路径必须注册 C4 时间预算与 C5 观测点。受控旁路不是“偷偷绕过”，而是“把绕过本身也变成契约”。

3.1.3 设计目标与约束

架构设计可以看作在候选配置集合 $\Pi$ 上求解一个多目标问题：

$$\underset{\pi \in \Pi }{\min }\mathbf{J}(\pi )=\left(T_{99}(\pi ),J(\pi ),E(\pi ),D_c(\pi ),R_p(\pi ),C_{\mathrm{ci}}(\pi )\right),$$

其中 $T_{99}$ 是端到端尾时延，$J$ 是抖动，$E$ 是每次任务或每次推理的能耗，$D_c$ 是契约债，$R_p$ 是可移植半径，$C_{\mathrm{ci}}$ 是契约检查与集成流水线的成本；$\mathrm{SIL}$ 表示安全完整性等级（Safety Integrity Level）。约束包括：

$$T_{99}(\pi )\le D,J(\pi )\le J_{\max },\mathrm{SIL}(\pi )\ge {\mathrm{SIL}}_{\mathrm{req}},\mathrm{Sec}(\pi )\ge {\mathrm{Sec}}_{\mathrm{base}},$$

$$\mathrm{Rollback}(\pi )\le R_{\max },\mathrm{Cost}(\pi )\le C_{\max }.$$

本文不把多目标压成单一分数，因为不同场景的权重差异很大：工业控制更看重 $T_{99}$ 与 $J$，消费电子更看重 $E$ 与成本，汽车域控制器则把功能安全与可更新性放在更前面。工程上应报告 Pareto 前沿，而不是只报告一个“综合分”。

3.1.4 符号表

符号	含义	单位或取值
$H,B,M,A$	硬件、BSP、中间件、应用四层	—
$\mathcal{C}$	跨层契约集合	—
$\mathcal{V}$	垂直平面集合	安全、安保、可观测性、生命周期
$c$	一条契约	八元组
$p,q$	契约提供方、消费方	层内组件
$\tau$	时间语义	时钟域、周期、截止时间、抖动
$\varphi$	失败语义	fail-stop / fail-degraded / fail-safe / fail-operational
$\nu$	契约版本	语义化版本
$T_{99}$	端到端 99 分位时延	ms
$J$	端到端抖动	ms
$E$	每次任务/推理能耗	J
$D_c$	契约债	$[0,1]$，越低越好
$R_p$	可移植半径	$[0,1]$，越低越易移植
$m_i$	第 $i$ 条契约的成熟度	$0,1,2,3,4$
$w_i$	第 $i$ 条契约的权重	${\sum }_i{w}_i=1$
$D$	任务截止时间	ms
$\pi$	一个架构配置	候选集合 $\Pi$ 的元素
$G_c$	契约依赖图	有向图

3.2 Framework Overview

3.2.1 四层与四类垂直平面

图 1 给出本文的参考架构。四层自下而上分别是硬件层、BSP 层、中间件层与应用层；每一层向上提供服务，向下提出约束。层间不是简单的“调用关系”，而是“契约关系”：上层声明需要什么时间语义、什么失败语义、什么可观测性；下层声明能提供什么能力、在什么条件下提供、失败时如何表现。

┌──────────────────────────────────────────────────────────────────────┐
│ 应用层 A                                                             │
│ 功能组件 · AI 推理管线 · 任务编排 · 人机交互 · 业务策略 · 降级逻辑   │
└───────────────────────────────┬──────────────────────────────────────┘
                                │ C3 数据/控制平面 · C4 时间/QoS · C5 可观测性
┌───────────────────────────────▼──────────────────────────────────────┐
│ 中间件层 M                                                           │
│ 通信(DDS/IPC/共享内存) · 调度/执行器 · 服务发现 · IDL · 时间同步     │
│ 资源管理 · 模型运行时 · 安全监控 · 降级编排                           │
└───────────────────────────────┬──────────────────────────────────────┘
                                │ C2 能力 · C3 数据/控制平面 · C4 时间/QoS · C5
┌───────────────────────────────▼──────────────────────────────────────┐
│ BSP 层 B                                                             │
│ 引导/固件 · 设备树/ACPI · 驱动 · HAL · OS 适配 · 电源/时钟/热        │
│ 看门狗 · 安全启动 · A/B 更新 · 资源表                                │
└───────────────────────────────┬──────────────────────────────────────┘
                                │ C1 启动/移交 · C2 能力 · C4 时间/QoS · C5
┌───────────────────────────────▼──────────────────────────────────────┐
│ 硬件层 H                                                             │
│ CPU/GPU/NPU/DSP/FPGA · SRAM/DRAM · NoC/PCIe/以太网/CAN · 传感器/执行器 │
│ 电源域/时钟域/热管理 · 安全岛 · 硬件信任根                            │
└──────────────────────────────────────────────────────────────────────┘

  垂直平面 V（贯穿四层）：
  ┌────────────┬────────────┬──────────────┬──────────────────────────┐
  │ 功能安全   │ 信息安全   │ 可观测性     │ 配置与生命周期           │
  │ 安全目标   │ 身份/完整  │ Trace/Metric │ 版本/兼容/OTA/回滚       │
  │ 失效响应   │ 最小权限   │ Log/Health   │ 配置基线/审计            │
  └────────────┴────────────┴──────────────┴──────────────────────────┘

图 1：软硬一体系统四层参考架构与四类垂直平面。 层间箭头表示契约边界，而不是简单的函数调用；垂直平面不拥有独立的数据通路，而是对每层施加约束并提供证据。

四类垂直平面的职责如下：

• 功能安全平面：把安全目标分解为各层的安全机制与失效响应，要求每条安全目标至少追溯到一条契约，并要求契约包含失败语义与验证证据。
• 信息安全平面：为每条跨层通道定义身份、完整性、机密性与最小权限；安全启动链、密钥管理、签名更新与可信执行环境在该平面内统一考虑。
• 可观测性平面：定义 trace、metric、log 与 health 的统一语义，使跨层事件可以关联到同一个任务或同一个数据帧。
• 配置与生命周期平面：管理硬件描述、BSP 配置、中间件 QoS、应用 manifest、模型版本与镜像版本，维护兼容矩阵、OTA 策略与回滚基线。

3.2.2 允许依赖与禁止依赖

本文把依赖关系分为三类：

1. 允许的相邻依赖：$A\to M$、$M\to B$、$B\to H$。箭头表示“上层使用下层通过契约暴露的能力”，不表示上层可以包含下层的实现头文件或直接访问寄存器。
2. 允许的垂直依赖：四类垂直平面可以读取各层的状态、注入检查点、记录证据；但垂直平面不得替代业务数据通路。
3. 受控旁路：在 C2/C3/C4 契约显式授权下，允许性能关键路径绕过中间件的常规序列化/拷贝路径；旁路必须被 C5 观测覆盖，并接受 C4 预算约束。

对应的禁止依赖包括：

• 应用层直接包含 BSP 头文件、直接映射寄存器或直接调用驱动 ioctl；
• 中间件绕过 BSP 直接解析设备树或直接操作直接内存访问（Direct Memory Access，DMA）描述符；
• BSP 中嵌入业务策略（例如“检测到某类目标就提高摄像头帧率”）；
• 垂直平面偷偷修改业务数据或绕过调度器提升优先级；
• 任何层使用未在 HCD 中声明的硬件能力。

这些禁止项不是风格问题，而是可移植性与故障隔离的前提。应用层一旦直接访问寄存器，硬件更换时就必须修改应用代码，3.6.2 节的可移植性命题不再成立。

3.2.3 参考部署形态

同一套四层架构可以映射到不同规模的系统。表 1 给出四种参考形态；它们不是互斥的产品分类，而是帮助读者判断“哪些契约必须显式化”的起点。表中 CPU、GPU、NPU、DSP、NoC、AMP、TSN 的全称依次为中央处理器、图形处理器、神经网络处理单元、数字信号处理器、片上网络、非对称多处理（Asymmetric Multi-Processing）与时间敏感网络（Time-Sensitive Networking）。

形态	典型硬件	软件组织	必须显式化的契约	主要风险
P-A：MCU 实时控制	单核/双核 MCU，SRAM，CAN/SPI/I2C	裸机或 RTOS，轻量中间件	C1、C2、C4	中断延迟、栈溢出、看门狗误复位
P-B：异构 AMP SoC	CPU + MCU/RTOS 核 + NPU/DSP，共享内存	Linux + RTOS，OpenAMP/RPMsg，共享内存	C1、C2、C3、C4	资源表不一致、缓存一致性、核间死锁
P-C：域控制器	多核 CPU + GPU/NPU，Hypervisor，TSN 以太网	多 guest OS，服务化中间件，容器	C2、C3、C4、C5	混合关键性干扰、优先级反转、版本漂移
P-D：云边协同	端侧 SoC + 边缘服务器 + 云	端侧运行时 + 边缘编排 + 云训练/更新	C2、C3、C5	模型版本不一致、网络分区、隐私泄漏

表 1：四种参考部署形态。 P-A 到 P-D 的复杂度递增；契约数量不必线性增加，但安全关键路径上的契约成熟度应随关键性提高。

3.3 Module Details

3.3.1 硬件层：暴露能力，不暴露策略

硬件层由计算、存储、互连、I/O、电源/时钟/热、安全与可靠性六类资源组成。计算资源包括通用 CPU、GPU、NPU、DSP、FPGA 与 MCU；存储资源包括片上静态随机存取存储器（Static Random-Access Memory，SRAM）、动态随机存取存储器（Dynamic Random-Access Memory，DRAM）、非易失存储与专用加速器缓冲；互连包括片上总线/NoC、PCIe、以太网、控制器局域网络（CAN）、SPI/I2C 等；I/O 包括摄像头、雷达、惯性测量单元（Inertial Measurement Unit，IMU）、麦克风、电机驱动与执行器；电源/时钟/热包括电压域、频率档位、热节流与低功耗状态；安全与可靠性包括安全岛、锁步核、纠错码（Error-Correcting Code，ECC）、硬件信任根与安全启动只读存储器（Read-Only Memory，ROM）。

硬件层对外输出的核心工件是 HCD。HCD 不是又一份寄存器手册，而是面向上层的能力声明，至少包含：

• 能力清单：某个加速器支持哪些算子/数据格式/精度，某个摄像头支持哪些分辨率/帧率/输出格式；
• 可用条件：能力在什么电源模式、时钟频率、温度范围、内存带宽下成立；
• 资源需求：需要哪些时钟、电源域、内存区间、DMA 通道与中断；
• 时间属性：启动延迟、首次推理延迟、稳态吞吐、最坏响应时间；
• 错误模型：ECC 错误、超时、总线错误、热节流、掉电等如何报告；
• 所有权：哪些资源在启动时由谁拥有，何时、以何种方式转移。

硬件层的设计原则是“暴露能力，不暴露策略”。硬件可以报告“当前温度下可持续的算力上限”，但不应该决定“应用是否应该降级”；后者属于应用或中间件的策略。硬件也不应该隐藏错误：错误必须通过可观测的错误模型上报，否则 BSP 无法把它转换成契约中的失败语义。

3.3.2 BSP 层：拥有硬件怪癖，不拥有业务策略

BSP 层是四层中最容易被低估的一层。它不只是“驱动集合”，而是把硬件能力转换成操作系统与中间件可以使用的一组稳定接口。本文把 BSP 的职责划分为五个子模块：

1. 引导与固件：从硬件信任根开始，经过一级引导、二级引导、引导加载器，最终移交到 OS/RTOS。每一步都要声明镜像完整性、回滚策略与移交状态。
2. 设备发现与描述：使用设备树、ACPI、资源表或厂商描述文件，把设备拓扑、资源区间、中断、时钟、电源域与能力标志暴露给 OS 与中间件[4][6]。
3. 驱动与 HAL：把外设寄存器操作封装为稳定接口；驱动内部可以处理硬件怪癖，但不得把怪癖泄漏为上层必须知道的隐式规则。Linux 的驱动模型与设备树绑定提供了可参考的实现方式[29]；Android 的 HAL/AIDL 则展示了用接口定义语言约束硬件抽象边界的做法[27]。
4. OS 适配：为 Linux、RTOS 或裸机提供调度钩子、内存映射、中断线程化、时间戳与电源管理接口；在 AMP 场景中还要管理核间中断、共享内存与资源生命周期[6]。
5. 可靠性与更新：看门狗、错误记录、A/B 分区、签名更新、恢复模式与诊断接口。

BSP 层的设计原则是“拥有硬件怪癖，不拥有业务策略”。例如，BSP 可以声明“该摄像头在 4K 模式下必须使用 2 个 DMA 通道，且首帧延迟增加”，但不应该决定“应用是否应该从 4K 降到 1080p”。BSP 还必须避免隐藏全局状态：所有跨层共享的资源都应有明确的所有者、生命周期与释放路径，否则 C3 契约无法成立。

3.3.3 中间件层：调解而不掩盖

中间件层把分布式组件连接起来，并在应用与 BSP 之间进行调解。本文把中间件职责划分为六个子模块：

1. 通信：DDS、共享内存、进程间通信（Inter-Process Communication，IPC）、TSN 以太网、CAN 网关等；通信机制可以多样，但必须向上暴露统一的 C3 数据/控制平面契约[3]。
2. 调度与执行器：线程池、回调组、优先级、CPU 亲和性、截止时间调度与降级执行；调度器必须理解 C4 的时间语义，而不是只理解线程优先级[18]。
3. 服务发现与类型系统：服务注册、发现、接口定义语言（Interface Definition Language，IDL）/schema、序列化与版本兼容；类型系统必须支持契约版本演进。
4. 时间同步：单调时钟、精确时间协议（Precision Time Protocol，PTP）硬件时钟、传感器时间戳与执行器触发时间；跨时钟域必须给出同步误差上界。
5. 资源管理：内存池、零拷贝缓冲区、加速器队列、DMA 通道与带宽配额；资源所有权必须与 C3 契约一致。
6. 模型运行时与安全监控：ONNX Runtime、TensorRT、TVM 等运行时负责把模型映射到 CPU/GPU/NPU；安全监控负责检测截止时间违约、数据陈旧、队列溢出与加速器错误，并触发降级[26]。

中间件层的设计原则是“调解而不掩盖”。中间件可以把 DDS 的 QoS 映射为线程优先级与网络队列，但不能让应用误以为“声明了 deadline 就一定有硬实时保证”；它必须把映射规则、可调度性假设与失败语义写入 C4。中间件也可以提供零拷贝路径，但必须把缓冲区所有权、释放责任与背压策略写入 C3。透明性在这里不是优点：隐藏的时间开销与隐藏的内存所有权，最终都会以尾部时延或难以复现的崩溃形式暴露出来。

3.3.4 应用层：声明意图，不声明寄存器

应用层由功能组件、AI 推理管线、任务编排、人机交互、业务策略与降级逻辑组成。应用层对下应该只声明“意图”：

• 我需要什么数据、什么精度、什么时间尺度；
• 我的任务图是什么、哪些任务是安全关键的、哪些可以降级；
• 我的模型需要哪些算子/数据布局/精度，失败时是否可以回退到小模型或规则；
• 我的输出需要什么执行器时序、什么安全包络；
• 我需要什么可观测性来定位问题。

应用层不应该声明“使用哪个 DMA 通道”“把寄存器 0x… 写成 0x…”“必须绑定到 CPU 2”。这些是实现细节，应由 BSP 与中间件根据 HCD、C4 与资源约束决定。应用层也不应该假设“模型一定能在 NPU 上运行”：它应该通过 C2/C3 询问能力，并在能力不足时执行已声明的回退路径。

3.3.5 层间职责表

层	核心职责	对外输出	禁止承担	典型标准/实现
硬件 H	提供计算、存储、互连、I/O、电源/时钟/安全能力	HCD、错误模型、时间属性	业务策略、调度策略	RISC-V/ARM 体系结构、PCIe、CAN、TSN
BSP B	引导、设备发现、驱动、OS 适配、电源/热、更新	C1/C2 工件、稳定驱动接口、错误码	业务逻辑、应用 QoS 决策	设备树[4]、ACPI[8]、UEFI[7]、Zephyr[5]、Yocto[28]、OpenAMP[6]
中间件 M	通信、调度、发现、IDL、时间同步、资源管理、模型运行时	C3/C4/C5 工件、统一 QoS 接口	直接操作硬件寄存器、隐藏时间开销	DDS[3]、ROS 2[1]、AUTOSAR AP[2]、ONNX Runtime[26]
应用 A	感知、决策、控制、业务逻辑、降级	任务图、数据 schema、QoS 需求	直接访问寄存器、包含 BSP 头文件	领域框架、AI 运行时、业务服务

表 2：四层职责、输出与禁止事项。 表中“典型标准/实现”仅用于举例，不代表本文要求系统必须采用某一实现。

3.4 Cross-Layer Contracts

本节给出五类契约。表 3 先给出总览，随后逐条说明关键字段、验证方法与常见反模式。

契约	连接	核心问题	关键字段	主要验证方法	典型失败模式
C1 启动与移交	H↔B↔M↔A	谁在什么状态下把控制权交给谁	阶段、镜像哈希、移交状态、资源所有权、超时、恢复动作	启动日志、哈希校验、故障注入	半初始化设备、回滚失败、看门狗误复位
C2 设备发现与能力	B↔M/A	有什么设备、能力在什么条件下可用	设备 ID、compatible、资源区间、能力标志、操作模式、依赖、错误模型	schema 校验、启动探测、能力自检	上层硬编码地址、能力假设失效
C3 数据与控制平面	B↔M↔A	数据如何表示、谁拥有缓冲区、如何背压	schema、编码、所有权、生命周期、背压、最大尺寸、时间戳源	静态兼容检查、运行时所有权检查、模糊测试	use-after-free、隐藏拷贝、无界队列
C4 时间与 QoS	A↔M↔B↔H	截止时间、抖动、优先级如何跨层映射	时钟域、周期、截止时间、抖动预算、优先级、亲和性、功耗模式、失败策略	可调度性分析、trace、截止时间监控	优先级反转、时钟漂移、QoS 错配
C5 可观测性与生命周期	全层	如何观测、如何升级、如何回滚	trace 上下文、指标、日志、健康状态、版本、兼容矩阵、回滚策略	trace 覆盖率、故障注入、升级演练	日志无上下文、版本漂移、回滚未测试

表 3：五类跨层契约总览。

3.4.1 C1 启动与移交契约

C1 描述“谁在什么状态下把控制权交给谁”。它至少覆盖：硬件信任根到一级引导、一级引导到二级引导、引导加载器到 OS/RTOS、BSP 到中间件、中间件到应用五个移交点。每个移交点必须声明：

• 当前阶段与下一阶段；
• 镜像的哈希/签名与校验结果；
• 移交时的 CPU 状态、内存映射、缓存一致性状态；
• 已初始化与未初始化的设备；
• 资源所有权（时钟、电源域、DMA、看门狗、共享内存）；
• 超时时间与失败恢复动作；
• 可观测的移交事件（供 C5 关联）。

C1 的常见反模式是“引导加载器把设备留在半初始化状态”。例如，引导阶段打开了某个电源域，但没有在移交时声明所有权，OS 启动后再次初始化同一电源域，导致设备复位或寄存器状态丢失。另一个反模式是“回滚路径未验证”：A/B 分区存在，但回滚镜像从未在真实硬件上启动过，更新失败时系统变砖。C1 要求回滚路径也纳入启动契约，并在出厂前进行故障注入演练。

3.4.2 C2 设备发现与能力契约

C2 描述“有什么设备、能力在什么条件下可用”。它把设备树/ACPI 的静态描述与 HCD 的动态能力结合起来，至少包含：

• 设备标识与 compatible 字符串；
• 资源区间（内存映射 I/O（Memory-Mapped I/O，MMIO）、I/O、中断、DMA、时钟、电源域）；
• 能力标志（支持的格式、精度、算子、分辨率、采样率）；
• 操作模式（性能模式、低功耗模式、热节流模式）；
• 依赖关系（某个设备依赖哪个时钟/电源/总线）；
• 错误模型与恢复动作；
• 能力探测接口（启动时自检、运行时查询）。

C2 的验证分为三层：构建期检查 schema 与资源冲突；启动期检查设备是否存在、资源是否可获取、能力自检是否通过；运行期检查能力是否因热节流、电源模式或固件错误而退化。常见反模式是“上层硬编码寄存器地址或设备路径”，以及“把能力当成永远可用”。前者破坏可移植性，后者在热节流或低功耗模式下导致难以复现的失败。

3.4.3 C3 数据与控制平面契约

C3 描述“数据如何表示、谁拥有缓冲区、如何背压”。它至少包含：

• 数据 schema（字段、类型、单位、坐标系、语义）；
• 编码与序列化（IDL、protobuf、FlatBuffers、共享内存布局）；
• 字节序、对齐与版本；
• 缓冲区所有权（生产者分配/消费者释放，或池化 + 引用计数）；
• 生命周期（何时可读、何时可写、何时释放）；
• 背压策略（丢弃最旧、阻塞、降采样、拒绝新请求）；
• 最大消息尺寸与队列深度；
• 时间戳源与时钟域；
• 错误与丢弃计数。

C3 的核心是所有权。零拷贝并非“没有成本”，而是把拷贝成本换成了所有权管理成本。本文建议使用显式所有权令牌：生产者写入完成后移交令牌，消费者读取完成后释放令牌；任何一方不得在未持有令牌时读写缓冲区。运行时监控可以检测“同一缓冲区被两个消费者同时写”“令牌未释放导致池耗尽”“消费者持有令牌超过生命周期”等违约。在虚拟化与异构多核场景中，VirtIO 的 virtqueue 提供了类似的所有权与通知机制[9]；OpenAMP 的 RPMsg 在其上构建核间通道[6]。常见反模式包括：隐藏拷贝（应用以为零拷贝，实际中间件复制了一次）、无界队列（短时过载导致内存耗尽）、以及跨进程共享指针（地址空间不同导致崩溃）。

3.4.4 C4 时间与 QoS 契约

C4 描述“截止时间、抖动、优先级如何跨层映射”。它是五类契约中最容易被写成“应用层一个 deadline 字段”的一类，也是尾时延问题的主要来源。C4 至少包含：

• 时钟域与同步方式（单调时钟、PTP 硬件时钟、传感器时间戳）；
• 周期/事件触发方式；
• 截止时间与抖动预算；
• 优先级、CPU 亲和性、调度类；
• 最坏执行时间（WCET）预算与测量方法；
• 功耗/频率模式与热约束；
• QoS 映射规则（应用 deadline → 中间件 QoS → BSP 调度/电源 → 硬件优先级）；
• 失败策略（超时后丢弃、降级、重启、切换冗余）。

表 4 给出一个 QoS 映射的例子。表中的数值仅用于说明映射结构，不代表任何实测平台参数。

应用语义	中间件 QoS	BSP 调度/电源	硬件行为	失败策略
控制回路 deadline = 10 ms	高优先级、可靠传输、队列深度 1	SCHED_FIFO、绑定隔离核、性能模式	中断亲和到同一核、低延迟定时器	超时切换安全控制律
感知帧 deadline = 33 ms	截止时间 QoS、丢弃最旧	普通实时优先级、性能模式	NPU 高优先级队列	复用上一帧 + 降分辨率
日志/遥测 best-effort	可靠但低优先级、批量	完全公平调度器（CFS）/低优先级、节能模式	共享 DMA	丢弃并计数
OTA 下载 best-effort	带宽受限、可暂停	低优先级、Wi-Fi 省电	网络协处理器	断点续传

表 4：C4 的 QoS 跨层映射示例（示例配置，非实测数据）。 映射必须是显式的、可审计的；应用不应假设“高优先级”会自动带来端到端时延保证。

C4 的验证需要三样东西：可调度性分析、运行时 trace、以及违约注入。可调度性分析给出“在假设成立时是否可调度”的静态结论；trace 给出“实际运行时 deadline 是否满足”的动态证据；违约注入验证“当假设不成立时，系统是否按契约降级”。三者缺一不可。常见反模式包括：优先级反转（中间件锁与 BSP 中断线程共享资源）、时钟漂移（传感器时间戳与执行器时钟不同源）、QoS 错配（应用要求可靠传输，中间件却使用 best-effort 传输）。

3.4.5 C5 可观测性与生命周期契约

C5 描述“如何观测、如何升级、如何回滚”。它至少包含：

• trace 上下文传播（任务 ID、帧 ID、请求 ID、模型版本、契约版本）；
• 指标（时延、抖动、队列深度、丢弃数、错误码、温度、频率、功耗）；
• 日志 schema（结构化字段、级别、采样率、脱敏规则）；
• 健康状态（starting、healthy、degraded、failed、recovering）；
• 版本信息（BSP、中间件、应用、模型、契约）；
• 兼容矩阵（哪些版本可以组合）；
• 更新策略（A/B、灰度、签名、回滚门限）；
• 审计与证据留存。

C5 的价值在于把“跨层问题”变成“可关联的事件”。例如，应用报告“推理超时”，C5 应该能够回答：是传感器帧迟到、BSP DMA 卡住、中间件队列溢出、NPU 热节流，还是模型版本不匹配？如果日志里只有一句“timeout”，就无法定位。C5 还要求更新路径可回滚：新版本必须在隔离分区试运行，通过健康门限后才提交；回滚镜像必须与旧版 BSP/契约兼容。常见反模式是“日志没有上下文”“版本号只存在于 Git 提交里”“回滚脚本从未演练”。

3.4.6 契约成熟度与契约债

契约写在文档里不等于有效。本文把契约成熟度分为五级：

等级	名称	证据形态	可检查性	典型成本
M0	隐式约定	工程师口头/代码习惯	不可检查	低（但风险高）
M1	文档化	设计文档、接口说明	人工评审	低-中
M2	机器可校验	schema、manifest、CI 规则	静态检查	中
M3	运行时强制	边界检查、QoS 执行、监控	运行时监控	中-高
M4	形式化/认证	模型检查、定理证明、认证证据	形式化验证/审计	高

表 5：契约成熟度模型。 并非所有契约都需要 M4；成熟度应与关键性匹配。

基于成熟度，本文定义契约债：

D c = ∑ i = 1 ∣ C ∣ w i ( 1 − m i 4 ) , ∑ i = 1 ∣ C ∣ w i = 1 , m i ∈ { 0 , 1 , 2 , 3 , 4 } . D_c = \sum_{i=1}^{|\mathcal{C}|} w_i \left(1 - \frac{m_i}{4}\right), \qquad \sum_{i=1}^{|\mathcal{C}|} w_i = 1, \quad m_i \in \{0,1,2,3,4\}. Dc​=i=1∑∣C∣​wi​(1−4mi​​),i=1∑∣C∣​wi​=1,mi​∈{0,1,2,3,4}.

$D_c\in [0,1]$，越低越好。该式假设成熟度等级近似等距；若团队认为 M3 到 M4 的跳跃远大于 M0 到 M1，可以用查表权重替代线性项。权重 $w_i$ 可以由安全关键性、调用频率、变更频率或故障影响面决定。契约债不是一个“精确的物理量”，而是一个管理工具：它迫使团队回答“哪些层间假设仍然是隐式的”“哪些假设一旦变化会导致系统失效”。本文建议：安全关键路径上的契约至少达到 M3；影响可移植性的契约至少达到 M2；仅影响诊断的契约可以先停留在 M1，但必须有明确的升级计划。

3.4.7 机器可读清单

为了让契约进入 CI，本文建议用 YAML/JSON 清单描述契约。下面是一个示例（示例配置，不代表任何实测平台参数）：

# 示例配置：仅用于说明字段结构，不代表实测参数
apiVersion: hwsw.example/v1
kind: CrossLayerContract
metadata:
  name: camera0-to-perception
  version: 1.3.0
spec:
  provider: bsp.camera0
  consumer: middleware.perception_input
  interface:
    type: shared_memory_frame
    schema: image/nv12
    width: 1920
    height: 1080
    fps: 30
  ownership:
    producer: bsp.camera0
    consumer: middleware.perception_input
    lifetime: consumer_release
    buffer_count: 4
  timing:
    clock: monotonic_raw
    period_ms: 33.3
    deadline_ms: 20
    jitter_budget_ms: 2
    timestamp_source: sensor_hw
  qos:
    priority: 80
    affinity: [2, 3]
    power_mode: performance
  failure:
    policy: fail_degraded
    fallback: last_good_frame
    max_stale_ms: 100
  observability:
    trace_context: true
    metrics:
      - frame_age_ms
      - drop_count
      - dma_latency_us

清单的作用不是“多写一份文档”，而是让以下检查可以自动化：

• schema 是否与消费方声明兼容；
• 缓冲区所有权是否形成闭环；
• 截止时间是否小于周期，抖动预算是否非负；
• 优先级/亲和性是否与 BSP 暴露的资源一致；
• 失败策略是否有可执行的 fallback；
• 契约版本是否与中间件/应用版本兼容；
• 安全关键路径是否达到所需成熟度。

3.5 Deployment and Runtime Workflow

3.5.1 构建期：先校验契约，再生成镜像

构建期的流程可以概括为：

需求/任务图
  → 选择平台与 HCD
  → 选择 BSP 配置（设备树/ACPI/资源表）
  → 选择中间件 QoS 与运行时
  → 生成应用 manifest
  → 契约静态检查（schema/所有权/时间/版本）
  → 可调度性分析与资源预算
  → 生成镜像、签名、记录 SBOM

图 2：构建期契约检查流程。 契约检查发生在镜像生成之前，目标是把跨层假设错误变成构建期错误。图中的 SBOM 指软件物料清单（Software Bill of Materials）。

关键点是契约检查前移。传统流程往往在集成测试阶段才发现“设备树节点名不对”“QoS 配错”“模型算子不支持”；契约优先流程把这些检查放到构建期，把问题从“运行时的偶发故障”变成“构建时的明确错误”。构建期还应生成一份“契约基线”（contract baseline），记录本次镜像使用的契约版本、成熟度与验证证据，供 C5 与审计使用。

3.5.2 启动期：按契约移交，而不是按经验移交

启动期的流程是：

硬件信任根
  → 一级引导（校验/度量）
  → 二级引导（DRAM/时钟/电源）
  → 引导加载器（镜像选择/A-B）
  → OS/RTOS（内核/驱动初始化）
  → BSP 自检（C2 能力探测）
  → 中间件初始化（C3/C4/C5）
  → 应用启动（健康检查）
  → 进入运行态或回滚

图 3：启动期移交流程。 每个箭头都是一个 C1 移交点，必须记录资源所有权与失败状态。

移交点必须记录“谁拥有什么资源、哪些设备已初始化、哪些错误已发生”。如果 BSP 自检失败，系统应按照 C1 的失败策略进入降级模式或回滚，而不是继续启动一个“看起来能跑”的系统。启动日志应带 trace 上下文，方便 C5 关联。

3.5.3 运行期：监控契约，而不是监控心跳

运行期的最小闭环是：

1. 调度：中间件按 C4 把任务分配到 CPU/加速器，BSP 按契约设置频率、电源域与中断亲和性。
2. 监控：C5 采集时延、抖动、队列深度、丢弃数、温度、频率、错误码；C2 监控能力退化（热节流、电源模式变化）。
3. 判定：当契约违约（截止时间错过、缓冲区池耗尽、能力不可用、版本不匹配）时，触发已声明的失败策略。
4. 降级/恢复：应用切换到备用模型/控制律，中间件降低帧率或丢弃非关键数据，BSP 调整电源/频率，必要时重启子系统。
5. 证据留存：把违约事件、相关 trace、版本信息写入黑匣子，供事后分析。

运行期监控不能只监控“进程是否活着”。一个进程可以心跳正常，但它的输出已经陈旧 500 ms；一个 NPU 可以“在线”，但已经因为热节流降频；一个 DDS 话题可以“有数据”，但队列里全是旧帧。C5 要求监控语义健康，而不仅是进程健康。

3.5.4 更新期：把回滚当作一等公民

更新期的流程是：

签名镜像/模型
  → 传输到备用分区
  → 校验签名与兼容矩阵
  → 隔离试运行（影子模式/灰度）
  → 健康门限判定（时延/精度/错误率/温度）
  → 提交或回滚
  → 更新契约基线与审计记录

图 4：更新与回滚流程。 更新必须同时校验镜像、模型、契约与兼容矩阵，回滚路径应与更新路径同等对待。

更新不只是“替换二进制”。它同时替换了 BSP 配置、中间件 QoS、模型权重、契约版本与安全策略。C5 的兼容矩阵必须回答：新模型能否在旧 BSP 上运行？新中间件是否仍支持旧应用的 QoS？新契约是否向后兼容？如果答案是否定的，更新应被拒绝，而不是“先上线再说”。回滚镜像必须与当前硬件、BSP 与契约兼容，并且回滚路径要在出厂前演练；Android A/B 更新是这一思路在消费级系统中的成熟实践[30]。

3.5.5 AI 模型部署链路

AI 模型部署是四层契约的一个典型试金石。一个端侧推理链路可以写成：

模型（算子/精度/输入布局）
  → 编译器（MLIR/TVM 等）[10][11]
  → 运行时（ONNX Runtime/TensorRT 等）[26]
  → 中间件（队列/调度/零拷贝）[3][1]
  → BSP（加速器驱动/内存/DMA/电源）[6]
  → 硬件（NPU/GPU/DSP）

图 5：端侧 AI 模型部署链路。 模型、编译器、运行时、中间件、BSP 与硬件之间的接口，应分别由 C2/C3/C4/C5 契约约束。

在这条链路中，C2 负责回答“加速器支持哪些算子/精度/布局”，C3 负责回答“输入输出缓冲区谁拥有、是否需要拷贝”，C4 负责回答“推理截止时间、批处理、优先级与功耗模式”，C5 负责回答“模型版本、运行时版本、精度误差与失败事件如何记录”。如果缺少这些契约，常见的失败包括：模型在 NPU 上回退到 CPU 导致时延超标；量化后的数值误差超出控制容限；零拷贝缓冲区被运行时提前释放；模型版本与 BSP 驱动不兼容。边缘 AI 综述与 BSP 感知框架都强调，这些问题不是单一模型优化能解决的，必须放在系统链路中治理[13][14][15]。

3.6 Complexity and Theoretical Properties

3.6.1 端到端时延分解

本文把从传感器采样到执行器动作的端到端时延分解为

$$
T_{\mathrm{e2e}}
= T_{s} + T_{b} + T_{m} + T_{a} + T_{\mathrm{act}}

• T_{q} + T_{\mathrm{clk}},
  $$

其中 $T_s$ 是传感器采样与曝光时间，$T_b$ 是 BSP 驱动/DMA/中断处理时间，$T_m$ 是中间件序列化、传输、排队与反序列化时间，$T_a$ 是应用计算时间（含 AI 推理），$T_{\mathrm{act}}$ 是执行器命令下发与机械响应时间，$T_q$ 是队列/阻塞时间，$T_{\mathrm{clk}}$ 是跨时钟域同步误差。最坏情况下，

$$
T_{\mathrm{e2e}}^{\mathrm{wc}}
= \sum_{\ell \in {s,b,m,a,\mathrm{act}}} T_{\ell}^{\mathrm{wc}}

• \sum_{q} B_q + \epsilon_{\mathrm{clk}},
  $$

其中 $B_q$ 是第 $q$ 个队列/资源的阻塞上界，${ϵ}_{\mathrm{clk}}$ 是时钟同步误差上界。抖动满足

$$J_{e2e}\le \sum _{\ell }{J}_{\ell }+\sum _q{J}_q+{ϵ}_{\mathrm{clk}}.$$

一个系统满足硬截止时间的一个充分条件是

$$T_{e2e}^{\mathrm{wc}}\le D\text{且}{J}_{e2e}\le J_{\max }$$

（证明见附录 E 的命题 3）。

这两个不等式看起来简单，但它们要求每一层都提供自己的最坏情况预算。传统分层图只写“应用 deadline = 10 ms”，没有写 BSP 中断延迟、DMA 完成时间、中间件队列阻塞与时钟误差，因此无法判断 10 ms 是否可达。C4 的作用就是把这些预算变成可加总的账本。

表 6 给出一个预算账本的模板。表中不填具体数值，避免把示例误认为实测结果。

预算项	符号	上界来源	数值	证据
传感器采样/曝光	$T_s^{wc}$	数据手册/实测		[TODO: 证据待补]
BSP 驱动/DMA/中断	$T_b^{wc}$	中断延迟测量/驱动分析		[TODO: 证据待补]
中间件传输/排队	$T_m^{wc}$	QoS/队列分析/trace		[TODO: 证据待补]
应用计算/推理	$T_a^{wc}$	WCET/推理基准		[TODO: 证据待补]
执行器响应	$T_{\mathrm{act}}^{wc}$	执行器手册/实测		[TODO: 证据待补]
时钟同步误差	${ϵ}_{\mathrm{clk}}$	PTP/时钟分析		[TODO: 证据待补]
合计	$T_{e2e}^{wc}$	求和		与 $D$ 比较

表 6：端到端时延预算账本模板。 每个预算项都必须有来源与证据；没有证据的预算只能视为假设，不能用于安全论证。

3.6.2 可移植性边界

本文用可移植半径描述“更换硬件时，需要改动多少契约面”：

$$R_p=\frac{|{\mathcal{C}}_B|}{|\mathcal{C}|},$$

其中 ${\mathcal{C}}_B\subseteq \mathcal{C}$ 是与 BSP/硬件直接相关的契约集合。$R_p$ 越小，硬件相关的契约面越窄，理论上越容易移植；但 $R_p$ 过小也可能意味着 HCD 暴露的能力不足，应用无法充分利用硬件。为此定义能力利用率：

$$U_h=\frac{|{\mathcal{C}}_{B,\mathrm{used}}|}{|{\mathcal{C}}_{B,\mathrm{available}}|},$$

其中 ${\mathcal{C}}_{B,\mathrm{used}}$ 是应用实际使用的 BSP 能力契约，${\mathcal{C}}_{B,\mathrm{available}}$ 是 HCD 声明可用的能力契约。好的架构应该在 $R_p$ 与 $U_h$ 之间取得平衡：既不让应用依赖过多硬件细节，也不让 BSP 把有用能力藏起来。

命题 1（功能可移植性）：若应用层代码只引用中间件契约符号、不包含 BSP/硬件符号，且中间件只通过 BSP 契约访问硬件，则更换硬件时，应用层代码无需修改；需要修改的范围被限制在 BSP 实现与 C2 配置内。

证明梗概：由依赖图的邻接性，应用层到硬件层的所有路径都必须经过 $M\to B\to H$ 的契约边；若应用层不引用 BSP/硬件符号，则不存在 $A\to H$ 或 $A\to B$ 的直接依赖。更换硬件只改变 $H$ 与 $B$ 的实现，以及 $B$ 对 $M$ 的契约实现；只要契约签名与语义不变，应用层无需改动。证毕。

需要强调：命题 1 只保证功能可移植性，不保证性能可移植性。更换硬件后，即使代码不变，$T_{99}$、$J$、$E$ 也可能变化；因此 C4 契约必须重新验证。把“能编译、能跑”当成“可移植”是工程上常见的误判。

3.6.3 故障隔离

本文把故障隔离定义为：层 $\ell$ 发生的故障不会在未触发已声明失败语义的情况下，静默改变另一层 ${\ell }^{\prime }$ 的状态。形式化地，若故障 $\varphi$ 发生在 $\ell$，且所有跨边界状态改变都经过带监控的契约，则要么 $\varphi$ 被限制在 $\ell$ 内，要么在边界上产生一个可观测的失败事件 $e\in \varphi$。

命题 2（契约中介下的故障遏制）：若每个层边界都有一个监控器，且所有跨层状态改变都经过至少一条良构契约，则任意单层故障最多导致其相邻层进入契约声明的失败状态，而不会静默传播到非相邻层。

证明梗概：对层数归纳。基础情况：硬件层故障由 BSP 的 C1/C2 监控器捕获，转换为错误码或失败状态。归纳步骤：假设第 $\ell$ 层故障已被限制在 $\ell$ 内或转换为契约失败事件；由于 $\ell$ 与 $\ell +1$ 之间状态改变必须经过契约，监控器会在边界上观察到违约并触发 $\varphi$，因此故障不会绕过 $\ell +1$ 静默传播。证毕。

命题 2 依赖两个强假设：监控器本身可信，且契约覆盖所有跨层状态改变。如果存在“受控旁路”但没有 C5 观测，或者监控器与被监控层共享同一故障域，故障仍可能传播。因此，安全关键系统应把监控器放在独立的安全岛或隔离域中，并对监控器本身做失效分析。

3.6.4 契约检查复杂度

设契约数量为 $n$，每条契约平均字段数为 $f$，契约依赖图的边数为 $e$。构建期静态检查的复杂度为 $O(nf)$；环检测与可达性分析的复杂度为 $O(n+e)$；版本兼容性检查在最坏情况下需要比较 $O(n^2)$ 对契约，但通过按接口分组可以降到接近线性。运行期监控的开销与监控事件数 $k$ 成正比；若采用采样，开销降为 $O(\alpha k)$，其中 $\alpha \in (0,1]$ 是采样率，但会降低违约检出率。

这意味着契约治理不是“零成本”的。本文的建议是按关键性分配检查预算：安全关键路径全量监控（$\alpha =1$），性能关键但非安全路径采用低开销计数器与阈值告警，best-effort 路径采用采样与离线分析。契约检查的成本应作为 $C_{\mathrm{ci}}$ 与 $E$ 的一部分纳入 3.1.3 节的多目标优化，而不是被当作“额外开销”忽略。

3.6.5 抽象开销的显式化

分层会引入抽象开销。本文定义

$$O_{\mathrm{abs}}=\frac{T_{\mathrm{layered}}-T_{\mathrm{monolithic}}}{T_{\mathrm{monolithic}}},$$

其中 $T_{\mathrm{layered}}$ 与 $T_{\mathrm{monolithic}}$ 分别表示同一功能在分层与单体实现下的端到端时延。$O_{\mathrm{abs}}$ 可能为正（序列化、边界检查、调度开销），也可能为负（分层带来的并行化、零拷贝、缓存友好布局）。本文不声称分层必然更快或更慢；本文的主张是：契约优先使 $O_{\mathrm{abs}}$ 的来源可见、可预算、可优化。如果一条路径的抽象开销不可解释，那么它就不是“架构成本”，而是“隐藏缺陷”。

4 Experiments

4.1 Experimental Setup

4.1.1 研究问题

本文把实证部分组织为四个研究问题：

• RQ1（集成效率）：与“有分层但无显式契约”的基线相比，契约优先架构是否降低跨层集成缺陷与移植工作量，同时不突破时延/能耗约束？
• RQ2（故障遏制）：五类契约中，哪几类对故障遏制与可诊断性贡献最大？契约成熟度从 M1 提升到 M3 是否带来可测的收益？
• RQ3（抽象开销）：机器可校验（M2）与运行时强制（M3）的契约检查，对尾时延、抖动、CPU/内存与能耗的代价是多少？零拷贝与受控旁路能否抵消这部分代价？
• RQ4（规模适应性）：同一套契约模型能否从 MCU（P-A）扩展到异构 SoC（P-B）与域控制器（P-C）？哪些契约需要裁剪，哪些必须保留？

4.1.2 平台

本文建议选择四类平台，覆盖从深嵌入式到云边协同的连续谱：

平台	硬件类别	软件组织	典型工作负载	重点观察
P1	单核/双核 MCU，SRAM，CAN/SPI/I2C	裸机或 RTOS，轻量中间件	电机控制、传感器采集	中断延迟、看门狗、栈/内存
P2	CPU + GPU/NPU + MCU 的异构 SoC，共享内存	Linux + RTOS AMP，OpenAMP[6]，DDS/IPC	视觉推理 + 实时控制	核间通信、零拷贝、缓存一致性
P3	多核 CPU + GPU/NPU，Hypervisor，TSN 以太网	多 guest OS，服务化中间件，容器	自动驾驶/机器人域控制	混合关键性、优先级反转、隔离
P4	端侧 SoC + 边缘服务器 + 云	端侧运行时 + 边缘编排 + 云更新	模型分发、联邦更新、远程诊断	版本一致性、网络分区、隐私

表 7：平台矩阵。 具体板卡型号、芯片版本、固件版本、内核版本与工具链版本在实验记录中登记；本文不预先填入未经核实的型号信息。[TODO: 平台型号与版本待补充]

4.1.3 工作负载

本文设计五类工作负载，分别压力测试不同的契约：

• W1 控制回路：周期性传感器采集 → 控制律 → 执行器输出，重点测试 C1/C4。建议设置多个周期档位（例如 1 ms、5 ms、10 ms），但具体档位需与目标平台能力匹配。
• W2 视觉推理管线：摄像头 → 预处理 → NPU/GPU 推理 → 后处理 → 规划/控制，重点测试 C2/C3/C4。模型可以选择公开的可复现模型；具体模型与精度在实验前预注册。
• W3 混合关键性：安全关键控制 + best-effort 日志/遥测 + OTA 下载同时运行，重点测试 C4/C5 与隔离。
• W4 故障注入：设备热插拔/移除、DMA 错误、时钟漂移、模型版本不匹配、网络分区、更新回滚失败，重点测试 C1/C2/C5 的失败语义。
• W5 移植任务：把同一应用从一块板卡迁移到另一块板卡，记录应用代码、BSP 配置、契约清单与测试用例的变更量，重点测试 C2 与可移植半径。

4.1.4 基线

为了区分“分层”与“契约”的贡献，本文设置五个基线：

基线	描述	分层	契约	目的
B0	单体固件/单进程应用	无	无	性能与资源占用的下界参考
B1	BSP + 应用两层	两层	隐式	传统板级开发
B2	BSP + 中间件 + 应用，接口临时约定	三层	M0/M1	“有分层但无契约”
B3	四层，契约文档化	四层	M1	文档化契约的收益
B4	四层，契约机器可校验 + 运行时强制	四层	M2/M3	本文主张的配置

表 8：基线设置。 B2 与 B3 的对比用于回答“写文档是否有用”；B3 与 B4 的对比用于回答“机器可校验/运行时强制是否值得”。

4.1.5 指标

本文把指标分为五组：时延、资源、可靠性、可维护性与可观测性。表 9 给出定义。

维度	指标	定义	方向
时延	$T_{99}$	端到端时延的 99 分位	越低越好
时延	$J$	端到端时延的标准差或 p99-p50 差值	越低越好
时延	DMR	截止时间错过率 $N_{\mathrm{miss}}/N_{\mathrm{total}}$	越低越好
资源	CPU 占用	稳态 CPU 利用率	越低越好
资源	内存占用	常驻内存 + 缓冲区池峰值	越低越好
资源	能耗	每次任务/每次推理的焦耳数	越低越好
可靠性	FCR	故障遏制率 $N_{\mathrm{contained}}/N_{\mathrm{injected}}$	越高越好
可靠性	MTTR	平均恢复时间	越低越好
可维护性	缺陷密度	每千行代码/每契约的集成缺陷数	越低越好
可维护性	移植杠杆	$\Delta {\mathrm{LOC}}_{\mathrm{app}}/\Delta {\mathrm{LOC}}_{\mathrm{BSP}}$	越低越好
可维护性	契约检查时间	CI 中契约校验的墙钟时间	越低越好
可观测性	覆盖率	有关键 trace 的关键路径比例	越高越好

表 9：指标定义。 MTTR 指平均恢复时间（Mean Time To Recovery）；“移植杠杆”越低，说明应用层改动相对于 BSP 改动越少，功能可移植性越好；它不衡量性能可移植性。

4.1.6 实现与统计方法

本文建议的实现包括：用 JSON Schema 描述契约清单；用 Python/Go 编写静态校验器；在 CI 中执行 schema 兼容、所有权闭环、时间预算与版本矩阵检查；在运行期用 trace（如 CTF/Perfetto 类工具）与硬件计数器采集时延、队列与频率；用可编程电源/功耗计采集能耗；用故障注入器模拟设备移除、DMA 错误、时钟漂移与版本不匹配。所有模型、数据集、随机种子、编译选项与内核配置都应记录在实验清单中。

统计方法应在实验前预注册：

• 每个配置至少重复 30 次独立运行；每次运行前有固定 warm-up；
• 报告 median、p95、p99 与 95% 置信区间；
• 对配对比较使用 Wilcoxon 符号秩检验或 bootstrap；对多重比较使用 Holm-Bonferroni 校正；
• 不事后选择“最好看”的阈值；效应量与最小可检出差异在实验前登记；
• 失败运行不删除，按“intention-to-treat”原则报告。

这些选择不能替代真实测量，但可以降低“用一次演示证明架构有效”的风险。

4.1.7 效度威胁

本文识别四类效度威胁。第一，平台效度：不同板卡的 BSP 质量差异很大，可能掩盖契约本身的效果；应至少选择两个厂商/两类 SoC。第二，工作负载效度：合成负载可能低估真实场景的抖动；应加入至少一个闭环真实应用。第三，实现效度：契约检查器的实现质量会影响开销；应开源校验器并固定版本。第四，统计效度：尾时延分布重尾，均值和标准差可能误导；应以分位数与置信区间为主。

4.2 Main Results

本节不报告实测数值。 截至本文写作时，跨平台实验尚未完成；任何填入表 10 的数字都将是编造。为避免把假设写成结论，本文只给出预注册的待检验假设与结果矩阵模板。

配置	$T_{99}$ (ms)	$J$ (ms)	DMR (%)	CPU (%)	内存 (MiB)	能耗 (J)	缺陷密度	移植杠杆	MTTR (min)
B0 单体	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]
B1 两层	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]
B2 三层临时接口	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]
B3 四层 M1	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]
B4 四层 M2/M3	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]

表 10：主结果矩阵（待填）。 每一格都必须来自可复现实验；在数据完成前，本文拒绝用估计值填充。

预注册的待检验假设如下：

• H1（集成效率）：在 W1/W2/W5 上，B4 的集成缺陷密度与移植杠杆低于 B2，且不低于 B3；代价是构建期契约检查时间增加。该假设若成立，说明“机器可校验契约”相对于“文档化契约”有额外收益。
• H2（故障遏制）：在 W4 上，B4 的故障遏制率高于 B2/B3，MTTR 低于 B2/B3；C1/C2/C5 的成熟度提升贡献最大。该假设若成立，说明契约的失败语义与可观测性比“接口签名”更重要。
• H3（抽象开销）：在 W1/W2 上，B4 的 $T_{99}$ 与 $J$ 相对 B0 的增加幅度可由 C4 预算解释；启用零拷贝/受控旁路后，增加幅度下降。该假设若成立，说明抽象开销是可管理的，而不是不可见的。
• H4（规模适应性）：P1 上可以裁剪 C3/C5 的部分字段，但 C1/C2/C4 必须保留；P3 上 C3/C5 不可裁剪。该假设若成立，说明契约集合应随关键性与部署形态缩放，而不是一刀切。

这些假设可能在实验后被证伪。本文保留证伪的空间：如果 B4 在某个平台上没有优势，或者契约检查开销超过收益，那么该平台应采用更轻量的契约子集，而不是强行套用完整模型。

4.3 Ablation Study

消融实验围绕“契约的哪个部分真正起作用”展开。表 11 给出消融矩阵模板。

消融项	变化	$T_{99}$	$J$	DMR	缺陷密度	MTTR	解释
契约成熟度	M1 → M2	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	静态检查的收益
契约成熟度	M2 → M3	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	运行时强制的收益/开销
契约粒度	粗（按层）→ 细（按接口）	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	粒度与维护成本
零拷贝	开/关	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	拷贝与所有权成本
受控旁路	开/关	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	旁路的收益与风险
C5 采样率	100% / 10% / 1%	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	可观测性开销
垂直平面	集成/分离	[TODO]	[TODO]	[TODO]	[TODO]	[TODO]	安全/安保/观测的耦合

表 11：消融矩阵（待填）。 消融的目的不是寻找“最高分”，而是找出每条契约的边际收益与边际成本。

4.4 Analysis

4.4.1 定性分析

在缺少实测数据的情况下，本文只做机制层面的定性分析，并把结论标为“待验证机制”，而不是“已观察结果”。

第一，契约优先把集成问题前移。传统开发中，BSP、中间件与应用往往由不同团队并行开发，接口假设停留在会议纪要与口头约定中；到了集成阶段，问题才以“设备打不开”“数据对不上”“时延超标”的形式出现。契约清单把这些假设变成构建期可检查的工件，理论上可以降低后期返工。但这也带来新的成本：团队必须学习 schema、维护版本、处理兼容性；如果契约工具链不好用，工程师会绕过它。因此，H1 是否成立，取决于工具链的易用性与组织约束，而不只取决于架构本身。

第二，失败语义比接口签名更能决定故障遏制。一个接口可以“签名正确”但“失败时行为未定义”，例如驱动返回 -EIO 后应用继续使用旧缓冲区。C1/C2/C5 要求每个失败都有可观测条件与恢复动作，这使故障从“静默传播”变成“显式降级”。但监控器本身可能成为单点：如果监控器与被监控层共享电源域、时钟或内存，故障仍可能同时击穿两者。因此，命题 2 的工程实现需要独立安全岛或隔离域。

第三，时间契约的价值在于“可加总”。应用层只写 deadline，无法判断端到端是否可达；C4 把 BSP 中断延迟、DMA 完成时间、中间件排队、应用 WCET 与时钟误差变成可加总的预算。即使某些预算暂时只能给出保守上界，它也能暴露“哪个环节没有证据”。这比一个看起来很精确、但没有来源的端到端数字更有价值。

4.4.2 效率分析

契约检查的成本可以分为三部分：构建期静态检查、运行期监控与组织维护。构建期成本随契约数量 $n$ 与字段数 $f$ 线性增长，通常可以接受；运行期成本取决于监控事件数与采样率，可能影响尾时延；组织维护成本最难量化，包括契约评审、版本升级、跨团队协商与文档同步。

本文的建议是“分级治理”：对安全关键路径，契约达到 M3/M4，监控全量；对性能关键路径，契约达到 M2，使用低开销计数器与阈值告警；对 best-effort 路径，契约达到 M1/M2，采用采样与离线分析。这样可以把有限的工程预算花在故障影响最大的边界上，而不是追求“所有契约都 M4”的形式主义。

4.4.3 失败案例

以下是设计层面常见的失败模式，而不是本文的实验结果：

• 契约漂移：实现改了，manifest 没改；CI 只能检查 schema，无法检查语义。缓解手段是把契约测试与实现代码放在同一仓库，并在代码评审中要求契约变更同步。
• 语义错配：提供方保证“最终送达”，消费方假设“按序送达”；两者签名兼容，但语义不兼容。缓解手段是把“顺序、去重、背压、失败”写入 C3，并用契约测试验证。
• 监控盲区：受控旁路没有 C5 观测，故障绕过监控器。缓解手段是把旁路注册为契约，并在旁路上放置轻量计数器。
• 优先级反转：中间件的锁与 BSP 的中断线程共享资源，导致高优先级任务被低优先级任务阻塞。缓解手段是把优先级继承/天花板协议写入 C4，并在 trace 中记录阻塞链。
• 模型/加速器不匹配：模型使用了 NPU 不支持的算子，运行时静默回退到 CPU，时延超标。缓解手段是 C2 能力查询 + 构建期算子检查 + 运行期回退告警。
• 更新不兼容：新模型需要新固件，但 OTA 只更新了模型分区。缓解手段是 C5 兼容矩阵与原子更新/回滚。

这些失败模式的共同点是：它们都不是“某一层写错了代码”，而是“两层之间的假设没有对齐”。 这正是契约优先要解决的问题。

4.5 Limitations

本文有五个明确局限。

第一，缺少实测数据。本文提出的是参考架构与分析框架，尚未完成跨平台测量；第 4.2 节的结果矩阵全部为待填占位符。任何关于性能、可靠性或可维护性的结论都应视为待验证假设，而不是已验证事实。

第二，契约开销可能不适合极小系统。在资源极度受限的 MCU 上，完整的 schema、版本矩阵与运行时监控可能超出 Flash/RAM 预算。本文建议 P-A 采用裁剪版契约（C1/C2/C4 为核心，C3/C5 简化），但裁剪后的有效性仍需实验验证。

第三，工具链与生态不成熟。设备树、DDS、AUTOSAR、ROS 2 各有自己的配置语言与版本规则；本文的 manifest 需要与这些生态对接，而不是另起一套。跨生态的 schema 映射、版本兼容与工具支持是后续工程化的主要障碍。

第四，安全认证不能只靠架构。ISO 26262、IEC 61508 与 DO-178C 要求需求追溯、验证证据、工具鉴定与过程审计；契约清单可以作为证据的一部分，但不能替代安全案例、测试覆盖与独立评估[23][24][25]。

第五，AI 模型引入非确定性。量化、算子融合、运行时调度与硬件加速都可能带来数值差异；C4/C5 可以记录版本与误差，但不能保证模型在分布外输入上的行为。对安全关键系统，仍需独立的安全监控、冗余与人工监督。

5 Discussion

5.1 为什么分层会失效

分层架构的失败通常不是因为“层数不够”，而是因为三种力量持续侵蚀边界。

第一，局部优化压力。性能团队发现绕过中间件可以降低几毫秒时延；BSP 团队发现为某个应用加一个私有 ioctl 可以快速交付；应用团队发现直接读寄存器可以避免等待驱动。每一次绕过在局部都是理性的，但累积起来会把分层图变成“历史遗迹”。契约优先的作用不是禁止绕过，而是让绕过的成本、责任与观测可见。

第二，信息不对称。上层不知道硬件的热节流曲线，下层不知道应用的 safety goal；中间件不知道模型的精度容限，模型不知道 BSP 的 DMA 对齐要求。契约是把这些信息从“某个人知道”变成“系统知道”的机制。没有契约，信息只能通过会议、邮件与口口相传传播，一旦人员变动就会丢失。

第三，契约债的复利。每一条未声明的假设都像一笔技术债：短期节省了文档与评审时间，长期在移植、升级、认证时以更高的成本偿还。契约债指标 $D_c$ 的意义不是追求零债，而是让团队看见债在哪里、利率有多高，并决定哪些债可以暂时保留。

5.2 适用边界

本文的架构不是“所有系统都必须四层”。适用边界可以按三个维度判断：

• 关键性：如果系统失效会导致人身伤害或重大财产损失，C1/C2/C4 必须显式化，且成熟度至少 M3；如果只是消费级信息娱乐，C3/C5 可以先做到 M1/M2。
• 异构性：如果系统只有一颗 MCU、一个固件，四层可能过重；两层或三层加轻量契约更合适。如果系统包含 CPU+GPU/NPU+RTOS 多核、多个操作系统与多种加速器，中间件层与 C3/C4 的价值会上升。
• 演进速度：如果硬件与模型几年不变，契约的边际收益较低；如果硬件每代更新、模型每月迭代、应用持续 OTA，契约的可移植性与版本治理价值会迅速上升。

因此，本文建议把四层架构视为“参考坐标系”，而不是“合规检查表”。团队可以根据关键性、异构性与演进速度选择契约子集与成熟度，但必须显式记录裁剪理由与风险。

5.3 安全、安保与伦理

功能安全：契约清单可以作为安全案例的证据索引：每个 safety goal 对应哪些契约、每条契约有哪些验证证据、失效时如何降级。但契约本身不是安全认证；它需要与危害分析、风险评估、独立验证与过程审计结合[23][24][25]。

信息安全：跨层契约同时是攻击面。每一条通道都需要身份、完整性、最小权限与审计；安全启动链、签名更新、可信执行环境与密钥管理应作为信息安全平面的一部分，而不是某一层的私有好东西[20][30]。尤其要注意“受控旁路”：它绕过了常规检查，如果缺少身份与权限约束，可能成为绕过安全策略的后门。

隐私：软硬一体系统常包含摄像头、麦克风、雷达与生物特征传感器。应用层应遵循数据最小化与端侧处理原则；中间件应支持脱敏与访问审计；BSP 应提供传感器关闭与硬件隔离能力。契约 C3 应声明数据用途、保留期与跨域传输规则，而不是只声明字段类型。

责任与可审计性：当 AI 模型更新导致行为变化时，系统需要回答“哪个版本、在什么契约下、由谁批准、如何回滚”。C5 的版本矩阵、审计日志与回滚策略是责任追溯的基础。没有这些证据，事故调查只能停留在“模型表现不佳”的层面。

5.4 对具身智能体系统的启示

本文的四层架构也可以映射到具身智能体（embodied agent）系统：

• 应用层对应智能体的策略、任务规划与工具调用逻辑；
• 中间件层对应工具运行时、记忆/上下文管理、调度与安全护栏；
• BSP 层对应“身体接口”：传感器/执行器抽象、运动控制、电源与安全限制；
• 硬件层对应机器人本体、算力平台与传感器套件。

在这个映射下，契约优先可以缓解智能体系统中的两类常见问题。第一类是“工具幻觉”：智能体调用了一个当前硬件/运行时并不支持的能力。C2 的能力契约可以把“可用工具、前置条件、失败语义”暴露给智能体，而不是让它在试错中猜测。第二类是“安全包络失守”：智能体规划了一个超出执行器能力或安全限制的动作。C4 与安全平面可以在中间件层强制执行包络，而不是完全依赖应用层的自我约束。

当然，智能体系统引入了新的不确定性：自然语言意图难以完全形式化，工具组合空间巨大，模型行为随版本变化。本文的契约模型不能解决所有问题，但它提供了一个可审计的骨架：哪些能力被声明、哪些假设被验证、哪些失败被记录。未来的工作可以把契约清单与大模型工具调用协议结合，让智能体在“可证明的能力边界”内行动，而不是在开放世界里盲目试探。

6 Conclusion

6.1 总结

本文把软硬一体系统的分层架构从“静态框图”重构为“可执行契约”。我们提出硬件、BSP、中间件、应用四层参考架构，以及启动与移交、设备发现与能力、数据与控制平面、时间与 QoS、可观测性与生命周期五类跨层契约；给出契约成熟度、契约债、可移植半径、端到端时延预算与故障隔离分析；并设计了从构建、启动、运行到更新的部署流程与可复现的评测协议。本文没有报告未经测量的实验数值；第 4 节的结果矩阵以待填占位符呈现，以避免把假设写成结论。

本文的核心结论不是“四层一定优于三层”，而是：当层间假设被写成可检查、可版本化、可运行时强制的契约时，分层才从“组织图”变成“工程约束”。 契约会增加前期成本，但它把隐式的跨层耦合变成了可见、可讨论、可优化的对象。

6.2 未来工作

未来工作可以从五个方向推进：

1. 开源契约 schema 与校验器：把本文的 YAML 清单变成 JSON Schema、CLI 与 CI 插件，并在真实项目中试用；收集工程师反馈，而不是只在论文中示例。
2. 完成跨平台实验：在 P1-P4 上执行第 4 节的预注册协议，填充主结果与消融矩阵；特别关注尾时延、故障遏制率与移植杠杆。
3. 形式化契约精化与兼容性：研究契约的精化关系（refinement）、版本兼容的可判定条件与跨时钟域时间语义；把命题 1/2 从工程论证提升为可机器检查的证明。
4. 与安全案例集成：把契约证据映射到 ISO 26262/IEC 61508/DO-178C 的安全案例结构，探索“契约即证据”的工具链。
5. AI 辅助契约提取与验证：利用大模型从代码、设备树、日志与设计文档中提取候选契约，再由人类评审与工具验证；重点解决“提取出的契约是否忠实”与“如何避免模型编造接口”的问题。

本文的长期目标是让软硬一体系统的架构评审像代码评审一样具体：每一条层间假设都有负责人、有版本、有测试、有失败语义；每一次硬件更换、模型升级与 OTA 都能沿着契约找到影响面。这比再画一张更漂亮的分层图更难，但也更有用。

References

说明：以下条目均为可公开访问的论文、标准或官方文档。本文不引用无法核实的作者、DOI、页码或机构；标准类条目以标准编号与官方页面为准。引用格式按出现顺序编号。

[1] S. Macenski, T. Foote, B. Gerkey, C. Lalancette, and W. Woodall. “Robot Operating System 2: Design, architecture, and uses in the wild.” Science Robotics, 7(66): eabm6074, 2022. DOI: 10.1126/scirobotics.abm6074.

[2] AUTOSAR. “Specification of Operating System Interface,” Adaptive Platform, R25-11. https://www.autosar.org/fileadmin/standards/R25-11/AP/AUTOSAR_AP_SWS_OperatingSystemInterface.pdf

[3] Object Management Group (OMG). “Data Distribution Service (DDS) Specification,” Version 1.4. https://www.omg.org/spec/DDS/1.4/

[4] Devicetree Specification, Version 0.4, June 2023. https://www.devicetree.org/specifications/

[5] Zephyr Project. “Board Porting Guide.” https://docs.zephyrproject.org/latest/hardware/porting/board_porting.html

[6] OpenAMP Project. “OpenAMP Documentation.” https://openamp.readthedocs.io/

[7] UEFI Forum. “UEFI Specifications.” https://uefi.org/specifications

[8] UEFI Forum. “ACPI Specifications.” https://uefi.org/specifications/ACPI

[9] OASIS. “Virtual I/O Device (VIRTIO) Specification.” https://www.oasis-open.org/committees/virtio/

[10] C. Lattner, M. Amini, U. Bondhugula, A. Cohen, A. Davis, J. Pienaar, R. Riddle, T. Shpeisman, N. Vasilache, and O. Zinenko. “MLIR: A Compiler Infrastructure for the End of Moore’s Law.” arXiv:2002.11054, 2020. DOI: 10.48550/arXiv.2002.11054.

[11] T. Chen, T. Moreau, Z. Jiang, L. Zheng, E. Yan, M. Cowan, H. Shen, L. Wang, Y. Hu, L. Ceze, C. Guestrin, and A. Krishnamurthy. “TVM: An Automated End-to-End Optimizing Compiler for Deep Learning.” In OSDI 2018, pp. 579–594; arXiv:1802.04799.

[12] A. Amid, D. Biancolin, A. Gonzalez, D. Grubb, S. Karandikar, H. Liew, A. Magyar, H. Mao, A. Ou, N. Pemberton, C. Schmidt, J. Wright, P. Rigge, J. Zhao, Y. S. Shao, K. Asanovic, and B. Nikolic. “Chipyard: Integrated Design, Simulation, and Implementation Framework for Custom SoCs.” IEEE Micro, 40(4): 10–21, 2020. DOI: 10.1109/MM.2020.2996616.

[13] L. Capogrosso, F. Cunico, D. S. Cheng, F. Fummi, and M. Cristani. “A Machine Learning-oriented Survey on Tiny Machine Learning.” arXiv:2309.11932, 2023.

[14] X. Wang, Q. Li, and W. Jia. “Cognitive Edge Computing: A Comprehensive Survey on Optimizing Large Models and AI Agents for Pervasive Deployment.” arXiv:2501.03265, 2025.

[15] Pitchai Muthu M. “Edge AI Deployment Beyond Models: A BSP-Aware Systems Framework for Industrial Embedded Platforms.” arXiv:2605.26119, 2026.

[16] P. V. Teixeira, D. Raposo, R. E. Lopes, and S. Sargento. “Deterministic and Reliable Software-Defined Vehicles: key building blocks, challenges, and vision.” arXiv:2407.17287, 2024.

[17] C. San Vicente Gutiérrez, L. Usategui San Juan, I. Zamalloa Ugarte, and V. Mayoral Vilches. “Towards a distributed and real-time framework for robots: Evaluation of ROS 2.0 communications for real-time robotic applications.” arXiv:1809.02595, 2018.

[18] H. Sobhani, H. Choi, and H. Kim. “Timing Analysis and Priority-driven Enhancements of ROS 2 Multi-threaded Executors.” arXiv:2408.08440, 2024.

[19] T. Betz, L. Wen, F. Pan, G. Kaljavesi, A. Zuepke, A. Bastoni, M. Caccamo, A. Knoll, and J. Betz. “A Containerized Microservice Architecture for a ROS 2 Autonomous Driving Software: An End-to-End Latency Evaluation.” arXiv:2404.12683, 2024.

[20] M. De Vincenzi, M. D. Pesé, C. Bodei, I. Matteucci, R. R. Brooks, M. Hasan, A. Saracino, M. Hamad, and S. Steinhorst. “Contextualizing Security and Privacy of Software-Defined Vehicles: A Literature Review and Industry Perspectives.” ACM Computing Surveys, 2025. DOI: 10.1145/3814955.

[21] S. Yoo and A. A. Jerraya. “Introduction to Hardware Abstraction Layers for SoC.” In Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE 2003), pp. 10336–10337, 2003.

[22] IEEE. “IEEE Std 1003.1-2017: Standard for Information Technology—Portable Operating System Interface (POSIX).” 2017; “IEEE Std 1003.13-2003: Standard for Information Technology—POSIX Realtime and Embedded Application Support (PSE51).” 2003.

[23] ISO. “ISO 26262:2018 — Road vehicles — Functional safety.” 2018.

[24] IEC. “IEC 61508 — Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems.” International Electrotechnical Commission.

[25] RTCA. “DO-178C — Software Considerations in Airborne Systems and Equipment Certification.” 2011.

[26] ONNX Runtime. “ONNX Runtime Documentation.” https://onnxruntime.ai/docs/

[27] Android Open Source Project. “HAL and AIDL.” https://source.android.com/docs/core/architecture/hal

[28] Yocto Project. “Yocto Project Documentation.” https://docs.yoctoproject.org/

[29] Linux Kernel. “Driver API.” https://www.kernel.org/doc/html/latest/driver-api/

[30] Android Open Source Project. “A/B (Seamless) System Updates.” https://source.android.com/docs/core/ota/ab

Appendix

A. 术语表

术语	英文	含义
BSP	Board Support Package	板级支持包，连接硬件与操作系统/中间件的板级软件集合
HAL	Hardware Abstraction Layer	硬件抽象层，把硬件相关操作封装为稳定接口
HCD	Hardware Capability Descriptor	硬件能力描述，声明能力、条件、资源、时间与错误模型
QoS	Quality of Service	服务质量，包括可靠性、截止时间、优先级、历史深度等
WCET	Worst-Case Execution Time	最坏执行时间
AMP	Asymmetric Multi-Processing	非对称多处理，不同核运行不同操作系统/运行时
TSN	Time-Sensitive Networking	时间敏感网络，提供确定性以太网通信
OTA	Over-the-Air	空中更新
SBOM	Software Bill of Materials	软件物料清单
契约债	Contract Debt	未声明或低成熟度层间假设的加权度量
可移植半径	Portability Radius	BSP/硬件相关契约面占全部契约面的比例

B. 契约清单的 JSON Schema 片段

以下片段只展示结构，不是完整 schema；完整版本应覆盖 C1-C5 的全部字段与条件约束。

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "CrossLayerContract",
  "type": "object",
  "required": ["apiVersion", "kind", "metadata", "spec"],
  "properties": {
    "apiVersion": { "type": "string" },
    "kind": { "const": "CrossLayerContract" },
    "metadata": {
      "type": "object",
      "required": ["name", "version"],
      "properties": {
        "name": { "type": "string" },
        "version": {
          "type": "string",
          "pattern": "^[0-9]+\\.[0-9]+\\.[0-9]+$"
        }
      }
    },
    "spec": {
      "type": "object",
      "required": ["provider", "consumer", "timing", "failure"],
      "properties": {
        "provider": { "type": "string" },
        "consumer": { "type": "string" },
        "timing": {
          "type": "object",
          "required": ["clock", "deadline_ms"],
          "properties": {
            "clock": { "type": "string" },
            "period_ms": { "type": "number", "exclusiveMinimum": 0 },
            "deadline_ms": { "type": "number", "exclusiveMinimum": 0 },
            "jitter_budget_ms": { "type": "number", "minimum": 0 }
          }
        },
        "failure": {
          "type": "object",
          "required": ["policy"],
          "properties": {
            "policy": {
              "enum": ["fail_stop", "fail_degraded", "fail_safe", "fail_operational", "restart"]
            },
            "fallback": { "type": "string" }
          }
        }
      }
    }
  }
}

C. 实验记录模板

run_id: "[TODO: 唯一运行 ID]"
date: "[TODO: YYYY-MM-DD]"
platform:
  board: "[TODO: 板卡型号]"
  soc: "[TODO: SoC 型号]"
  firmware: "[TODO: 固件版本]"
  kernel: "[TODO: 内核版本]"
  toolchain: "[TODO: 编译器/工具链版本]"
software:
  commit: "[TODO: Git commit]"
  middleware: "[TODO: 中间件版本]"
  runtime: "[TODO: 模型运行时版本]"
  model: "[TODO: 模型与哈希]"
contract_baseline: "[TODO: 契约版本/成熟度]"
workload: "[TODO: W1/W2/W3/W4/W5]"
config:
  period_ms: "[TODO]"
  deadline_ms: "[TODO]"
  zero_copy: "[TODO: on/off]"
  tracing_rate: "[TODO]"
  seed: "[TODO]"
metrics:
  t99_ms: "[TODO]"
  jitter_ms: "[TODO]"
  dmr: "[TODO]"
  cpu_pct: "[TODO]"
  mem_mib: "[TODO]"
  energy_j: "[TODO]"
artifacts:
  trace: "[TODO: 路径/哈希]"
  logs: "[TODO: 路径/哈希]"
  notes: "[TODO: 异常与排除说明]"

D. 架构评审检查清单

1. 每一层是否只暴露 HCD/契约中声明的能力？
2. 每个跨层共享资源是否在任意时刻有且仅有一个所有者？
3. 每条契约是否声明了时钟域、截止时间与抖动预算？
4. 每条契约是否声明了失败语义、可观测条件与恢复动作？
5. 契约版本是否遵循语义化版本，破坏性变更是否有迁移计划？
6. 每个安全目标是否至少追溯到一条契约与一份验证证据？
7. 受控旁路是否注册、是否有权限约束、是否被 C5 观测覆盖？
8. 更新与回滚路径是否在真实硬件上演练通过？
9. 模型、运行时、BSP 与契约版本是否在兼容矩阵中？
10. 契约债是否被测量、排序并纳入迭代计划？

E. 命题证明补充

命题 1 的证明（展开）：设应用层节点集合为 $V_A$，中间件节点集合为 $V_M$，BSP 节点集合为 $V_B$，硬件节点集合为 $V_H$。由 3.2.2 节的允许依赖，跨层边只可能是 $V_A\to V_M$、$V_M\to V_B$、$V_B\to V_H$。若应用代码不引用 BSP/硬件符号，则不存在 $V_A\to V_B$ 或 $V_A\to V_H$ 的边。更换硬件只改变 $V_H$ 与 $V_B$ 的实现以及 $V_B\to V_M$ 的契约实现；只要契约签名与语义不变，$V_A$ 及其出边不变。因此应用层代码无需修改。证毕。

命题 2 的证明（展开）：对层数 $k$ 归纳。$k=1$（硬件层）时，硬件故障由 BSP 的 C1/C2 监控器捕获，转换为错误码或失败状态。假设第 $k$ 层故障已被限制在该层内，或已转换为契约失败事件；考虑第 $k+1$ 层。由于第 $k$ 层与第 $k+1$ 层之间的所有状态改变都必须经过良构契约，且边界监控器会检查契约的前置条件、时间语义与失败语义，故障若试图跨层传播，必然触发一个已声明的失败事件。因此故障最多使第 $k+1$ 层进入契约声明的失败状态，不会静默传播到第 $k+2$ 层。证毕。

命题 3（截止时间充分条件）：若 3.6.1 节的最坏情况预算满足 $T_{e2e}^{\mathrm{wc}}\le D$ 且 $J_{e2e}\le J_{\max }$，则在该预算模型覆盖所有实际执行路径的前提下，任务满足硬截止时间与抖动约束。

证明：由 $T_{e2e}^{\mathrm{wc}}$ 的定义，它是所有实际端到端时延的上界；若上界不超过 $D$，则任意实际时延不超过 $D$。抖动同理。证毕。需要强调，这个命题是充分条件，不是必要条件；保守的预算可能导致“实际可调度但分析判为不可调度”，工程上应通过测量与更精细的分析收紧预算。

F. 研究伦理与可复现性声明

本文不涉及人类受试者、动物实验或个人数据；所有引用均来自公开论文、标准或官方文档。本文不报告未经测量的实验数值，第 4 节的结果矩阵以待填占位符呈现；任何后续实验应遵循预注册协议，并公开平台配置、随机种子、原始 trace 与失败运行记录。本文的契约 schema、校验器与实验脚本计划开源；在仓库链接与版本号确认前，以 [TODO: 代码与数据链接待补充] 标注。