基于模型的民机验证需求捕获及应用技术

2022-11-09郭泰钱馨宫綦任文明杨栓宝徐清刚

北京航空航天大学学报 2022年10期

郭泰钱馨宫綦任文明杨栓宝徐清刚

(1. 中国航空综合技术研究所, 北京 100028; 2. 中航西飞民用飞机有限责任公司, 西安 710089)

民用飞机作为典型的复杂产品系统,其研制过程具有规模庞大、要求众多、技术领先、界面复杂等显著特点[1]。整个研制过程涉及众多不同层级产品的集成和验证活动,以演示证明集成实现的实物产品对设计需求的符合性。基于需求的验证技术成为解决复杂产品研制过程中验证与集成的最佳实践方法,受到飞机制造商的广泛关注。

在验证规划方面,目前国外如波音、空客等公司对系统工程的运用较为成熟,在飞机产品研制早期的需求捕获过程中同步对验证活动进行了充分的考虑[2-3]。例如,空客公司要求针对每条需求识别相应的产品验证活动,形成验证需求,并经过设计团队、集成团队及试验团队的共同确认,作为后续验证活动开展的依据。此外,美军对于验证的考虑则是按照MIL-STD-961E 在需求文档中将验证内容作为单独章节,对设计需求的符合性方法进行规范性阐述[4]。 Chen 等[5]针对复杂产品研制提出了一种基于本体论的需求验证方法以更好地促进验证与产品设计的融合。随着不同型号研制中基于需求的系统工程方法的应用和经验的积累,国内对于飞机与系统的验证技术方面进行了积极的探索,逐步认识到在飞机产品研制早期阶段对于验证活动的充分规划和确认对于整个项目成功与否至关重要。根据SAE ARP 4754A需求确认与实施验证流程[6],徐万萌等[7]结合飞行管理系统的研制过程,给出了相应的需求确认及系统验证流程。许光磊等[8]则是基于模型的方式对航电系统验证技术进行了研究。

在需求捕获方面,随着基于模型的系统工程(MBSE)[9-11]的兴起,NASA、空客和波音均已在多个项目中成功应用MBSE 方法[12]。 Zhu 等[13]对基于模型的需求捕获方法进行研究,针对航电领域系统,提出了一种基于SysML 语言的功能性需求捕获方法。梅芊等[14]结合IBM Harmony MBSE方法论,开展了飞机功能架构定义方法研究,其中包括相关功能性需求的捕获。郑党党等[15]提出了飞机全生命周期基于模型的系统工程业务过程模型,并结合型号在需求捕获与分析、功能和架构设计过程中进行了应用。邓兴民等[16]对基于运行场景模型的需求捕获方法进行研究,并给出具体案例。谢陵等[17]则对面向需求捕获与确认的飞机场景进行分析,给出了场景划分层级及维度等构建要素。

针对传统验证工作开展中验证规划较为滞后、过分验证或验证不充分、对所需的验证资源考虑不全等问题,本文以基于系统工程的飞机产品研制为背景,对基于模型的验证需求捕获及应用技术开展研究,着眼于飞机产品研制早期,给出构建产品设计需求-验证需求-验证活动映射关系的完整技术思路,结合某型飞机起落架系统案例,对验证场景建模、验证需求捕获及验证计划和验证程序定义进行详细阐述。

1 验证需求的必要性

按照需求工程理论,验证活动在整个产品研制过程中越早开展越好,因为如果在产品几乎完成设计前才开展验证活动可能导致非常昂贵的设计更改甚至重新设计成本[18]。因此,验证活动应该在可行性研究阶段开始启动,并贯穿飞机整个产品研制过程,具体如图1 所示。在基于需求的系统工程实践中,为了表明最终实现的物理产品的正确性和完整性,设计团队需要对飞机产品设计过程中的每一条设计需求确定相应的验证方式,用于向客户或适航局方演示证明最终实现的物理产品已经正确、完整地满足了相应的设计需求。产品设计需求的不同验证方式组合需要进行全局性统筹规划考虑,这就要求在产品设计需求定义完成后,对需要开展的验证方式予以明确,以便指导后续不同类型、不同阶段验证活动的开展。

图1 验证活动与飞机产品研制对应关系Fig.1 Corresponding relationship between verification activities and aircraft product development

通常产品设计需求提出了产品的功能性及非功能性要求,而不对具体的产品实现方式及如何满足需求进行说明,但是为了保证设计需求的可实施性和可验证性,需要在需求属性中给出设计需求相应的验证方式,或称之为设计需求的符合性验证方法。验证方法的划分颗粒度一般较粗,只能给出验证活动开展的总体指导性概念和顶层规划,是后续制定的验证实施方案的顶层输入,并不能取代详细的验证实施方案和程序,更无法给出验证活动的成功准则,也不能确定产品最终设计是否能够充分满足设计需求。其可以被看成是设计需求的所有者向客户或利益关联方就设计需求的符合性方式所达成的协议。

因此,在设计需求与实施的验证活动之间需要对为满足产品设计需求所需要开展的验证活动进行清晰划分、定义和描述,即需要捕获支持设计需求的验证需求,并通过确认验证需求支持设计需求的正确性和完整性确认。

验证需求的必要性分析如下:

1) 在产品设计最初即需明确如何满足产品需求,什么意味着客户满意。

2) 验证需求的存在能够演示产品设计需求的可验证性。

3) 验证需求的定义有助于识别缺失的产品需求。

4) 达成一致的验证需求支持确定需要开展的验证活动和预期的验证结果,可促使工业方与适航当局、采购方与供应商之间就产品满足要求达成一致。

5) 验证活动成本是飞机产品研制成本的重要组成,验证需求支持尽早地确认验证活动和所需的资源,能够更好地支持产品研制项目对项目成本的管理和控制。

6) 更好地支持产品研制项目对进度计划的估计,降低项目进度管理的不确定性,可在复杂产品研制V 模型的左半边尽早确定任务范围,从而支持对项目管理计划的制定。

7) 更好地支持确定产品的验证构型和对项目变更的控制,尽早确定变更影响范围。

因此,飞机产品的验证需求可以认为是产品需求的衍生需求,支持产品需求的“验证方式”属性的确认。飞机产品验证需求经过利益关联方的确认是飞机设计需求规范通过确认的条件之一,也可以认为飞机产品的验证规划开始于经过确认的产品设计需求,所有验证活动的满足对象是验证需求,而不是产品设计需求。只有当所有验证需求完成并满足后,才能表明产品设计需求得以满足。同时,验证需求应覆盖所有需求层级,设计需求与相关验证需求存在一对多的映射关系。

2 基于验证需求的验证流程

基于验证需求的必要性分析,结合飞机研制系统工程思想[19-21],对民用飞机基于验证需求的验证方法与验证过程进行规划,总体思路如图2所示。

图2 围绕验证需求的验证总体思路Fig.2 General technical process based on verification requirements

整个思路按照过程域可以划分为产品需求定义、制定验证计划、验证活动执行与总结。

1) 产品需求定义。先以产品设计需求为输入,确定对应的验证方法,目前常用的验证方法包括检查、分析、建模仿真、演示、试验等[22],也可参考《航空器型号合格审定程序》定义的MOC0 ～MOC9 验证方法[23]。根据这些验证方法手段组合确定每条需求所需采用的验证方法,但对于产品设计需求的验证来说,验证方法是必要但不充分的。因此,针对地面试验及飞行试验等较为复杂的验证活动,需要结合基于模型的方式,开展验证场景建模,从而捕获详细的验证需求,并建立初始的验证矩阵。验证需求包括根据特定验证方法如何验证设计需求的定义,还包括验证过程中验证使能需求,如对试验平台及人员等的要求。

2) 制定验证计划。根据需求所确定的验证方法,以满足验证需求为目标,结合验证场景模型,开展验证计划的制定。根据验证方法的不同,验证计划可进一步分为检查计划、分析计划、建模仿真计划、演示计划、试验计划等,这些验证计划应与产品集成流进行关联,从而确保验证活动与集成活动的协调统一。

3) 验证活动执行与总结。依据已经批准的验证计划,结合验证场景模型,开展验证程序的制定。验证程序经过批准后,即可按照程序内容开展具体的验证活动,记录验证活动数据,生成验证报告,待验证报告批准后,向构型管理提交数据报告完成归档。

本文重点阐述从产品设计需求及相应验证方法开始,如何通过场景建模的方式捕获并定义验证需求,并在此基础上根据验证场景模型如何支持验证计划的制定及初步验证程序的定义。

3 验证场景建模

3.1 产品设计需求及验证方法

3.1.1 产品设计需求

产品设计需求是开展产品设计的依据,根据设计需求开展产品的功能逻辑定义及物理设计,设计需求的定义应遵循相关表达原则,以保证设计需求清晰、无二义等。本文以某机型起落架停机刹车系统为例,给出产品设计需求的示例,如表1所示。

表1 某机型产品设计需求示例Table 1 Example of product design requirements for a certain aircraft

3.1.2 需求的验证方法属性

除设计需求本身正文的表达外,在进行需求捕获及定义时,应对需求相关的属性进行完善,如需求的编号、假设、类别、验证方法、需求状态等。验证活动的规划主要关注设计需求的验证方法,如针对停机刹车的设计需求,其对应的验证方法如图3 所示。

图3 设计需求的验证方法属性示例Fig.3 Example of verification method property of design requirements

每条设计需求可能需要一种或多种验证方法进行验证。例如,采用蓄压器进行停机刹车时,设计需求(DR-6)要求飞机在地面停放12 h 后,刹车压力仍保持在3 MPa 以上,且期间不允许启动液压泵进行供压,该条需求需要通过MOC1 符合性声明、MOC2 设计分析、MOC4 实验室试验、MOC5地面试验多种手段进行验证,从而表明最终实现的产品对设计需求的符合性。

3.2 验证场景利益关联方识别

针对较为复杂的验证方法,尤其像实验室试验、地面试验及飞行试验等,涉及利益关联方众多、资源成本较大、适航关注度更高,可针对验证内容开展具体验证场景的建模,以支持在飞机产品研制早期对验证需求的捕获、验证计划的制定及初步验证程序定义。

在构建验证场景模型前,应对场景中不同利益关联方进行识别与定义,为验证场景建模提供输入。试验实施过程中主要的利益相关方包括飞机的主制造商、供应商、适航当局、试验实施单位、试验使能设施的研制单位等。在场景建模前应对试验所涉及的利益相关方进行全面识别,并构建层次化、结构化的利益相关方分解结构。以主制造商研制系统为例,其分解结构示例如图4 所示。在利益相关方分解结构基础上,参考相关行业标准并结合试验内容职责,对所涉及到的利益相关方元素进行定义,具体包括利益相关方范围、内涵、职责或功能。某试验场景利益相关方定义示例如表2 所示。

表2 某试验场景利益相关方定义示例Table 2 Example of stakeholder definition in a test scenario

图4 主制造商研制系统利益相关方分解结构示例Fig.4 Example of stakeholder decomposition structure of main manufacturer development system

3.3 验证场景活动逻辑

验证试验利益相关方识别并定义后,先开展验证场景顶层活动逻辑的搭建,通用的试验活动逻辑如图5 所示。整个活动逻辑划分为4 个主要阶段:试验准备、试验条件确认、试验实施、试验结束。

图5 试验验证场景顶层活动逻辑示例Fig.5 Example of top-level activity in test verification scenario

1) 试验准备。该阶段主要包括安装试验件及试验使能设施、试验件及试验使能设施安装检查、申请局方目击、试验方案调整、试验件及试验使能设施安装调整。

2) 试验条件确认。该阶段主要包括试验质量审核、试验准备审查。

3) 试验实施。该阶段主要包括试验实施及数据记录。

4) 试验结束。该阶段主要包括试验结束处置。

顶层验证活动逻辑定义完毕后,可根据场景复杂程度进一步细化分解,构建下一层级的场景活动逻辑。以停机/应急刹车功能试验为例,则可在试验实施基础上进一步细化为试验前操作准备、停机刹车功能试验及应急刹车功能试验,详细的活动逻辑如图6 所示。

图6 细化的验证场景活动示例Fig.6 Example of detailed verification scenario activity

3.4 验证场景时序描述

在详细验证活动逻辑模型基础上,针对每个细化活动构建不同利益相关方的各自行为及互相之间的资源交互。以停机刹车功能试验实施活动为例,所涉及的利益相关方包括试验操作人员、铁鸟台、停机/应急刹车系统试验件及试验记录人员,在活动初始对每个利益相关方状态进行说明,然后按照时序依次对每个利益相关方的行为进行描述。通过不同利益相关方在时序的推演下,描述各自的行为及互相之间的交互资源,从而实现对该详细活动场景的微观描述。某验证场景行为模型示例如图7 所示。

图7 某验证场景时序描述示例Fig.7 Example of averification scenario timing description

4 验证需求捕获

4.1 验证需求内涵

验证需求规定为证明对产品设计需求的满足需要开展的验证事件,并支持定义验证过程与环境。

验证需求应涵盖如下要素:

1) 目标。说明验证的目的。

2) 方法。说明采用的具体方法及验证条件(如实验室试验、分析、飞行试验等)。

3) 环境。说明验证活动开展的外部环境。

4) 特殊状态(如有必要)。说明是否存在执行验证所需的任何特殊条件(如构型要求)。

5) 成功准则。说明验证活动预期的结果。

根据设计需求对应的验证方法,可建立设计需求到验证方法再到验证需求的追溯关系,产品设计需求-验证方法-验证需求映射如表3 所示。

表3 产品设计需求-验证方法-验证需求映射表Table 3 Product design requirement-verification method-verification requirement mapping table

4.2 验证需求定义

根据所构建的验证场景活动模型及时序模型,以DR-1 为例,所构建的验证场景模型已经对停机刹车铁鸟试验过程进行清晰描述,并经过产品需求人员、产品设计人员、验证分析人员及验证实施人员共同确认。根据模型对试验过程定义,如图7 中对供压模式的选择、循环次数的构建等,通过验证场景模型所捕获的MOC4 验证需求如下。

停机刹车系统的停机刹车功能将通过实验室环境下(在温度为(25 ±5)℃温度条件下向蓄压器充(800 ±50) psi 氮气,1 psi(磅力/平方英寸) =6.894 76 ×103Pa)的铁鸟试验进行验证。试验结果显示,当采用液压源供压时,执行10 次手柄循环,每次停机/应急刹车手柄拉起并锁定后,主机轮刹车压力应为(3 000 ±100) psi;当采用蓄压器供压时,停机/应急刹车手柄拉起并锁定后,主机轮刹车压力应为(3 000 ±100) psi,12 h 后,主机轮刹车压力不小于435 psi(3 MPa)。

此外,通过验证场景模型可捕获所需验证资源的验证使能需求,验证使能需求主要包含3 个方面:①试验件验证使能需求;②试验平台验证使能需求;③人员验证使能需求。

通过验证场景活动逻辑及行为建模能够对试验件、试验平台及试验相关人员的行为进行清晰描述。根据行为要素捕获其验证使能需求,基于模型的验证使能需求捕获示例如图8 所示,试验件行为为“提供测试点I、J、K、L处的压力信号”,根据该试验件行为及与铁鸟台之间的资源交互,可捕获需求“停机/应急刹车系统试验件应在停机刹车(液压源供压)试验过程中提供测试点I、J、K、L处的刹车控制阀出油端口压力信号”。该验证使能需求将传递到负责加装传感器的操作单位,作为对其试验加改装的输入性需求,要求其在测试点I、J、K、L安装符合试验精度及范围的压力传感器。

图8 基于模型的验证使能需求捕获Fig.8 Capture of verification enabling requirement based on model

5 验证计划及验证程序定义

根据SAE ARP 4754A[6]对验证计划的阐述,验证计划应包含定义验证策略,定义验证角色、职责和资源,提出对输入可行性的假设,识别执行验证方法所需的能力,描述各需求文件如何满足,识别验证活动交付物,定义可追溯性与需求覆盖度,提供验证进度及描述发现问题的处置过程。通过对复杂、关键、长周期等验证活动开展建模,建立验证活动模型,为验证策略及活动的定义提供直观的讨论基础,实现对验证活动的确认,从而为验证计划尤其针对试验验证计划的制定提供有效输入。

与此同时,基于所构建的验证场景模型,站在人员视角,可对不同试验参与人员的行为进行总结,形成初步的验证程序,支持试验任务书中对于验证活动实施要求的编制。基于模型的验证程序定义示例如图9 所示。其中,试验记录人员行为“确认主机轮刹车装置压力范围为2 900 ～3 100 psi之间”,“记录主机轮刹车压力”,根据这2 条行为及试验记录人员与铁鸟台之间的资源和信息交互,即可定义该试验步骤为“试验记录人员通过试验显示仪器确认测试点R、S、T、U主机轮刹车压力范围,并操作试验记录仪器记录4 个主机轮刹车压力值”。

图9 基于模型的验证程序定义示例Fig.9 Example of model based verification procedure definition

根据SAE ARP 4754A[6]所制定的验证程序模板如图10 所示,可将根据验证场景所定义的验证程序步骤按照模板进行编制。

至此,通过验证场景建模,基于需求管理平台构建从设计需求-验证需求-验证程序的完整追溯链条,具体如图11 所示。形成的验证需求将进一步传递到验证实施单位,指导验证活动的详细设计与实施。以试验验证为例,验证需求将作为试验开展的约束性要求传递到承试单位,而非直接的产品设计需求,承试单位基于验证需求开展试验活动的设计,并编制相应的试验大纲。根据最终的验证程序开展验证活动以确认对验证需求的满足,只有所有的验证需求正确完成后,方可确认所有设计需求得到满足。