Global Sources
電子工程專輯
 
電子工程專輯 > 放大/轉換
 
 
放大/轉換  

Hines-Ortega方法簡化複雜的軟體設計問題

上網時間: 2001年09月01日     打印版  Bookmark and Share  字型大小:  

關鍵字:Hines-Ortega  Ken Hines  Consystant  嵌入式系統  OOP 

在瞬息萬變的市場上,嵌入式系統開發人員經常面臨在設計最後階段還要改變的問題,以及應付數量不斷成長的多處理器目標架構帶來的設計挑戰;在此同時,開發人員們還必須處理與系統底層資源直接連結的軟體模組間的複雜關係,這些關係往往會使費時費力的開發周期延長並推遲開發進度,以便能跟上設計變更的要求。所以說在典型的嵌入式開發環境中,軟體問題往往比硬體問題更複雜,而且開發環境隨著各種關聯設計的出現會變得更加糟糕。

Ken Hines


副總裁兼首席專家


Ross Ortega


副總裁兼技術總監


Consystant Design Technologies公司

值得慶幸的是,現在一種新的方法可以處理這種複雜的情況,名為Hines-Ortega的新設計方法可使設計人員工作於更高的抽象層級上。基本上,Hines-Ortega讓設計人員能更有效地進行開發、測試及除錯複雜軟體,而不必理會低層的實現問題。這種以協同為中心的方法使設計人員可將功能行為與各軟體組件的協同性分開,進而簡化了設計和除錯,加快了與硬體整合的速度,使程式碼得以重新利用,同時也使嵌入式設計能輕易地再使用於不同的硬體平台上。

在嵌入式系統設計中,軟體一般都落後於硬體的開發,而且這也一直是嵌入式系統產品進度拖延和發佈延誤的主要原因。僅管許多公司都要求產品應盡快上市,但嵌入式軟體設計人員卻發現自己受到設計方法的禁錮,往往要被迫等到硬體到位後才能著手進行開發;而當他們好不容易可以開始軟體開發時,又發現每一項都需要作專門設計,因為以往計劃中本來可以利用的軟體與具體的系統配置聯繫非常緊密,要想重新使用不是那麼容易。

那些完全利用嵌入式系統來製造不同產品的公司則要冒更大的延誤風險,傳統的開發方式在越來越緊的時間壓力下已不具時效性,事實上,朝向多種不同處理器結構發展的趨勢,為開發過程帶來了很沉重的負擔。

系列處理器

在系統結構上,開發人員正在尋找一系列低成本專用處理器,以用於網路、圖形處理和數位信號等應用領域中。與採用一種昂貴的通用處理器相比,這類專用處理器能保証提高系統性能,並降低整體成本。不過,對嵌入式系統開發人員來說,有潛力目標架構的不斷成長已對市場上的開發資源和開發能力構成了威脅,因為半數以上的嵌入式產品開發進度都已經延後了好幾個月。

連鎖效應

的確,在開發後期產生硬體設計變更,會給採用多種分散式網路處理器的設計帶來嚴重的問題。在傳統開發方式中,基礎硬體的任何改變都會引起相關軟體產生大的變化,這是因為開發人員不能將軟體功能與硬體低層之間的聯繫以及與其它軟體組件分開,與硬體相關的通訊和控制過程與軟體功能緊密結合在一起,所以硬體配置產生任何變化都會要求軟體做出大的修改。

除了因應複雜的多處理器結構帶來的設計挑戰以外,產品開發人員還認為傳統的開發方式使他們在開發時有些力不從心。通常採用這類結構的公司都設立獨立的開發小組來進行開發,各組負責一種專用類型處理器。在這種情況下,各開發小組在系統級上會缺乏一致的看法,有關系統級的考慮因素常被忽略,或者最多也只能折衷採納。整個開發會因此受損而達不到最佳狀態,由於常常要應付因某個子系統變化連鎖影響到另一些子系統而暴露出來的問題,軟體再使用和轉向其它平台的想法也被淹沒在實現設計所需的無數瑣碎事情之中。

嵌入式系統軟體的效率取決於軟體功能與實現細節的分離,包括各組件同其它應用組件、服務例程、作業系統軟硬體資源等的相互協同關係。Hines-Ortega方法包含了這種將功能與協同分離的思路,為實現功能與交互的分離,該新方法在嵌入式設計中引入了一種更高級抽象概念。新方法為可視化設計、模擬、系統級除錯、目標平台選擇以及程式碼合成提供了一種概念性架構。

根據Hines-Ortega方法,開發人員分兩個階段進行嵌入式系統設計,即與目標對象無關階段和與目標對象有關階段。在前一階段中,開發人員將系統設計為一個抽象模型,並對系統模型和執行情況進行模擬和除錯,以確保它在模組級執行正確;在後一階段?,開發人員將藉由驗証的設計和具體硬體資源聯繫起來,根據映射模型自動產生針對具體平台的C或Java碼,可以利用現成的程式碼,並進行正常的單元和系統測試。

能否完成這兩個階段取決於開發人員構造嵌入式系統抽象模型的能力,這種抽象模型將各組件的軟體功能行為與描述各組件間相互作用細節的軟體交互相隔離。各組件通過相關協同介面進行交互。協同介面又將各組件與協同程式相連,協同程式對組件間可能產生的連接、狀態和交換處理等都作了明確的描述。

以協同為中心的處理方法強調鬆散組合軟體組件間的直接協作,而把具體實現的問題向後推,這樣軟體開發人員就能在系統開發的早期開始設計軟體,既與硬體開發同步又獨立於具體的實現細節。

實際上,以協同為中心的方法有助於開發人員專注於應用上的問題,而不是實現細節,從而提高工作效率。例如建立一個循環調度程式,開發人員可以做一些通過協同介面與某個協同程式通訊的組件,協同程式包含了所有和循環調度程式協議有關的資訊。

按這種處理方法,任何一個組件都無需參照其它組件,事實上各組件甚至都不用知道它們在某個循環協議中正在與別的組件協作。因此開發人員可以專注於應用的要求,而不是糾纏於相互作用協議和實施細節。協同程式本身會處理所有所需的參考資訊,如果應用需要改變調度程式協議,變更也只限於協同程式和協同介面。

獨立行為

抽象系統模型設計好以後,開發人員就可以通過對模型進行模擬和除錯來驗証組件功能的協同正確性。以協同為中心的設計具有很強大的系統級除錯能力,同時能在系統級觀察各軟體模組,使開發人員在必要時容易地進入到各層軟體找出並解決問題。而最重要的是,這種能力完全獨立於實現方法。

這種抽象設計甚至可在不同的多處理器平台或單處理器平台上實現,在第二階段的最後一步,開發人員將組件和協同程式反映到具體目標平台資源上,如通訊通道、子系統和處理器等,代碼合成階段產生針對給定硬體和作業系統的軟體,無需中間的軟體抽象層。換句話說,產生的軟體可直接調用本身的作業系統以發揮出其功能和獨特的性能。

這種將相互作用與功能分離的能力使得以協同為中心的方法有別於另外兩個常用系統設計方法,即面向對象的設計方法(OOP)和統一建模語言(UML)。

開發人員用OOP定義一組介面,使一個對象在另一個對象前面就像是一組方法或過程。從理論上講,OOP傳統的動態類型檢查功能允許對象相互作用而無需事先知道作用規則,但實際上動態類型檢查已經讓位給靜態類型檢查以保証相互作用的可預測性。使用靜態類型檢查就要求對象要包含其它對象使用方法的一些資訊。




投票數:   加入我的最愛
我來評論 - Hines-Ortega方法簡化複雜的軟體設計問...
評論:  
*  您還能輸入[0]個字
*驗證碼:
 
論壇熱門主題 熱門下載
 •   將邁入40歲的你...存款多少了  •  深入電容觸控技術就從這個問題開始
 •  我有一個數位電源的專利...  •  磷酸鋰鐵電池一問
 •   關於設備商公司的工程師(廠商)薪資前景  •  計算諧振轉換器的同步整流MOSFET功耗損失
 •   Touch sensor & MEMS controller  •  針對智慧電表PLC通訊應用的線路驅動器
 •   下週 深圳 llC 2012 關於PCB免費工具的研討會  •  邏輯閘的應用


EE人生人氣排行
 
返回頁首