機載軟件耦合覆蓋方法分析和設計

中國航空工業集團公司第一飛機設計研究院 陳剛 羅旭升

民用飛機機載軟件適航對RTCA DO-178C 的使用，與DO-178B 相比提高了軟件驗證工作中耦合覆蓋的要求。本文以DO-178C 對耦合覆蓋的要求為基礎，分析并提出了一種能夠滿足目標要求的控制耦合和數據耦合分析方法，同時對商用工具的選擇和工具的鑒定考慮給出了可行的建議，對我國民用飛機機載軟件符合性舉證過程具有重要的參考意義。

民用飛機機載軟件適航標準RTCA DO-178C 中對A、B、C 等級的軟件均提出了耦合覆蓋（包括數據耦合和控制耦合）的要求[1]，其初衷在于評估測試的充分性。DO-178C 中對于數據耦合和控制耦合的定義如下：

數據耦合：由于軟件組件中某數據不完全受控于本組件而導致的對其他組件的依賴性。

控制耦合：一個軟件組件影響另一個軟件組件執行的方式或程度。

傳統的軟件研制過程一直強調高內聚、低耦合，其耦合也是依賴性的概念，強調軟件設計過程中對函數、類或組件封裝過程中應降低數據依賴及控制依賴。這兩個概念的相似性導致一部分供應商通過軟件設計標準或編碼標準的方式提高軟件設計的內聚性來滿足目標要求，還有一部分供應商會通過設計評審和代碼評審的方式來滿足目標要求。

實際上，盡管耦合的概念類似，但DO-178C 提出該目標的目的并非為了降低組件間的耦合性，而是為了確認代碼耦合關系與設計耦合關系的一致性，從而發現：

（1）測試的不充分；

（2）代碼實現的多余功能。

DO-248C FAQ #67[2]雖然就該問題進行了解釋，但其重點在于解釋數據耦合和控制耦合的具體含義，并結合代碼邏輯進行了說明，卻仍然未能明確給出DO-178C 提出該目標的意義及其與傳統耦合性之間的區別。本文在研究DO-178C 及相關標準的基礎上，進一步闡明了耦合覆蓋分析的目的，并提出了一種能夠滿足該目標的人工執行方法。

1 DO-178C 的耦合覆蓋目標分析

DO-178C 中的耦合覆蓋目標內容如下：

軟件測試的結構覆蓋率（數據耦合和控制耦合）達標。

由目標可知，DO-178C 中所提的數據耦合和控制耦合僅僅是結構覆蓋率分析準則的一種，同樣的結構覆蓋率分析準則還包括語句覆蓋、判定覆蓋和MC/DC 覆蓋，不同的準則覆蓋了代碼的不同結構。結構覆蓋率的目的在于為測試充分性提供一定程度的度量，分析基于需求的測試是否能夠覆蓋所有的代碼結構（語句、判定、條件、數據關系、調用關系等）。而數據耦合和控制耦合對應的代碼結構即不同軟件組件之間的數據依賴關系和控制依賴關系。

正常情況下，語句、DC 及MC/DC 覆蓋率都會分別在組件級別的測試中進行收集后匯總得出分析結果。換句話說，軟件組件內部的結構覆蓋性可以因此得以保證，但是對軟件集成測試，也就是集成后組件和組件之間的結構關系并未進行覆蓋，而這也正是耦合覆蓋分析的主要目的，對不同組件之間的依賴關系進行結構覆蓋[3]。組件之間的依賴關系主要體現在以下幾個方面：

（1）軟件組件之間的調用關系；（2）通過任務調度、跳轉、中斷處理等觸發的軟件組件的執行關系；（3）軟件組件間的參數傳遞；（4）多于一個組件使用的全局變量。在耦合覆蓋分析之后，可以驗證軟件集成關系或依賴關系的正確性，同時證明軟件測試的充分性。耦合覆蓋分析結果與預期不符時，可能有兩種情況：

1）測試不充分，需增加需求及測試用例或單獨增加測試用例對未覆蓋的耦合關系進行覆蓋；2）代碼冗余，應修改代碼，去掉不應實現的依賴關系，若出于某種原因（如防御性編程）需要保留，應進行分析說明。

2 耦合覆蓋分析的執行方法

完成耦合覆蓋分析，需要完成以下幾個活動：

（1）耦合分析活動的計劃：在軟件驗證計劃中具體說明數據耦合分析及控制耦合分析的方法；

（2）標準約束：前文提到的在標準文件中增加設計約束的方法，雖不能單獨滿足耦合覆蓋目標，但仍然建議使用。可以大幅降低耦合覆蓋分析的復雜度，可以考慮的因素包括限制全局變量的使用、限制同一變量在多處賦值的情況、限制類型的強制轉換、限制直接跳轉語句的使用等；

（3）軟件架構設計：在軟件架構設計時，明確組件間的接口、調用關系、調度策略、中斷處理邏輯等。必要時采用控制流圖、數據流圖、時序圖等圖表方式表達；

（4）軟件設計評審：在軟件設計評審時，確認軟件架構設計的合理性和正確性；

（5）代碼耦合關系分析：提取源代碼中已經實現的組件間的調用關系、變量的定義和使用關系、數據流等耦合關系，必要時可采用圖形方式表達。一般情況下，這一步采用工具進行分析，若采用人工分析代碼的形式，需要滿足兩個條件：

1）使用第（2）步的標準約束大幅降低人工分析的復雜度。如果不加限制，對于多處寫一處讀和多處寫多處讀的情況，當讀寫次序發生變化時，可能造成極其復雜的情況，人工分析無法保證覆蓋所有可能的情況；2）源代碼量在可接受范圍以內。一般情況下，使用這一步驟分析得出的軟件間的耦合關系可以向軟件架構設計過程反饋，對于某兩個組件間關系過于復雜的情況，可以考慮將這兩個組件進行合并處理（可以使用工具的自動優化功能，優化出來的軟件架構可能從設計方面并不符合人工的設計習慣，但耦合關系能夠大為簡化，可以參考執行）。對軟件架構關系進行優化后，應從第(3）步重新開始執行；

（6）耦合覆蓋對比分析：在動態測試中使用插樁或使用工具統計耦合關系的覆蓋情況。將耦合覆蓋結果與預期結果（即第（3）步在設計階段明確的耦合關系）進行對比分析，主要關注以下方面[4]：

1）數據類型的一致性，即是否存在類型的隱式轉換，并分析其帶來的影響；2）數據含義的一致性，保證不同組件對同一個變量的含義有相同的理解和使用，好的變量名稱定義可以降低此類錯誤發生概率；3）確認數據依賴的類型（如圖1所示四種類型，指向Data 的表示數據的寫入方，Data 指向的為數據的讀取方），保證組件之間的數據寫入和讀取順序與設計相一致，存在多方讀操作或多方寫操作時，操作順序與設計結果一致；4）組件間調用關系、執行次序與設計一致；5）組件之間的通訊時效性檢查（同步/異步，可能包含向寄存器或數據緩沖區的寫入和讀取操作）。

圖1 四種數據依賴類型Fig.1 Four data dependency types

需要注意的是，在使用基于需求的測試對組件間的依賴關系進行覆蓋時，也應同時考慮需求正常范圍和異常范圍的測試。另外，數據耦合覆蓋分析和控制耦合覆蓋分析是兩個獨立的驗證方法，美國FAA 的立場文件CAST-19 中認為應該生成兩個獨立的報告。以DO-178C 的一貫作風，其實一個完整報告還是分開為兩個報告并不重要，重要的是認識到這兩個驗證活動的獨立性，即使生成同一報告也應該分章節對不同的覆蓋準則進行描述和匯總。

3 工具選擇及工具鑒定考慮

除上文所述方法外，由于軟件結構復雜度的影響，很多情況下即使對軟件架構進行了優化，仍然會有很高的耦合分析復雜度，此時最好的方法就是使用成熟商用工具，這也是國內外大部分民用飛機設備供應商的選擇。在商用工具的選擇方面，建議考慮以下幾點：

（1）組件定義的靈活程度：不同項目對組件的劃分方法不同，有的項目以文件為基本單元劃分不同組件分別包含哪些文件，有些項目則喜歡以函數為基本單元劃分組件。由于使用工具之前需要指定不同組件所包含的內容（如包含哪些文件或包含哪些函數），因此更靈活的組件定義方法可以適用于更多的機載軟件研制項目；

（2）是否能用于架構優化：耦合分析工具能夠根據軟件源代碼以及用戶對組件的定義分析得出現有的軟件組件間耦合關系。部分工具還帶有架構自動優化功能，可以指導用戶進一步優化軟件架構，簡化組件間的耦合關系；

（3）耦合關系識別的全面程度：耦合分析工具是否考慮了本文第2 節提出的所有可能關系，如分析不全面，仍需人工分析進行補充；

（4）插樁代碼量：插樁的代碼量關系到對源代碼結構的影響，如果插樁的代碼量較大，意味著插樁后代碼與原軟件產品的差異越大，局方給與的置信度也會越低。因此在選擇工具時，必須考慮插樁代碼對源代碼結構的影響問題；

（5）耦合報告內容詳細程度：為支持耦合覆蓋分析結果（如覆蓋率百分比），對已覆蓋的耦合關系應給出耦合關系類型（如讀寫耦合、調用耦合等）、對應代碼位置、覆蓋該關系的測試用例等信息，對于未被覆蓋的耦合關系也應至少給出耦合關系類型和對應的代碼位置，以便于分析該段代碼對應的需求完整程度或測試用例完整程度。

對于工具鑒定，RTCA DO-178C 中明確，如果滿足以下兩個條件，則需要對工具進行鑒定：

（1）由于工具的使用，造成了某個過程的自動執行、減少執行或不執行；（2）不會對工具的輸出進行驗證。

以耦合覆蓋分析工具為例來說，該工具的使用是為了替代人工，也就是用于自動執行分析過程的。因此，如果我們信任工具的結果，不對結果進行再次核對和檢查，則該工具需要執行工具鑒定。反過來說，如果該工具未進行鑒定，且不打算隨機取證，則需要工具提供足夠的中間數據，用以支撐用戶對其結果進行核對和分析，從而人工確定其分析結果的正確性。

4 結語

軟件的數據耦合覆蓋分析和控制耦合分析是結構覆蓋率分析的一種，是DO-178C 對A、B、C 級軟件的強制要求。隨著國內民機事業的不斷發展，搞清楚DO-178C 提出耦合覆蓋分析的目的，并知道如何去實施是勢在必行的事情。本文在研究DO-178C、CAST Paper 及相關報告的基礎上，提出了一種從計劃階段一直到驗證階段的符合性方法，并給出了耦合覆蓋分析的若干分析要點，同時對工具的選擇及鑒定考慮也給出了相關建議，對我國民用飛機機載軟件的耦合覆蓋分析舉證過程具有相當的指導意義。