“實時”這個術語是數據庫系統供應商隨便說說的，但是實時在嵌入式系統中一直有特定的含義。“實時系統意味著系統是實時的，換句話說，響應應該在指定的時間限制內得到保證，或者系統應該滿足指定的期限。例如，飛行控制系統、實時監視器等。”換言之，在嵌入式開發中，實時并不意味著真正的快速。在實時系統中，速度不是衡量成功的標準;決定論是衡量成功的主要標準。

　　實時系統正以令人難以置信的速度發展。實時系統曾經相對簡單，比如飛機上的防抱死制動系統，以及后來的汽車。今天，實時系統更加復雜。高級駕駛輔助系統(ADAS)是典型代表。它們是現代實時系統復雜性的一個很好的例子。ADAS必須接收來自多個不同來源的數據，例如激光雷達、聲納、雷達、光學相機、GPS和地圖等，這就產生了一個重大的傳感器數據融合問題。有必要將所有數據放在一個中心位置(一個數據庫!)以便可以關聯、分析和采取行動(啟動、停止、轉向等)，所有這些都在嚴格的實時期限內完成。

　　但問題是：直到最近，還沒有商用現貨(COTS)嵌入式數據庫可以用于實時系統，因為所有產品都不知道最后期限。為了說明這一點，嵌入式開發人員考慮一個必須在50毫秒內做出反應的實時系統。如所示圖1，實時任務分別在5毫秒和10毫秒標記處完成前兩步。然后，該任務調用數據庫運行時。然而，數據庫運行時不知道截止日期，直到截止日期到期時才把控制權交還給任務。這個系統失敗了。

　　三個目標

　　為了適用于實時系統，嵌入式數據庫運行時系統必須達到三個目標。第一，必須讓它知道最后期限，并根據給它的最后期限記錄已經過去的時間。第二，它不能有任何不具有時間認知的外部依賴。例如，數據庫運行時不應調用malloc()(用于動態分配內存的C運行時函數)。第三個目標是它必須能夠以適合實時系統的方式調度數據庫事務。

　　1.最后期限—如果嵌入式數據庫系統必須管理截止日期，那么嵌入式數據庫運行時必須能夠知道截止日期。只要數據庫中的工作單元是一個事務，開始一個事務的數據庫API就是將截止日期傳遞到數據庫運行時的邏輯位置。隨著事務的進行，數據庫運行時需要根據截止日期頻繁地檢查進度，并且如果必要的話，中止事務以滿足截止日期。在實時數據庫系統中，事務可以滿足(成功提交)或錯過(成功中止)它們的截止日期，但絕不會遲到(超過它們的截止日期)。實現這一點并不像你想象的那么簡單，除非你只針對一個實時操作系統(RTOS)，因為不同的RTOS有不同的管理時鐘和定時器的方式。圖2說明了事務的時間線。嵌入式開發人員感興趣的是截止時間驗證控制點和截止時間控制點。

　　2.外部依賴性—大多數嵌入式和實時系統都是用C/C++編寫的。程序員傾向于自由地使用C運行時(CRT)庫中的函數。在許多情況下，這是無害的，但是應該避免調用像malloc這樣的CRT函數，或者執行輸入/輸出。它們具有與圖1所示相同的風險:調用任務和(在本例中是數據庫運行時)可能會在沒有時間認知的CRT函數中消失，并且直到超過截止日期才返回，從而導致系統失敗的風險。

　　3.行程安排—數據庫通常由多個任務/線程/進程使用。數據庫運行時必須協調任務對數據庫的訪問，以避免沖突。在行業術語中，這被稱為并發控制，分為兩大類：樂觀和悲觀并發控制。嵌入式開發人員使用悲觀并發控制，一個任務請求訪問一個資源，該資源可以是整個數據庫、一個數據庫表或一組表、一個數據庫頁或表中的一行。不管這些請求的粒度如何，數據庫運行時的一個組件(通常稱為鎖仲裁器或鎖管理器)需要協調這些請求。

　　通常，這是按照先進先出的順序進行的。但是這對于實時數據庫系統來說是不夠的。實時數據庫系統必須首先根據開發人員指定的優先級來調度事務，然后在相同的優先級內，首先根據最早的截止日期來調度事務。或者，實時數據庫運行時必須利用優先級繼承，以便已經運行的低優先級任務的事務可以提升到與新調度的具有更高優先級的事務相同的優先級。

　　重新想象的數據庫

　　今天的實時系統正在經歷增長，就像90年代末和21世紀初的嵌入式系統一樣，當時嵌入式數據庫成為一種必需品，因為嵌入式系統被賦予了更多的任務。業務線/部門計算嵌入式數據庫需要重新設計，以便在嵌入式系統的資源限制內運行。這就是McObject的eXtremeDB開發的驅動力。現在，隨著硬實時系統中數據管理需求的不斷增長，嵌入式開發人員重新設想和設計了eXtremeDB，以創建eXtremeDB/rt，這是第一個在任務和安全關鍵實時系統的約束下運行的COTS確定性數據庫管理系統。