在實時分布嵌入式應用平臺上進行設計與調(diào)試

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

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

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

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

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

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

　　分布式系統(tǒng)開發(fā)平臺

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

　　1. 執(zhí)行線程之間的通信

　　2. 事件同步

　　3. 受控延時和網(wǎng)絡資源的高效使用

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

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

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

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

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

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

　　DDS在處理目標網(wǎng)絡方面有點像狀態(tài)機，它承認實時系統(tǒng)是數(shù)據(jù)驅(qū)動的，數(shù)據(jù)的到達、移動、轉(zhuǎn)換和消耗將從根本上確定實時系統(tǒng)的操作。

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

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

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

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

　　分布式系統(tǒng)工具面臨的挑戰(zhàn)

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

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

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

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

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

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

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

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

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

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

　　分布式應用開發(fā)的新工具

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

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

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

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

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

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

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

　　三種調(diào)試用例

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

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

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

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

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

　　這類工具經(jīng)常作為分布式系統(tǒng)中維護環(huán)境的一部分，并且同樣包含易用的GUI構建器，因此可以產(chǎn)生面向最終用戶的系統(tǒng)數(shù)據(jù)和健康顯示。

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

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

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

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

　　更深入的分析

　　這時候你已沒有選擇，只有進行更深入的分析，才能了解到底發(fā)生了什么。協(xié)議分析器雖然可以提供你所需的所有UDP或其他包信息，但這沒有任何意義，除非你能夠?qū)⑺鼈冎匦屡c應用程序關聯(lián)到一起。

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

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

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

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

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

        圖3：RTI分析器是一個系統(tǒng)級調(diào)試工具，可以發(fā)現(xiàn)運行系統(tǒng)中的RTI數(shù)據(jù)分布服務對象，對其進行重組，并顯示它們的通信參數(shù)。將該信息與你的系統(tǒng)設計相關聯(lián)能夠迅速找出性能和可靠性問題。

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

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

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

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