0 引言

自动飞行控制系统作为主要的人机交互系统，主要由自动飞行软件和飞行模式控制板（flight mode control panel，简称FMCP）两大物理部分组成。其中，FMCP作为人机交互设备，其主要功能是为正、副驾驶员提供对自动飞行控制系统的操作控制。但作为硬件设备，FMCP仅负责飞行员操作信号输入与目标值显示功能，而实际复杂的飞行操作控制逻辑则由自动飞行软件实现。对于飞行模式操作控制这一涉及多目标、多要素的复杂人机交互功能，如何进行有效的测试与验证，确保功能综合目标与性能的实现，是自动飞行控制系统设计与验证的关键所在。因此对自动飞行模式操作控制验证方法进行研究很有必要。

1 自动飞行模式操作控制功能介绍

自动飞行功能通常包括飞行指引、自动驾驶仪、飞行模式操作控制和推力管理等功能。其中，飞行模式操作功能是实现自动飞行控制系统人机交互的主要功能。飞行模式操作功能由FMCP硬件设备和自动飞行软件中的模式操作逻辑处理模块两部分组成。FMCP硬件的主要功能包括接收飞行员的输入指令（按钮、旋钮以及两卡位开关输入）、通过视窗显示当前飞机的飞行目标值及目标类型，以及通过按钮灯显示自动飞行系统状态信息（包括自动驾驶（AP）、自动油门（AT）、飞行指引/推力指引（FD/TD）等预位接通状态）、飞行指引模式接通状态、进近状态及耦合侧指示等。飞行模式操作控制系统物理界面如图1所示^[4-6]。

2 面向开发过程的模型验证

对于涉及一个多目标、多要素与多过程的综合功能，如何开展有效的测试与验证，确保验证功能综合目标与性能的实现，是功能验证的关键所在。由于模式操作设计的功能需求与性能需求是通过系统开发过程实现的，系统的偏离也是由系统的开发建模活动决定的。因此，模式操作功能的测试与验证方法需要面向开发过程，根据功能开发的功能架构与层级来设计。功能验证需要与功能的建模开发过程紧密结合，要综合考虑各功能模块的关联性与耦合性。根据飞行模式操作控制的功能架构，需要分阶段对功能开发每一层级的功能实现结果进行评估^[2，6-7]。

因此，首先需要了解飞行模式操作控制系统开发的功能架构。T1层级模式操作功能由三个功能分区实现：第一部分主要负责通道选择及信号处理；第二部分负责按钮灯的飞行状态显示；第三部分负责视窗的目标值显示。由于视窗模块的逻辑最为复杂，因此本文针对视窗模块的底层逻辑进行了建模与验证方法研究。针对视窗模块，在T2层级进行分解。FMCP视窗分区分为4个视窗，分别用来显示速度目标值、高度目标值、航向目标值与VS/FPA目标值，因此第二层级按照视窗的显示功能分为四部分。以速度视窗为例，在T3层级对速度视窗的功能模块进行分解时，需要分别从FMS与FMCP获取输入的速度目标值指令。然后，通过逻辑判断计算出不同的速度目标值，并分别传输给AFCS控制律、PFD显示与FMCP显示。由于PFD显示的速度目标值与AFCS控制律中使用的速度目标值相同，因此速度视窗的逻辑架构可以简化为两条逻辑分支。在每个分支内，串联了速度目标值计算与显示的多个功能模块，通过功能模块的架构集成，实现速度视窗功能。飞行模式操作控制的架构如图2所示。

基于上述划分的飞行模式操作控制功能架构，可以进行综合测试与验证架构设计。针对功能架构中的三个层级，可自下而上分别进行独立的试验测试，对每一层级的功能实现结果进行功能及性能效果评估。首先，对开发的功能模块进行功能测试；接着，对模块集成的视窗功能进行功能及性能测试；然后，对通道选择、按钮灯及视窗三个功能分区分别进行功能及性能测试；最后，进行模式操作控制功能的整体功能性能测试。具体的飞行模式操作控制功能综合测试与验证架构设计如图3所示。

3 集成测试方法设计

根据第2章中的飞行模式操作控制功能综合测试与验证架构，首先需要在建模的过程中，对T3层级的每一个模块进行独立的功能测试，验证每个模块的基本功能实现是否符合预期。在这个阶段，无法保证验证的场景与功能的全面性，考虑到模块交联之后的关联性与耦合性，需要进一步对T2层级的速度视窗进行集成测试，对于速度视窗多目标、多要素的综合功能进行试验设计。本章通过提出一些定义与假设，将视窗的功能实现全部放在状态转换矩阵当中，进而通过状态转换矩阵来指导复杂人机交互系统的桌面测试，在减少测试工作量的同时，尽可能对飞行模式操作控制功能进行全面的验证。

本章将继续以速度视窗为例对FMCP速度视窗人机交互测试方法进行介绍。为了区分复杂的人机交互场景，首先将所有的人机交互操作（包括系统的自动响应与人工操作造成的响应）划分为状态响应与动作响应，如果可以合理地定义飞行模式操作的状态，则可以将部分飞行模式控制操作定义为状态转换，使得飞行模式操作控制表格更具备条理性与全面性。比如当前显示的速度类型Mach可以作为状态，速度类型由Mach切换为CAS则为状态转换；而当前的速度模式FMS也是状态，速度模式由FMS切换为MAN同样是状态转换。不会改变速度目标值状态的人机交互操作定义为动作。根据上一章可以发现，PFD与FMCP的速度目标值与速度类型响应逻辑是不同的。由于PFD与FMCP的速度响应不同，在进行合并考虑的情况下需要重新定义状态基准。考虑到实际飞机的飞行状态取决于控制律中使用的速度目标值，为了与实际飞机飞行状态保持一致，故将控制律内部所采用的速度源与速度类型定义为状态。而当执行某些操作后，FMCP视窗显示与控制律内部计算响应不同的情况下，将此时执行的操作定义为动作，而FMCP速度视窗的显示定义为该操作的响应。由于PFD显示的速度目标值为控制律内实际使用的，因此将PFD显示的速度模式与速度类型定义为状态，速度模式与速度类型两种状态互相不关联，因此它们对应两个状态层级。两个状态层级的两种状态两两组合后可得到如下4种基准状态，见表1。

通过完整梳理每一种状态的转换条件以及对应的状态响应，可以形成速度视窗的状态转换矩阵，通过根据矩阵执行的每一项状态转换操作，可以测试FMCP速度视窗与PFD的速度目标值显示是否符合预期响应，并以此来设计速度视窗状态转换的桌面测试。

同时，将其余所有不改变速度目标值状态的操作定义为动作，由于每一个动作均是在特定的状态下进行的，因此可以依据所处的状态来梳理人机交互动作：FMS模式下，速度类型为IAS（或Mach）时执行的动作有：1）通过旋转速度旋钮进行速度目标值预选；2）在预选过程中通过按压速度类型切换旋钮切换FMCP速度视窗显示的速度类型；3）在预选过程中飞机穿越XX高度层，自动切换FMCP速度视窗显示的速度类型；4）在预选结束后未激活预选的速度类型，FMCP速度视窗恢复Dash；5）FMS输入的速度目标值更改，输出的速度目标值随之更新。人工模式下，速度类型为IAS（或Mach）执行的动作有：1）通过旋钮调整速度目标值。2）当人工输入的速度目标值超过自动飞行速度包线，则FMCP上的速度目标值会显示飞行员输入的目标值并进行闪烁提醒；PFD上显示的速度目标值为限制在速度包线内的目标值并闪烁提醒。3）自动飞行系统初始化，需要进行目标值初始化，并且初始化速度类型为IAS。

通过以上定义执行动作操作，可以验证速度视窗以及PFD响应是否符合预期来进行速度视窗操作测试。由于每一个动作均是在特定的状态下进行的，并且动作操作不会引起状态改变，因此为了便于试验设计，可以将动作操作及响应放置于状态转换矩阵的对角线上，汇总得到状态转换与动作响应矩阵，见表2（以下所有转换表均从列状态转换到行状态）。

表2列举了速度视窗的不同状态转换以及不同动作下的操作方式与预期结果。参考矩阵中的输入与响应，测试集成模型输出的FMCP速度目标值与PFD的速度目标值显示是否符合预期响应，可以保证集成模型的功能验证的全面性与完整性。

4 结论

1）本文介绍了一种面向过程开发的飞行操作控制功能的验证方法，首先梳理了飞行模式操作控制功能开发的功能架构，进而根据功能开发的功能架构与层级来设计功能验证方法。将功能验证与功能的建模开发过程相结合，综合考虑各功能模块的关联性与耦合性，分别针对功能架构中的三个层级自下而上分别进行独立的试验测试，对每一层级的功能实现结果进行功能及性能效果评估。

2）针对系统验证过程的集成模型测试阶段，以FMCP速度视窗模型为例介绍了一种集成模型验证策略。定义了4种飞行模式操作控制的状态，并且将所有飞行模式操作行为划分为状态转换以及动作两种形式，状态转换操作会导致速度目标值的状态变化，动作操作不会引起速度目标值的状态变化。分别梳理了每种状态转换的操作及响应情况，以及每种动作的触发方式及响应情况，最终汇总形成速度视窗层完整的状态转换响应与动作响应矩阵，为自动飞行模式操作控制的集成模型验证提供参考。

参考文献