嵌入式系统空间过于多样化，无法创建一个满足嵌入式开发人员需求的 RTOS。从事安全关键型软件工作的人需要强大的、激光严格的确定性，商业开发人员会乐于满足软实时需求，并将强大的确定性视为矫枉过正。永远不会有一个单一的 RTOS 来统治它们，但如果 RTOS 本身更像是权力之环，而操作系统抽象层 (OSAL) 是唯一的一个环呢？

　　通过 OSAL 管理 RTOS

　　OSAL 是一个非常有用的工具，开发人员可以利用它来抽象出他们选择的特定 RTOS。OSAL 本质上是一个通用接口，可用于与任意数量的现有 RTOS 进行交互和控制。如果一位开发人员喜欢 FreeRTOS，他们只需将 FreeRTOS API 与 OSAL 一起包装。如果另一个开发人员想要使用 ThreadX、uC OS III 或其他一些 RTOS，他们只需使用 OSAL 接口包装 RTOS 调用。

　　使用 OSAL 实际上有很多优点。首先，OSAL 允许开发人员将他们的应用程序代码与 RTOS 分离。有这么多的选择，团队不应该围绕 RTOS 编写他们的应用程序。RTOS 只是一个组件或工具，应用程序中对 RTOS 的依赖越少越好!一个完美的例子可能是在概念验证期间使用一个 RTOS，因为它是免费的，而在开发和生产期间可以使用安全认证版本。有了 OSAL，就无需重写应用程序代码，只需将 OSAL 接口重定向到其他 RTOS 并重新编译。

　　其次，OSAL 允许嵌入式开发人员在不关心使用什么 RTOS 的情况下构建他们的软件。软件架构师希望处理抽象的细节，以便他们可以专注于架构和应用程序业务规则。因此，本质的 RTOS 细节被推到 OSAL 后面，成为应用程序架构师不需要考虑的实现细节。

　　最后，借助 OSAL 背后的 RTOS，可以更轻松地测试和模拟软件。当 RTOS 与应用程序紧密耦合时，开发人员需要弄清楚如何让 RTOS 在持续集成服务器上运行，以及如何让它在模拟和集成测试中正常运行。使用 OSAL，可以更轻松地模拟行为，这有助于节省时间，但更重要的是防止开发人员的压力水平达到临界水平。

　　结论

　　嵌入式系统行业中的每个人都不会只使用一个 RTOS，我们所能期望的最好的结果是嵌入式系统行业的嵌入式开发人员采用单个 OSAL 作为任何嵌入式应用程序的标准接口，那里有潜在的 OSAL，例如面向 Arm 用户的 CMSIS-RTOS v2 和其他一些微控制器供应商特定的 OSAL。