35 KiB
面向边侧异构SoC的混合实时控制基础系统研究综述
摘要
随着边缘人工智能从“离线感知”走向“在线决策”，边侧系统需要在同一异构SoC上同时承载硬实时控制、深度学习推理、设备管理、网络通信和人机交互等差异显著的工作负载。传统单一操作系统难以同时满足确定性、算力利用率、软件生态和故障隔离要求，Linux、实时操作系统（RTOS）、静态分区Hypervisor以及非对称多处理（AMP）相结合的混合系统因而成为重要技术路线。本文围绕边侧异构SoC上的混合实时控制基础系统，对实时Linux、双内核、AMP、静态分区虚拟化、共享资源干扰治理、GPU/NPU可预测执行、跨域通信以及安全降级等研究进行结构化综述。已有研究表明，处理器核、内存和设备的静态划分能够降低软件域之间的直接干扰，但共享末级缓存、内存控制器、DMA、片上互连、加速器驱动以及功耗热约束仍会形成难以忽略的跨域耦合；同时，平均推理速度、虚拟机切换开销和通信吞吐量均不能单独证明端到端实时性。本文据此提出“控制响应时间—AI结果新鲜度—资源干扰预算—故障恢复语义”四维分析框架，并给出适用于本课题的系统分工、评价指标和实验路线。综述认为，下一阶段的关键不在于简单选择Linux、RTOS或某一种Hypervisor，而在于形成可测量、可配置、可复现且可审查的系统级实时边界，使AI域失效、过载或超时时，控制域仍能维持安全状态。
关键词： 边缘人工智能；异构SoC；混合关键系统；实时操作系统；静态分区Hypervisor；共享资源干扰；NPU；安全降级
1 引言
边侧智能控制系统正从“传感器采集—云端分析”转向“本地感知—本地推理—本地闭环”。典型平台往往在单芯片中集成多核CPU、GPU、NPU、DSP、共享内存控制器、DMA和高速外设。一方面，Linux能够提供完整的AI运行时、设备驱动、网络协议栈和应用生态；另一方面，电机控制、运动控制、制动、保护和看门狗等任务要求低抖动、可分析的最坏响应时间及明确的故障处置责任。两类需求叠加后，系统设计问题从“模型是否足够快”扩展为“整个控制链在竞争、过载和故障条件下是否仍满足边界”。
Vestal提出的混合关键度任务模型揭示了同一计算平台上不同保证等级工作负载共存的基本矛盾[1]；后续综述表明，混合关键系统研究已经从处理器调度扩展到内存、I/O、通信、虚拟化和认证证据[2]。在边侧AI场景中，这一矛盾进一步表现为：AI任务通常具有高吞吐、突发性和运行时不透明等特征，而控制任务强调周期性、优先级、截止期和故障可控。因此，本文不把“Linux+RTOS”视为天然实时的答案，而是考察操作系统分工、虚拟化隔离、共享资源治理、跨域数据语义和安全降级如何共同构成实时保证。
本文的主要目的有三点：
- 梳理边侧异构SoC混合实时系统的主要技术形态及其适用边界；
- 总结影响端到端确定性的关键干扰源、测量方法和治理机制；
- 将已有研究转化为子课题B可执行的体系结构、实验问题和评价指标。
2 综述范围与方法
2.1 研究范围
本文关注部署在边侧异构SoC上的本地闭环系统，主要覆盖以下对象：
- 实时Linux、双内核和协内核机制；
- Linux与RTOS并行运行的AMP系统；
- 静态分区Hypervisor、分离内核和微内核虚拟化；
- 多核共享缓存、DRAM、DMA、片上互连和加速器竞争；
- GPU/NPU推理的调度、抢占、可观测性和时延分析；
- 跨域共享内存、消息通道、时钟与状态同步；
- AI失效、超时和异常条件下的监测、隔离、降级与恢复。
本文不重点讨论云端训练、纯服务器推理、仅含单片机且没有多操作系统共存的系统，也不把平均帧率提升作为实时性研究的充分证据。
2.2 文献选择与证据使用
本文采用结构化叙述综述方法，检索和分析截至2026年9月公开的代表性研究论文、国际标准和项目官方资料。材料选择遵循以下原则：
- 优先采用原始论文、标准正文入口和项目官方文档；
- 同时覆盖体系结构、调度与资源干扰、跨域通信、安全与评价方法；
- 对尚缺乏开放实现或可复现实验的数据，仅作为研究趋势，不作为确定结论；
- 对厂商或项目自述的能力，明确视为工程资料，而不等同于独立实验验证。
本文属于面向课题设计的结构化综述，不宣称穷尽全部文献，也不进行统计意义上的Meta分析。
3 核心概念与分析框架
3.1 混合实时控制系统的基本对象
本文所称“混合实时控制基础系统”，是指在同一边侧SoC上，以两个或多个执行域共同承载控制与智能任务的系统。典型职责划分如下：
| 执行域 | 典型职责 | 主要保证目标 |
|---|---|---|
| RTOS/安全域 | 传感采集、控制律、执行器输出、联锁、看门狗、降级控制 | 截止期、低抖动、故障可控 |
| Linux/智能域 | AI推理、模型管理、复杂协议、日志、可视化、OTA | 算力与生态、功能完整性 |
| Hypervisor/分离层 | 核、内存、设备、中断与通信通道划分 | 空间隔离、故障约束、启动与生命周期管理 |
| GPU/NPU/DSP域 | 神经网络或信号处理加速 | 有界排队、可观测执行、资源预算 |
这里的“混合”不是简单并存，而是要求各执行域之间存在明确的资源所有权、数据契约、时间边界和故障处置规则。
3.2 端到端实时边界
单独测量控制线程周期或模型推理时间会遗漏大量系统开销。对一次“采集—推理—决策—执行”链路，可采用下式描述端到端时延：
[ L_{e2e}=L_{sense}+L_{input}+L_{queue}+L_{infer}+L_{ipc}+L_{validate}+L_{actuate} ]
其中，输入搬运、队列等待、跨域通信和结果校验都可能形成长尾。对高关键控制任务，其响应时间可进一步分解为：
[ R_c=C_c+B_{os}+B_{hv}+I_{cpu}+I_{cache}+I_{dram}+I_{dma}+I_{irq}+I_{thermal} ]
式中，(C_c)为任务自身执行时间，(B_{os})和(B_{hv})分别为操作系统与虚拟化阻塞，(I_*)表示核、缓存、内存、DMA、中断和热降频等干扰。该分解并非假定各项严格独立，而是用于建立可测量的干扰清单和预算归属。
AI结果的有效性还应同时满足时间和内容条件：
[ Valid(y)=Fresh(y)\land Integrity(y)\land Confidence(y)\land VersionMatch(y) ]
即结果必须未超过新鲜度窗口、数据完整、置信度满足策略且模型与协议版本匹配。由此可见，AI推理完成并不等于控制系统可以使用该结果。
4 系统形态及其适用边界
4.1 单Linux与PREEMPT_RT
PREEMPT_RT通过可抢占内核、优先级继承锁和线程化中断等机制缩短Linux中的不可抢占区间[3]。这一方案保留了完整Linux生态，开发与部署成本较低，适合关键度中等、外设和AI软件栈复杂的系统。然而，它主要改善调度延迟，并不自动消除设备驱动长临界区、内存带宽竞争、GPU/NPU运行时阻塞、SMI等固件活动以及应用级故障。因此，“启用PREEMPT_RT并测得较低平均延迟”不能直接推出硬实时保证。
4.2 双内核或协内核
Xenomai Cobalt等双内核方案在Linux旁建立更高优先级的实时执行环境，使实时活动能够优先于普通Linux路径[4]。相较单Linux，该方案可以减小Linux负载对实时线程的直接影响，同时仍利用Linux驱动和应用生态。其代价是内核适配、系统调用迁移、调试链和版本维护复杂度增加；更重要的是，双内核仍共享缓存、DRAM和部分设备，不能仅依靠中断优先级解决片上共享资源干扰。
4.3 AMP：Linux与RTOS并行运行
AMP通常把不同CPU核交给Linux和RTOS独立管理，并通过共享内存和核间中断通信。OpenAMP及Linux remoteproc/RPMsg为远端处理器生命周期和消息通道提供了通用框架[5][6]。AMP结构适用于SoC已经包含应用核与实时核、设备所有权较易静态划分的场景。其优势是RTOS可以独立掌握控制循环和执行器；其局限在于启动顺序、共享内存一致性、地址映射、设备复位、故障传播和跨域优先级等通常依赖平台实现，系统级证据容易碎片化。
4.4 静态分区Hypervisor
静态分区Hypervisor在启动阶段把CPU核、内存区域和设备分配给各客体，运行期尽量避免复杂的动态资源复用。Jailhouse采用Linux先启动、随后建立隔离单元的工程路径[7]；Bao强调面向嵌入式多核平台的轻量静态分区[8]；Xen Dom0-less、ACRN等也提供面向嵌入式或工业场景的不同部署模式[9][10]。静态分区减少了动态调度与频繁VM退出，便于构造较清晰的资源所有权。
但静态分区并非“物理隔离”的同义词。即使CPU核、内存页和设备已划分，不同分区仍可能共享末级缓存、内存控制器、片上互连、电源域和热设计功耗。Martins和Pinto对多种Arm静态分区Hypervisor的系统比较也说明，应同时评估中断延迟、通信、启动、代码规模和共享资源影响，而不能只比较虚拟化微基准开销[11]。
4.5 分离内核与高保证微内核
seL4等微内核通过能力机制和形式化验证强化空间隔离与内核正确性证据[12]。这类方案适合对可信计算基和认证证据要求较高的场景。不过，经过验证的内核并不意味着设备驱动、Hypervisor配置、硬件实现、AI运行时和应用任务的最坏执行时间也已经得到验证。因此，高保证内核应被视为证据链的一部分，而不是完整系统安全与实时性的替代品。
4.6 形态比较
| 形态 | 实时隔离潜力 | Linux生态 | 跨域协同成本 | 主要风险 | 适用场景 |
|---|---|---|---|---|---|
| Linux + PREEMPT_RT | 中 | 高 | 低 | 内核、驱动与共享资源长尾 | 单域、中等关键度、快速产品化 |
| 双内核/协内核 | 中至高 | 较高 | 中 | 内核适配与共享硬件干扰 | 需要强实时线程但仍依赖Linux |
| AMP（Linux+RTOS） | 高 | 高 | 中至高 | 生命周期、共享内存与故障传播 | 应用核/实时核天然分离的SoC |
| 静态分区Hypervisor | 高 | 高 | 高 | 共享微体系结构资源与设备复位 | 多核SoC、关键域与智能域共存 |
| 分离内核/高保证微内核 | 高 | 中 | 高 | 驱动生态、系统集成与验证成本 | 高可信、高认证要求系统 |
选择依据不应是“哪一种架构更先进”，而应是其能否满足具体设备所有权、截止期、AI软件栈、故障模型和认证目标。
5 共享资源干扰与确定性治理
5.1 干扰来源
边侧SoC上的干扰具有跨层特征：
- CPU与调度： 核超售、优先级反转、不可抢占区、中断风暴；
- 缓存与一致性： 末级缓存替换、缓存行争用、跨核一致性流量；
- DRAM与互连： 内存控制器队列、行缓冲冲突、bank冲突、总线仲裁；
- DMA与I/O： 摄像头、网络、存储和NPU的大块传输挤占带宽；
- 加速器： 驱动队列、命令提交、不可抢占内核、上下文切换；
- 功耗与温度： DVFS、热降频和共享电源预算导致执行时间漂移；
- 固件与管理域： 安全监控、系统管理中断和不可见固件活动。
其中，CPU核独占只能消除部分调度竞争，无法消除共享缓存、DRAM、DMA和温度耦合。
5.2 缓存与内存治理
MemGuard通过按核带宽监管降低内存带宽争用，并为实时任务提供可控的内存预算[13]；PALLOC利用页着色和DRAM bank感知分配改善内存资源隔离[14]；面向多核并行任务的研究进一步表明，干扰上界需要考虑请求并行性，而不能把每次访存阻塞简单相加[15]。RT-Gang则通过限制高关键并行任务并发、控制内存带宽等方法降低与其他任务之间的不可预测干扰[16]。
这些工作共同说明，资源隔离需要“空间划分+时间监管+运行时监测”协同：
- 空间划分用于核、内存区域、缓存路和设备所有权；
- 时间监管用于内存带宽、DMA窗口和加速器服务配额；
- 运行时监测用于发现预算超限、热降频和异常排队；
- 超限后的处置必须预先定义，不能只记录日志而继续无界运行。
5.3 从资源指标到控制指标
内存带宽、缓存未命中率和DMA吞吐是解释变量，而不是最终验收指标。研究应建立以下因果链：
资源竞争强度 → 控制任务响应时间变化 → 截止期违约 → 控制品质或安全状态变化。
因此，资源治理机制必须同时报告其对控制抖动、最大响应时间、AI新鲜度和业务吞吐的影响，避免以牺牲AI功能到不可用为代价获得表面上的实时改善。
6 GPU/NPU推理的可预测执行
6.1 主要困难
GPU/NPU的峰值算力不能代表其实时能力。边侧AI加速器常见的不确定性包括：
- 驱动和固件内部排队策略不可见；
- 多模型或多进程共享时缺少明确优先级；
- 神经网络算子或命令批次难以中途抢占；
- CPU预处理、内存复制和后处理未计入“推理时间”；
- 统一内存减少显式复制，但可能增加缓存一致性和带宽竞争；
- 温控、功耗封顶和动态频率改变长时间运行结果。
6.2 代表性调度研究
GPUart探索了嵌入式GPU上的受限抢占和面向应用的实时调度[17]；GPU server将GPU请求集中到服务任务中，以改善共享GPU时的优先级管理和分析性[18]；GCAPS进一步从GPU上下文与优先级角度研究多核实时任务的加速器调度[19]。RT-Gang等工作也把DNN工作负载纳入共享资源干扰实验[16]。这些成果证明，加速器实时化需要调度协议、驱动机制和可分析模型共同支持，而不是仅在应用层设置线程优先级。
现有GPU研究相对丰富，而NPU通常具有更封闭的编译器、运行时和固件接口。在缺乏公开抢占机制和执行模型时，本课题应采用“黑盒可测、边界可控”的工程策略：固定模型与编译产物，冻结驱动和固件版本，测量提交、排队、执行和完成通知的独立时间戳，并通过准入控制限制并发模型、输入频率和队列深度。
6.3 AI结果新鲜度优先于平均吞吐
控制系统对AI输出的核心约束通常不是每秒帧数，而是：
- 最迟何时得到结果；
- 结果对应哪一帧、哪一时刻和哪一模型版本；
- 超时后旧结果是否会被误用；
- 连续多少次无有效结果后必须降级；
- 恢复后需要满足什么条件才能重新参与控制。
因此，建议同时记录平均值、P99/P99.9、观测最大值、截止期违约率和连续违约长度，并强调：有限测试中的“零违约”只是实验观察，不是数学意义上的最坏情况证明。
7 跨域通信与协同协议
7.1 通信机制
Linux与RTOS之间常采用共享内存环形队列、核间中断、RPMsg、虚拟串口或虚拟网络。共享内存可以降低复制开销，但其确定性仍取决于缓存维护、内存屏障、接收端调度和队列策略。Dong等提出的混合双操作系统实时通信机制表明，跨域RPC需要显式处理优先级和同步语义，单纯追求吞吐不足以满足实时交互[20]。
对于板间或设备间通信，DDS和IEEE TSN分别提供数据分发QoS及确定性以太网相关标准框架[21][22]。它们可用于外部网络的优先级、时钟和传输治理，但不能替代片上共享内存与接收端调度分析。
7.2 消息契约
本课题中的跨域消息至少应包含：
| 字段 | 作用 |
|---|---|
| 序列号 | 检测重复、乱序与丢失 |
| 采集时间戳 | 计算结果年龄和端到端时延 |
| 截止时间/有效期 | 在RTOS侧拒绝过期结果 |
| 模型与协议版本 | 防止版本不一致 |
| 置信度与质量标志 | 支持结果准入与降级策略 |
| 完整性校验 | 检测传输或内存破坏 |
| 运行状态 | 表示Linux、NPU及数据源健康状态 |
队列宜采用有界设计。对状态估计类数据，通常应优先保留最新值而不是无限堆积旧值；RTOS控制线程不应因等待Linux或NPU结果而无界阻塞。
7.3 时间同步与因果一致性
跨域分析必须区分采集时间、发送时间、接收时间、推理完成时间和执行器生效时间。若各域时钟来源不同，应定义同步方式和最大偏差；若共享同一硬件时钟，也应验证虚拟化层的时间暴露和暂停语义。没有统一时间基准，就无法可靠判断AI结果是否新鲜，也无法把一次截止期违约定位到采集、排队、推理还是通信阶段。
8 故障隔离、安全降级与恢复
8.1 控制权归属
面向安全相关控制，建议把最终执行器控制权、超时判定和降级状态机保留在RTOS/安全域。Linux/AI域提供建议值、目标值或感知结果，而不是未经校验直接驱动执行器。已有面向AI实时信息物理系统的研究在异构平台上采用Linux承载AI、FreeRTOS承载安全功能，并通过共享内存通道、健康监视和结果新鲜度校验实现故障兜底[23]，这与本课题方向高度一致。
8.2 需要覆盖的故障模型
至少应包含：
- Linux用户进程崩溃、内核卡死或重启；
- NPU驱动超时、固件异常、队列停滞；
- 跨域消息丢失、乱序、重复、损坏和版本不匹配；
- AI结果低置信、越界、过期或持续不可用；
- DMA越界、设备复位影响其他域；
- 内存或互连过载导致控制任务长尾；
- 温度过高、降频和电源预算收缩；
- RTOS健康监测本身失效或误判。
8.3 标准语境
ISO 26262面向道路车辆功能安全[24]，ISO 21448关注预期功能安全及感知、算法能力不足等非故障风险[25]，ISO/PAS 8800进一步聚焦道路车辆AI安全[26]。三者关注点不同：软件或硬件故障、功能性能局限、AI特有不足不能混为一类。若本课题面向工业或其他领域，也应映射到相应功能安全标准，而不是直接宣称符合汽车标准。
AUTOSAR Adaptive Platform为高性能ECU提供了面向服务的软件架构和执行管理机制[27]。这类行业框架有助于定义进程生命周期和接口，但系统确定性仍取决于底层调度、资源隔离、设备路径和具体部署配置。
8.4 降级与恢复语义
完整的兜底机制应定义以下状态：
正常协同 → AI结果异常/超时 → 降级控制 → 故障隔离 → 服务恢复验证 → 受控重新接入
其中，“Linux已重启”不等于“AI可以重新参与控制”。重新接入至少需要完成模型版本校验、通道清空、连续健康样本确认、时间同步检查和状态重建。恢复期间应继续由RTOS维持安全控制策略。
9 国内外研究进展综合
9.1 国外研究脉络
国外研究大致形成四条相互衔接的路线：
- 混合关键度调度理论： 从不同关键等级任务的执行时间假设和模式切换出发，研究可调度性与服务降级[1][2]；
- 分区与虚拟化： 通过Jailhouse、Bao、Xen、ACRN、seL4等降低操作系统之间的直接耦合[7]-[12]；
- 共享资源分析： 从内存带宽监管、DRAM bank划分、并行请求分析和gang调度等角度控制多核干扰[13]-[16]；
- AI与加速器实时化： 从GPU调度逐步扩展到DNN负载、异构平台协同和AI故障兜底[17]-[19][23]。
总体趋势是由“降低虚拟化开销”转向“给出系统级时间与故障证据”，评价对象也从单次VM退出或IPC时延扩展到端到端控制链。
9.2 国内公开研究与工程实践
国内公开成果在混合双操作系统通信、嵌入式虚拟化和国产实时操作系统工程适配方面已有积累。例如，面向TrustZone的混合双操作系统实时RPC研究关注了跨域通信中的优先级与可预测性[20]；湖南大学嵌入式与网络计算实验室公开的ZVM项目面向嵌入式多核平台提供虚拟化研究与原型基础[28]。同时，国产RTOS和行业SoC生态为本土化验证提供了工程条件。
但从公开、可复现证据看，仍缺少把国产SoC、国产RTOS、Linux、NPU运行时和完整闭环控制统一起来的基准套件；尤其缺少共享NPU/DDR压力下的截止期数据、跨域故障注入记录和可复用安全降级协议。因此，国内工程适配不应只停留在“系统成功启动、域间能够通信”，而应转向边界测量和证据固化。
9.3 代表性研究对比
| 研究/项目 | 主要对象 | 核心贡献 | 对本课题的启示 | 主要局限 |
|---|---|---|---|---|
| Vestal[1] | 混合关键任务 | 建立不同保证等级执行时间模型 | 明确控制域与AI域保证等级 | 未覆盖现代异构加速器 |
| PREEMPT_RT[3] | 实时Linux | 降低Linux内核不可抢占延迟 | 可作为低成本基线 | 不提供完整空间/故障隔离 |
| Jailhouse[7] | 静态分区 | Linux辅助建立硬件分区 | 工程集成路径清晰 | 共享资源仍需单独治理 |
| Bao[8] | 轻量Hypervisor | 面向嵌入式多核的静态分区 | 适合研究小型可信基 | 设备生态和平台适配成本较高 |
| seL4[12] | 高保证微内核 | 提供形式化内核正确性证据 | 支持高可信隔离证据链 | 不覆盖整机时序与AI栈 |
| MemGuard/PALLOC[13][14] | DRAM干扰 | 带宽监管与bank感知分配 | 建立内存预算与隔离基线 | 需适配具体内存控制器 |
| RT-Gang[16] | 多核/DNN负载 | 限制关键并行任务间干扰 | 适合AI与控制共存实验 | 可能降低总体吞吐 |
| GPUart/GCAPS[17][19] | GPU实时调度 | 抢占、优先级与可分析调度 | 为NPU治理提供方法参照 | GPU机制不能直接移植到封闭NPU |
| RTRG-RPC[20] | 双OS通信 | 跨域RPC及优先级协同 | 通信协议必须携带实时语义 | 仍需结合共享资源分析 |
| Cittadini等[23] | AI+RTOS+Hypervisor | 健康监测、新鲜度验证和兜底 | 与本课题体系结构高度对应 | 平台与应用特定，需跨平台复现 |
10 现有研究的主要不足
10.1 证据链条分散
Hypervisor论文常强调隔离和切换开销，实时调度论文关注任务响应时间，AI系统论文关注吞吐和准确率，安全研究关注风险与降级。这些证据通常来自不同平台、负载和测量口径，尚未自然组合成“传感输入到执行器输出”的完整论证。
10.2 NPU运行时缺乏可分析接口
相较CPU和部分GPU，边侧NPU的队列策略、固件执行、抢占粒度和内部内存流量往往不公开。这使传统WCET分析难以直接应用，也容易造成“推理平均值稳定、极端情况下却阻塞控制域”的风险。
10.3 跨域优先级与新鲜度缺乏统一语义
一个高优先级RTOS任务发出的请求，进入Linux驱动、NPU队列和回传通道后可能丢失原有优先级；即使及时返回，也可能对应已经过期的传感帧。现有IPC性能测试往往只测往返时间，未同时验证数据年龄、版本和接收端可用性。
10.4 动态治理与可认证性存在张力
动态调整核、带宽和加速器配额可以提高平均利用率，但增加了状态空间和时序分析复杂度。如何在不破坏高关键域保证的前提下，让AI域使用剩余资源，是系统设计中的关键权衡。
10.5 故障恢复研究弱于故障检测
许多系统能够检测Linux或AI任务异常，但对清理旧消息、重建共享状态、验证模型版本和安全重新接入缺少明确协议。若恢复路径未被测试，其风险可能高于直接维持降级模式。
11 面向子课题B的研究框架
11.1 建议体系结构
本课题宜采用“RTOS掌握控制权、Linux承载智能栈、Hypervisor实施静态隔离、共享内存执行有界通信”的主线：
传感器 ──> RTOS/安全域 ──> 基础控制与执行器
│
├─ 有界输入通道 ─> Linux/AI域 ─> NPU/GPU
│ │
└─ 新鲜度/完整性校验 <── 有界结果通道
Hypervisor：CPU核、内存、设备、中断和通信区域静态划分
资源监测器：DDR、DMA、加速器队列、温度、截止期与故障状态
RTOS不等待AI结果完成才推进控制周期；当AI结果有效时，可用于修正目标、估计状态或优化控制参数；当结果超时、异常或不可用时，立即保持基础控制或切换到预定义安全策略。
11.2 建议研究问题
| 编号 | 研究问题 | 可验证假设 |
|---|---|---|
| RQ1 | 静态分区能否显著降低Linux负载对控制任务的影响？ | 核、内存和设备划分后，控制时延长尾下降，但DDR/DMA压力下仍存在残余干扰 |
| RQ2 | 哪些共享资源是目标SoC的主要瓶颈？ | 干扰贡献与工作负载类型有关，可由硬件计数器、带宽和时延联合识别 |
| RQ3 | AI输出怎样在控制域中安全使用？ | 带时间戳、版本、置信度和有效期的有界协议可消除旧结果误用 |
| RQ4 | Linux/NPU故障是否会突破控制实时边界？ | 执行器归RTOS所有且通道非阻塞时，AI域故障可被限制在预设恢复时间内 |
| RQ5 | 资源治理的性能代价是多少？ | 合理配额可换取长尾稳定性，但存在吞吐—确定性折中曲线 |
11.3 建议实验矩阵
实验应至少设置四类对照：
- 普通Linux；
- Linux + PREEMPT_RT；
- Linux/RTOS共存但不启用完整资源治理；
- 静态分区Hypervisor + RTOS控制域 + Linux智能域 + 资源治理与兜底机制。
每类系统分别施加以下压力：
- CPU计算压力；
- LLC/DRAM带宽压力；
- 摄像头、网络、存储和DMA并发；
- 多模型或多流NPU/GPU推理；
- 高温、降频和长时运行；
- Linux崩溃、AI进程退出、NPU超时、消息损坏与通信中断。
11.4 建议评价指标
| 维度 | 核心指标 |
|---|---|
| 控制实时性 | 周期抖动、响应时间分布、观测最大值、截止期违约率、最长连续违约 |
| AI时效性 | 输入年龄、队列等待、推理时延、端到端时延、有效结果率、过期丢弃率 |
| 资源隔离 | DDR带宽、LLC未命中、DMA流量、加速器队列深度、干扰放大系数 |
| 通信 | 单向/往返时延、抖动、丢包/覆盖、队列水位、时钟偏差 |
| 故障安全 | 检测时间、隔离时间、降级切换时间、安全状态保持率、受控恢复时间 |
| 功耗热 | 功耗、温度、频率状态、热稳态前后时延变化 |
| 控制品质 | 超调量、稳态误差、整定时间、轨迹误差或任务特定安全指标 |
实验报告必须同时记录硬件型号、内核和RTOS版本、Hypervisor提交、固件/驱动、模型哈希、编译参数、频率策略、环境温度、负载脚本和原始日志。否则，所谓“实时改善”难以复现和比较。
11.5 预期创新点
结合现有研究空白，子课题B可把创新集中在以下四点：
- 系统级实时边界模型： 将控制响应时间与AI结果新鲜度放在同一端到端链路中分析；
- 异构共享资源预算： 建立CPU、DDR、DMA、NPU/GPU及温度干扰的测量与预算方法；
- 跨域安全数据契约： 形成包含时间戳、版本、置信度、有效期和恢复代次的有界协议；
- 故障注入与证据闭环： 通过Linux/NPU/通信故障注入验证降级、隔离和重新接入，而非只验证正常路径。
12 结论
边侧异构SoC上的混合实时控制不是单一操作系统、单一Hypervisor或单一调度算法可以独立解决的问题。PREEMPT_RT、双内核、AMP、静态分区和高保证微内核各有适用范围；核与内存静态划分能够减少直接干扰，却不能自动消除共享缓存、DRAM、DMA、加速器和热约束带来的长尾。AI任务的评价也必须从平均吞吐转向结果新鲜度、连续违约和故障条件下的可用性。
对本课题而言，最稳妥的研究主线是：把执行器控制权和降级状态机固定在RTOS域，把复杂AI生态放在Linux域，用Hypervisor和硬件机制建立资源边界，用有界通信协议传递可校验的AI结果，并通过混合压力与故障注入形成系统级证据。最终成果不应只是“Linux与RTOS可以同时运行”，而应回答在何种资源预算、负载和故障条件下，控制截止期仍可维持、AI结果仍可使用、系统仍可安全降级。
参考文献
[1] VESTAL S. Preemptive Scheduling of Multi-criticality Systems with Varying Degrees of Execution Time Assurance[C]//Proceedings of the 28th IEEE International Real-Time Systems Symposium. 2007: 239-243. DOI: 10.1109/RTSS.2007.47.
[2] BURNS A, DAVIS R I. A Survey of Research into Mixed Criticality Systems[J]. ACM Computing Surveys, 2018, 50(6). DOI: 10.1145/3131347.
[3] THE LINUX KERNEL DOCUMENTATION. Real-time preemption[EB/OL]. [2026-09-28]. https://www.kernel.org/doc/html/latest/core-api/real-time/index.html.
[4] XENOMAI PROJECT. Xenomai 3 Overview[EB/OL]. [2026-09-28]. https://v3.xenomai.org/overview/.
[5] OPENAMP PROJECT. OpenAMP Overview[EB/OL]. [2026-09-28]. https://openamp.readthedocs.io/en/latest/openamp/overview.html.
[6] THE LINUX KERNEL DOCUMENTATION. Remote Processor Messaging (rpmsg) Framework[EB/OL]. [2026-09-28]. https://www.kernel.org/doc/html/latest/staging/rpmsg.html.
[7] RAMSAUER R, KISZKA J, LOHMANN W, et al. Look Mum, no VM Exits! (Almost)[EB/OL]. 2017. https://arxiv.org/abs/1705.06932.
[8] MARTINS J, TAVARES A, SOLIERI M, BERTOGNA M, PINTO S. Bao: A Lightweight Static Partitioning Hypervisor for Modern Multi-Core Embedded Systems[C]//Next Generation Real-Time Embedded Systems. 2020. DOI: 10.4230/OASIcs.NG-RES.2020.3.
[9] XEN PROJECT. True Static Partitioning with Xen Dom0-less[EB/OL]. [2026-09-28]. https://xenproject.org/blog/true-static-partitioning-with-xen-dom0-less/.
[10] LI S, KWEON S, YANG X, et al. ACRN: A Big Little Hypervisor for IoT Development[C]//Proceedings of the 15th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments. 2019. DOI: 10.1145/3313808.3313816.
[11] MARTINS J, PINTO S. Shedding Light on Static Partitioning Hypervisors for Arm-based Mixed-Criticality Systems[C]//2023 IEEE 29th Real-Time and Embedded Technology and Applications Symposium. 2023. DOI: 10.1109/RTAS58335.2023.00011.
[12] KLEIN G, ELPHINSTONE K, HEISER G, et al. seL4: Formal Verification of an OS Kernel[C]//Proceedings of the ACM SIGOPS 22nd Symposium on Operating Systems Principles. 2009. DOI: 10.1145/1629575.1629596.
[13] YUN H, YAO G, PELLIZZONI R, et al. MemGuard: Memory Bandwidth Reservation System for Efficient Performance Isolation in Multi-core Platforms[C]//2013 IEEE 19th Real-Time and Embedded Technology and Applications Symposium. 2013. DOI: 10.1109/RTAS.2013.6531079.
[14] YUN H, MANCUSO R, WU Z P, PELLIZZONI R. PALLOC: DRAM Bank-Aware Memory Allocator for Performance Isolation on Multicore Platforms[C]//2014 IEEE 20th Real-Time and Embedded Technology and Applications Symposium. 2014. DOI: 10.1109/RTAS.2014.6925999.
[15] YUN H, PELLIZZONI R, VALSAN P K. Parallelism-Aware Memory Interference Delay Analysis for COTS Multicore Systems[C]//27th Euromicro Conference on Real-Time Systems. 2015: 184-195. DOI: 10.1109/ECRTS.2015.24.
[16] ALI W, YUN H. RT-Gang: Real-Time Gang Scheduling Framework for Safety-Critical Systems[C]//2019 IEEE Real-Time and Embedded Technology and Applications Symposium. 2019. DOI: 10.1109/RTAS.2019.00020.
[17] HARTMANN C, MARGULL U. GPUart: An Application-Based Limited Preemptive GPU Real-Time Scheduler for Embedded Systems[J]. Journal of Systems Architecture, 2019, 97: 304-319. DOI: 10.1016/j.sysarc.2018.10.005.
[18] KIM H, PATEL P, WANG S, RAJKUMAR R. A Server-Based Approach for Predictable GPU Access with Improved Analysis[J]. Journal of Systems Architecture, 2018, 88: 97-109. DOI: 10.1016/j.sysarc.2018.05.003.
[19] WANG Y, LIU C, WONG D, KIM H. GCAPS: GPU Context-Aware Preemptive Priority-Based Scheduling for Real-Time Tasks[C]//36th Euromicro Conference on Real-Time Systems. 2024. DOI: 10.4230/LIPIcs.ECRTS.2024.14.
[20] DONG P, JIANG Z, BURNS A, DING Y, MA J. Build Real-Time Communication for Hybrid Dual-OS System[J]. Journal of Systems Architecture, 2020, 107: 101774. DOI: 10.1016/j.sysarc.2020.101774.
[21] OBJECT MANAGEMENT GROUP. Data Distribution Service Specification[EB/OL]. [2026-09-28]. https://www.omg.org/spec/DDS/.
[22] IEEE 802.1 TIME-SENSITIVE NETWORKING TASK GROUP. Time-Sensitive Networking[EB/OL]. [2026-09-28]. https://1.ieee802.org/tsn/.
[23] CITTADINI E, MARINONI M, BIONDI A, CICERO G, BUTTAZZO G. Supporting AI-Powered Real-Time Cyber-Physical Systems on Heterogeneous Platforms via Hypervisor Technology[J]. Real-Time Systems, 2023, 59: 609-635. DOI: 10.1007/s11241-023-09402-4.
[24] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 26262 Road Vehicles—Functional Safety[EB/OL]. [2026-09-28]. https://www.iso.org/publication/PUB200262.html.
[25] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21448:2022 Road Vehicles—Safety of the Intended Functionality[EB/OL]. [2026-09-28]. https://www.iso.org/standard/77490.html.
[26] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/PAS 8800:2024 Road Vehicles—Safety and Artificial Intelligence[EB/OL]. [2026-09-28]. https://www.iso.org/standard/83303.html.
[27] AUTOSAR. Adaptive Platform[EB/OL]. [2026-09-28]. https://www.autosar.org/standards/adaptive-platform/.
[28] 湖南大学嵌入式与网络计算实验室. ZVM嵌入式虚拟化项目[EB/OL]. [2026-09-28]. https://esnl.hnu.edu.cn/zvm/.
说明：本文中的公式、四维分析框架、建议体系结构、研究问题与实验矩阵，是在所引文献基础上针对子课题B形成的综合研究设计，不是对某一篇文献结论的直接复述。