- 外部中断：响应外设或外部信号，并执行相应的中断处理程序。
- 系统 Tick：推进系统时间，并根据内核实现处理超时与时间相关事件。
- 内核操作：例如任务延时、消息传递或资源释放，可能改变任务状态。
SYSTEM VIEW / SYSTEM MODEL
System Model
系统运行模型
HRTOS 的运行过程涉及中断响应、任务状态变化、调度决策、上下文切换与时间约束。 系统模型用于描述这些机制之间的关系，并为执行路径分析、实时性评估和工程验证建立统一的分析框架。
SYSTEM MODEL / CORE RELATIONSHIP
从事件到执行，再到时间验证
系统运行不是所有模块依次执行的固定流水线，而是由事件触发、 内核状态变化、调度决策和实际执行共同构成的动态过程。
RUNTIME RELATIONSHIP
Conceptual model · Not a fixed pipeline
01 / EVENT
事件触发
Interrupt · Tick · API
02 / KERNEL
内核处理
State · Kernel Path
03 / SCHEDULER
调度决策
Ready · Priority · Policy
04 / EXECUTION
执行与响应
Context · Task · Result
实际控制流可能包含中断返回、嵌套处理、任务继续运行或其他内核路径；
图示用于建立机制之间的关系，不代表每次事件都会经历全部阶段。
Event → Kernel Processing → Scheduling Decision → Execution
Task State + Interrupt Behavior + Resource Constraints
→ Timing Behavior
说明：以上是用于理解系统机制的概念模型，不代表每次事件都会触发任务切换， 也不构成对所有执行路径均已获得形式化时间上界的声明。
01
事件与中断处理
事件是系统运行过程中的触发因素。外部中断、系统 Tick 和内核通信操作， 可能引起任务状态变化或调度需求，但它们的执行路径并不完全相同。
Interrupt / Tick / Kernel Event
产生处理需求或状态变化
Kernel Processing
内核根据事件类型执行对应的处理逻辑。是否进入调度路径，
是否发生上下文切换，以及何时恢复任务执行，取决于事件类型、
当前执行环境和具体内核实现。
02
任务状态与调度决策
任务状态描述任务是否具备执行条件；调度器则根据可运行任务、 优先级及调度策略决定后续执行对象。两者相关，但不是同一个概念。
Task Lifecycle
Ready：任务已具备运行条件，等待获得处理器。
Running：任务当前正在执行。
Blocked：任务正在等待时间、消息或其他事件。
具体状态定义、状态转换和边界条件，以 HRTOS 对应版本的实际实现为准。
Scheduler Decision
调度器根据当前任务状态和调度规则，确定接下来应执行的任务或内核路径。
优先级、时间片、任务就绪情况和中断返回路径，都可能影响最终执行结果。
调度决策不等于任务切换：若选中的执行对象未发生变化，可能不需要切换任务上下文。
状态变化与调度决策共同影响执行路径
Scheduling Result
调度结果决定后续执行对象，但实际运行还受到中断到达、
临界区、上下文切换成本和共享资源访问等因素影响。
因此，分析调度策略时，还需要结合真实执行路径与处理器时间预算。
03
执行路径与上下文切换
执行流描述处理器在任务代码、中断处理程序和内核路径之间的转移。 它是连接调度机制与时间分析的关键部分。
Execution Flow
- 任务持续执行，直到发生调度点、中断或其他控制流转移。
- 中断处理可能改变系统状态，并影响当前任务的后续执行。
- 当调度结果要求更换执行任务时，内核需要按照实现规则保存和恢复相应上下文。
- 中断返回、任务恢复和嵌套中断的具体顺序取决于目标处理器及内核实现。
执行路径时间模型
Tpath = Tinterrupt + Tkernel + Tschedule + Tcontext + Ttask 这是用于拆分执行路径中时间开销的分析框架。 各项是否发生、是否重叠及如何计入，应根据具体路径定义； 不能直接将该表达式视为适用于所有路径的固定计算式。
Tpath = Tinterrupt + Tkernel + Tschedule + Tcontext + Ttask 这是用于拆分执行路径中时间开销的分析框架。 各项是否发生、是否重叠及如何计入，应根据具体路径定义； 不能直接将该表达式视为适用于所有路径的固定计算式。
详细机制参见 Execution Flow、 Interrupt Flow 和 Scheduler Cycle。
04
时间约束与实时性分析
实时系统不仅关注功能是否正确，还需要关注结果是否在规定时间内产生。 时间约束必须结合具体任务、事件路径与系统负载进行分析。
Timing Constraints
- 中断响应时间：从规定的中断事件发生，到指定响应点之间的时间。
- 调度与切换开销：内核完成调度决策及必要上下文切换所消耗的时间。
- 执行时间：指定代码路径在目标硬件和明确环境条件下所需的处理器时间。
- 截止时间：任务或响应必须满足的时间约束。
实时性判定的基本形式
R ≤ D R：按明确边界定义的响应时间
D：对应事件或任务的截止时间
R ≤ D R：按明确边界定义的响应时间
D：对应事件或任务的截止时间
WCET（最坏执行时间）分析、响应时间分析和压力测试可以提供不同层面的证据， 但它们回答的问题并不相同。只有明确目标硬件、编译结果、执行路径、 中断条件和分析边界，才能解释时间结论的适用范围。
相关内容参见 Time System 与 Deterministic Chain。
05
资源与干扰因素
处理器时间并非只由任务代码长度决定。中断活动、临界区、资源竞争、 存储器访问以及上下文管理开销，都可能影响实际响应时间。
Memory & Context
在资源受限的 8051 环境中，需要关注内部 RAM、外部 RAM、
寄存器组、堆栈及上下文保存与恢复的成本。
具体影响取决于芯片型号、存储器配置和编译结果。
Interrupt & Critical Section
中断嵌套、关中断区间和临界区可能改变事件响应的可达时刻。
分析时应区分全局中断屏蔽、特定中断源屏蔽及其他同步机制的影响。
Shared Resources
共享数据、消息队列和互斥资源可能引入额外处理步骤或等待时间。
需要根据资源访问规则与同步机制确定相关路径的时间边界。
Build & Hardware
指令周期、编译器优化、时钟配置和芯片具体实现都会影响测量结果。
时间分析应绑定明确的目标配置，而不能脱离构建条件讨论。
内存布局与资源约束参见 Memory View。
06
系统模型如何用于工程验证
将抽象的系统运行关系转化为可检查的工程对象：先固定目标环境， 再界定执行路径，建立时间证据，最后评价约束是否满足。
Step 1 — Define the Target
明确 MCU 型号、时钟配置、编译器版本、编译选项、HRTOS 版本和运行条件。
Step 2 — Identify the Execution Path
选定需要分析的中断响应、任务切换、调度周期或其他具体路径，
明确起点、终点及可能介入的中断。
Step 3 — Establish Timing Evidence
结合反汇编指令分析、路径边界检查和目标硬件测量，
分别记录理论估算与实测数据，并说明各自的假设和限制。
Step 4 — Evaluate the Constraint
将分析结果与明确的时间约束比较，记录满足条件的范围、
尚未覆盖的路径和需要进一步验证的风险。
07
系统模型的边界
系统模型帮助组织运行机制和时间约束，但模型本身不等于完整的实时性证明。
ANALYSIS SCOPE / EVIDENCE BOUNDARY
系统模型提供的是一种组织运行机制和时间约束的分析框架， 并不自动证明系统具有确定的最坏响应时间，也不意味着所有路径 都已完成形式化验证。
对 HRTOS 的实时性进行评价时，应区分架构设计、实现机制、 静态时间分析、目标硬件测量与长期压力测试等不同证据。 这些证据相互补充，但不能彼此替代。
System Model → Execution Analysis → Timing Evidence → Constraint Evaluation
目标是让系统行为更容易理解、分析和验证，并逐步提高关键执行路径的可预测性。
08
系统模型关系
System View 从不同角度描述同一套系统：执行路径、任务状态、中断行为、 调度规则、内存资源与时间约束共同构成完整的运行视图。
推荐阅读顺序
执行流 → 任务生命周期 → 中断流 → 调度周期 → 内存视图 → 时间系统 → 确定性因果链
执行流 → 任务生命周期 → 中断流 → 调度周期 → 内存视图 → 时间系统 → 确定性因果链