CN103257871B - 飞行器的运行许可软件应用的数据更新的优化方法和设备 - Google Patents

Abstract

本发明涉及飞行器的运行许可软件应用的数据更新的优化方法和设备，目的尤其是优化飞行器的运行许可软件应用中的数据的更新，包括利用第二软件元件的第一软件元件(235)。在接收(250)包括所述第二软件元件的更新的软件组件之后，对接收的所述软件组件进行分析并且确定所述第二软件元件的所述更新的归属分类。根据所述归属分类，将所述第二软件元件的所述更新传(S255，S255，)给所述第一软件元件和/或中央加载系统。如果所述第二软件元件的更新被传送给所述第一软件元件，则更新所述第二个软件元件并且创建表示所述更新的配置报告。

Description

飞行器的运行许可软件应用的数据更新的优化方法和设备

技术领域

本发明涉及信息系统中的软件元件的更新，尤其是对如在ARINC667标准中定义的飞行器的许可运行软件应用中的数据进行更新的优化设备和方法。

背景技术

为了简化飞行器的维护操作和便于飞行器某些元件(通常是计算机软件元件)的更新升级和/或校正，在最新一代飞行器上普遍使用可加载的软件应用。

所述最新一代飞机也包括允许对计算机的某些软件元件进行更新的加载机制。为此，称之为软件的软件应用的新版本或称之为软件元件的所述软件应用的组件被提供在所涉及的飞行器中在所述飞行器的物理存储载体上，或经由有线或无线信息通信装置被提供。在下文中称之为加载的计算机更新操作被然后执行并配置报告被生成。当执行加载时，操作员查看生成的配置报告以验证相应的操作是否正确执行。

临界水平通常根据更新所针对的部件而与执行的所述更新有关。每个临界水平通常对实施更新的操作员的具体资格和操作有要求。因此，在对机载的软件进行更新的机制和操作方面存在不同的规章。为了使不同软件类型统一和清楚，美国爱瑞克公司(ARINC：Aeronautical Radio Inc.的首字母缩合)发行了将软件根据可用的规章进行分类的ARINC667规范。

当操作员实施软件的安装操作或更新操作时，必须要证明根据需要以正确的流程将正确的软件版本安装在正确的设备上。为此，加载机制一般允许通过配置报告来考虑安装的软件的版本以及以下称之为FIN(功能识别号，Functional Item Number的首字母缩合)的功能位置和相关设备。所述配置报告趋向于将安装在不同设备上的众多软件的配置进行分组从而使操作员不必必须针时每个软件元件或每个设备对配置报告进行处理。

所述配置报告因此包括安装在不同的加载设备上的软件的列表及其版本。通常，所述配置报告另外包括与构成具体规章的目标的软件相关和与所述规章 相关的额外信息。

当所述配置报告包括信息(根据这些信息，设备的配置对于飞行器的安全性或可靠性具有潜在重大的影响)时，其查看通常只能通过用于证明的可用的合格的设备在飞行器边缘进行。因此，当使用软件更新的某些机制时，需要委派合格的维修人员到飞行器中以进行操作。

此外，观察到一定数量的软件需要在频繁更新时将大量数据传输给飞行器。

因此，换言之，软件元件的更新通常以以下三步进行：

-从载体或通过通信网络将数据导入；

-由操作员在相关设备上安装导入的软件元件(加载)；以及

-生成描述安装的内容的配置报告。

配置报告包括安装在不同设备上的软件元件的列表以及每个软件元件的版本。在软件元件的版本和其归属于的功能识别码之间一对一存在相关度(cardinalité)。因此，当对软件元件进行更新时，需要将整个软件元件导入和安装，即便是只修改了这个软件元件的一部分。

为了改进飞行器中的软件的更新，可以将软件元件划分成更细的子软件元件。这就能够只将发生变化的子软件元件更新。

另一个改进在于为一个能够被其他软件元件以增量方式进行后续补充的软件元件创建若干个功能识别码并创建能够容纳增量的所述功能识别码的列表。

然而，所述方案不是最优的。首先，最初的划分必须考虑软件结构以及以后的变化，这通常是不现实的且这样做会使功能划分不清晰，并使得所述的功能划分变成一种技术划分，对于操作者来说更加难以掌握。此外，由于软件元件的数量增加，所以也会增大配置管理的复杂性。

此外，由于性能的原因和对构成软件元件的子部件数量的限制，需要定期地安装软件元件的完整的新版本。此外，为了确保新配置总是飞行器状态的真实图像，需要卸载先前安装的一部分增量，从而生成对于操作者有影响的特定程序。

最后，由于这些改进，所以安装的软件元件变得更复杂。因此，很难在计算机的全部软件元件上都遵守约束条件。事实上，可能变得很难、甚至不可能必须对安装在地址中的增量进行管理，这些增量本质上互不相同且与相应软件的前一完整版本也不相同。

发明内容

因此，存在改进将飞行器上的软件进行更新的系统的需要，限制操作员的干预时间及其在飞行器中的移动。

本发明的目的是时属于在飞行器的信息系统中实施的至少一个运行许可软件应用的至少一个软件元件进行更新的方法，所述至少一个运行许可软件应用包括利用至少一个第二软件元件的至少一个第一软件元件，该方法包括以下步骤：

-通过飞行器的信息系统接收包括所述至少一个第二软件元件的至少一个更新的软件组件；

-通过飞行器的信息系统对接收的所述至少一个软件组件进行分析并且响应于所述分析步骤来确定所述至少一个第二软件元件的所述至少一个更新的归属分类；

-根据所述归属分类，通过飞行器的信息系统将所述至少一个第二软件元件的所述至少一个更新至少传送给所述至少一个第一软件元件和/或中央加载系统；

-如果所述至少一个第二软件元件的所述至少一个更新被至少传送给所述至少一个第一软件元件，则通过飞行器的信息系统更新所述至少一个第二个软件元件；和

-创建表示所述更新的配置报告。

根据本发明所述的方法能够改进运行允许可用的软件元件的更新，尤其如ARINC667标准中定义的在飞行器的信息系统中实施的运行允许可用的软件元件的更新，从而尤其限定操作员的干预时间和其在飞行器中的移动。

根据本发明所述的方法与目前的维护操作是兼容的且不会给飞行器的操作员带来新的操作，也不会产生事先特定操作，例如卸载和重新配置操作。此外，在统一的配置报告中每个软件的特征都是清楚的，从而使操作员避免进行多重查询。此外，更新的数据格式可以是通常使用的类型，典型地是根据ARINC665规范而被格式化的载荷(load)。

在根据本发明所述的方法中生成的一个或若干个配置报告反映了飞行器的状态。这尤其意味着配置报告中呈现的全部软件的安装确保飞行器处于所期望的状态。在配置报告的内容和飞行器状态之间存在一一映射。

有利地，该方法另外包括对所接收的软件组件进行验证的步骤，其尤其允许检验接收到的数据对应于想要的数据。

根据具体的实施方式，该方法另外包括对至少一个第二软件元件的所述至少一个更新进行验证的步骤。这样的验证例如包括检验接收的数据与事先接收的数据之间的兼容性。

还根据具体的实施方式，本发明另外包括以下步骤：对所述至少一个第一软件元件进行询问，以与所述至少一个第二软件元件相关地获得所述至少一个第一软件元件的配置信息。所述至少一个第一软件元件因此能够了解其配置，因此其可以是负责的。数据配置的管理的该分散化尤其允许避免服从限制技术方案的数量的规范。

有利地，所述方法另外包括将所获信息配置整合到中央加载系统生成的配置报告中的步骤。

还是根据具体的实施方式，该方法另外包括接收对更新至少一个第二软件元件的激活请求的步骤，所述更新所述至少一个第二软件元件的步骤是响应于接收所述激活请求来实施的。

该方法因此允许示出更新数据相对于核准的连贯性，预期更新有效。

有利地，所述配置信息包括对更新所述至少一个第二软件元件的激活或不激活的指示，其允许标识更新的状态。

根据具体的实施方式所述，该方法另外包括允许有效更新的生成所述激活请求的步骤。

本发明的目的还有包括当所述程序在计算机上执行时能够实施根据前述方法的每一个步骤的指令的计算机程序，以及包括适于实施前述方法的每一步的装置的设备。由该计算机程序和该设备产生的优点与前述相似。

附图说明

本发明的其他优点、目的和特征在以下参考附图进行的详细描述中变得清楚，以下描述作为非限制性示例给出，在附图中：

-图1示出了根据ARINC667规章的可在飞行器中加载的软件的分解树状图；

-图2示出了对飞行器中DAFA类型的软件元件进行更新的本发明实施例；

-图3示出了在实施本发明的系统中生成的表格形式的配置报告的结构示例；以及

-图4示出了用于实现本发明或本发明一部分的信息处理设备的示例。

具体实施方式

首先可以看到，飞行器上实施的软件应用(或软件)与不同的规章有关，因此，对其配置进行管理存在困难。

如图1所示，图中示出了根据ARINC667规章的可在飞行器中加载的软件的分解树状图，在飞行器中实施的能够容纳也称为ACLSP(飞行器控制可加载软件部分，AircraftControlled Loadable Software Part的首字母缩写)的此类应用的软件应用可以根据ARINC667标准被分为4类：

-在飞行器设计框架下被认证的软件应用，通常称为LSAP(可加载软件飞行器部分，Loadable Software Aircraft Part的首字母缩合词)；

-必须经过飞行器操作员的当地管理机构在运行上许可的计算软件应用，通常称为OAB(运行许可二进制，Operationally Approved Binaries的首字母缩写)，其包括：MOS(维护操作软件，Maintenance Operations Software的首字母缩写)，即用于飞行器维护操作的软件；和FOS(飞行操作软件，Flight Operations Software的首字母缩写)的一部分，即用于与飞行器的飞行驾驶有关的操作的软件；

-由许可的应用使用的通常以表格形式的数据构成的软件元件，通常称为DAFA(许可应用的数据，Data for Approved Applications的首字母缩写)，其包括称为techpub的数据和FOS的一部分；以及

-称为任务数据(mission data)的在每个任务处被更新并被存储在称为ADB(航空数据库，Aeronautical Database的首字母缩写)的数据库中的软件元件。

为了能够符合飞行器的认证，LSAP类型的软件应用必须符合以下规定，根据该规定，每个逻辑地址只有一个软件版本。

OAB类型的软件应用可以违背飞行器认证所必需的这样的配置规章。然而，鉴于与LSAP类型的软件应用的信息相似度和鉴于操作员必须向监督机构就其配置进行解释，优选地应该根据每个软件元件只能有单一一个软件版本的配置规定。换言之，每个FIN只有唯一的软件版本识别码，称之为PNR(部分 号，Part Number的首字母缩写)。

已经观察到DAFA类型的软件元件一般经常被更新且通常尺寸很大。因此希望与这样的软件元件相关的配置规定能够放宽。

因此本发明的目的尤其在于直接向利用DAFA类型的软件元件提供DAFA类型的软件元件，而无需求助于中央安装系统。接收这些数据的软件元件管理这些数据的配置。借助于本发明，地面操作员可以实现DAFA类型的软件元件的更新并跟踪该更新，而无需进入到飞行器中。

根据本发明，优选地，在中央配置报告中，把利用DAFA类型的软件元件的软件元件和以与安装版本(PNR)相对应的识别码的形式的DAFA类型的软件元件相关联，从而尤其允许操作员证实对DAFA类型的软件元件的更新。此外，利用DAFA类型的软件元件的软件元件优选地在中央配置报告中报告由编译DAFA类型的软件元件得到的合成元件，以便于操作员对合成形式的数据进行管理。

有利地，可以仅把已更改的数据、即增量传送给飞行器以便减少传送成本并改进更新速度。

为此，本发明涉及包括以下功能的机制：

-输入和路由功能，能够使接收的ACLSP朝向中央安装服务或直接地朝向一个或若干个利用DAFA类型的软件元件的软件应用；

-通过利用DAFA类型的软件元件的软件元件实现的对DAFA类型的软件元件的处理和输入跟踪功能；

-被集中配置为对利用DAFA类型的软件元件的软件元件进行查询的配置收集的功能，从而可以将配置信息和/或与DAFA类型的软件元件相关的合成数据记入在配置报告中；和

-在需要时允许实施机载软件数据处理的功能，例如激活安装的数据但不允许用于飞行器机载用途。

图2示出了将飞行器200中的DAFA类型的软件元件进行更新的本发明实施例。

如图所示，更新的环境200在此包括地面信息系统205和飞行器信息系统210。

地面信息系统205包括与传输服务器220连接的通信网215和操作员终端 225，例如PC(个人计算机，Personal Computer的首字母缩写)类型的计算机。

飞行器信息系统210在此包括接收和路由模块230和/或中央加载系统240，该模块230被配置以将接收到的软件元件指向一个或若干个数据消费应用235，即利用DAFA类型的软件元件的软件元件。

为了更新指定的飞行器信息系统210的软件元件，操作员在此使用终端225以发起将至少一个软件元件传送给信息系统210。在步骤S250过程中，该软件元件通常是以FLS(现场可加载软件，Field Loadable Software的首字母缩写)形式和以称为载荷(Load)的软件组件的形式的相关联的指令和/或参数一起被发送，例如，载荷(Load)符合ARINC665标准。这样的参数尤其包括符合ARINC667标准的FLS分类信息。

因此，当接性和路由模块230接收到载荷(Load)时，对所接收到的载荷(Load)进行分析以从中提取出分类信息从而将接收到的该载荷(Load)传送给一个或若干个利用DAFA类型的软件元件的软件应用(数据消费应用)或传送给中央加载系统。如果涉及DAFA类型的软件元件，则将其在参考步骤S255中传送给OAB的一个或若干个相应应用。替代地成补充地，将其在参考步骤S255’中传送给中央加载系统。

将载荷(Load)传送给应用可以以多播的方式实现，即从接收和路由模块向若干个应用进行传输，或者以单播的方式实现，即从接收和路由模块向单一应用进行传送。当被告知只有一个应用时，使用单播通常性能更好。

可见，在此，DAFA类型软件元件(或DAFA数据)自动地被频繁地更新，在选择要被传送的DAFA载荷(Load)(即，包括DAFA类型的软件元件)时可能会发生错误。为了处理这样的潜在错误，位于接收和路由模块与利用DAFA类型的软件元件的软件元件之间的载荷(Load)传输和通知系统允许利用DAFA类型的软件元件的软件元件对接收到的DAFA载荷(Load)进行验证，即接受或拒绝。所述接收或拒绝优选地在行动开始时传送给操作人员的终端。接受或拒绝的决定通常基于将载荷(Load)中传送的信息和预定的信息进行比较，以便例如检验接收到的数据对应于预期的数据。

在以下步骤S260中，接收到的DAFA数据被信息系统210进行处理以便被目标应用所考虑。对DAFA数据的处理尤其包括检验DAFA能够被目标应用有效地考虑。这尤其允许使已经开始行动的操作人员能够得到快速的反馈。

因此，例如，当包括DAFA数据的载荷(Load)包含数据的增量变化(对于一个或若干个具体应用而言)时，一个或若干个目标应用就能够检验所述数据是否与先前拥有的数据相兼容。

如果接收到的DAFA数据被接受，则一个或若干个目标应用可以直接地使用DAFA数据或替代地将其存储用于后续激活，从而延迟更新的影响。当操作人员使用由接收的数据所针对的应用时，这样的实施方式尤其有必要。

当应用接受所接收到的DAFA数据时，该应用在此能够考虑其新配置。为此，实施机制能够专用于每个应用从而向其提供数据更新机制的实施选择。因此每个应用都对其配置负责。这种数据配置管理的分散化尤其允许避免服从强制根据功能识别码来具有一个单一技术方案的规定。

因此应用可以宣布其配置由针对同一功能的若干修改的堆叠得到，每个修改都会对最后定义产生作用。

为了不增多配置报告且为了使地面信息系统和飞行器信息系统之间共享传送装置，由目标应用管理的与接收的DAFA数据相关的配置报告有利地被包括在飞行器的集中配置报告中。

为此，如标号S265所示，中央加载系统240向每个利用DAFA类型软件元件的软件元件(即每个DAFA客户应用)发出对应的请求。应用通过经由根据DAFA客户应用而被定位的属性的列表提供全部配置元件来做出响应。

这些附加的属性例如是日期信息、生效信息和扩展名信息。

如图3所示，与未接收DAFA的应用相对应的FIN只有一个PNR，而对于DAFA载荷(Load)的用户应用，可以同时存在若干个PNR，这尤其允许允许进行增量更新。

在配置报告中报告的PNR允许操作员证实已经正确地进行了更新操作。额外的信息允许数据管理者更加精确地了解飞行器机载的除了单个PNR列表之外的数据的有效性。在安装的数据没有自动生效的情况下，这些数据的状态有利地构成由应用所提供的配置报告的一部分。

由于需要认证的原因，飞行器操作员必须证明在其控制下的飞行器机载的数据是连贯的。由于DAFA数据被频繁地更新，所以前述机制允许通过在飞行器上安装随后称为“潜在”数据的数据组来使飞行器预先准备好。这些潜在数据可以被激活但不能以有效的方式被目标应用所使用。在操作员的请求下，通过 机载或从地面上进行请求，潜在数据用于替换或补充由目标应用先前所使用的数据。

在图2中示出的请求S280尤其可以以自动的方式(例如以固定日期或在事件时)触发，也可以从地面或从机上手动地触发。

在收到这样的请求时，目标应用进行切换并更新其配置报告。因此，地面操作员了解安装的和机上有效使用的数据的准确配置。

图3示出了表格形式的在实施本发明的系统中生成的配置报告300的结构的示例。

配置报告在此通常包括标号为305的行的集合和标号为310的列的集合。其包括两部分，其中一部分由列310-1和310-2形成，另一部分由列310-3至310-6形成。

列310-1至310-6在此分别地涉及功能地址、软件版本的唯一第一识别码、数据描述、有效日期、补充信息以及软件版本的唯一第二识别码。

第一部分与标准配置报告相对应。所述第一部分在此由中央配置系统所担任。在该第一部分中，每个行对应于功能地址。因此，例如，行305-3对应于功能地址FIN C，在此是LSAP类型应用的软件元件，且行305-4对应于功能地址FIN D，在此是OAB类型应用的软件元件。软件版本的唯一识别码与每个功能地址相关联。例如，PNR3和PNR4的软件版本的唯一识别码分别与功能地址FIN C和FIN D相关联。

配置报告的第二部分与DAFA类型数据特有的信息有关。这些信息与一个或若干个应用相关联，其取决于OAB类型的应用的软件元件的功能地址。该第二部分由利用DAFA类型的软件元件的软件元件所担任。例如，涉及两个DAFA类型的软件元件的行310-4-1和310-4-2与功能地址FIN D的软件元件相关联。换言之，功能地址FIN D的软件元件与使用在行310-4-1和310-4-2中描述的数据的应用相对应。

需要提醒地是，如果软件版本的唯一识别码与LSAP或OAB类型的应用的软件元件的各个功能地址相关联，则软件版本的若干个唯一识别码可与允许通过子元件进行增量更新的每个DAFA类型的软件元件相关联。因此，例如，软件版本的唯一识别码PNR4xx、PNR4xy、PNR4xz关联于与在行305-4-1中识别的数据相关的软件元件，该软件元件本身与OAB类型的应用的软件元件的功能地址FIND相关联

图4示出了能够用于至少部分地实现本发明的、尤其是参照图2描述的步骤的信息处理设备的示例。设备400例如是一个IMA(综合模块化航空电子设备，Integrated ModularAvionics)类型的计算机或电脑。

设备400优选地包括通信总线402，与之相连的是：

-中央处理单元或微处理机404(CPU)；

-可以包括应用系统和诸如“Prog”程序等的只读存储器(ROM)406；和

-随机存储器或缓存存储器(RAM)408，该随机存储器包括适于记录在执行上述程序过程中生成和修改的变量和参数的寄存器；和

-与例如是AFDX(Avionics Full Duplex)网的分步通信网428连接的通信接口426，所述接口能够传送和接收数据，尤其是软件元件的更新数据。

可选地，设备400还可以具有以下元件：

-与屏幕416相连的图形卡414；

-能够包括上述Prog程序和根据本发明已经过处理或需要进行处理的数据的硬盘420；

-键盘422和鼠标424或任何其他指向设备，如允许使用者与根据本发明所述的程序进行互动的视觉笔、触摸屏或遥控器；和

-能够从存储卡读出或向存储卡写入根据本发明所述已经过处理或需要进行处理的数据的存储卡阅读器(未示出)。

通信总线允许在包括在设备400中的或与该设备连接的不同元件之间进行通信和互操作。总线的表现形式没有限制性，并且，中心单元能够向设备400的所有元件直接地或通过设备400的其他元件发送指令。

允许编程装置实现根据本发明的处理的每个程序的可执行代码可以被例如存储在硬盘420中或只读存储器406中。

根据变型，程序的可执行代码可以经由接口426通过通信网络428接收，以便以与上述相同的方式被存储。

通常，一个或若干个程序可以在执行前被加载在设备400的其中一个存储装置中。

中央单元404将控制和引导执行根据本发明所述的程序的软件编码部分的 指令以及存储在硬盘420或只读存储器406中或其他上述存储元件中的指令。当施加电压时，存储在非易失性存储器中的程序，例如存储在硬盘420或只读存储器406中的程序，被转移到随机存储器408(其然后包含根据本发明所述的一个或若干个程序的可执行代码)中和用于存储实施本发明所需的变量和参数的寄存器中。

需要注意的是，包括根据本发明的设备的通信装置还可以是编程装置。该装置因此包含例如固定在专用集成电路(ASIC)中的一个或若干个信息程序的编码。

当然，为了满足具体需要，本领域技术人员可以在上面的描述中进行修改。

Claims (6)

1.一种对属于在飞行器的信息系统(210)中实施的至少一个运行许可软件应用的至少一个软件元件进行更新的方法，所述方法的特征在于，所述至少一个运行许可软件应用包括利用至少一个第二软件元件的至少一个第一软件元件(235)，该方法包括以下步骤：

-通过飞行器的信息系统(210)接收(S250)包括所述至少一个第二软件元件的至少一个更新的软件组件；

-通过飞行器的信息系统(210)对接收的所述至少一个软件组件进行分析并且响应于所述分析步骤来确定所述至少一个第二软件元件的所述至少一个更新的归属分类，所述归属分类是根据能应用的规章进行的；

-根据所述归属分类，通过飞行器的信息系统(210)将所述至少一个第二软件元件的所述至少一个更新至少传送(S255，S255’)给所述至少一个第一软件元件和/或中央加载系统；

-如果所述至少一个第二软件元件的所述至少一个更新被至少传送给所述至少一个第一软件元件，则通过飞行器的信息系统(210)更新所述至少一个第二个软件元件；

-创建表示所述更新的配置报告；

-对所述至少一个第一软件元件进行询问，以与所述至少一个第二软件元件相关地获得所述至少一个第一软件元件的配置信息；

-将所获得的配置信息整合到由所述中央加载系统生成的配置报告；

-接收对更新所述至少一个第二软件元件的激活请求，所述更新所述至少一个第二软件元件的步骤是响应于接收所述激活请求来实施的；

所述配置信息包括对更新所述至少一个第二软件元件的激活或不激活的指示。

2.根据权利要求1所述的方法，另外包括对接收的软件组件进行验征的步骤。

3.根据权利要求1或2所述的方法，另外包括对至少一个第二软件元件的所述至少一个更新进行验证的步骤。

4.根据权利要求1或2所述的方法，另外包括生成所述激活请求的步骤。

5.一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序包括当所述计算机程序在计算机上执行时能够实施根据权利要求1-4中任一项所述的方法的每一个步骤的指令。

6.一种包括能够实施根据权利要求1-4中任一项所述的方法的每一个步骤的装置的设备。