四家在國防市場競爭的嵌入式計算機供應商為嵌入式系統編寫了四個標準。它們是：矢量，信號和圖像處理庫（VSIPL）;實時消息傳遞接口（MPI/RT）;消息傳遞接口（MPI）;和Data Reor -

組織接口（DRI）。以下是它們是什么以及每種情況發生了什么。

VSIPL是一個專為矢量和信號處理而定制的數學庫。該庫的公共域工作站實現目前可從TASP COE計劃獲得。 VSIPL規范不依賴于語言;它是為C編程語言開發的。此外，雖然VSIPL包含負責設置操作的對象，但它不是面向對象的API。現在還不清楚如何在現代的面向對象框架中實現相同的API，例如C ++。與此同時，用C ++編寫的現代基于模板的庫似乎達到了相當的性能水平。

在所有最近的標準中，VSIPL最有可能被用戶采用，因為它的實現很簡單，并且與硬件和系統軟件的工作方式不沖突。它的問題都與性能和開銷有關，用戶可以及時學習繞過它們，或者可以在實施者的幫助下消除它們。用戶還沒有急于接受VSIPL規范，因此供應商采用了觀望策略。

功能子集

大多數供應商都實現了一小部分功能調用根據客戶的要求提供更多功能的想法。另一方面，用戶并不急于采用VSIPL，因為他們面臨困境：使用VSIPL意味著放棄經過充分測試并經得起時間考驗的遺留代碼。在VSIPL中重新編碼相同的數學方法在短期內是繁瑣，昂貴和無利可圖的。

MPI/RT是一個消息傳遞庫，它在實時多處理環境中標準化節點之間的通信。 MPI/RT不是實時系統的MPI擴展，正如論壇開始創建新規范時所預期的那樣。與MPI不同，它是一種面向對象的API，它基于“延遲早期綁定”的原則。這意味著必須在每個應用程序的開頭精確定義節點之間預期通信的復雜細節，并且在進程之間交換任何數據，消息或信號之前很久。

也許所需要的是新的授予MPI/RT工作站版本的唯一目的，就像MPI一樣。不幸的是，資助機構在啟動這種標準化和可移植性工作方面有著悠久的歷史，并且在這些項目期間沒有跟進額外的資助。因此，在MPI/RT開發工作中是否可以獲得這樣的授權是值得懷疑的。

MPI

MPI存在了大約八年，是一個較舊的消息傳遞庫，它標準化了多處理環境中節點之間的通信。嵌入式系統用戶可能會質疑API的特性：

MPI提倡舊式過程編程技術，這些技術依賴于發送和接收功能來分發與數據保持獨立的數據。功能。

MPI通信基于后期綁定協議，會損害性能。在執行發送或接收功能之前，系統不知道通信即將發生。在數據傳輸之后，沒有信息被保留以指示可以再次使用相同的通信線路，從而阻止系統優化重復的數據移動。

MPI不是為嵌入式和實時系統設計的。但是，它的存在時間比任何其他便攜式軟件標準都要長，并且得到了公共工作站版本的強力支持。嵌入式系統供應商采用MPI為其平臺感受到客戶的壓力，用戶經常將其用于基準測試目的。該庫的某些版本甚至已經安裝在面向國防的實驗室中，以協助在桌面環境中進行的研究項目。但是當談到嵌入式和實時系統的部署時，以及人的生命依賴于系統可靠性和性能的情況下，不使用MPI。

不幸的是，MPI/RT論壇無法創建MPI的實時擴展，這將擴展到現有的MPI功能，并提供錯誤處理和嵌入式應用程序中急需的恢復過程。在目前情況下，MPI將繼續不足以用于嵌入式系統，MPI/RT將繼續疏遠新應用的潛在設計者。這種情況違背了嵌入式系統編程標準規范的可行性。

DRI是一個高級庫，它使用底層通信機制（如MPI或MPI/RT）在本地重新分配多維數據集在眾多處理節點中。潛在用戶可能會在以下方面質疑此API：

DRI規范不完整，并且不清楚何時完成1.0版。初步規范仍然包含邏輯錯誤和矛盾，需要縮小其重點，而不是爭取更多的一般性。

關于DRI分配數據緩沖區和底層通信機制的屬性存在未解決的問題。多維數據空間。

盡管應用程序和底層通信協議都可以提供自己的分配機制，但仍在考慮DRI內存分配。

MPI和MPI/RT是完全不同的，以引起人們的懷疑，即兩個API都可以支持DRI級別上顯示的相同類型的數據移動。