我的 HRTOS 项目，最初创立于 2017 年。

很多人看到 HRTOS 这个名字，可能会把它理解成一个普通的 RTOS 项目名称。但对我而言，这个名字真正重要的部分，从来不是 “RTOS”，而是其中的 H——Hard Real-Time，硬实时。

HRTOS 的完整含义是：

Hard Real-Time Operating System

但这里需要首先说明一点：

HRTOS 并不是我创造出来的一个专有名词，而是计算机科学与实时系统领域中已有的通用技术概念和缩写。

因此，在未来的论文、教材、标准和技术资料中看到 “HRTOS”，它很可能只是泛指 Hard Real-Time Operating System，而不是指我的这个项目。

我的项目只是选择了这个具有明确技术含义的通用缩写作为名称。

而我之所以选择它，是因为我希望这个名字本身就代表一个方向。

 

一、什么是 Hard Real-Time？

理解 HRTOS，首先要理解什么是 Hard Real-Time。

硬实时真正强调的，并不是“运行得快”。

一个系统即使运行速度非常快，如果它的时间行为不可预测，也不能因此被称为严格意义上的硬实时系统。

硬实时关注的是：

系统不仅要算对，还必须在规定的时间内算对。

实时系统的正确性因此同时包含逻辑正确性和时间正确性；对于硬实时系统，如果规定的时间约束被违反，一次截止期限的失效就可能意味着整个任务失败。

例如，一个控制系统要求某个任务必须在规定的时间窗口内完成。

那么：

10 μs 完成，正确；

20 μs 完成，正确；

100 μs 完成，如果超过了系统规定的截止期限，即使计算结果完全正确，也可能已经没有意义。

这就是硬实时与普通计算系统最本质的区别之一。

时间本身成为了系统正确性的一部分。

因此，硬实时系统真正追求的并不是单纯的平均性能，而是：

确定性、可预测性，以及对最坏情况的控制。

这也是为什么硬实时研究中会涉及调度理论、截止期限、最坏情况执行时间（WCET）、最坏情况响应时间（WCRT）、可调度性分析等问题。

 

二、Hard Real-Time 并不是今天才出现的概念

实时计算的发展有着更早的历史，但至少到了 20 世纪 70 年代初，“Hard Real-Time”已经成为明确的学术研究对象。

1973 年，C. L. Liu 和 James W. Layland 发表了经典论文：

Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment

这篇论文研究的就是在具有严格时间要求的环境中，如何通过调度算法保证任务获得所需要的服务。它后来成为实时调度理论的重要基础之一。

这意味着：

Hard Real-Time 并不是后来为了给操作系统起一个更“硬核”的名字而产生的营销概念。

它背后是一套已经发展了几十年的计算机科学理论。

随后，实时调度、优先级调度、截止期限调度、资源访问协议、响应时间分析等理论不断发展。

到 1990 年代，Giorgio C. Buttazzo 的《Hard Real-Time Computing Systems》已经系统讨论了硬实时计算系统、可预测调度算法以及关键控制应用。书中涉及的应用包括核电、铁路、汽车电子、航空、通信、机器人和军事系统等。

今天，这一研究方向仍然在继续发展，并且已经进一步延伸到网络化控制、机器人、自动驾驶、网络物理系统以及包含机器学习组件的实时系统等领域。最新版本的相关教材甚至专门讨论如何在网络物理实时系统中提高可预测性和安全性。

 

三、为什么今天“硬实时”越来越重要？

我认为，一个很重要的原因是：

计算机正在越来越深入地进入真实世界。

过去，计算机的大量工作是在处理信息。

网页、数据库、文字、图片、视频、办公软件——即使出现几十毫秒甚至几百毫秒的延迟，很多时候也只是体验上的差异。

但当计算机开始越来越多地直接控制真实世界，情况就发生了变化。

机器人需要控制电机。

汽车需要控制执行机构。

工业设备需要进行实时控制。

飞行器需要处理传感器和控制回路。

电力电子系统需要在严格的时间窗口内响应。

这些系统的共同特点是：

软件的执行结果最终会作用于物理世界。

而物理世界不会因为软件“还没算完”而暂停。

这也是为什么实时计算长期以来就在航空航天、汽车、工业自动化、机器人、关键基础设施等领域具有重要地位。

未来，随着机器人、智能汽车、工业自动化以及各种网络物理系统的发展，计算系统与物理世界之间的联系只会越来越紧密。

人工智能可以让系统拥有更复杂的感知和决策能力。

但是最终：

电机什么时候动作、执行器什么时候响应、控制回路什么时候完成、传感器数据什么时候必须被处理——这些问题仍然属于时间。

甚至可以说，计算能力越强、系统越复杂，对底层时间确定性的要求反而可能越值得重视。

 

四、所以，我为什么叫它 HRTOS？

这才是这个项目名字真正的原因。

2017 年创建这个项目的时候，我选择了 HRTOS 这个名字。

并不是因为我认为：

“我已经做出了一个绝对意义上的硬实时操作系统。”

恰恰相反。

我知道自己距离这个目标还有很远。

甚至从更加严格的理论角度来看，也不存在一个脱离具体硬件、应用模型、任务集合、时间约束和运行条件之后，可以对所有情况都宣称“绝对硬实时”的系统。

一个硬实时系统的保证，本身就是建立在明确的系统边界、时间模型和可验证条件之上的。

换句话说：

硬实时不是一个脱离条件的绝对标签，而是一种不断提高系统时间确定性的工程目标。

这也是我理解 HRTOS 这个名字的方式。

 

五、HRTOS 是一个不断逼近的方向

如果把一个系统的时间行为看成一条不断收紧的边界，那么我们可以不断向硬实时方向靠近：

从不可预测，到可预测；

从只关注平均响应，到关注最坏情况；

从“通常很快”，到“能够解释为什么最坏情况下仍然满足要求”；

从依赖经验，到建立明确的时间模型；

从普通软件调度，到精确控制任务、中断、上下文切换和资源访问；

从能够运行，到能够验证；

从验证单个功能，到验证整个系统的时间行为。

这条路本身，就是 HRTOS。

因此，我并不把 HRTOS 理解成一句简单的产品宣传语。

它更像是一个长期目标。

 

六、我希望 HRTOS 最终走到哪里？

我的目标其实很简单：

希望有一天，HRTOS 能够越来越接近真正意义上的硬实时系统。

这里的“真正”，不是简单地在项目名称前面加上 Hard。

而是希望系统能够在越来越严格的条件下，对自己的时间行为给出越来越明确的解释。

为什么这个任务能够在规定时间内完成？

最坏情况下需要多少时间？

中断来了以后，系统最多需要多久响应？

任务切换需要多久？

多个任务同时竞争资源时，会产生多大的时间影响？

系统负载提高以后，时间行为会发生什么变化？

哪些情况可以被证明？

哪些情况还不能被证明？

这些问题，比“系统能不能跑起来”更加困难。

而我认为，这恰恰也是硬实时真正有价值的地方。

 

七、所以 HRTOS 对我而言不是一个已经完成的定义

2017 年，我给这个项目取名 HRTOS。

今天回头看，我反而越来越觉得这个名字不是一个终点，而是一种约束。

它不断提醒我：

系统还可以更确定。

响应还可以更快。

边界还可以更清晰。

最坏情况还可以研究得更深入。

系统对硬件的控制还可以更加彻底。

这也是为什么我一直在关注中断、上下文切换、任务调度、资源管理、内存布局、响应延迟以及各种极端情况下的行为。

因为这些东西最终都会回到同一个问题：

当系统真正进入极端条件时，我还能不能知道它会发生什么？

这可能才是硬实时真正困难的地方。

 

八、HRTOS 这个名字属于一个技术概念，而不仅仅属于一个项目

因此，我也希望把这个概念本身讲清楚。

未来，当有人在论文、教材、标准或者其他技术资料中看到 HRTOS 时，很多情况下它所代表的仍然会是：

Hard Real-Time Operating System

而不是我的项目。

这是一个通用的技术缩写。

我的 HRTOS，只是借用了这个缩写。

但我希望自己的项目能够逐渐配得上这个名字背后的方向。

这两件事情需要被明确地区分开。

名字不是证明。

名称也不是保证。

一个项目叫 HRTOS，并不意味着它天然就实现了严格的硬实时保证。

真正的硬实时能力，需要建立在明确的系统边界、时间约束、最坏情况分析以及验证基础之上。

所以，我不会仅仅因为项目叫 HRTOS，就宣称它已经实现了严格意义上的硬实时。

恰恰相反：

我希望用长期的工程实践，逐渐向这个目标靠近。

 

九、这也是我给项目取名 HRTOS 的真正原因

如果一定要用一句话解释：

HRTOS 不是“我已经做到的事情”，而是“我希望不断做到的事情”。

我知道绝对意义上的终点并不存在。

硬件会变化。

处理器会变化。

软件会变化。

系统复杂度会不断提高。

应用场景也会不断提高要求。

所以，所谓“硬实时”，更像是一条不断向前延伸的边界。

我们能够做的，是在现有硬件、软件和理论条件下，不断提高确定性，不断压缩不可控因素，不断扩大能够被分析、被验证、被保证的范围。

今天比昨天更确定，明天比今天更接近最坏情况可控。

这就是我理解的 HRTOS。

2017 年，我只是选择了这个名字。

但从那以后，它逐渐变成了这个项目长期努力的方向。

HRTOS，不是一个已经抵达的终点。

而是不断向“硬实时”靠近的过程。