在實(shí)時分布嵌入式應(yīng)用平臺上進(jìn)行設(shè)計(jì)與調(diào)試

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

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

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

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

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

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

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

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

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

　　2. 事件同步

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　某些系統(tǒng)將允許你隨時創(chuàng)建新的類型，不過你應(yīng)該知道，這可能形成一個潛在的錯誤源，因?yàn)槿绻幊唐鞑恢榔渲械募?xì)節(jié)，那么驗(yàn)證有關(guān)數(shù)據(jù)的使用合約是非常困難的。

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

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

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

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

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

　　三種調(diào)試用例

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

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

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

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

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

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

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

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

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

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

　　更深入的分析

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

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

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

　　對高效工具的基本需求主要表現(xiàn)在兩個方面：一方面是能夠定義和支持可覆蓋不同操作系統(tǒng)、處理器和網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)的一致性和可預(yù)測的實(shí)時環(huán)境；再就是能夠?yàn)榘_發(fā)應(yīng)用的分布式系統(tǒng)架構(gòu)提供各種不同層次(設(shè)計(jì)，代碼，集成，調(diào)試和維護(hù))調(diào)試信息的全集成工具鏈。

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

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

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

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

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

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

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