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

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

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

數(shù)據(jù)耦合：由于軟件組件中某數(shù)據(jù)不完全受控于本組件而導(dǎo)致的對其他組件的依賴性。

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

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

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

（1）測試的不充分；

（2）代碼實現(xiàn)的多余功能。

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

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

DO-178C 中的耦合覆蓋目標內(nèi)容如下：

軟件測試的結(jié)構(gòu)覆蓋率（數(shù)據(jù)耦合和控制耦合）達標。

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

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

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

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

2 耦合覆蓋分析的執(zhí)行方法

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

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

（2）標準約束：前文提到的在標準文件中增加設(shè)計約束的方法，雖不能單獨滿足耦合覆蓋目標，但仍然建議使用?？梢源蠓档婉詈细采w分析的復(fù)雜度，可以考慮的因素包括限制全局變量的使用、限制同一變量在多處賦值的情況、限制類型的強制轉(zhuǎn)換、限制直接跳轉(zhuǎn)語句的使用等；

（3）軟件架構(gòu)設(shè)計：在軟件架構(gòu)設(shè)計時，明確組件間的接口、調(diào)用關(guān)系、調(diào)度策略、中斷處理邏輯等。必要時采用控制流圖、數(shù)據(jù)流圖、時序圖等圖表方式表達；

（4）軟件設(shè)計評審：在軟件設(shè)計評審時，確認軟件架構(gòu)設(shè)計的合理性和正確性；

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

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

（6）耦合覆蓋對比分析：在動態(tài)測試中使用插樁或使用工具統(tǒng)計耦合關(guān)系的覆蓋情況。將耦合覆蓋結(jié)果與預(yù)期結(jié)果（即第（3）步在設(shè)計階段明確的耦合關(guān)系）進行對比分析，主要關(guān)注以下方面[4]：

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

圖1 四種數(shù)據(jù)依賴類型Fig.1 Four data dependency types

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

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

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

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

（2）是否能用于架構(gòu)優(yōu)化：耦合分析工具能夠根據(jù)軟件源代碼以及用戶對組件的定義分析得出現(xiàn)有的軟件組件間耦合關(guān)系。部分工具還帶有架構(gòu)自動優(yōu)化功能，可以指導(dǎo)用戶進一步優(yōu)化軟件架構(gòu)，簡化組件間的耦合關(guān)系；

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

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

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

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

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

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

4 結(jié)語

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