用于交互式应用的安全“客户端-服务器”计算机系统

摘要

本发明大体的领域是用于交互式应用的安全“客户端-服务器”计算机系统，即，用于在称为“显示单元”的显示屏上以称为“窗口小部件”的软件单元的形式显示数据，所述系统被用于控制一种机器的操作，该机器包括至少一个人机接口，该人机接口允许与窗口小部件交互，所述系统管理关键数据或功能。根据本发明的该计算机系统包括一个安全引擎，其控制关键窗口小部件的显示、通过人机接口执行的命令的发送、关键数据的输入和显示的完整性。此安全引擎的主要设置是计算机“签名”的使用，“反馈”电路的设置以及防卫机制或专用确认对话框的设置。优选地，该机器是一种航空器，该计算机系统是所述航空器的舰载航空电子系统并且该显示屏是座舱显示系统。

说明书

技术领域

本发明的领域是用于交互式应用的安全的被称为“客户端-服务器”的 计算机系统，并尤其用于航空电子学应用。

背景技术

该“客户端-服务器”系统，在计算机网络世界中被广泛使用，其在座 舱航空电子系统中的首次出现是在新千年的开始。座舱航空电子系统应 当被理解为覆盖所有使得能够处理、显示、控制以及修改航空器的驾驶 和导航所需信息的电子和计算机装置，并且更普遍地用于在飞行过程中 完成航空器的任务。

ARINC 661标准提供了一种标准化的框架，用于在航空学中实现这 些计算机架构。这种系统的主要组件为：

-图形服务器，提供根据提示绘制基本图形对象的能力，以来自于船 员或“客户端”的请求或命令的形式接收这些提示。此服务器对应于该“座 舱显示系统”。它包括显示单元、人机接口、“窗口小部件(widgets)”或 “窗口小部件库”的特征数据库，以及一种“ARINC 661”格式的对话协议。 “窗口小部件”是与图形展示相关的软件单元；

-在ARINC 661标准中被称为“用户应用”或“UA”的客户端，执行操 作功能并发送请求至服务器以显示信息。

该图形服务器提供了处理动作的功能，该动作是一位操作员，在此 处为船员，想要在客户端初始化的动作。在一种客户端-服务器架构中， 该操作智能因此位于客户端内。该服务器简单地执行来自于其客户端的 请求而其并不具有任何操作的知识。相反地，在传统的航空电子系统架 构中，该操作智能位于座舱设备元件中，因此这些元件控制着他们所显 示的功能性内容。

图1和图2描述了当系统初始化并当该系统正被使用时的交互式服 务器的功能流。当系统初始化时，一种交互式应用或客户端，以“例示” 命令的方式，发送以“窗口小部件”的模型的形式存储在服务器上的交互 式页面的定义。“窗口小部件”应当被理解为与图形化展示相关的一种软 件单元以及展示在座舱显示单元上的一种行为，显示单元也被称为“DU”。 该窗口小部件使得船员通过控制介质给于航空器控制系统指令并接收信 息。根据这一模型，如图2所示，图形化命令被循环生成并被发送至图 形化机器。窗口小部件的模型可被一命令从应用自身主动的发送而修改， 或被控制介质上的用户动作修改，该控制介质还以一种命令的形式生成 来自于应用的响应。在图2中，来自于媒体的命令所采取的路径由粗线 箭头来表示。

作为示例，该控制媒介是键盘、计算机“鼠标”、“轨迹球”、触摸屏或 专用控制站，例如为“KCCU(键盘指针控制单元)”类型。该窗口小部件 传统上是弹出菜单、图形化按钮、数字输入域、“组合框”以及更一般地 覆盖了所有图形化交互装置。

在航空电子系统中，有着一定数量的所谓关键功能，他们必须能够 被“客户端-服务器”系统管理。一种关键数据或功能应当被理解为这种数 据或功能，其被驾驶系统预料不到的修改或不合时宜的激活可能导致航 空器的灾难性情况或事故。要担心的事件被归为两类，一方面是人为的 失误，另一方面是引起功能或数据的不完整性问题或甚至不合时宜的激 活问题的故障。

人为的失误包括在操作器的部分上的意外或不合时宜的动作，例如 对窗口小部件的意外点击。

完整性问题涉及三类事件：

-获取好的视觉反馈的用户交互，但是对其来说，在该用户没有意识 到它情况下，相关命令未被处理或发送。因此，确保源自在一种图形元 素上的动作的用户请求被考虑并且确保相关的处理被执行是重要的；

-不会引起任何视觉反馈的用户交互，但是对其来说，在该用户没有 意识到它的情况下，相关命令被处理或发送。因此，确保用户交互和相 关视觉反馈之间的一致性是重要的；

-窗口小部件模型结构或此模型属性的不可预料的修改。

为了可靠性，在座舱系统中将对操作功能的完整性检查落到实处是 必要的。普遍实现的技术之一为“反馈”，其包括通过逆计算验证与供给 系统的参数一起显示的参数的一致性。此机制的数学基础基于这一事实： 函数和其逆的组合等于恒等函数(F°F^-1＝identity)。因此，如果能够找到 关键参数p的显示函数F的逆函数F^-1，那么足以验证F(F^-1(p))＝p以确保 函数F确实已被执行。从系统的角度来看，为了确保不存在可能同时影 响该函数及其监视的失误，函数F和F^-1必须被足够隔离。因此特定的隔 离或“分区”机制在每个计算核心的主机结构中被执行，以防止由第一函 数的失败所产生的一种可能的恶化影响到第二个函数(特别是监视函 数)。图3示出了用于显示子系统的“反馈”控制机制，其通常包括：

-用于获取从传感器到达的信息的装置，例如其可为惯性单元；

-用于处理所述参数的装置，以及；

-图形生成装置，该设备形成一函数F以用于处理来自于传感器的 参数。

该子系统包括一监视子系统，其并行地获取来自于传感器的信息并 将该信息与函数F^-1产生的数据进行比较，该函数根据图形信息重新计算 来自于传感器的参数值。

因此，一种可被用于关键函数的“客户端-服务器”系统，例如，用于 航空学应用，必须允许：

-在一客户端上安装的交互式应用以命令的方式发送的关键数据在 “DU”上的显示。由适当的计算机发送的发动机参数的显示将被明显地引 用；

-“DU”上的交互性的使用，以检查关键函数。作为一个示例，令船 员满意的是能够以一种安全方式修改燃料管理系统的抽吸状态。

将客户端-服务器架构引入关键系统中造成完整性检查的执行的问 题。当前覆盖了所有功能子系统的反馈机制一方面不能被直接用在服务 器上另一方面不能直接用在客户端上。

此外，用户交互，也就是说船员从图形化界面的命令发起，当前没 有针对关键函数执行或者使用额外的装置执行，这些装置在人为因素方 面被严格限制。当前，为了避免这些问题，“客户端-服务器”结构在非关 键嵌入式系统中实现。

发明内容

本发明的目的是提出一种机制，用于安全化一种客户端-服务器系统 从而使其能够：

-防止用户触发一功能的机会；

-确保服务器功能的完整性，包括由操作员发起交互动作；

-确保服务器和客户端之间信息的一致性。

安全机制是一种功能性装置，其也被称为“安全引擎”，执行特定于 服务器的每个函数族的一组机制。因此，该完整性检查基于一种计算引 擎，该引擎关注于在特定于每个服务器功能族的一组机制上执行的检查：

-“防卫”的使用；

-数学“签名”的使用；

-一些子功能而不是整个子系统上的“反馈”的实现。

该数学签名是一种一开始为监控数据传输和探测计算机文件而设计 的技术。在这种情况下该技术可用于系统可靠性的目的。根据本发明的 该安全机制在ARINC 661协议上是可用的，但是本发明通常可被应用于 任意类型的客户端-服务器交互式系统。

本发明使其能够确保ARINC 661服务器的完整性，也就是说确保该 服务器的关键输出，即ARINC 661形式的命令以及本文中被称为“XGL” 的任意图形化语言的驾驶指令与由输入和指示系统提供的其输入和 ARINC 661命令一致。应当注意的是安全引擎是一组软件功能模块，该 软件并不位于一特定计算机上。

更具体地，本发明的主题是一种用于图形化应用的客户端-服务器类 型的计算机系统，也就是说用于以称为“窗口小部件”的软件单元的形式 在被称为“显示单元”的显示屏上显示数据，每个窗口小部件由“属性”来定 义，所述系统将会控制一机器的操作，该机器包括至少一个允许与窗口 小部件交互的人机接口，所述系统管理关键数据或功能，也就是说数据 或功能可能引起所述机器的严重故障，该窗口小部件被合并在一个称为 “模型”的包括每个窗口小部件的性质以及它们的等级组织的结构内，所 述模型根据客户端-应用定义文件来创建，处理关键功能的显示的窗口小 部件被称为“安全窗口小部件”，

特征在于所述计算机系统包括一个安全引擎，该引擎包括用于监视 所述安全窗口小部件的显示的设置，

第一控制设置，由所述安全窗口小部件的模型的“签名”的第一计算、 所述安全窗口小部件的定义文件的“签名”的第二计算以及对两个签名的 比较组成，一个签名是一种与所述安全窗口小部件的属性相关的数学代 码；

第二控制设置，由用于检查由服务器通过所述安全窗口小部件的模 型生成的图形化指令堆栈的一致性的算法组成，所述算法是“反馈”类型 的。

有利地，该安全引擎包括至少一个设置，用于控制通过所述安全窗 口小部件上的人机接口执行的命令的发送和数据的输入和显示，所述设 置是“UA-验证”类型的安全窗口小部件，也就是说，当改变所述安全窗 口小部件的状态的命令被从人机接口接收时，所述安全窗口小部件在改 变状态之前等待来自“客户端”的确认消息。

有利地，该安全引擎至少包括：

-第一设置，用于控制通过所述安全窗口小部件上的人机接口执行的 命令和数据的输入与显示，所述第一设置是包括防卫机制或者对话框的 安全窗口小部件，防卫机制是一种图形化对象，其保护所述安全窗口小 部件，该窗口小部件在访问所述安全窗口小部件前必须被解锁；

-第二设置，用于控制通过所述安全窗口小部件上的人机接口执行的 数据的输入和显示，所述第二设置确保该防卫或者对话框的锁定与所述 安全窗口小部件的状态的一致性；

-第三设置，用于控制通过所述安全窗口小部件上的人机接口执行的 命令和数据的输入和显示，所述第三设置由所述关键窗口小部件的签名 和它们的防卫或确认按钮的关联以及通过映射表由成对签名的UA执行 的验证组成；

-第四设置，确保由用户通过传输至值的UA所输入的该值的完整 性，并确保由UA验证其一致性的签名的完整性。

优选地，该机器是一航空器，该计算机系统是所述航空器的舰载航 空电子系统，该显示屏是座舱显示系统，并且该计算机系统按照ARINC 661航空标准操作。

附图说明

通过阅读以非限制性实施例的方式给出的下述说明并借助于附图， 将会更好地理解本发明并且会发现其他的优点，其中在附图中：

图1和图2展示了两个已经被讨论过的根据现有技术的客户端-服务 器系统的典型操作方块图，第一方块图有关系统的初始化并且第二方块 图有关系统的常规操作；

图3展示了一种根据现有技术的显示子系统，包括具有反馈的监视 子系统；

图4展示了在航空客户端-服务器应用的背景下的不同数据流；

图5是在引擎控制电路的显示的背景下，锁定和解锁位置中的防卫 按钮的图形化展示的一部分；

图6、图7和图8展示了在发送安全命令时防卫机制或对话框的根据 本发明的操作原则。

具体实施方式

下述所有内容涉及一种在ARINC 661下操作的用于航空应用的安全 的客户端-服务器计算机系统。然而，在这一特定上下文中发展的观念可 被简单地变换至具有在计算机交换和图形化展示方面的相似需求的其他 技术领域。

图4展示了航空客户端-服务器系统的各种组件之间的数据交换的方 块图。本系统的核心是显示单元或DU。它显示了根据窗口小部件模型的 窗口小部件，该窗口小部件模型是由存储着每个窗口小部件的属性和窗 口小部件间等级的ARINC 661服务器管理的存储器中的数据结构。此模 型根据“用户应用定义文件”或“UADF”创建，下文中更简单地称之为 “DF”。“DU”与由用户和“UA”控制的多种交互媒体进行交互。

正如所看到的，该安全化引擎必须确保关键数据的显示的完整性， 然后，其次，确保显示单元上的交互。因此，下面的说明包括两个主要 部分，第一个用于介绍显示的安全化，第二个用于介绍交互的安全化。

显示的安全化

保证由UA或DU以ARINC 661形式发送的关键数据的显示的安全 化是必要的。ARINC 661服务器管理在DU上的窗口小部件的显示，包 括两个步骤：

a)在存储器中管理被称为窗口小部件模型的数据结构，该模型包 括每个窗口小部件的属性并支持不同窗口小部件间的父子关系；

b)通过浏览该数据结构生成被称为XGL的图形化指令。

该安全引擎应当覆盖这两个步骤：

a)窗口小部件模型的安全化

两类事件可能修改此模型：

-UA发送的A661形式的命令；

-由称为“CDS”(座舱显示系统)的座舱航空电子系统发送的事件导 致，例如，对DU的重新配置；

关于CDS发送的事件，在源自驾驶交互的重新配置之间产生了差别， 例如驾驶交互例如是由DU上的船员发出的页面改变请求，以及归因于 对系统状态的改变的那些，例如引起系统重新配置的DU的故障。

重新配置的结果是交互式元素显示的修改，这决定了UA和ARINC 661服务器之间的对话。该对话的修改对窗口小部件模型具有或大或小的 重要影响。新的交互页面的激活是外部可视修改的示例，其导致窗口小 部件模型的升级，形成此页面的所有窗口小部件的可视属性均被修改。

因此安全化窗口小部件模型相当于：

-在初始化时管理其关于DF的完整性，

-然后确保该模型在运行时间未被出乎意料地修改；

-最后检查它的改变符合从UA和CDS事件接收的ARINC 661命令。

在规范时间，正确地识别要安全化的窗口小部件以确保此过程仅被 应用于这些窗口小部件是重要的。

为了这一安全化过程，安全引擎使用“签名”，签名是一种数学代码， 与安全窗口小部件的属性相关。此代码通常为“汉明”(Hamming)码。 应当注意的是，DF可被视作一组ARINC 661命令，因此将相同的签名 方法用于由UA和DF文件发送的ARINC 661命令是可能的。对于这些 签名，能够使用一种考虑到下述内容的函数：

-命令的类型及其A661代码；

-该窗口小部件的标识符；

-命令的值。

例如，在初始化DU或重新配置时，一致性引擎计算用于安全窗口 小部件及其双亲的DF签名以及模型的签名，并验证这两个签名相配。因 此有：

SignatureDF＝f(∑DF的安全窗口小部件的属性)

SignatureMod＝f(∑模型的安全窗口小部件的属性)

在运行时间，只要没有事件修改该模型，该一致性引擎在每个时间 间隔Δt处周期性地重新计算模型的签名，并验证在t+At时的 SignatureMod等于在t时的SignatureMod。

当该窗口小部件的模型随着UA发送的一个ARINC 661命令被修改， 一致性引擎根据该模型属性的改变来取回该A661命令。符合以下条件：

A661命令＝F^-1(模型属性的改变)

它验证了与接收的A661命令的匹配。作为第一示例，“触发按钮” 类型的页面y的窗口小部件x从未被按下状态切换至按下状态。函数 F^-1(模型属性的改变)使得能够取回名为“按下页面y的窗口小部件x”的 ARINC 661命令。作为第二示例，页面y的“文本框”窗口小部件x2的“文 本”属性取值“ALPHA”，这使得能够取回命令：设置页面y窗口小部件 x2的文本“ALPHA”。

应当注意的是，窗口小部件模型的完整性的监视，也就是说如上文 所描述的签名的计算和验证，必须与显示功能分开。

因此，由一致性引擎实现的窗口小部件模型的安全化实现如下：

-防止该模型与DF不一致：

○在初始化和重配置时比较DF的签名与模型的签名。

-避免没有命令时对模型的不可预料的修改：

○在运行时比较时刻t和t+Δt之间的模型签名；

-避免与接收到的命令不相符合的命令的执行：

○当修改模型时计算ARINC 661命令并与将其与接收到的命令 相比较。

b)生成图形化指令的安全化

其涉及确保关键数据显示的安全化直到从A661服务器输出，也就是 说，以XGL形式生成图形化命令的堆栈。

根据本发明的用于安全化图形化指令的生成的方案包括使一致性引 擎为安全窗口小部件周期性地检查图形化指令的堆栈与窗口小部件模型 的一致性。这一验证取决于窗口小部件的类型。作为一个示例，用于验 证图形化指令的堆栈与用于“标签”类型的窗口小部件的窗口小部件模型 的一致性的算法可能是：

对于所有“标签”类型的安全窗口小部件，

-在对应于该窗口小部件的图形化指令的堆栈中找出 “XGLWriteText”命令。为此，在现存函数SGLFeedbackVertex的模型上， 在XGLWriteText命令中需要一种“反馈id”参数；

-从XGLWriteText命令开始，向上移动堆栈至在前的 XGLSetAttributes命令，并比较其参数与用于当前窗口小部件的模型的属 性，例如，字体和背景颜色、字体大小等等，

-检验显示坐标的一致性。在XGL命令中，该坐标系可能与模型的 坐标系不同。因此，对于每个安全窗口小部件，它们涉及XGL命令的坐 标应当在之前就已经被投射在该模型中。

对于每个要被安全化的窗口小部件类型，必须在该模型上写入一算 法。因此，一致性引擎对图形化指令的生成的安全化被实现为如下内容：

-通过将“反馈id”类型的函数加入XGL图形化语言中，周期性地检验 生成的图形化指令(XGL)的堆栈与窗口小部件模型的一致性。

交互性的安全化

DU上的交互性组合了多个如下元素：

a)显示单元上的短暂交互，包括指针的转移、焦点的管理，也就是 说可选的窗口小部件区域或窗口小部件、指针划过的对象的高亮显示、 “组合框”的打开、列表的滚动，等等。

b)窗口小部件发送命令的交互，对于关键的命令，交互必须被安全 化；

c)数据输入和显示的交互，对于关键的数据，交互必须被安全化。

a)短暂交互

该短暂交互为用户提供一种直接视觉反馈，该用户检测出可能的故 障并且如果必要的话可使用辅助交互装置。例如，无法识别指针位置。 此外，此类交互并不产生至交互式应用的命令或数据的发送。这两个理 由使得此类交互并不关键，因此它不必被安全化。

b)发送命令的交互

对于发送命令的交互，该关键窗口小部件是所谓的“UA验证”类型。 这些窗口小部件具有特定的特征，在改变状态之前等待来自客户应用的 确认消息。例如，在指针点击事件中，具有两种状态(按下/未按下)的 按钮将发送一种状态改变请求至UA，UA驱动此功能并在实际改变其状 态前等待来自UA的确认消息。如果该确认消息在预定时间内没有到达 该窗口小部件，其返回其初始状态。如果能够确保UA和DU之间关键 数据的处理，此机制确保了HMI的状态和UA的状态之间的一致性，此 点在前面的章节已被讨论过。

此“UA验证”机制是必要的但并不是充分的。其并不能防止可能由程 序漏洞或用户失误引起的对窗口小部件的不可预料的触发。为了克服这 一最后问题，任何关键命令都被一防卫机制或一确认对话框安全化。防 卫机制是一种图形化对象，其保护安全窗口小部件，该窗口小部件在该 安全窗口小部件被访问前必须被解锁。

该防卫或确认按钮从而必须被确保。为了保证此功能，该安全引擎 发送UA，例如通过防卫或确认按钮、由所应用的函数f计算的签名，至 窗口小部件的标识符或任意其他在该防卫被唤起或确认按钮被点击时唯 一的特性。相同的程序被应用至与关键功能相关的窗口小部件的交互。 由相同函数f计算的签名被发送，在已经唤起了防卫或在显示确认按钮之 前。该UA然后解码两个签名并在一个表中检查它们相对于彼此的一致 性，该表将关键窗口小部件的标识符与它们各自的防卫或确认按钮关联 起来。按钮的管理及其防卫的管理也必须分开。

作为一个示例，图5是在显示引擎控制电路的背景下在锁定和解锁 位置中防卫按钮的图形化展示的一部分。此图在其中间示出了航空器的 两个喷气式引擎，它们的燃料供应电路、等级指示“6100”以及两个指示 为“ENG1”和“ENG2”的命令按钮，使得能够在打开或关闭喷气式引擎间 切换。将清楚地理解，这些按钮对于航空器的正确操作是十分重要的。 这两个按钮被图5中用阴影矩形表示的防卫安全化。在锁定位置，该防 卫覆盖该按钮，如图5的左侧所示。在解锁位置，该防卫处于较低的位 置并不再覆盖该按钮，如图5的右侧所示。为了锁定或解锁，用户将指 针放在所选择的防卫上，在图5中该指针由两个粗体的V形成的X表示， 然后在其上点击。

因此，为了安全化从DU至UA发送ARINC 661形式的关键命令的 交互，安全化引擎同时执行下述三种方法：

-为了避免由于人为失误对HMI上的窗口小部件的不合时宜的触 发；

○在由隔离软件所管理的相同DU上，防卫机制或对话框的系统 化使用；

○关键窗口小部件的签名与它们的防卫或确认按钮的关联，以及 由签名对的UA通过映射表实现的验证；

○如果必要(在交互后，在定义的持续时间后，等等)，在按钮 上防卫的自动复位；

-为了避免HMI和UA之间的一致性的缺失，也就是说命令没有被 考虑并没有被UA执行：

○仅使用“UA验证”窗口小部件。

因此，存在于安全化发送关键命令的交互中的问题相当于确保与UA 状态相关的窗口小部件的显示的一致性。

c)数据的输入和显示的交互

在输入交互的情况下，针对航空应用的ARINC 661的当前实现提出 了一个窗口小部件的“UA验证”族。输入“编辑框”类型的窗口小部件的值 或在“组合框”类型的窗口小部件中选择的值被UA验证，然后被返回至 DU用于最终的显示。这些窗口小部件的使用确保了UA和DU之间的一 致性，如果UA和DU之间的关键数据的传输可被确保，此问题已经被 处理。

可能满足于此机制并依靠用户去验证输入的值确实是被UA考虑的 值。然而，使用本发明的安全引擎将签名系统在依据所关注的窗口小部 件的类型(编辑框或组合框)从DU到UA输入或选择的值上落实到位 更为安全。然后，在验证和发送已确认值至DU之前，UA证实签名与输 入或选择的值的一致性。对值的签名的计算必须被执行得尽可能接近输 入并在分隔软件层中执行。可设想出多个方案，例如，一种KCCU(键 盘指针控制单元)类型的“智能”键盘，能够存储输入结果并计算其签名， 或者“逐键”(key by key)地传输签名以在DU上重建输入并验证一致性。

最后，优选对防卫机制或者确认对话框实施系统化使用以保护对于 输入窗口小部件的访问，在两种情况下都由分隔软件层管理，以便防止 任何意外的输入。此防卫或此对话框必须遵从具有上文已经描述过的输 入窗口小部件的一致性引擎控制机制。

因此，为了安全化从DU至UA输入或选择ARINC 661形式的关键 值的交互，通过同时使用下述四种方法：

-为了避免由HMI对值的不合时宜的发送并为了避免，在输入后， 对不正确值的发送

○对在同一DU上但是被分隔软件层管理的防卫按钮机制或对话 框的系统化使用；

○由关联签名与输入或选择的关键值的安全引擎执行的管理，以 及由实现签名的一致性和值的一致性的UA所执行的验证；

○由UA实现的防卫或对话框与输入窗口小部件的一致性的安全 引擎所执行的管理。

-为了保证输入值已经被考虑的确认，例如通过人机接口和UA之间 的一致性：

○仅使用“UA验证”窗口小部件。

此原理在图6、7和8中展示，图中展示了在发送安全命令的情况下 使用防卫按钮或对话框的顺序图。图6展示了用于具有防卫的输入的顺 序图的基本原理，并且图7和图8根据其是否为防卫按钮或确认对话框 展示了此相同图。

图6被组织成3列，第一列包括由“用户”(USER)执行的任务，第 二列包括由“DU”执行的任务，第三列包括由“UA”执行的任务。任务行以 逻辑次序被组织在一起，箭头指示动作的方向，任务行按照时间顺序彼 此跟随。因此，用户处理三个任务，第一个任务为“点击防卫”，在于解 锁所选择的防卫，第二个任务为“编辑值”，在于进入所选择的值，第三 个任务为“监视值”，最终在于验证所选择的值。DU传输接收到的信息并 且UA处理操作的安全化。

图7和图8被组织成4列，第一列包括由“用户”执行的任务，第二 和第三列包括由属于“DU”的两个分隔软件层执行的任务，被标识为“DU SW层1”以及“DU SW层2”，第四列包括由“UA”执行的任务。与之前的 描述一样，任务行以逻辑次序被组织在一起，箭头指示动作的方向，任 务行按照时间顺序彼此跟随。在图6所示的情况下，用户处理解锁、选 择和验证任务。

下面的表格总结了根据本发明的分布在DU和UA之间的“安全引擎” 的各种动作，并依据ARINC 661服务器的不同处理阶段。