嵌入式系统 | Ansys SCADE在空客电传飞控系统中的应用

近期推出的嵌入式系统专题内容中，我们详细梳理了Ansys SCADE的诞生、发展及应用，也针对“形式化方法”做了进一步阐述，详实地介绍了在当今软件行业已有众多测试手段下为什么形式化方法尤为重要？本期我们将分享Ansys SCADE在航空电传飞控系统中的应用。全文将从民用飞机的飞行控制系统、空客的电传飞控系统、SCADE在空客电传飞控中的应用、空客在研发选用的工具链中对形式化方法的重视以及案例展现等多个方面来阐述基于SCADE的形式化方法在空客电传飞控中的具体应用。在后续专题内容中我们还将推出包括轨道交通、核能重工及航天防卫等行业应用案例。

飞机的飞行控制系统(FCS: Flight Control System)就是利用控制原理使得飞机的操纵面(又称舵面,surface or rudder)偏转，以实现对飞机的姿态和航迹运动进行稳定控制的系统。飞控系统通常包括

• 飞行器运动，包括其重心的线运动、绕机体轴的角运动(升降舵Elevator完成俯仰Pitch，副翼Aileron完成滚转Roll，方向舵Rudder完成偏航Yaw)，以及飞行器结构模态的变化;

• 完成对飞机姿态和航迹运动的稳定和控制所需的所有硬件及软件

  
  

图表1：飞行控制示意图

通常认为，迄今为止飞控系统共演进了四代，分别是简单机械控制系统、液压助力控制系统、增稳控制系统和电传控制系统。采用电传控制技术的飞机有几大优势：

1. 相比传统的机械控制系统的飞机有着更轻的重量，这是因为电传飞控省去了机械传动控制系统中的大量复杂、冗余的机械设备，减轻了系统部件的总重量，解放了飞机的内部空间；

2. 电传飞控的引入意味着飞机可以采用打破传统气动布局的静不稳定设计，使得飞机结构内部那些起着控制飞行稳定性的部分零件省去或者减小比重，例如减小机尾的水平稳定面与垂直稳定面，减负后的飞机在航程与载重上都会有所提高，这对于特别考虑经济成本的民航而言有着重要的意义;

3. 使用了新一代飞控技术的民航客机极大增加了飞机的安全性，电传技术的引入使得飞行员可以实现对飞机飞行姿态的微调，简化操纵流程，提高驾驶精度，有效地预防飞行员过载、飞机失速等隐患。

电传飞控系统分为模拟式和数字式两种。前者使用模拟信号，后者使用数字信号，使用数字信号可以实现更多的状态，使得飞行控制变得更加精细。而模拟式则只能根据相位，频率，幅度的不同组合给出有限的几个状态来。

英国BAE和法国Aérospatiale 联合设计的协和(Concorde)超音速客机是第一代应用电传飞控技术的飞机，不过该飞控系统是模拟式的。第一代数字式电传飞控系统出现在1980年初的空客A310上，该系统主要控制了缝翼、襟翼和扰流板几个操纵面。1988年通过适航认证投入使用的A320使用了第二代电传飞控技术，它可将高级控制律应用到所有的操纵面。

空客A320是世界上首个采用电传飞控与静不稳定设计的民航客机。除此之外，A320还是业界首创使用侧杆驾驶的民航客机。相对于传统的中央操作盘，电传侧杆具有独特的优势。首先，电传侧杆控制系统结构精简，重量轻，易于装配和拆卸，维护成本明显降低。其次，电传侧杆占用的驾驶舱空间较小，飞行员更易于观察前方显示器，为进一步优化驾驶舱显示、控制布局提供可能。最后，在臂托的配合下，驾驶员前臂相对固定，可以保证驾驶员操纵的稳定性，减少驾驶员的工作负荷，降低操作难度。不管是中央操作盘还是侧杆，都是通过推拉控制俯仰，通过左右转动控制滚转，通过脚蹬控制方向舵，即偏航。

图表2：左侧座舱的中央操作盘和右侧座舱的侧杆

空客设计的电传飞控系统极其复杂，毫不夸张地说，这可能需要一整本书才有可能完整准确地描述，本文仅择其要点进行简单介绍。

为了满足适航认证的要求，空客使用了9大“黄金法则”来研制其电传飞控系统。

2.1.1 进行系统安全评估(SSA: Safety System Assessment)：评估每个功能失效对系统的影响。SSA使用故障树方法，研究所有可能的失效组合，以确定事件发生的概率。每个基本失效的概率由相关设备的制造商给出，并根据经验重新评估或确认。

2.1.2 遵循严格的开发流程：主要基于ARP 4754/ED79(1996)系统开发标准，DO178B/ED12(1992)软件开发标准和DO254/ED80(2000)硬件开发标准。

2.1.3 硬件冗余的设计：例如使用多台电传飞控计算机，操纵面的作动器使用不同的电源。A320/340使用3套电源(液压驱动)，A380使用4套电源(2套液压驱动和2套电驱动)。发动机引擎支持驱动液压回路给网路供电。作为备份，冲压空气涡轮(RAT: Ram Air Turbine)也支持驱动液压回路给网路供电。

2.1.4 监控的设计：所有的飞控系统部件都需要实时监控，例如传感器，作动器和探针等。计算机的所有输入和输出也都需要监控。例如，主控计算机发送伺服指令，需要监控信息被正确地发送和接收。

2.1.5 重构(Reconfiguration)的考虑：可对功能失效进行自动管理，这对飞机的容错设计非常关键。重构分为两个层面：

2.1.6 非相似的设计:所有空客飞机都至少有两种类型的计算机：一台主控和一台备份。它们的硬件和软件都不一样，也不是由同一个团队开发的。上述系统级的重构使用了主控计算机和备份计算机的切换，备份计算机比主控计算机简单。非相似的设计也涉及作动器。在A380上使用了多种类型作动器：传统的液压驱动作动器(hydraulic Actuator)，新一代电驱作动器(EHA: Electro-Hydrostatic Actuator)和电动备用液压作动器(EBHA: Electrical Backup Hydraulic Actuators)。EBHA在正常时是传统的液压作动器，在发生失效时可切换为电驱动作动器。

2.1.7 安装的隔离考虑：计算机必须物理安装在飞机上的不同地方，以避免在任何损坏的情况下完全失效。例如，发动机转子爆裂会切断为计算机供电的电线。同样的原因，液压系统和电气系统的线路也要安装在不同的地方。

图表5：A380上飞控计算机安全位置的物理隔离

2.1.8 飞行控制计算机体系架构：空客设计了含有命令计算机和监控计算机的基本单元。每台计算机各有一个命令通道(COM)和一个监控通道(MON)。每个通道都监视另一个通道。COM通道提供分配给计算机的主要功能(飞行控制律计算和操纵面的伺服控制)。MON通道主要确保对飞行控制系统的所有部件(传感器、执行器、其他计算机、探针等)进行永久监控，并通过向COM通道和其他计算机发送故障检测信号来触发重构。两个通道彼此相邻以方便维护。一台计算机的COM和MON通道或者同时处于活动态，或者同时待机，或者再次同时激活变为活动态。

A320飞控系统使用两种计算机：ELAC(升降舵与副翼计算机:Elevator and Aileron Computers)和SEC(扰流板和升降舵计算机: Spoiler and Elevator Computers)。由于每台计算机都有一个命令通道和一个监视通道。因此，有四个不同的通道对应的四个不同的软件包。除了ELAC和SEC之外，还有两台计算机用于方向舵控制(飞行增强计算机FAC: Flight Augmentation Computers)。它们不是ELAC和SEC的冗余。

A320飞控系统共由7台计算机组成，包括2台ELAC，3台SEC和2台FAC。这其中的ELAC和SEC共计5台计算机组成了A320电传飞控的主飞控计算机，5台主飞控计算机中的任一台都可以控制A320的飞行。

后续的A340和A380型号也使用两种计算机：PRIM(主控计算机:Primary computers)和SEC(辅助计算机:Secondary Computers)。尽管计算机与A320是不同的，但基本的安全原则是相似的。

2.1.9 鲁棒性的考虑：例如，没有假的监控警报、抗电磁干扰(EMI: Electro Magnetic Interference)和在严重雷击、总风冷损失等情况下继续运行的能力。

以下图表6所示的是包含硬件冗余、非相似和系统重构的电传飞控架构综合视图。顶部是A340飞机的双翼，每个机翼上包含了内侧(Inboard)和外侧(Outboard)的副翼(Ailerons)和6个扰流板(Spoilers)。在中部是左右两个升降舵(Elevator)和中间的可配平水平安定面(THS: Trimmable Horizontal Stabilizer)。底部是方向舵(Rudder)，该方向舵由增强电气结构的脚蹬触感配平单元(PFTU: Pedal Feel Trim Unit)组成，也连接着基本的机械结构的备份控制单元(BCM: Back-up Control Module)组成，其方向舵的绿色操纵面由PFTU连接P1和S1冗余操作。

像扰流板这样的非关键操纵面只需一个作动器驱动，而关键的操纵面需要与两个甚至三个作动器相连。每个作动器与某颜色表示的液压回路相关联(例如,Y表示黄色等)。P表示主控计算机，S表示辅助计算机。对于带有冗余作动器的操纵面，箭头显示了重构逻辑。例如，在左侧升降舵上，P1是主控计算机，控制绿色作动器，P1和绿色作动器都处于主动态；P2是辅助计算机，控制蓝色作动器，P2处于待机态，蓝色作动器处于被动态。如果P1主控计算机、或绿色作动器、或绿色液压回路出现故障，则自动重构将P2设为主控计算机，蓝色作动器设为主动态(同时绿色作动器设为被动态)。如果当前主动态再失效，下一个重构是P2到S1；再失效的重构是到S1到S2，可见辅助计算机也可作为冗余备份。

图表6：A340电传飞控的操纵面架构综合视图

飞行控制计算机的主要任务之一就是计算飞行的控制律。根据飞行员的指令(侧杆或脚蹬)、飞机的运动传感器和大气数据传感器信息来计算，其结果是操纵面按照指令偏转，以实现所需的飞行轨迹修改。作动器会驱动操纵面偏转到指定的位置。

在飞控计算机中，通常从3个冗余的大气数据惯性基准单元(ADIRU: Air Data Inertial Reference Unit)中接收各自检测到的大气和惯性数据值，再为控制律计算所需的飞行参数。这种专门的处理，称为“合并”(consolidation)或“三余度处理”(Triplex)，通常分为两步：首先从3个独立ADIRU源中表决得出准确的参数；其次监视3个独立源，舍弃任何失效的源，并确保选择的数据是正确的。这种多数表决机制是较成熟的技术，在现代电传飞控系统中使用广泛。

图表7：飞行控制律计算的通用原理

在大型民用飞机上，飞控计算机的计算能力比其他传统的非关键应用(例如，多媒体)要低，这是因为安全关键的应用程序必须使用经过验证的，可靠的处理器。例如，A340主控计算机处理器是频率为32 MHz的AMD 486 DX4，每秒大约处理1900万条指令。由于处理器配置较一般，尽管计算的负担相当繁重，但诸如非线性滤波“矩阵三角化”，“在线优化算法”，“傅里叶变换”或“小波计算”等高级处理算法依然较难使用。所以必须删除所有不必要的计算和冗余数据，以尽可能精简开发出来的复杂算法。然而这种算法的简化又会出现性能的损失，这就需要设计者们找到复杂度和高性能之间的折衷平衡。

由于典型的空客飞控计算机包括两个独立的通道，每个通道都有自己的时钟。因此，两个单元之间存在时间异步。而飞控计算机是多速率时间触发的，这意味着即使在同一个单元中，所有的数据也不是在同一采样周期内处理的。例如，某些数据每40 毫秒采样生成，而算法逻辑的计算周期是每10毫秒，这就需要使用预测滤波器等方法修改算法逻辑使其适配采样时间。这是电传飞控的设计需要认真考虑的因素。

图表8: A340和A380飞控计算机配置的对比

从1980年代开始，A320系列客机的电传飞控软件开发中就使用了Aérospatiale推出的SAO (Computer-Assisted Specification)工具（详见：嵌入式系统 | 细数Ansys SCADE的前世今生）。电传飞控的技术规范中准确地定义了需要由软件实现的功能，主要内容有：各传感器信息获取与监控功能、飞行控制律功能、监控功能、操纵面修正功能和重构功能。

SAO可通过一组有限的图形符号(加法、滤波、积分、查找表等)来描述预先定义在功能规范表(functional specification sheets)内的每个部分。

图表9：SAO工具开发A320的控制律

在后续的其他空客系列(例如: A340，A380和A400M等)研制中转而使用更成熟的下一代工具SCADE(Safety Critical Application Development Environment)。

图表10：SCADE工具开发A340、A380的控制律

使用这种基于形式化语言的模型开发工具，通常分为两个步骤。第一，根据软件技术规范进行建模。不同型号的飞机可以通过桥接的配置管理工具，方便快捷地复用相关的设计，并自动化地进行语法语义检查。第二，通过认证的工具可以自动将设计完毕的模型生成可在飞控计算机中直接运行的代码。

图表11：飞控计算机的软件实现概览

使用SCADE工具进行开发是电传飞控软件容错设计的重要手段，对安全性有积极作用。自动化的工具确保了即使需要快速实现对规范的修改(例如在飞行测试阶段遇到的情况)，也能轻松胜任。完成后还可以很容易地实现自动代码生成。支持在设计过程的早期进行“非回归”测试，以检查有效性及是否存在由于变更而导致的错误。这些测试应该尽可能早地执行，以尽量减少开发阶段的调试工作。

下方图表12为伺服控制驱动某操纵面的功能规范图示例（部分）。该规范只使用了非常基本的符号：加法、增益、门限、逻辑门和选择开关。输入是三角形符号的布尔类型条件和浮点型的真实信号(表示命令、位置等)。输出是浮点型信号数据和对作动器的模拟硬件输出(黑色输出表示)。该逻辑描述了某操纵面的伺服器使用比例积分(PI: Proportion Integration)进行控制的通用方案。将请求的操纵面位置的命令值与作动器内部专用传感器实际测量的操作面位置值进行比较。由此产生的控制回路误差乘以适当的增益(K1或K2)以输出到底下第一个输出值current。为了补偿作动器级的任何可能的偏差，在第一个输出值中添加适当的补偿Bias值(PI控制的积分部分)，以提供发送到执行器的第二个输出值current_c。该偏差Bias的计算在另一张功能规范图中定义，并未在当前图中标识。伺服阀接收计算后的总输值出current_ano，并将其转换为作动器内的液压流体运动，最终控制与操纵面相连的作动器杆移动到相应位置。

图表12：伺服控制某操纵面的功能规范图案例

功能规范图还包含诸如飞机类型、计算机类型、特定功能、采样周期、版本(修改次数)、设计者姓名等信息定义。据统计，A380的主控计算机大约有5000个专用的功能规范图，A380的辅助计算机大约有3000个专用的功能规范图，可见相关计算的工作量是极其巨大的。设计中还需要将功能规范图进行级联排序，以便一张接一张的计算，以最小化信号间的延迟，再由SCADE工具进行实现。

图表13：SCADE实现A380飞控辅助计算机的某功能规范图

而空客在开发过程所用的形式化工具及其在各阶段的对应关系如何，本节将针对空客电传飞控产品的研发流程中使用的形式化方法工具链进行介绍。

图表14:空客开发流程

空客将形式化方法应用到以下产品的软件开发验证流程中。

图表15：空客应用形式化方法开发的产品

从上期《基于SCADE模型的形式化方法介绍》一文中我们知道，形式化方法分为三种，抽象解释、模型检查和演绎法。在空客研发的包括电传飞控系统等安全关键软件中用过如下的形式化方法工具。

图表16：空客使用的形式化方法相关的工具

Frama-C意思是“C代码的模块化分析框架”，是A framework for modular analysis of C code中蓝色字的缩写。它是由CEA和INRIA研发的开源软件，可基于不同理论对C源代码进行静态分析。静态分析是从源代码中提取一定数量的信息，而不运行它。Frama-C允许以抽象解释等方法对给定程序检查是否存在可能的运行时错误，例如，对初始化指针的引用、溢出、除零等。

Frama-C中实现信息提取的技术主要有抽象解释和演绎方法。Frama-C基于核(kernel)，且使用同一种形式化规约语言ACSL即标准C规约语言(ANSI C Specification Language)对C源代码做标注(annotation)，因此基于Frama-C开发的插件可使不同的静态分析在同一标注代码上进行协作。

图表17：Frama-C架构和插件

这些插件利用了Frama-C平台提供的几个内核和基本服务来计算用户需要的结果。这些结果包括抽象语法树、证据项目管理、命令日志、每个函数甚至C表达式的I/O计算、程序依赖关系图、控制流、数据流、代码切片、影响分析、死代码或无法访问的代码的检测等。

图表18：Frama-C常用插件介绍

尽管在数学中，实数的精度是无限的。但在工程实践中，实数的精度有限的，通常为单精度浮点数(float)和双精度浮点数(double)。因此，在进行浮点运算时，四舍五入等错误会影响结果。另外，在理论演算时稳定的计算在工程实践中也可能不稳定。CEA公司开发了Fluctuat，可用于分析C源代码程序在特定处理器上数值精度。可以：

• 确保浮点数表示的变量精度在程序全周期有效

• 如果运算涉及浮点数，确保浮点数与实际浮点数的误差在程序全生命周期内的精度可控

除此之外，Fluctuat还可以协助用户找到代码中浮点数的问题。诸如缺乏精度、不稳定、灵敏度等。空客的电传飞控系统中不少基础库是用SCADE实现的，用Fluctuat进行检查后获得了较好的结果。

Astree是基于抽象解释的静态分析器，能够证明用C语言编写的程序中没有运行时错误。它最初由Ecole normale supérieure的计算机科学实验室开发，现在属于AbsInt公司。因为是基于抽象解释理论，所以它可能会产生虚假警报。为了使其能安全关键领域的工程上得到应用，对其做了改进。改进后的Astree对基于同步语言的控制设计软件SCADE（或SAO，SCADE前身）尤其适用，其分析结果的精度极高（虚假警告几乎为零）。其可扩展性、适用性为也极佳，在可接受的时间内成功分析了50万行代码。

aiT是AbsInt公司的一套工具，可用于计算飞机、汽车等不同微处理器的最坏运行时间(WCET: Worst-case Execution Time)。这些工具有一个可执行程序和一个标注文件(给工具的指令)作为输入。标注中，目标板外部存储器和总线的描述是以含有相关访问时间的地址区域列表形式出现的。计算WCET前还需要用户提供任务的起始点。被分析的程序必须是顺序执行的(没有多线程，并行或等待外部事件)。

该工具首先构建程序的控制流图(CFG: Control Flow Graph)。接下来分别进行值分析(value analysis),缓存分析(cache analysis)，管道分析(pipeline analysis)和路径分析(path analysis)。

值分析计算寄存器和地址在内存访问时的值间隔，其中的循环界限分析阶段要确定可能的循环迭代次数上限，由正在分析的任务来预测地址的计算，并排除后面分析中不可能的路径。

缓存分析使用值分析的结果预测缓存的行为。它将对内存的访问分类为“命中”、“未命中”或“不确定”。缓存分析可以在缓存未命中的情况下预测下面管道停止的情况，特别是在命中或未命中分类的情况下，可减少了不确定情况的数量。

管道分析是相当于在目标处理器模型上的程序执行，该程序是由安全符号组成的CFG。管道分析利用前面分析的结果，预测所分析任务的时间行为，并计算所有基本块的WCET，基本块是指由跳转或程序调用完成的汇编程序指令序列。

路径分析计算任务最长的执行路径。路径分析使用整数线性规划(integer linear programming)技术，求其上界得出结果。

WCET将程序分离为若干个断续的阶段使得每个阶段的技术应用成为可能。对值、缓存和管道的分析是用静态分析和抽象解释技术。当前Ansys公司SCADE Suite产品中含有该模块。

图表19：PowerPC MPC755 aiT/WECT

Stackanalyzer是AbsInt公司的工具。以二进制形式分析程序堆栈的使用，计算实际内存使用量的上限。该静态分析有助于证明没有程序执行引起的堆栈溢出。当前Ansys公司SCADE Suite产品中含有该模块。

Lesar是使用二元决策图(BDD: Binary Decision Diagram)对基于Lustre语言模型进行模型检查的工具，其算法用于枚举可达状态。

L4是Prover Technology公司开发的可对SCADE模型进行形式化验证的插件，可提供类似Lucifer的功能，但界面更加友好，可以与SCADE集成开发环境无缝连接。

NP-Tools是Prover Technology公司基于Stålmarck证据流程的的通用验证工具。

L4、NP-Tools和Lucifer都是Prover Technology公司提供的针对SCADE模型进行形式化验证的早期版本。只能处理整型数据类型。

SCADE Designer Verifier是当前Ansys公司SCADE Suite产品的标准形式化验证模块。

由CEA开发的C代码静态分析工具，可用于验证安全关键软件。主要基于霍尔逻辑(Hoare Logic)和一阶逻辑谓词(first order logic predicates)进行最弱前置条件的计算。Caveat集成了3款工具:代数式简化器(algebraic simplificator)，自动定理证明器(demonstrator/automatic theorem prover)和交互式预测转换器(IPT: interactive predicate transformer)。Caveat是空客在90年代为C代码程序使用的形式化验证工具，2006年后转而使用后继产品Frama-C。使用Caveat的形式化方法符合《DO-333》中介绍的Unit Proof方法，主要是针对手写C代码的，其对应的形式化的低层需求(LLR: Low level Requirement)是由一阶谓词逻辑设计。

新版DO-178C系列中A-7表第9个目标是：验证无法追踪到源代码的附加代码。该目标是DO-178C标准新加的，将原标准中的隐性目标明确化了。航空软件的验证通常会在源代码级执行结构覆盖，然而由于可执行目标码是实际飞行的代码，所以对于A级软件，需要有一些分析来确保编译器没有生成不可追踪的或不确定的代码。但是，编译器是非常复杂的软件，特别是对于C语言这类全功能通用语言的处理更为复杂，直接对编译器进行验证极为困难。因此，业内并不存在通过了工具鉴定的通用C语言编译器。

为了解决该问题，2008年12月开始空客和INRIA合作开展了CompCert编译器项目，该编译器最初由INRIA计算机专家Xavier Leroy领衔研发，是经过形式化验证的可信编译器的杰出代表。该编译器将C的一个重要子集Clight翻译为PowerPC汇编代码(后来也支持IA32和ARM后端，目前已扩展至可支持64位处理器)，其编译过程使用了11中语言，并划分为多个阶段，每个阶段的翻译正确性都借助工具Coq进行了证明，且这些证明可由独立的证明检查器检查，这是迄今最强的形式化验证手段，达到了人们所能期望的最高可信程度。CompCert对目标码也做了包括简化控制流和数据资源智能使用的优化，其最坏运行时间提升12%左右。

图表20：CompCert开发工作流

下图为空客的基于CompCert编译器的工具链配置。

图表21：空客基于CompCert编译工具链

图表21右上角的Airbus ACG是空客在SCADE KCG基础上定制的自动代码生成器工具(Automatic Code Generator)。其详细内容如图表22所示，该定制工作保持Suite模型到C代码前端不变，又在后端增加了可适配不同硬件平台、不同处理器和编译选项，不同框架代码的处理。所有定制工作不影响SCADE模型和生成的代码。前端后端合并后，可一起通过DO-178B的工具鉴定。

图表22：空客基于SCADE KCG定制的自动代码生成器

综上，用一张图来描述空客使用的各形式化分析工具在其开发流程中的对应关系

图表23：空客的形式化分析工具在开发流程阶段的对应关系

空客从A320开始使用了SCADE来开发模型，在A340、A380和A400M等型号开始对SCADE做了模型检查等形式化分析。这些工作主要由空客和法国国家航空航天研究中心(ONERA)协作研究完成，使用的模型检查引擎主要是Prover Technology公司提供的。

先简述一下空客典型的模型检查验证框架。该框架包含3个部分：SCADE模型，待验证的属性(P: Property)和系统环境相关的假设(H: Hypothesis)。基于SCADE的模型检查，就是验证在给定假设的前提下，模型满足预设的属性。

假设H用于在整个分析过程中对输入进行约束，它不是唯一的，也不是必须的。属性P的识别和提取是难点，通常有两种方法：和系统设计者讨论得出，或者研究安全相关的设计文档和验证文档。属性提取后，以独立的布尔型输出变量表示出来。当SCADE模型满足该属性，则属性P结果恒为真，即通过模型检查。当属性P结果为假，则模型至少存在一个错误，该错误可由模型检查器返回的反例来重现。下面介绍几个案例。

图表24：空客基于SCADE的模型检查证框架

如前所述，电传飞控系统由主控计算机和辅助计算机组成。其中的计算机使用SCADE实现了功能规范图，包括输入验证，逻辑处理，控制律，伺服控制等。设计师提出两个安全需求属性。

首先是关于侧杆控制的功能。飞机有主驾副驾两位飞行员，每个飞行员都有一个侧杆可以操纵。

P1：两个侧杆不可同时发生故障，任意时刻必有一个侧杆处于活动状态。

第二个是关于内副翼的功能。对副翼操纵面有主控计算机PC1，PC2，两个辅助计算机SC1，SC2。

P2：如果两个主控计算机PC1和PC2都发生故障，则辅助计算机SC1开始运行。

在精化这两个属性前，先简要介绍下常用的一阶谓词逻辑，这在推理证明中是比较常用的

图表25：常用的一阶谓词逻辑

P1属性的不足之处在于当前“活动”侧杆的定义方法。可以考虑根据侧杆传输的指令来定义当前“活动”的侧杆。因为主驾副驾的指令可以传送到操纵面。P1属性改为

也就是说，如果主驾指令不等于0或副驾指令不等于0，则传输顺序不等于0。然而，由于计数器等原因，该属性表达式是错误的。确实存在一个侧杆已经发生故障，另一个侧杆正在运行且值为0的情况。即处在“虽然属性P1是false，但实际上是有效的”状态。问题的关键是：活动的的侧杆未发送指令，或活动的侧杆发送了指令但指令为0。所以如果需要从传输指令的角度判断，需要更深入规范，可以从另外一个角度来分析。P1的另外一种表达方式

该P1的含义是：不存在这样的情况，即主驾有优先权且主驾的侧杆故障，或副驾有优先权且副驾的侧杆故障。本例说明非形式化文本转换到形式化表达式是有个过程的，是不容易的。

属性P1描述完毕后，应用模型检查引擎(基于Lucifer和Lesar)就行分析。除了一个反例外，最终被证明是有效的。该反例是初始化时两个侧杆都失效了，所以再添加一个简单的假设即可。

仔细看P2定义，其实不完整，还隐含两个重要的功能。更精确地分析后，得出第一个隐含功能：

1. 当PC1和PC2都故障时，如果SC1可以用，则用SC1；

   如果SC1也不可用，则需要判断SC2是否可用。表达式可以写为：

   P2:   if (两个主控计算机PC1和PC2 都发生故障)

   then if (辅助计算机S1是否可用)

   then (辅助计算机 SC1 运行)

   else (申请辅助计算机SC2 是否可用)

   else (辅助计算机 SC1不可用)

    

2. 第二个隐含功能推荐反向推导，如果PC1和PC2没有同时发生故障，则SC1不可用。

   该语句可以表述如下：

   P2b:  if not (两个主控计算机PC1和PC2 都发生故障)

   then not (辅助计算机SC1可用)

   再次反推简化，如果SC1是可用的，则PC1和PC2必然都发生故障了。

   P2b:  if (辅助计算机SC1是可用的)

   then (两个主控计算机PC1和PC2都发生故障)

辅助计算机SC1可通过检查由它管理的两个主控计算机门是否关闭了，来判断其自身是否可运行。使用一阶逻辑谓词的表达式为

属性P2b描述完毕后，应用模型检查引擎(基于Lucifer)分析后，发觉除了在初始化阶段系统不稳定的情况外，其他时候都是有效的，所以添加了begin_ok操作符，使之屏蔽最初运行的几个周期，只关注后续稳态的行为。新增假设为：

本案例中的SCADE模型还包含了很多浮点数变量。但是早期的Lucifer对浮点数的支持能力一般，只能处理布尔和整数。方法是将浮点数转换成整数，案例中采用了以下方法：首先找到所需的精度，然后将每个浮点数与之相乘，将其转换为整数。本例中我们将浮点数乘以100。这种转换会可能会给验证带来问题，但能得出有意义的结果，在前期就确保了不会出现重大问题。

考虑某基础模块“复位偏置锁存器”操作符(the reset-biased latch operator)，含有Set, Reset两个输入，output一个输出。该锁存器的初始态output为false。只要输入Set为true且输入Reset为false，则output必为true。除此之外，output延迟的运行结果必为false。

图表26：复位偏置锁存器模型 reset-biased latch

现有某扰流板的气闸(air brake)要调用该锁存器操作符，设计气闸控制模型airBrakeControl。

图表27：原气闸控制模型airBrakeControl(待形式化分析验证来修正错误)

设计内容如下：

设计师提出安全需求属性为：不存在输出airBrakeExtension和输出airBrakeRetraction同时为true的情况。设计属性表达式如下

属性P为：Not (airBrakeExtension and airBrakeRetraction)

从物理上来说，输入airBrakeLeverOn和输入airBrakeLevelOff同时为true,相当于气闸上的操纵杆同时设置为on和off，这是不可能的。因此可以设计

假设H为：Not (airBrakeLeverOn and airBrakeLevelOff)

将原模型，属性P和假设H设计到同一张页面后的总SCADE模型如下：

图表28：气闸控制模型的形式化分析页面

应用SCADE Design Verifier引擎进行第一次分析，得出该airBrakeControl操作符不满足属性P，得到一个反例。该反例由两个周期组成：

图表29：修改后的气闸控制模型airBrakeControl

对A340的500-600型号的电传飞控辅助计算机的多个方面做形式化分析能力的验证，结果如图表30。主要对12个基于SCADE的模型进行评估，从三个方面验证模型检查的可用性。

1. 多处理器方面。空客的电传飞控系统运行在异步容错的多处理器架构；

2. 多速率组方面。系统的不同代码在不同速率组的运行；

3. 数值计算方面，例如二阶滤波器，含有复杂的浮点数运算等。

共试验了12个模型，从最右侧那列可以看到结果。Yes代表可以进行形式化分析，Failure代表不能。形式化分析结果无论是对或错，都是Yes,即具有形式化分析的能力。分析的结果是没有，就是Failure，即无形式化分析的能力。中间三列若都没有勾选符号√，代表是单处理器且单个时钟的架构。

图表30：形式化能力的验证结果

显而易见，3,8,9三项的模型是单处理器单时钟架构，天然可以做模型检查。

考虑通信延时(communication delays)和时钟异步(clocks asynchrony)设计，会加剧模型的复杂度。1,2,7三项是相对简单的模型，因此也可以做模型检查。由于早期SCADE不太擅长处理异步行为，所以10这项失败。对复杂的设计需要权衡模型精确度和状态空间爆炸。

对仅仅是多速率组的情况，也可以进行模型检查，可以用专门的工具插入手写代码实现多速率组。第5项是含有100页内容的SCADE模型，且运行在4个不同速率组。

第11项是相对简单的浮点数运算的模型检查，也成功。

4,6,12三项是浮点数相关的非线性运算，现有的形式化分析引擎较难应对，不可进行形式化分析。

案例四是A380扰流板功能。扰流板展开后，可用于减少飞机升力，促进刹车效果。需要验证：在飞行中，扰流板不可过度展开。该功能主要是布尔逻辑组成，仅有部分基础的数值计算（门限比较，整数运算），有时间计时器。限于商业涉密的资料，***息不多，尽管详尽的分析过程资料有限，但公开的分析报告结果也足以说明形式化分析的作用。

案例四有两个版本的功能设计，一个是有错误的版本，一个是正确的版本。有错误的版本在常规测试未发现错误，在实验室的飞行动力学测试后发现错误。尽管扰流板功能涉及的数值计算不多，但由于存在较多的计时器设计和布尔逻辑处理，因此依然足够复杂。

在配置为256M内存、1.7GHz的Pentium 4处理器上对“正确版本模型”进行形式化验证，分析了48小时，得出正确的结论。而对“不正确版本的模型”进行的形式化分析，其反例的产生时长为几分钟到一小时，这取决于选用SCADE策略(见《基于SCADE模型的形式化方法》介绍)的检测深度。反例运行的深度范围是50~160之间。

通过以上对多个案例的分析，研究人员在空客电传飞控的形式化方法应用上得出以下的经验与收获。

关于属性P的设计。缩小非形式化的安全需求与形式化的安全属性的差距，需要花不少功夫。

关于假设H的设计。研究表明有两类假设：1.排除不合理行为的假设，2.便于自动化分析而简化验证的假设。对于第一类假设，实际上并不容易区分该假设对应的行为是否真不合理，确定有效的输入阈得由飞行动力学试验来解决。第二类假设是故意排除了一些合理的行为，例如起落架轮分析时，会假设轮子静止不动或保持匀速旋转。假设缩小了验证范围，但该范围较难排除所有不合理的行为。

关于反例的解释。形式化分析证伪得出的反例需要进一步分析，可能是假设不足引起的不合理行为，也可能是对应真实飞行场景的反例。常规测试出现的错误，可以通过时间图观察可视化的航迹来定位模型的错误。形式化验证的反例较难应用时间图，因为有些反例从物理角度看来毫无意义。尽管有些不合理的细节，但反例可能恰恰揭示了模型中的真正问题。推荐用两个方法缩小范围来分析反例：1.识别反例随时间变化的模型结构部分；2.基于反例构建一个有意义场景，再来观察。第一个方法较容易，只要方案被精确定义。第二个方法较难，需要专业的航空领域知识。

图表31：形式化分析的方法

迭代的过程。形式化分析不是按个按钮的问题，需要探索分析迭代进行。产生反例可能是模型的缺陷，也可能是属性P的问题，也可能是假设H的不足。

综上，空客在电传飞控系统上应用的形式化方法是有效的，模型检查是切实可行的手段。尽管后期实验室的飞行动力学测试和飞行测试也能找到飞控模型的缺陷，但这个阶段再修改错误的代价就较高了。前期形式化分析阶段就能暴露的问题体现了软件行业“越早发现缺陷，成本越低”的金科玉律。

[1] Yong.Wang. FBW flight control system Airworthiness&Safety Design[R] CAIF 2019

[2].飞行二次元 [EB/OL]. 电传飞控，民航客机的“绝顶内功”http://www.sohu.com/a/247579057_685248. 2018年8月

[3] 军中利刃 吃透电传飞控：国产三代机上天的头号战役[EB/OL] https://www.jianshu.com/p/3ae6592abd0e. 2015年11月

[4] 张建军. 神奇的电传侧杆控制器[J]. 大飞机, 2017 (12): 82-83.

[5] Goupil P. AIRBUS state of the art and practices on FDI and FTC in flight control system[J]. Control Engineering Practice, 2011, 19(6): 524-539.

[6] Airbus Customer Services A380-800 Flight Deck and Systems Briefing for Pilots [EB/OL]. http://www.smartcockpit.com/docs/A380_Briefing_For_Pilots_Part%202.pdf. 2006年3月

[7] Van Den Bossche D. The A380 flight control electrohydrostatic actuators, achievements and lessons learnt[C]//25th international congress of the aeronautical sciences. 2006: 1-8.

[8] Traverse P, Lacaze I, Souyris J. Airbus fly-by-wire: A total approach to dependability[M]//Building the Information Society. Springer, Boston, MA, 2004: 191-212.

[9] Jean-Philippe BEAUJARD. Airbus Flight Control Systems and future evolutions[EB/OL]. https://slideplayer.com/slide/3110094. 2003年

[10] Bochot, Thomas, Pierre Virelizier, Hélène Waeselynck and Virginie Wiels. Model checking flight control systems: The Airbus experience[J] 2009 31st International Conference on Software Engineering - Companion Volume (2009): 18-27

[11] Jean Souyris. Formal Methods at Airbus: Experience Feedback[EB/OL]. http://projects.laas.fr/IFSE/FMF/J1/P04_JSouyris.pdf. (2012)

[12] Boulanger, Jean-Louis. Static analysis of software: The abstract interpretation[M]. John Wiley & Sons, 2013.

[13] Souyris J, Wiels V, Delmas D, et al. Formal verification of avionics software products[C]//International symposium on formal methods. Springer, Berlin, Heidelberg, 2009: 532-546.

[14] Laurent O, Michel P, Wiels V. Using formal verification techniques to reduce simulation and test effort[C]//International Symposium of Formal Methods Europe. Springer, Berlin, Heidelberg, 2001: 465-477.

[15] J.SOUYRIS.Industrial Use of CompCert on a Safety-Critical

Software Product[EB/OL]. http://projects.laas.fr/IFSE/FMF/J3/slides/P05_Jean_Souyiris.pdf 2014年2月

[16] Leroy X. Formally verifying a compiler: what does it mean, exactly?[C]//ICALP. 2016: 2:1-2:1.

[17] Kosmatov, Nikolai and Julien Signoles. Runtime Assertion Checking with Frama-C[R]. (2013).

[18] 崔少轩. 基于抽象解释理论的程序循环边界分析[D].南京航空航天大学,2018.

[19] 尚书,甘元科,石刚,王生原,董渊. 可信编译器L2C的核心翻译步骤及其设计与实现[J]. 软件学报,2017,28(05):1233-1246.

[20] Blazy S, Laporte V, Maroneze A, et al. Formal verification of a C value analysis based on abstract interpretation[C]//International Static Analysis Symposium. Springer, Berlin, Heidelberg, 2013: 324-344.

[21] Jean-Charles DALBIN. SCADE for AIRBUS critical avionics systems[EB/OL] SUGC 2009 (内部文档)

[22] Wiels V, Delmas R, Doose D, et al. Formal verification of critical aerospace software[J]. 2012.

[23] Moy Y, Ledinot E, Delseny H, et al. Testing or formal verification: Do-178c alternatives and industrial experience[J]. IEEE software, 2013, 30(3): 50-57.