在實(shí)時(shí)分布嵌入式應用平臺上進(jìn)行設計與調試

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

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

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

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

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

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

　　分布式系統開(kāi)發(fā)平臺

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

　　1. 執行線(xiàn)程之間的通信

　　2. 事件同步

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　三種調試用例

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

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

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

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

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

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

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

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

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

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

　　更深入的分析

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

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

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

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

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

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

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

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

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

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

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