HRTOS 架构模块

实时操作系统系统架构（Architecture Overview）

HRTOS 架构将实时操作系统拆分为应用、调度、内核、中断与内存层级，保证系统实时性、确定性和可调度性。

系统架构概览

HRTOS Architecture 定义实时操作系统在执行、调度、内存与中断层面的整体架构组织方式。

HRTOS 将实时系统拆分为多个核心架构模块，每个模块负责不同层级的时间约束与资源管理：

这些模块共同决定系统是否具备： 实时性（Real-Time Behavior）、确定性（Determinism）、可调度性（Schedulability）与资源可控性（Resource Predictability）。

从系统工程视角看，这些模块不是彼此独立的功能块，而是一条从事件输入到确定性收敛的执行链。外设事件先进入中断域，中断将状态变化投递给调度器，调度器依据优先级、截止时间和就绪队列做选择，内核完成上下文切换，内存层再为栈、队列与共享缓冲区提供有界访问路径。

因此，架构文档真正描述的是“时间如何在系统中流动”。评估一个 HRTOS 架构是否成立，不能只看任务切换速度，还要联合检查 ISR 上界、锁持有时间、通信唤醒链路以及最坏情况下的资源竞争传播范围。

架构层级模型

HRTOS 采用分层架构组织实时系统能力。

应用层（负责用户任务执行与接口调用）
↓
调度层（任务选择与时间分配）
↓
中断层（外部和内部事件响应）
↓
内核控制层（执行调度决策）
↓
内存与资源层（管理资源访问与调度）
↓
硬件抽象层（屏蔽底层硬件差异）

该分层模型同时包含自上而下的语义分解和自下而上的执行约束。应用层定义业务目标，调度层把目标翻译为可执行的时间序列，中断层负责异步入口整形，内核控制层保证状态转换合法，而底层资源层则提供确定性的空间与带宽边界。

以电机控制器为例，采样中断会在中断层产生执行入口，调度层优先唤醒控制任务，内核层切换到控制回路上下文，内存层保证采样缓冲区和任务栈不会互相干扰。只有每一层都具备清晰边界，闭环控制周期才能稳定落在截止时间内。

核心栏目

聚焦当前专题的核心模块、技术概念与文档入口，帮助快速理解系统结构。

在架构阅读顺序上，核心栏目适合承担“建立地图”的作用。它们把系统拆成若干可单独分析的局部模型，但每个模型最终都要回到同一条主线：事件如何进入系统、谁决定 CPU 归属、哪些资源会改变最坏情况路径。

当团队进行代码走查时，也可以把这些栏目当作检查清单：先看中断入口是否最小化，再看调度点是否闭合，最后看共享资源是否存在无界等待。这样的阅读方式更接近真实工程问题。

推荐内容

精选当前专题中的关键页面与延伸阅读内容。

如果当前任务是做架构评审，建议优先追踪一条完整执行链，例如“定时中断 → 调度 → 控制任务 → IPC 唤醒 → 输出任务”。沿着一条链把多个页面串起来阅读，比孤立理解单个概念更容易发现真实瓶颈。

架构设计原则

HRTOS Architecture 的设计目标是建立可分析、可预测且具备实时正确性的系统结构。

HRTOS 的核心目标不是追求更高吞吐量，而是构建一个具备时间约束可证明性的实时系统。

系统设计遵循以下原则：

✔ 确定性执行（Deterministic Execution）
✔ 延迟上界控制（Bounded Latency）
✔ 资源隔离与访问可控（Resource Isolation）
✔ 可预测调度路径（Predictable Scheduling）
✔ 实时系统正确性（Real-Time Correctness）

这些原则共同定义 HRTOS 是否能够满足实时系统的核心要求： 在有限资源条件下保持行为可预测、时间可分析与执行可验证。

实际设计时通常采用“从截止时间反推架构”的方法：先确定端到端响应预算，再把预算分摊到中断入口、调度决策、上下文切换、通信同步和内存访问等链路节点。这样得到的不是抽象原则列表，而是一组可测量、可审计、可验证的工程约束。

这也是 HRTOS 架构与通用软件架构的差异所在。前者强调最坏情况可证，后者更强调平均性能和功能扩展；前者要求每条执行路径都能解释，后者通常容忍局部不可预测行为。