實時系統設計師和嵌入式軟件開發工程師對獨立的或者與嵌入式系統關聯不大的設計、開發和調試工具與技術都非常熟悉。他們通常在設計階段使用UML，在開發階段使用IDE，在集成與調試階段使用調試器和邏輯分析器(位于其它工具之中)。

　　過去相互連接的節點通常只有幾個，且每個節點之間的功能劃分非常明晰，但隨著嵌入式系統之間互聯的普遍化，如今常常是幾十個甚至數百個節點都共同分擔著一些邏輯應用功能。

　　事實上，隨著實時系統與企業系統之間聯系越來越緊密，這種分布式系統在操作系統和執行處理器方面的差異越來越顯著。本文將討論實時分布式系統開發方面的問題，并介紹開發平臺和開發工具必須如何演進來應對上述新環境所帶來的挑戰。

　　開發平臺的概念在嵌入式設計領域已經流行很久了，作為一個工具，它將應用開發環境與底層(通常是非常復雜的)實時硬件、協議棧以及設備驅動等分割開來。

　　就象操作系統(OS)提供獨立系統開發平臺的基礎構建模塊一樣，實時中間件主要負責解決分布式系統開發中所面臨的實時網絡性能、可擴展性以及對不同處理器和操作系統提供支持等方面的挑戰。

　　就象在標準實時操作系統的演變過程中發生的現象一樣，為了支持目標環境(本文中為大型分布式系統中的實時程序)的開發、調試和維護，業界推出了許多新的工具。

　　分布式系統開發平臺

　　從應用開發工程師的角度看，當邏輯應用跨越多個連網計算機時，應用開發平臺必須能夠提供如下三個基本功能：

　　1. 執行線程之間的通信

　　2. 事件同步

　　3. 受控延時和網絡資源的高效使用

　　顯然通訊和同步是分布式平臺的服務要求，這與OS所提供的服務非常類似。但對于分布式應用來說，它們必須在不同操作系統和處理器構成的網絡設施中透明運行，所有這些都暗示著要遵從一定的字節順序和數據表示格式。

　　最好采用這樣一種機制，它不要求開發人員清晰地了解消息或同步線程的接收對象所處的位置，以便從應用開發的角度將網絡視作一個單一目標系統。

　　通常用戶采用商用或自己開發的中間件來提供上述這些關鍵功能。有多種支持這種方法的中間件解決方案，例如Object Management Group (OMG)公司的JMS和DDS (數據分配業務)。

　　不過只有DDS(圖1)這樣的方案明確地解決了上述的第三點，即受控延時和 (目標)網絡資源的高效使用，這在實時應用中是一個關鍵問題。DDS在提供消息和同步方面與JMS類似，但額外還采用了稱為服務質量(QoS)的機制。

             圖1：DDS框架可以提供受控延時和目標網絡資源的高效使用。

　　QoS從應用層次上明確地定義了消息或同步請求的發送端和接收端之間所需的服務等級(優先級，性能，可靠性等)。

　　DDS在處理目標網絡方面有點像狀態機，它承認實時系統是數據驅動的，數據的到達、移動、轉換和消耗將從根本上確定實時系統的操作。

　　某些數據是關鍵數據，需要在受控/固定的延遲時間內獲取和處理，并且大多數要穿越網絡。另外，有些數據需要持續一定的時間以便用于計算，而另一些數據需要可靠地提供，時間倒不是關鍵。QoS使得所有這些需求得以簡化，并提供更多功能。

　　也許使用中間件的最大優點常常到應用開發過程的最后才看到，以豐富的中間件格式來定義接口將使得系統的集成、調試和維護變得非常容易。優異的中間件功能可以幫助你通過服務質量完整地定義數據交互，并形成應用“合約”。

　　例如，DDS不僅允許數據源規定數據類型，還允許規定數據以“一次性發送”還是以“重復發送直到”語義進行發送，遲到接收端的歷史數據需要多大的存儲空間，該數據源相對于其他數據源的優先級，數據的最低發送速率，以及更多的可能性。

　　通過明確地規定這些問題，延伸到集成階段的許多問題都可以通過快速地實現承諾特性與要求特性之間的匹配來解決。DDS中間件甚至可以在合約不滿足時即時產生告警。

　　分布式系統工具面臨的挑戰

　　直到擁有能夠支持整個應用周期中應用環境的工具之前開發平臺都不算完整。如果詢問任何一個支持或維護工程師，他們都會說需要三樣東西：好的文檔，豐富的工具集以及盡可能容易地獲取狀態和事件參數的代碼。

　　如果連網應用節點之間有清晰的接口定義語言可供使用，那么工作在一個單節點上的最新工具鏈在用盡內存、代碼校正和性能時仍然是非常有用的，在某些情況下，還可以用于白盒子測試。

　　開發人員面臨的新挑戰是在集成階段出現的各種問題的隔離、確認和更正，因為這時候單個分布式子部件是相互連接的，這些連網的子部件將首次作為大型集成應用而開始執行。

　　大多數工程師熟悉在單板環境里進行調試，都具備很強的“硬故障”解決能力，這些硬故障指的是引起進程停止或沖突的故障。

　　這類故障的調試相對比較容易，因為從沖突狀態退出來基本可以正常工作，如果幸運的話，還可以在調試器中捕獲故障，并且對這類故障的調試可以不受約束。

　　最難查找的硬故障通常是與多線程相關的故障，因此在采用更大更復雜的分布式系統時遇到越來越多這類故障也就不足為奇了；每個節點都有其自己的執行線程，這些線程可能對同一時刻來自分布式系統架構的相同數據進行操作。

　　分布式系統似乎也存在大量的軟故障。在這些情況下，沒有應用沖突，但告警指示燈卻閃亮，且分布式應用執行不好或者根本不執行。

　　軟故障的類型有許多，不過絕大多數都與多機器間數據產生和處理的同步有關。例如單個丟棄消息效應，如果該消息只是一個更新數據的樣本，可能不會有什么大問題，但如果是一個轉換事件或者命令，系統就會立刻進入無法預期的狀態。

　　另外，這類故障可能出現很長時間后你才能檢測到，這將導致可怕的調試惡夢。這只是軟故障的一種，通常還會產生許多其它類型的軟故障：比如：引起控制環路不穩定的長延遲(持續不變或周期性的)，自我增強(self-reinforcing)數據的丟失，不期望的中斷應用，系統在實驗室中工作良好但升級后出現故障，提供的和期望的數據不匹配等。

　　因此對于分布式系統來說，在不中斷或者不顯著減慢系統運行速度的條件下獲得狀態和事件信息非常重要。

　　分布式應用開發的新工具

　　讓我們從基本的開始：首先需要的是能夠產生可涵蓋所有板子的公共數據類型以及使它們保持同步的進程的工具。如果使用中間件，你通常會使用元語言(IDL, XML, XDR)來書寫你的數據類型，并自動生成處理數據類型的代碼。

　　某些系統將允許你隨時創建新的類型，不過你應該知道，這可能形成一個潛在的錯誤源，因為如果編程器不知道其中的細節，那么驗證有關數據的使用合約是非常困難的。

　　另一個你所需要的工具應能幫助你設計應用程序，并規定數據和QoS要求。這類工具理想上應該用來設計盡可能多的應用程序，以便在設計階段就能滿足發送端和接收端之間的QoS合約(這比后面再進行調試和修復要容易得多)。

　　理想地，該工具應與你正常使用的設計方法相結合。例如，UML用戶可能希望你考慮Sparx UML。該工具帶有用于DDS這類中間件的接口描述組件，從而使得初次建立QoS變得更加容易。

　　一旦應用完成部署后，你需要確保通訊能如期進行，QoS參數設置正常，系統能夠立即運行！在集成時你首先需要回答的問題之一是：“這些分布式應用功能間的通話是否正常？”

　　利用合適的中間件詢問工具，比如RTI分析器，你就能確定中間件是否將兩個應用程序聯系到一起，也能確保這兩個應用功能是否滿足實際規范要求。

　　這樣的工具還需要告訴你哪些對象正在交換數據，或許更重要的是，哪些不在交換數據，如果不在交換數據的話，分析不在交換數據的原因。當你有3個不同分包商(或者僅是自由開發商)，且每個分包商只負責分布式應用中的一部分，而你需要將它們集成到一起時，你將會真切地感謝這類工具。利用這些工具可以迅速精確并且沒有異義地發現絕大部分配置問題的根本原因。

　　三種調試用例

　　盡管你的前端設計不錯，也具備良好的通用接口，但仍然可能不工作。這時分布式系統的狀態和事件分析就變得極其關鍵。通常調試過程中有三種用例：

　　用例1：監視整個分布式系統的健康狀態。這種情況下，你可能想觀察系統中大部分應用程序的高層行為。像SL Corporation公司的RTView這樣的工具可以通過偵聽中間件及具體應用程序釋放出的數據，幫助用戶構建一個或多個控制平面GUI或者數據報告視圖。

　　選擇性地構建應用中的關鍵變量，這可能是隔離系統問題并確保系統正常工作的最重要的第一步。當利用像DDS這類數據中心中間件實現時，諸如RTView等工具就可以在沒有相關資源詳細信息的情況下生成顯示內容。

　　僅需要知道其存在和適用的格式(與數據元語言中定義的一樣)，以及如何才能使數據可用(QoS)，就可以快速消化這種有用系統瀏覽顯示器所需的信息。

　　通常使用這類工具的應用程序有許多不同的數據源，且大都具有較低的時間分辨率，因此需要將其組合起來顯示，方可形成有意義的系統健康遠景。

　　這類工具經常作為分布式系統中維護環境的一部分，并且同樣包含易用的GUI構建器，因此可以產生面向最終用戶的系統數據和健康顯示。

　　用例2：深入了解故障應用程序。一旦利用系統健康分析工具確定出是哪一個節點存在問題，就需要從所選的一些應用程序以及網絡上這些應用的交互情況中獲得更詳細的信息和更高的時間分辨率數據。像RTI Scope這樣的工具就可以提供這類功能，它允許用戶在沒有預配置的情況下，以圖形的方式實時地查看流入或流出應用程序的不同數據流。

　　用戶可以將RTI Scope看作一臺用來觀測網絡中任何一個應用程序的輸出數據的示波器，它能利用負時間沿觸發，具有多種繪圖類型(與時間的關系，x與y的關系)，獲取信號并能夠存儲以用于后續處理。RTI Scope仍然工作在規定的數據級別，不過其設計意圖是以最少的介入方式捕獲較少的數據源。

　　對于獲取超出范圍的數據或者說提供超出所需吞吐率或性能要求的數據來說，它是非常理想的。其底層中間件實現的豐富知識意味著它能夠‘發現’數據的發送方和接收方，并通過網絡與它們連接，從而通過中間件提取數據用于本地分析和可視化。

　　應例3：網絡分析。有時候，中間件試圖執行一些應用請求的服務，但底層網絡實現自身的表現卻不如預期。這個問題也許是路由器掉包，或無線中繼所提供的帶寬低于要求，或者某個節點周期性地斷網一兩秒鐘，或者任何一個其他的問題所致。

　　更深入的分析

　　這時候你已沒有選擇，只有進行更深入的分析，才能了解到底發生了什么。協議分析器雖然可以提供你所需的所有UDP或其他包信息，但這沒有任何意義，除非你能夠將它們重新與應用程序關聯到一起。

　　一個構建良好的分布式中間件應包含一個標準的有線協議，比如DDS就采用了開放標準的RTPS(實時數據的發布與訂閱)協議。正如你所期望的那樣，這樣的平臺能夠監控有線流量并抽取相關的中間件數據包，并將數據包分拆用來與應用層相關。這里RTI也是有用的，它和專用協議分析器一起能夠實時顯示所有“線上活動”。

　　如上所述，在大型和復雜的網絡上工作的實時應用開發需要一個創新性方案，該方案應能提供一個高效的工具策略來應對這類分布式環境所帶來的多種挑戰。如果沒有這種連貫和綜合的策略，無論是系統性能還是項目開發時間都將大打折扣。

　　對高效工具的基本需求主要表現在兩個方面：一方面是能夠定義和支持可覆蓋不同操作系統、處理器和網絡拓撲結構的一致性和可預測的實時環境；再就是能夠為包含開發應用的分布式系統架構提供各種不同層次(設計，代碼，集成，調試和維護)調試信息的全集成工具鏈。

　　Bob博士是Real-Time Innovations公司工程服務副總裁。他在2000年加入RTI公司，在控制系統和分布式網絡技術方法擁有非常豐富的經驗。他是復雜分布式應用的設計與調試專家，有兩年時間在專門研究嵌入式和網絡系統調試。他過去還做過客戶培訓、系統設計和集成調試等咨詢工作。

        圖2：利用IDL文件定義 “rtiddsgen”等數據類型工具可以生成能處理被定義數據類型的代碼。擴展的“rtiddsgen”可以用來產生與CORBA兼容的數據類型。

        圖3：RTI分析器是一個系統級調試工具，可以發現運行系統中的RTI數據分布服務對象，對其進行重組，并顯示它們的通信參數。將該信息與你的系統設計相關聯能夠迅速找出性能和可靠性問題。

        圖4：RTI分析器能顯示DataReader與DataWriter 之間的“所有權”中的QoS失配。

        圖5：RTView提供的虛擬儀器可以幫助用戶查看關鍵的分布式數據。

        圖6：RTI Scope能夠利用一個類似示波器一樣的顯示器來圖形化顯示DDS Topic Data與時間的關系。

        圖7：RTI協議分析器允許觀測在線流量。