嵌入式系統空間過于多樣化，無法創建一個滿足嵌入式開發人員需求的 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。