董亮，劉看旺

航空工業(yè)第一飛機設(shè)計研究院，陜西 西安 710089

需求管理是航空行業(yè)全面推行基于模型系統(tǒng)工程（MBSE）研制技術(shù)的關(guān)鍵技術(shù)領(lǐng)域，其建設(shè)和應(yīng)用面臨技術(shù)范圍定義、實現(xiàn)途徑規(guī)劃、軟件架構(gòu)選型、應(yīng)用模式選擇等問題。為了更好地選擇適合行業(yè)特點及發(fā)展水平的需求管理建設(shè)及應(yīng)用模式，本文對空中客車公司（空客公司）的需求管理發(fā)展進行了分析研究。

為了充分滿足市場的需要，應(yīng)對波音公司的挑戰(zhàn)，提高產(chǎn)品競爭力，空客公司十分重視對需求的管理，提出了基于需求的工程（Requirement Based Engineering， RBE）。RBE[1～3]始于1996年，在A380、A400M、A350等機型的研制中逐漸成熟，體系化于2006年（以AP1034-RBE Policy為代表）。空客公司的RBE借助IBM DOORS RMF需求管理平臺，在A380、A400M、A350等飛機研制中進行了應(yīng)用，覆蓋50多個主要供應(yīng)商、3000多個終端用戶，對減少研制后期的產(chǎn)品缺陷、減少額外費用、提高產(chǎn)品客戶滿意度方面取得了良好效果。

1 空客公司需求管理文件體系

1.1 總體文件體系

頂層飛機需求考慮飛機最終產(chǎn)品和使能產(chǎn)品的劃分進行定義。依據(jù)頂層飛機需求定義飛機總體功能，形成飛機功能需求文件（飛機級FRD），同時對于每個系統(tǒng)及結(jié)構(gòu)組成形成相應(yīng)的功能需求文件。由于設(shè)計理念、專業(yè)、方法的不同，機體結(jié)構(gòu)領(lǐng)域和系統(tǒng)領(lǐng)域的設(shè)計采用不同的設(shè)計規(guī)則，并形成不同的需求設(shè)計文件，如圖1所示，其中結(jié)構(gòu)設(shè)計對應(yīng)的頂層需求文件為TLStRD，系統(tǒng)設(shè)計對應(yīng)頂層需求文件為TLSRD。而結(jié)構(gòu)設(shè)計過程與系統(tǒng)設(shè)計過程的需求文件體系有所不同[4]。

1.2 結(jié)構(gòu)設(shè)計需求文件體系

針對結(jié)構(gòu)設(shè)計，基于TLStRD生成各個結(jié)構(gòu)部件的結(jié)構(gòu)需求文件（StRD），并進一步定義其對應(yīng)的結(jié)構(gòu)設(shè)計原則文件（RSDP），RSDP的內(nèi)容來自以前的飛機研發(fā)經(jīng)驗、重要的設(shè)計準則、最新的技術(shù)進步、最近制造和服務(wù)經(jīng)驗，主要內(nèi)容組成有通用設(shè)計準則、復(fù)材設(shè)計準則、金屬材料設(shè)計準則、組部件設(shè)計準則，如機身設(shè)計準則、機翼設(shè)計準則、尾段設(shè)計準則等[5]。其中，頂層結(jié)構(gòu)需求文件用于飛機主要部段的需求定義，如機翼、機身。結(jié)構(gòu)框架在設(shè)計之初就已經(jīng)確定，結(jié)構(gòu)設(shè)計領(lǐng)域的工作就是設(shè)計各主結(jié)構(gòu)的功能需求，并裝配成完整的飛機機體，達到裝配協(xié)調(diào)和功能承載[5]。結(jié)構(gòu)設(shè)計過程的需求文件相對簡單。在A400M項目的前機身研制中[4]，前機身的飛機組件管理團隊（ACMT）根據(jù)研制合同、頂層飛機需求頂層支持需求及空中加油、低位飛行、空中運輸投放等功能需求，定義前機身頂層結(jié)構(gòu)需求文檔，如圖2所示。這是在進行前機身下一層結(jié)構(gòu)組成需求定義（形成子部件需求規(guī)范）的基礎(chǔ)上，同時對他們直接的接口關(guān)系進行定義，形成相應(yīng)的接口定義文檔。

圖1 空客公司需求管理文件體系Fig.1 Requirement management fi les system in Airbus

1.3 系統(tǒng)設(shè)計需求文件體系

系統(tǒng)設(shè)計不像結(jié)構(gòu)設(shè)計，在設(shè)計之初沒有統(tǒng)一的系統(tǒng)架構(gòu)，而是從系統(tǒng)的功能需求開始，進行總體布局和設(shè)計，并經(jīng)過多次迭代才能形成。因此，系統(tǒng)架構(gòu)因系統(tǒng)需求不同而不同。相對而言，系統(tǒng)設(shè)計是現(xiàn)代飛機設(shè)計的難點和重點。因此，系統(tǒng)的需求文件體系相對復(fù)雜。

系統(tǒng)研制所涉及的各類需求文件按照系統(tǒng)工程過程進行傳遞演變，如圖3所示，各層級用到的空客公司文件見表1，分為程序（AP）、手冊（AM）、指令及指南（ABD）等三類文件。在飛機層主要指導(dǎo)文件為空客公司的AP2161與AP2245，用于對用戶需要的定義和管理，并將其轉(zhuǎn)換為上層需求。進入系統(tǒng)研制時，空客公司指導(dǎo)文件為AP2283、AP1013和ABD0200，上層需求要被分解分配到不同的系統(tǒng)，依次形成系統(tǒng)需求文件（SRD）和系統(tǒng)描述文件（SDD），通過對系統(tǒng)安裝方式及接口關(guān)系的分析定義，形成系統(tǒng)安裝需求卷宗（SIRD）和系統(tǒng)接口文件（SID），在此基礎(chǔ)上根據(jù)供應(yīng)商交付要求，定義采購技術(shù)規(guī)范（PTS）和設(shè)計規(guī)范（DFS）及設(shè)備安裝需求文件（EIRD）。各供應(yīng)商根據(jù)任務(wù)分工，定義形成供應(yīng)商設(shè)備規(guī)范（SES），該層對應(yīng)的空客公司指導(dǎo)文件為ABD0100[6，7]。

圖2 A400M前機身需求文件層次關(guān)系Fig.2 The requirement fi les of A400M front fuselage

在這個過程中的確認活動包含需求確認和產(chǎn)品確認。需求確認包含：確認各系統(tǒng)對上層需求的接受、確認上下游需求的一致性、確認衍生需求、確認假設(shè)、確認供應(yīng)商需求與對應(yīng)PTS的一致性等。產(chǎn)品確認包含：結(jié)合系統(tǒng)產(chǎn)品對SRD、SDD、PTS進行補充確認，對系統(tǒng)產(chǎn)品與用戶需要的一致性進行確認等。

在這個過程中的驗證活動自底向上進行，包含針對供應(yīng)商交付產(chǎn)品的PTS及SES驗證，針對設(shè)備安裝的EIRD驗證，針對系統(tǒng)安裝的SIRD及SID驗證，針對系統(tǒng)產(chǎn)品的SRD驗證等[6]。

圖3 需求確認與驗證過程及對應(yīng)的主要標準文件Fig.3 The main standard documents during requirements conf i rmation and verif i cation process

表1 部分需求管理相關(guān)的標準文件Table 1 The main standard documents related to requirement management

2 空客公司需求管理實施過程

2.1 功能需求管理

空客公司在功能需求管理過程中，將飛機劃分為4個層次，如圖4所示，覆蓋飛機頂層到供應(yīng)商的功能分解過程。

以飛機頂層構(gòu)件為例，在飛機頂層功能分解過程中，根據(jù)飛機的功能樹分解和運行場景分析，定義飛機初步功能及每個生命周期的用例定義?；谟美捎美?guī)范，形成基于黑盒模型的需求分配，輸出初步的飛機級FRD。針對特定用例進行，詳細用例場景定義，形成包含架構(gòu)選擇的白盒場景，并進一步通過需求分配，明確飛機的系統(tǒng)組成及系統(tǒng)對應(yīng)需求，形成各系統(tǒng)初步的FDD。

在整個飛機研制過程，功能逐層分解，以遞歸的方式進行細化，以分配的需求為源，經(jīng)過邏輯架構(gòu)設(shè)計形成FRD或SRD，進一步通過物理架構(gòu)設(shè)計形成FDD或SDD，同時根據(jù)確定的設(shè)計方案進行分配，形成下一層產(chǎn)品結(jié)構(gòu)組成進行設(shè)計的分配需求。在各層邏輯架構(gòu)設(shè)計和物理架構(gòu)設(shè)計過程中，大量的衍生需求也將被納入需求文件。

2.2 安全性需求管理

在空客公司的安全性需求管理體系中，主要的文件組成及層級關(guān)系如圖5所示。美國汽車工程師協(xié)會（SAE）提出的ARP 4754和ARP 4761是開展安全性需求管理工作最頂層要求。空客公司在此基礎(chǔ)上分別制定了面向系統(tǒng)和系統(tǒng)設(shè)備層面的操作指導(dǎo)文件ABD0200和ABD0100文件。而在最底層具體的設(shè)備軟硬件開發(fā)過程中，則以RTCA的DO-178C和DO-254分別進行軟硬件開發(fā)過程進行嚴格的指導(dǎo)和約束，應(yīng)用DO-160進行具體的測試過程控制。

圖4 飛機功能分解層級劃分Fig.4 Aircraft functional decomposition levels

圖5 安全性需求控制文件Fig.5 Safety requirements control fi les

2.3 機載軟件需求管理

在機載軟件開發(fā)過程中[7]，同樣采用需求管理進行控制，實現(xiàn)需求到測試、代碼的傳遞控制，機載軟件需求管理的文件組成及相互關(guān)系如圖6所示。設(shè)備層分配的需求是源頭，SRD_Global 只存在于當(dāng)軟件由多個組件組成的情況，組件表示可執(zhí)行單元，如CPU、進程或分區(qū)。該文檔是軟件分析和設(shè)計活動的結(jié)果，定義了分配給軟件的需求及軟件的高層需求，高層需求隨后將被分配給不同的組件。而這些被分配的需求將在每個SRD_xxx（對應(yīng)組件xxx）中進行重復(fù)。SRD_xxx是組件需求分析活動的結(jié)果，是對組件相關(guān)高層次需求的分組。需求要和SRD_Global中的高層次需求、詳細系統(tǒng)規(guī)范中的分配需求和衍生需求相一致，隨后，動態(tài)設(shè)計與靜態(tài)設(shè)計活動的結(jié)果是分別產(chǎn)生SDDDYN和SDDSTAT，定義與高層次需求一致的實體，也包含低層次（SDDDYN和SDDSTAT）的衍生需求及高層次（SDDDYN）衍生需求。Code源自靜態(tài)設(shè)計，通過轉(zhuǎn)化規(guī)則（自動或非自動）得到。靜態(tài)設(shè)計與Code間的追蹤性是隱含的。單元測試計劃（PTU）覆蓋低層次設(shè)計需求，靜態(tài)設(shè)計與PTU的追蹤性是隱含的，通過命名規(guī)則識別。

圖6 機載軟件開發(fā)需求文件組成Fig.6 Requirements fi les for airborne software development

組件xxx的驗證測試計劃（SDCP_xxx）覆蓋了只用于集成驗證的高層次需求和低層次需求。整個軟件的確認測試計劃（SDCP）覆蓋了SRD_Global中并未被測試（指組件驗證測試或其單元測試）的高層次需求。而軟件的需求傳遞過程如圖7所示，包含需要分析、組件分析、組件設(shè)計、組件編碼、驗證與確認、組件測試、衍生需求分析等活動。

圖7 機載軟件需求傳遞過程Fig.7 The delivery process of airborne software requirements

3 需求管理軟件架構(gòu)

空中客車防務(wù)及航天公司負責(zé)國防和航空航天產(chǎn)品及服務(wù)的公司，是空中客車集團旗下三大子公司之一，主要負責(zé)軍用運輸機、衛(wèi)星、運載火箭、衛(wèi)星運營與服務(wù)、戰(zhàn)斗機、導(dǎo)彈系統(tǒng)、防務(wù)電子等產(chǎn)品。其在需求管理方面主要采用的軟件解決方案如圖8所示，各組成軟件信息見表2。

圖8 需求管理軟件架構(gòu)Fig.8 The software architecture of requirement management

表2 需求管理架構(gòu)相關(guān)軟件組成Table 2 The main software for requirement management

在空客公司民用飛機機載軟件研制中，按照設(shè)計支持、需求追蹤、代碼生成、規(guī)則驗證、測試環(huán)境、過程控制與構(gòu)型管理等業(yè)務(wù)進行系統(tǒng)架構(gòu)設(shè)計，具體的軟件選擇如圖9所示。

圖9 機載軟件需求管理軟件架構(gòu)Fig.9Requirements management software architecture for airborne software development

4 結(jié)束語

空客公司需求管理經(jīng)過多個型號十余年的發(fā)展，逐步構(gòu)建了一整套相對完善的需求管控體系，形成了包含需求管理文件組成體系、需求管理控制流程、需求管理系統(tǒng)平臺等多個要素的解決方案。在RBE體系的分步、分線實施過程中，空客公司在飛機研發(fā)領(lǐng)域的優(yōu)勢進一步加強。但隨著基于模型的需求分析與架構(gòu)設(shè)計、多學(xué)科綜合仿真分析技術(shù)等基于模型系統(tǒng)工程新技術(shù)的進一步發(fā)展，需求數(shù)據(jù)還需要進一步與產(chǎn)品設(shè)計的其他過程及研制數(shù)據(jù)進行更加深入的關(guān)聯(lián)，才能真正實現(xiàn)需求驅(qū)動的設(shè)計。這些新技術(shù)與傳統(tǒng)研制體系的融合，正逐步成為數(shù)字化發(fā)展的新方向。

[1] Roussel J C. Airbus presentation benefits of requirement engi-neering with DOORS [C] // Presentation at telelogic capital market event， 2005.

[2] John P F. Requirements based engineering for aerospace certif i cation projects [EB/OL]. http：//www.read bag.com/ n-w-c-de-f i lesrbe-handout-day2-abr.

[3] Alexander I. Requirements management with DOORS a success story [EB/OL]. http：//easyweb.easy net.co.uk/～iany/index.htm.

[4] Schulze S O. Systems engineering in der entwicklung des airbus A400M [EB/OL]. http：//www.fzt.haw-hamburg.de/pers/Scholz/dglr/hh/ text_2004_04_15_SystemsEngineering.pdf.

[5] 王慶林.飛機構(gòu)型管理[M].上海：上?？茖W(xué)技術(shù)出版社， 2012.WANG Qinglin. Aircraft conf i guration management [M]. Shanghai： Shanghai Scientific & Technical Publishers， 2012. （in Chinese）

[6] Richard S. Design and development of transport aircraft systems[EB/OL]. http：//www.fzt.haw-hamburg.de/pers/ Scholz/dglr/hh /poster_2008_10_30_Systeme.pdf.

[7] Patrick F. Traceability of software requirements why ? how ?A380 avionics software [EB/OL]. http：//adsabs.harvard.edu/abs/2000ESASP.457.355F.