2.2.1 嵌入式通信系統的開發過程
嵌入式通信系統是專用的計算機系統，運行在特定的目錄環境中，需要同時滿足功能和性能等方面的要求。在嵌入式通信系統的開發過程中，要考慮實時性、可靠性、穩定性、可維護性、可升級、可配置、易于操作、接口規范、抗干擾、物理尺寸、重量、功耗、成本、開發周期等多種因素。在建立一個完整的嵌入式系統或者產品時必須要考慮一些設計的重點。
良好的設計方法在嵌入式通信系統的開發過程中是必不可少的。首先，好的方法有助于規劃一個清晰的工作進度，避免遺漏重要的工作，例如性能的優化和可靠性測試對于一個合格的嵌入式產品而言是不可或缺的。其次，采用有效的方法可以將整個復雜的開發過程分解成若干可以控制的步驟，通過現代一些先進計算機輔助設計工具的輔助，可以按部就班、有條不紊地完成整個項目。最后，通過定義全面的設計過程以使整個開發團隊的各個成員更好地理解自身的工作，方便成員之間相互交流和協作。在嵌入式通信系統的開發過程中，團隊的概念至關重要。圖2-1所示嵌入式通信系統開發的一般過程。嵌入式通信系統設計過程一般由5個階段構成：需求分析、體系總體設計、硬件/軟件設計、系統集成和系統測試。
圖2-1 嵌入式通信系統開發的一般過程
1.需求分析與規格說明階段
需求分析階段需要確定設計任務和設計目標，并提煉出設計規格說明書，作為正確設計指導和驗收的標準。區分需求和規格說明是必要的，因為在客戶關于所需系統的描述和體系結構系統設計師所需的信息之間存在極大的距離。
嵌入式通信系統的客戶通常不是嵌入式通信系統的設計人員，甚至也不是最終產品的設計人員，他們對嵌入式通信系統的理解是建立在他們想象的與系統之間的交互的基礎上的，對系統可能有一些不切實際的期望，或者是使用他們自己的話而不是專業術語來表達其需求。將客戶的描述轉化為系統設計者的描述的結構化方法就是從客戶的需求中獲取一組一致性的需求，然后從中整理成正式的規格說明。
設計系統之前，必須先了解需要設計哪些部分，所以設計過程的首要步驟就是捕捉有關系統與組件建立的消息。通常處理的過程分為兩個階段：第一階段是收集客戶所描述的消息，整理成需求列表；第二階段就是把這些需求進一步萃取之后，定成規格，這些規格就是系統架構設計的數據。需求分析是指從用戶那里搜集系統的非形式描述。以此為基礎經過進一步提煉得到系統的規格說明，并以此來設計系統的體系結構和系統構件。
通常，和關心用戶僅了解實際使用問題和需要具備的功能，但是往往不能完整、準確地表達這種需求，更不清楚怎樣利用計算機去實現所需的功能。為了對系統進行準確無誤地定義，要求開發人員和用戶之間充分進行交流，開發人員需要詳細考察，最終得出經用戶確認的、明確的系統實現邏輯模型。
需求可分為功能部分和非功能部分。功能性需求是指系統必須要有哪些功能；非功能性需求則是指其他因素，比如大小、價格、設計時間等。常見的非功能性需求包括：
①性能：系統的速度是系統可用性與最后價格的主要考慮對象，所表現出來的性能也往往包含軟件程序使用狀況，與某些操作必須在期限時間內完成的綜合表現。
②成本：系統最后的價格是很重要的因素，成本主要來自兩方面：制造成本，包括零件價格與組裝成本；客戶委托制造成本，包括人力與設計系統的其他成本。
③實體大小與重量：外觀的大小和應用有很大的關系，以工業控制系統中組裝在線的機器來說，大小必須和機架相同，否則會裝不進去。至于手持式的設備，也必須考慮重量，否則會有超重的情況。
④電力消耗：對于使用電池的系統來說，必須注意電力消耗的問題，否則產品使用的時間會很短，在使用上就不夠方便。
確認需求最好的方法是建立模型。模型可以使用原始數據來模擬功能，并可以在計算機上運行。模型還應讓用戶了解系統是如何工作的，以及用戶如何與系統交互。通常系統的非功能模型可以讓用戶了解系統的特性。
對一個大型的系統進行需求分析是一件煩瑣的工作，可以從先獲取相對少量的、簡單的信息入手。表2-1所示為一個簡易需求表格樣本，可以利用它思考系統的基本特性，并且整理成列表。
表2-1 需求表格樣本
①名稱：給項目取一個好的名稱，可以使設計目的更加明確，也便于交流、討論時使用。
②目的：用最精練的語言來描述清楚系統需要滿足的需求。
③輸入和輸出：系統的輸入和輸出包含了大量的細節，如數據類型，包括模擬信號、數字信號、機械輸入等；數據特性，包括周期性或非周期性數據、用戶的輸入、數據位數等；I/O設備類型，包括按鍵、ADC、顯示器等。
④功能：功能的描述可以從對輸入到輸出的分析中得出，如當系統接收到輸入時，執行哪些動作，用戶通過界面輸入的數據如何對該功能產生影響，不同功能之間如何相互作用。
⑤性能：系統控制物理設備或者處理外界輸入的數據都需要花費一定的時間。在大部分情況下，嵌入式通信系統在計算時間上都有要求，因此從需求分析開始，這種性能的要求就必須明確，并在執行過程中加以認真考慮，以便隨時檢查系統能否滿足其性能要求。系統的處理速度通常又是系統實用性和成本的主要決定因素。在大多數情況下，軟件的性能在很大程度上決定了系統的性能。
⑥生產成本：產品的成本會影響其價格。成本包含兩個主要部分：生產成本，包括購買構件以及組裝費用等；不可再生的工程成本，包括人力成本以及設計費用等。生產成本主要包括的是硬件成本。通過對硬件成本的估計，可以大略估計產品形成后的價格；或者基于產品最終的粗略價格來計算構建系統可以使用的硬件構件，因為價格最終會影響系統的體系結構。
⑦功耗：由電池供電的系統必須對功耗問題認真考慮。而系統的功耗需要在設計開始時就要至少有一個粗略的了解。通常，基于這種了解可以使開發者決定系統是采用電池供電還是采用市電。
⑧物理尺寸和重量：產品的物理尺寸和重量因使用領域的不同而不同。例如，對飛機上的電子設備，其重量應嚴格限制。又如，手持設備對系統的物理尺寸和重量都有嚴格限制。對系統的物理尺寸和重量有一定的了解有助于系統體系結構的設計。
最后需要注意的是，這些需求的內容是不是有相互沖突的狀況，例如模塊之間的接口不兼容或者系統操作的不合理狀況。綜合來說，一個好的需求文件應該具有以下幾項特性：
（1）正確性：一個需求描述不可以誤解顧客所需，也不應該過分描述顧客不需要的需求。
（2）精確性：需求文件應該做清楚的描述，而不是籠統的說明。
（3）完整性：所有需求都應該記錄。
（4）一致性：一個需求不能和另一個需求相矛盾。
（5）可證明性：所有的需求都應該有方式可以證明這行需求是合理的，像是文件里就不應該出現“親和的界面”這類文字，因為無法定義什么叫作親和的界面。
（6）可修改性：需求文檔應結構化，以便在不影響一致性、可檢驗性等情況下可以被修改以適應變化的需求。
（7）可追蹤性：每份文件都應該可以追蹤，包括為什么會有這樣的需求，彼此需求間的相關性，這些需求是否可能實現，以及最后是否滿足這些要求。
如何界定需求呢？在大公司里，銷售部門會幫忙反映市場的需要，或者去咨詢顧客，然后將這些意見匯整進行分析。如果是顧客直接找上門，就需要和顧客進行訪談，以了解他們的期望。如果顧客能夠給設計者一個簡單的樣品，將可以使設計者更清楚應該要設計出什么樣的產品。或者設計者先做出一個雛形，請銷售部門進行展示或者進行意見調查，然后再將結果進行分析來決定需求的內容。
規格說明是需求分析的進一步細化，實際上可以看作是甲乙雙方的合同。系統開發過程中可能碰到各種不同類型的由于不明確的規格說明而導致的問題。如果行為在規格說明中不明確，就可能導致功能的錯誤。如果規格說明不完整，那么所開發建造的整個系統體系結構可能就不能完全達到客戶的要求。
2.體系結構設計階段
體系結構設計階段描述系統如何實現所述的功能性和非功能性需求，體系結構描述必須同時滿足功能上和非功能上的需求。必須符合成本、速度、功率和其他非功能上的約束，包括對硬件、軟件、執行裝置功能的劃分以及系統的硬件、軟件選型等。逐步把系統體系結構細化為硬件和軟件體系結構。首先集中考慮系統框圖中的功能元素，然后在建造硬件和軟件體系結構時考慮非功能約束。
如何知道硬件和軟件體系結構實際上符合速度、成本等方面的限制呢？
①必須有某種方式估算框圖中的構件，如移動地圖系統中的搜索和繪制功能的特性。
②精確估算源于經驗，既有一般的設計經驗也有類似系統的特定經驗。
3.構件設計階段
可以直接使用一些標準構件，構件通常包括硬件和軟件兩部分。如果采用標準數據庫，就可以用標準例程對該數據庫進行訪問。這些數據庫中的數據不僅使用預定義的格式，而且被高度壓縮以節省存儲空間。在這些訪問函數中使用標準軟件不僅節約設計時間，而且有可能較快地實現像數據解壓縮這樣的專用函數。但很多時候必須自己設計構件，如PCB、做大量定制的函數等。在設計期間，經常會利用一些計算機輔助設計工具和開發平臺，并且對每個構件都需要進行功能和性能等方面的測試。嵌入式系統的設計還要求有較高的設計技能，在設計軟件時要非常小心地讀/寫存儲器以減小功耗。由于存儲器訪問是主要的功耗來源，因此存儲器事務必須精心安排以避免多次讀取同樣的數據。
4.系統集成階段
把系統的軟件、硬件和執行裝置集成在一起，進行調試，發現并改進單元設計過程中的錯誤。系統集成一般是指硬件與軟件的集成，實際上集成的對象應包括：嵌入式操作系統、板級支持包（BSP）、硬件、軟件和實時特性。實時特性對嵌入式系統來說是相當重要的，硬件可以像設計所要求的一樣操作，軟件也可以像編寫及調試所要求的一樣運行，而產品卻可能會由于實時性問題依然無法運行。
使用商業標準硬件平臺，如單板機，廠商會提供板級支持包，沒有板級支持包，嵌入式操作系統就不能在目標平臺上運行。就算擁有設計良好的板級支持包，當嵌入式操作系統運行時仍有許多問題亟待解決。由于嵌入式操作系統是嵌入式產品中最重要的部分，任何關于工具需求的討論都必須在嵌入式操作系統的背景中進行。
假設在通用計算機上調試C語言程序時，使用的是GNU編譯器和調試器：GCC和GDB。當停止應用程序檢查變量值時，計算機并沒有停下來，只是被調試的應用軟件停止了運行，而計算機的其余部分仍像剛才一樣正常運行。如果程序破壞了某個UNIX平臺，計算機就會轉儲此平臺的核心映像，但計算機本身仍在正常運行。
如果沒有采用嵌入式操作系統，當程序崩潰后，嵌入式系統也就停止了運行，直到重新開機或按下復位鍵。如果系統采用了嵌入式操作系統，并且開發工具可以在嵌入式操作系統環境下使用，就極有可能具有中斷正在運行的進程，并且按照在調試主機上的調試過程進行調試的能力。盡管是正在調試的某個處于調試器控制之下的進程，嵌入式操作系統也能保持其剩余部分最大限度地正常工作。由于要完成以上工作非常困難，所以嵌入式操作系統開發商要精心制作在嵌入式操作系統環境中支持調試功能的工具，并以獨一無二的定位把產品提供給用戶。因此，一旦決定采用哪種嵌入式操作系統，就會在整個嵌入式系統的設計開發過程中產生連鎖反應。當將嵌入式操作系統、應用軟件與硬件集成到一起時，這種影響會最大限度地表現出來。
如果開發工具設計得很好，就能最大限度地降低使用嵌入式操作系統的復雜度；如果沒有合適的開發工具，調試采用嵌入式操作系統的嵌入式系統是十分困難的。
5.系統軟件測試階段
軟件測試是軟件生存期中的一個重要階段，是保證軟件質量的關鍵步驟，1983年IEEE提出的軟件工程術語中給軟件測試做出如下定義：“使用人工或自動手段運行或測定某個軟件系統的過程，其目的在于檢驗軟件系統是否滿足規定的需求或弄清預期結果與實際結果之間的差別”。這個定義明確指出軟件測試的目的是為了檢驗軟件系統是否滿足需求。也就是說，軟件測試是在軟件投入運行前，對軟件需求分析、設計規格說明和編碼進行最終復審的活動。