|
在傳統的信息技術領域，Java已成為首選的編程語言，因為它能提高開發者的生產率、軟件復用率和可靠性，降低軟件維護成本，并提供更靈活、更通用的軟件結構。 如今，在低級、硬件、實時軟件領域已有各種各樣的Java方案。但是，當在像數字音頻信號處理這樣非常低級的軟件中應用Java技術時，某些方案將更能發揮傳統Java技術的優越性。 其中一種方法基于針對資源受限和安全關鍵的Java定義的推薦規范。設計該方案的主要目的是保持Java的可移植性、可維護性和可擴展性優勢。在系統內的信息流中包括兩臺計算機，這兩臺計算機協同操作以便通過網絡通訊通道交換音頻信息(圖1)。 在一個節點上采集到的音頻信號被傳輸至其它節點，并被輸出至遠程計算機的揚聲器。在第二個節點上采集到的音頻信號則在第一臺計算機的揚聲器中輸出。從概念上講，信息流被構造成兩個獨立的數字音頻數據流。 這種簡單的音頻處理應用可以被當作PERC Pico應用程序來實現。該軟件目前正在開發中，它首次實現了針對安全關鍵和資源受限應用所提出的實時Java(RTSJ)規范概要分析。“硬實時概要分析(hard real-time profile)”即指這種環境。 圖1：一個簡單的數字音頻應用構成了本文討論的關鍵性軟件工程的基礎 1 維護和可擴展性要求 摩爾定律推動了典型嵌入式應用的規模和復雜度快速增長。競爭壓力促使軟件不斷發展，以滿足功能越來越強大的硬件的需求。對某些消費電子設備的研究發現，新產品中代碼規模的增長速度非常接近摩爾定律，大約每18至36個月就翻一番。 大約20年前，每個新的嵌入式設備中的所有軟件通常是由一個或兩個工程師在不到一年的時間內寫完。而現代嵌入式軟件的開發則非常困難。假設每次新產品的軟件修訂都要求增加數十萬，甚至數百萬行的代碼，那么嵌入式軟件開發人員的職責將更多地轉向如何解決集成許多獨立開發的軟件組件所帶來的挑戰。 這個簡單的數字音頻例子代表了一種原型的低級嵌入式軟件“產品”。對大多數產品而言，開發原始軟件的成本要比整個產品生命周期內的軟件維護成本小得多。以下列出了該應用在產品生命周期內的發展過程。 (1)軟件將需要被移植到不同的操作系統和不同的處理平臺上，這將改變它的CPU時間和內存需求。 (2)軟件將與各種不同的補充功能集成在一起。也許下一代產品也將包括視頻信號。也許它將支持共享數字白板，以便于召開遠程會議，或者可能與電子郵件和日歷軟件集成在一起。或者，一些應用可能增加錄制功能，以將會議實況保存在磁盤中。 (3)雙節點網絡拓撲可能需要進行通用化，以支持有任意多參加者的會議。 (4)模數轉換器(ADC)和數字信號處理器(DSP)的接口可以不斷發展。在一些配置中，操作系統提供了這種服務。而在其它配置中，這種應用可能包括連接音頻子系統硬件和DMA內存設備的設備驅動程序接口。音頻硬件本身有望繼續發展，這要求軟件設備驅動程序不斷發展。 (5)網絡通信協議可能需要作一些改變。在某些環境中，軟件將依賴底層操作系統服務來與網絡連接。隨著各種網絡通信協議的發展，連接操作系統網絡業務的接口甚至也可能發生變化，以便提供新的QoS參數和更高帶寬。在其它情況下，這種應用將需要包含面向硬件接口的低級設備驅動程序，也可能需要實現通信協議棧。可以采用帶沖突檢測的載波偵聽多路訪問(CSMA/CD)技術、無線、光纖和其它有待發明的技術，在低成本專用串行通道、同軸電纜和雙絞線數據鏈接中實現相同的基礎通信能力。通信庫可能集成了壓縮、加密、檢錯和糾錯，以及滑動窗口協議。 上面給出了軟件在商業化業務應用中的幾種可能發展方式，這里并非想窮舉所有的優勢，只是為了說明保留Java設計優勢的好處，即使是對于一些資源受限和硬實時應用來說。 圖2：硬實時JAVA翻譯環境顯示了各種工具之間的關系，這些工具可使實時組件的開發、維護和集成更容易 2 實時JAVA的能力 這些實時Java編程技術由RTSJ衍生發展而來。該規范具有很好通用性，能支持多種獨特的實時編程要求。由于本文主要關注非常低級的實時軟件，所以我們將開發人員的操作限定在完整RTSJ規范的子集范疇內。 這種概要分析可改善可移植性、可靠性和效率，因為它禁止使用一些需要很大的運行時間開銷、會帶來不可移植的實現依賴性、增加軟件復雜度以致使程序員更容易出錯的功能。硬實時概要分析和完整RTSJ之間一些特殊差異包括： (1)完整的RTSJ對同步鎖采用優先級繼承方法，并支持優先級限高仿真可選。硬實時概要分析禁止使用優先級繼承并要求支持優先級限高仿真。 (2)完整的RTSJ允許即時修改各種線程調度和對象同步參數。硬實時概要分析禁止對線程調度和同步協議進行即時調整。 (3)完整的RTSJ還支持一些機制，這樣每當任務錯過最終期限或超出其CPU時限時，就可以自動觸發異步事件。請注意，這些服務的實現是完全不可移植的，而精確執行會帶來極高的運行時間開銷。此外，在硬實時應用中不需要運行時間限制，因為在程序執行之前，已經靜態地滿足資源預算和最終期限要求。因此，硬實時概要分析不支持這些機制。 (4)完整的RTSJ支持傳統線程、訪問垃圾收集堆的實時線程，以及不訪問垃圾收集堆的實時線程的混合體。這種不同線程類型的混合大大增加了系統的復雜度和規模。這種復雜度將增加由于不同線程類型之間不能正確共享信息而導致的實時編程出錯的可能性，硬實時概要分析僅支持不訪問垃圾收集堆的實時線程。 (5)完整的RTSJ提供一系列可供應用程序員使用的庫，以便舉例說明動態內存范圍，并在特定范圍內分配對象。由于程序員在開發或集成采用嵌套作用域(nested scope)的組件時可能會產生許多小錯誤，所以這些庫的使用尤其成問題。為執行正確的區域性存儲器(scoped-memory)使用協議，RTSJ在每次讀取和/或重寫參考字段時都執行特殊的運行時檢查。在完整的RTSJ中，運行時進行檢查會使程序組件出錯，從而使得程序由于非法分配、非法讀取、區域性存儲器協議錯誤、內存不足錯誤等原因，以運行時間異常方式終止執行。硬實時概要分析禁止使用RTSJ內存作用域(memory scope)操作庫。相反，它要求程序員以編程注釋的形式描述其對作用域內存(scoped-memory)的使用。在編譯期間，這些注釋可以被分析和執行，例如本文應用提到的@Scoped和@StaticAnalyzable注釋。 (6)RTSJ不會為了中斷處理或低級設備的I/O而對庫進行標準化，而硬實時概要分析對這些庫進行定義。 硬實時概要分析的商用化前實現試驗顯示，它運行在某些CPU密集型基準程序的速度比標準Java和完整RTSJ的速度快三倍。這是因為硬實時執行環境比標準RTSJ簡單得多，并且它還用編譯時間驗證替代各種運行時檢查。這種性能可以與相應的C和C++程序相媲美，有時甚至更好。 盡管采用受限的硬實時概要分析比采用傳統Java更加困難，但這種平臺的代碼開發和維護要比用C或C++開發出的相應平臺的維護容易。這是因為硬實時Java平臺具有更好的可移植性，并提供高級的面向對象的抽象。此外，硬實時Java平臺包括可使實時組件的開發、維護和集成更為容易的一些重要開發工具(圖2)。 由于包含了強制嚴格遵守類型安全的字節碼校驗器，與C和C++相比，Java開發可提高可靠性和可維護性。C和C++程序員可以利用多種讓使類型安全無效的機制，而有意或無意地利用這些漏洞將使代碼更容易產生錯誤，并降低可移植性。 受限的實時環境提供了比傳統Java更嚴格的字節碼驗證。特別是，圖2中的硬實時驗證器可確保指向堆棧分配對象的參數(指針)不會比對象本身的生存期更長。它也確保用專用@StaticAnalyzable注釋標記的程序組件，可限制它們對可分析子集使用Java。與硬實時翻譯器的集成，則能提供確定執行每個組件所需的CPU時間和堆棧內存上限的能力。 執行硬實時組件所需的所有臨時內存分配，必須由正在執行線程的運行時棧來實現。執行從單主線程開始，而主線程的運行時棧代表了所有可重復使用的內存。對于由主線程派生的每個附加線程，它提供了部分運行時棧作為派生線程的運行時棧。 圖3：該模塊圖說明了SimpleAudio數字音頻應用的體系結構 3 數據音頻應用的實現 圖3給出了數字音頻應用的體系結構。它共有6個線程，包括主線程和用Orchestrator實例表示的異步事件處理器。BufferPair將每個插座接口連接至相應的DSP接口。主線程監控用戶指令，并在用戶請求關閉會話時調用SimpleAudio實例的terminateActivity()方法。所有其它線程通過調用continueActivity()業務，定期輪詢SimpleAudio實例。到了關機時，該方法返回false值。 在缺省配置中，該應用以8kHz采樣頻率對麥克風輸入進行采樣，每次采樣采集8比特數據。這種配置每秒鐘產生8k字節的數字音頻數據，這對簡單的語音應用來說已經足夠。但是，它不適合高保真立體聲信號。一般的CD錄制以44.1kHz的采樣頻率對兩個立體聲信道每次采樣16比特。這種高保真度信號的帶寬要求為176.4千字節/秒。 在缺省配置中，插槽讀模塊和寫模塊采用足夠的帶寬進行可靠傳輸，以可靠提供所有從DSPReader模塊采集的數據。我們采用了一種直接壓縮技術，一連串同樣的字節值(像出現在靜音期間的那樣)由一個專用的轉義(escape)值、重復次數和重復值表示。當然，更先進的壓縮技術將更為合適。 在實時系統中，由抖動描述特定實時組件的理想執行時間的預期偏離，由一個確切的線程描述數字音頻應用的每個組件。SocketWriter線程接收來自DSPReader模塊的原始數據流，對數據進行壓縮，并將數據傳送至網絡插座通道。如果網絡插座通道的帶寬有限，只能達到預算的8千字節/秒，那么任何導致SocketWriter延遲數據傳輸的抖動影響將隨著時間而累積。 在缺省配置中，預計SocketWriter每125s傳輸1字節數據。如果每秒的音頻數據有1個字節延遲半毫秒，則1小時后，累積延遲將約為2秒。為防止抖動延遲的累積，該架構包含一個運行在16Hz的監視線程。 在每個周期內，該線程強制讓SocketWriter和DSPWriter組件丟棄62.5ms之前的數據。由于我們處理的是音頻數據，所以通常來講，丟棄的臨時數據值比允許數據到達時間偏移更可取一些。人們通常不會注意到丟棄臨時數據字節的影響。 請注意在第1行出現的@StaticAnalyzable注釋，源碼列表中的@ StaticAnalyzable(enforce_time_analysis = {false}, enforce_non_blocking = {false})。這代表了部分方法簽名(method signature)。注意該注釋給出了enforce_time_analysis 和enforce_non_blocking屬性的參數值，兩者都是false。這表示該方法的實現無需將其本身限制在子集內，對于該子集，靜態分析器可從中推斷執行該方法所需要的嚴格CPU時間上限，也不要求靜態分析器驗證該方法執行時永遠不會阻斷。 如果這些屬性定義沒有給出，硬實時驗證器將認為程序不合法，因為在源碼列表的(!orchestrator.destroy()) { through 57, }執行時，靜態分析器無法確定該循環包含了多少次第55行。此外，main方法的執行可能會在第59行的socket_ reader_thread.join()至63行的orchestrator_thread.join()之間阻斷，以及在第51行sa.awaitTermination()調用的await-Termination()方法中阻斷。 在@StaticAnalyzable注釋中未注明的是enforce_memory_analysis屬性的值。該屬性的缺省值為true，這意味著該方法的實現必須符合限定的指導方針以使執行該方法時靜態分析器能夠確定將要分配的最大內存。假設該環境的實時Java規則將內存作為運行棧的一部分，則臨時內存分配的上限就表示必需的主線程的運行時棧大小。 注釋有助于軟件開發，并大大簡化軟件維護工作。通常，系統架構師將復雜的系統功能分為較小的組件，以便由不同的開發小組實現。因此，描述不同組件之間連接的接口定義，不僅詳細說明了可以在組件間傳遞的參數類型，還包括在每個組件中必須實現的實時處理的限制，能減少軟件維護方面的開銷。 對于現有軟件的修改必須遵從組件接口注釋中描述的所有其它特殊實時限制。如果軟件維護人員違反了這些接口要求，他們可以從字節碼驗證器得到直接、明確的反饋。從而確保現有大型實時軟件系統的不斷變化不會動搖現有系統的穩定性。 在對可靠運行該主程序所需的堆棧內存進行分析時，靜態分析器必須確定在該方法以及該方法所調用的方法中，每個對象要求分配多大內存。為了支持靜態分析結果的模塊化合成，字節碼驗證器要求每個由主程序調用的方法被聲明為@Static-Analyzable，而enforce_time_ analysis屬性設置為true。快速復查main方法的實現可確保無限循環內不產生分配。這是字節碼驗證器所要執行的任務之一。 在第37行的socket_reader_thread = new Thread-Stack(SocketReader.class)；到41行的orchestrator_thread = new ThreadStack(Orchestrator.class)之間分配了幾個新的ThreadStack對象；每次分配描述了主程序派生的線程所使用的堆棧內存。一般來說，靜態分析工具可能難以確定可靠執行這些子線程所必需的堆棧內存數量。 每個ThreadStack構造函數的參數為提供代碼由相應線程執行的類(Class)。靜態分析器要求每個在該環境中傳遞的NoHeapRealtimeThread子類具有帶@ StaticAnalyzable注釋，且enforce_ memory_analysis屬性設置為true的run()方法。如果ThreadStack構造函數的參數并非來自BoundAsyncEventHandler(例如在Orchestrator類的情況下)，則靜態分析器要求該類的asyncEventHandler()方法采用@StaticAnalyzable注釋來聲明，且enforce_memory_analysis屬性設置為true。 當前線程的運行時棧能滿足所有臨時內存需要。請注意，我們在第23行分配了兩個臨時BufferPair實例，microphone_stream = new BufferPair()；而在第24行，speaker_stream = new Buffer-Pair()；然后這些對象的參數被傳遞至構造函數，用于包含該軟件應用的不同功能組件的各個線程。硬實時驗證器實施的限制之一在于，stack-allocated對象的參數不能比引用參數的對象本身生存時間更長，同樣是通過注釋機制來執行。我們來看一下SocketReader類的構造函數： @ScopedPure @StaticAnalyzable(enforce_time_analysis = {false}, enforce_non_blocking = {false}) SocketReader(SimpleAudio sa, Buffer-Pair buffers, String socket_name) throws FileNotFoundException @ScopedPure注釋說明該構造函數的每個輸入引用參數(reference parameter)可以指代那些位于外部嵌套作用域的運行時棧的對象。字節碼驗證器確保這些參數的內容絕不會復制到那些由于具有@Scoped指派而未被同樣區分的變量上。 此外，它禁止將內部嵌套作用域變量的值復制到外部嵌套作用域變量。一個例外情況是，在特殊環境下，它可證明帶參數對象位于與要賦值變量相同或更外層嵌套的作用域。如果這一構造函數的參數未由@Scoped注釋指定，字節碼驗證器將不允許主程序將參數傳至堆棧分配的BufferPair和SimpleAudio對象。 本應用展示的RTSJ支持的實時編程抽象之一為PeriodicTimer類。注意，本應用在第49行舉例說明了PeriodicTimer對象，drumbeat = new PeriodicTimer(start_time, period, orchestrator)；并將結果賦值給本地drumbeat變量。參數之一為orchestrator對象的引用參數，其本身是BoundAsyncEventHandler的一個實例。該drumbeat周期計時器被設置為每秒觸發orchestrator對象的handleAsyncEvent()方法執行16次，即每62.5微秒一次。 采用C或C++語言的實時開發人員可以實現這些實時Java技術所支持的許多相同構造。但是，C或C++程序員必須產生懸掛指針(dangling pointer)以及內存泄漏，他們還缺乏標準工具的支持來自動分析執行時間和堆棧大小。 另外，C和C++程序員還缺乏完整性檢查以確保方法的實現能夠滿足文檔化實時接口的要求，并確保方法調用能夠傳遞同樣滿足文檔接口要求的參數。最后，在對現在軟件系統進行維護的過程中，C和C++程序員沒有工具支持來保證對現有軟件的修改與在原軟件開發過程中假設的各種組成要求是相符的。 傳統Java在生產效率和成本上具有許多優勢。規范地使用實時Java技術可提供許多這樣的優勢。與使用C和C++相比，一般Java程序員在新代碼開發期間具有2倍的生產率，而在現在軟件維護期間具有5到10倍的生產率。隨著嵌入實時軟件的大小和復雜度增加，這些激發人們向更現代的軟件工程技術(如由實時Java實現的工程技術)轉化的因素已越來越重要了。 |
