對不同自動駕駛系統所用的通信中間件比較感興趣。但直接相關的資料比較少。最近看了兩篇比較早的論文，大致先總結下里面的內容，之後再逐漸往上補充內容。
爲什麼需要通信中間件
現代基本的軟件設計原則是模塊化。模塊化可以提高可維護性、代碼重用性並隔離故障。例如，一個大型機器人系統可以分解成特定的任務，如數據採集、狀態估計、任務規劃等。爲了完成它們的任務，模塊必須與其他模塊交換信息。在現代操作系統中，將單個模塊映射到軟件進程非常方便，這些進程可以位於相同的計算設備上，也可以位於物理上獨立的計算設備上。這就把信息交換的任務轉化成了深入研究的進程間通信問題 。
模塊化爲開發提供了便利，但也引入了對通信中間件的需求。將模塊映射到單獨的進程的一個最顯著的特性是每個模塊接收一個單獨的內存地址空間。這一界限的引入帶來了許多好處;模塊可以在相同或不同的主機設備上運行，可以獨立啓動和停止，可以用不同的編程語言和不同的操作系統編寫，一個模塊的災難性故障不一定會影響另一個模塊。與此同時，模塊之間的隔離使得共享信息也不再是一項簡單的任務。模塊設計人員必須仔細考慮在模塊之間共享哪些信息，如何將這些信息封送編碼到消息中，如何將封送的消息從一個模塊傳遞到另一個模塊，以及如何在接收到消息後解碼。
通信中間件的引入整體上可以幫助開發人員提高工作效率。儘管消息傳遞系統引入了複雜性，但它也提供了分析和內省的機會，這對開發人員來說可能是無價的。特別是，可以通過專門設計用於幫助系統開發的模塊捕獲和分析消息。這些模塊可以將消息記錄到磁盤，提供關於帶寬、消息速率等方面的統計信息。如果消息是根據正式的類型系統編組（Marshalling）的，那麼流量檢查模塊可以自動解碼消息，就像程序調試器可以自動解碼正在運行的應用程序的堆棧變量一樣。
通信中間件該滿足什麼特性
基於通信中間件的工作流程，一箇中間件應該包括以下幾個模塊:數據類型規範語言、消息傳遞系統、日誌/回放工具和實時分析工具.
依據以上主要模塊，好的通信中間件應該擁有以上特性：
- 數據類型規範語言應獨立於平臺和具體的編程語言，以消除用戶實現編組（Marshalling）代碼的需要，同時保證運行時類型的安全性
- 消息傳遞系統需要在不同的進程之間傳輸消息，並提供低延遲的消息傳遞功能，且消除對中央通信的依賴
- 需要使混合模擬、記錄和實時數據源的工作更容易。
- 需要提供大量的日誌記錄、回放和流量檢查工具，以簡化常見的開發和調試任務
關於通信中間件有什麼相關工作
目前有各種消息傳遞系統，每個系統都有進行一下權衡。是否使用可靠或不可靠的數據傳輸以及是否提供自動數據編組系統。
Player
Player project(Player 2.0: Toward a practical robot programming framework)是一個比較著名的系統，它提供了一個機器人控制的客戶端/服務器模型。服務器在單個進程中運行,並有一組用戶可配置的驅動(Driver)，每個驅動在其自己的線程中。Player發行版包含許多驅動，每個驅動都有一個指定的任務，比如讀取攝像機數據或執行輪速命令。用戶編寫客戶端程序來通過服務器與驅動交互，通常是通過在客戶端地址空間中的驅動代理(proxy)對象上進行操作。代理對象處理與服務器的通信和數據編組.
Player爲習慣於傳統應用程序開發的軟件開發人員提供了一個熟悉的編程模型，並嘗試簡化機器人開發的許多方面。這些努力包括各種各樣的驅動，促成了它的廣泛成功。然而，這種架構也有其缺點：創建新驅動是一個複雜的過程，一個驅動的失敗可能會影響到其他驅動，甚至可能導致整個機器人的失敗；單片進程的特性使調試單個組件變得複雜。Player最初是爲客戶端-驅動通信而設計的;驅動-驅動和客戶端-客戶端通信的機制已經被添加到player中，但是在組合的自由度上依然存在一定侷限性。
Player默認使用TCP通信。雖然TCP本身是可靠和有序的，但Player添加了一組add-replace規則，如果訂閱方無法跟上發佈方，這些規則會導致消息被刪除。如果沒有這樣的規定，TCP緩衝區最終將被填滿，並導致發佈服務器的運行變慢
在內部，Player使用（XDR）[http://www.rfc-editor.org/rfc/rfc1832.txt]進行數據編組。Player的內置類型利用並鼓勵用戶使用XDR。
MOOS
MOOS(MOOS - mission orientated operating suite)在水下機器人社區中特別流行。它提供了一個發佈訂閱模型，其中所有通信都通過一箇中央服務器路由，客戶端以固定的速率(通常爲10hz)獲取消息。MOOS消息是ASCII字符串，其優點是使消息易於被人類讀取，缺點是比二進制編碼的消息消耗更多的帶寬。
CARMEN
CARMEN robotics包(Perspectives on standardization in mobile robot programming: The carnegie mellon navigation (carmen) toolkit)主要使用IPC消息傳遞系統(Inter-Process Communication)。IPC使用TCP和一箇中心來協調模塊之間的通信。默認情況下，中央服務器路由所有通信，但也可以將其配置爲用於促進客戶端到客戶端直接通信的撮合服務。在這兩種模式中，IPC都實現了發佈/訂閱模型。與pull系統不同，push系統儘可能快地向訂閱者發送消息。IPC提供了一種工具，它可以部分地自動化消息的編組和反編組，但它要求用戶手動將類型的ASCII描述與C結構聲明保持同步嗎，用戶必須確保其結構的包裝和對齊方式符合ASCII描述，對於不同單詞大小的機器，這容易導致出錯
JAUS
JAUS實現了一個路由消息模型，在這個模型中，單個消息被定位到特定的目的地[The Joint Architecture for Unmanned Systems: Reference Architecture Specification]。JAUS的主要優勢不是消息處理系統本身，而是JAUS規範包含了200多個標準化數據類型。原則上，實現這些標準格式的模塊可以自由地組合在一起，以構建大型系統。
JAUS是圍繞一個路由消息傳遞系統設計的，其中每個消息都有一個特定的目的地。
儘管組件可以在沒有相應查詢的情況下單方面傳輸消息(包括廣播)，但其也支持基於“query查詢“”和“inform通知“”消息的類似rpc的機制。作爲這個消息傳遞框架的一部分，JAUS允許一個通信節點樹。JAUS規範本身沒有指定傳輸，但是通常使用UDP。因此，JAUS不保證消息傳遞。與Player和MOOS相比，消息丟失的機制是不同的，但是效果是非常相似的。
JAUS沒有提供自動生成編組代碼的功能:每種數據類型都必須手工編碼。此外，消息的類型(命令代碼)編碼在一個16位小整數中，這些值的賦值由JAUS規範指定。由於這個集合只有一個子空間可用於用戶定義類型，開發人員必須確保以無衝突的方式分配這些值。
雖然JAUS以前支持Java，但是OpenJAUS v3.3中取消了這種支持。JAUS規範的其他限制包括4096字節的消息限制，以及每個節點必須由系統構建器手動分配一個全局惟一標識符。
ROS
機器人操作系統(ROS)旨在爲機器人開發提供一個完整的環境。例如，它提供了一個自動處理依賴項的包管理系統。它的消息傳遞子系統提供了發佈/訂閱模型和麪向服務的模型。採用match-maker流程來促進客戶與客戶之間的聯繫。消息傳遞接口足夠通用，可以使用不同的傳輸，包括共享內存、TCP、UDP和Spread最初的版本使用TCP作爲唯一的消息傳輸。
ROS還提供了一種基於類似於c的類型規範語言的數據組服務。這允許在little-endian系統上進行快速而簡單的數據編組，但是不支持big-endian系統
RDS
Microsoft s Robotics Development Studio (RDS)(Microsoft robotics studio: A technical introduction,)與大多數其他系統的不同之處在於，它沒有提供發佈/訂閱模型，而是採用了服務模型。這個模型可以看作是一種有狀態的遠程過程調用習慣用法，它基於簡單對象訪問協議(Simple Object Access Protocol, SOAP)。有幾個傳輸層可用，從簡單的內存副本(用於相同內存空間中的服務)到通過Internet連接的服務的XML/RPC。
對現有中間件的整體總結
在現有系統中有幾個重複出現的主題。發佈/訂閱模型是最常用的，TCP是最常用的傳輸。大多數這些系統使用一個集中的中心，不管它是用於消息路由還是僅僅用於匹配。幾乎所有這些系統都提供了一個可靠且有序的傳輸系統，儘管有些系統將UDP傳輸作爲非標準選項提供。
服務模型提供了一種熟悉的編程模型，但這有其缺點。例如，將以前記錄的數據注入基於服務的系統通常比較困難。這種能力在開發感知和其他數據處理算法時特別有用，因爲可以使用相同的代碼操作日誌數據和實時數據。在發佈/訂閱系統中，這可以通過簡單地將以前的消息重新發送到客戶機來實現。由於在面向服務的系統中通信是有狀態的，因此事件注入需要服務本身的協作。
這些系統在它們所提供的數據編組支持方面差異很大。二進制格式的消息具有簡潔的顯著優點，大多數系統都使用這種格式。一些系統使用基於xdr的編組系統，儘管一些實現只提供部分自動代碼生成。例如，語言支持通常是有限的，在某些系統中，用戶必須手動保持格式化字符串與結構的佈局同步
再看通信中間件需要什麼特性
- 基本上需要一個push-based發佈/訂閱模型。
- 使用UDP多播作爲低延遲但不可靠的傳輸，從而避免了對集中式sub的需要。
- 提供基於正式類型聲明語言生成編組代碼的工具;此代碼可以爲大量平臺和操作系統生成，並提供運行時類型安全性。
- 提供一個相對獨立的消息傳遞系統，以便於集成而不是提供操作環境，包括預定義的數據類型、準備使用的模塊、事件循環、消息傳遞系統、可視化和仿真工具、包管理等等的集合。
- 支持靈活的程序調試和運行數據分析的功能。雖然所有的系統都提供了某種機制來將消息從一個模塊傳遞到另一個模塊，但是很少有系統提供一種方法來方便地調試和檢查實際傳輸的消息。這樣做的通常是以犧牲效率和性能爲代價的。
來源：《南潯遇雨 博客》