CN111176978A - 验证不合格部件的工具验证系统和方法 - Google Patents

Abstract

一种验证不合格部件的工具验证系统和方法，包括：接收工具和未验证部件之间的通信；将通信与先前合格的一组通信进行比较；以及基于比较确定不合格部件是否可以使合格。

Description

验证不合格部件的工具验证系统和方法

相关申请的交叉引用

本申请要求于2018年11月9日提交的美国临时专利申请No.62/758,008的优先权和权益，其全部内容合并于此。

技术领域

本公开涉及一种用于基于相似的过去合格性来使原本不合格的工具合格的方法和设备。

背景技术

在技术环境中，例如在飞行器的航空电子系统中，工具，软件和应用有资格作为受管制的操作环境的一部分。但是，在某些情况下，被包含作为系统或工具的一部分的更新的或改进的软件或应用不合格或以其他方式重新被合格。

发明内容

在一个方面，本公开涉及一种工具验证系统，包括：合格工具；测试系统，测试系统具有不合格部件，测试系统与合格工具通信地连接；以及工具验证部件，工具验证部件配置成感测合格工具与不合格部件之间的一组通信，将感测到的一组通信与合格工具和先前合格的部件之间的预定的一组通信进行比较，并基于比较确定用于不合格部件的合格决定。先前合格的部件是不合格部件的先前版本。

在另一方面，本公开涉及一种验证不合格部件的方法，该方法包括：由工具验证部件接收先前合格的工具与不合格部件之间的一组通信；由工具验证部件将接收到的一组通信与先前合格的工具和不合格部件的先前合格的版本之间的预定的一组通信进行比较；基于比较，确定不合格部件是否在功能上根据不合格部件的先前合格的版本进行操作；和基于确定不合格部件在功能上根据不合格部件的先前合格的版本进行操作，来确定不合格部件为合格部件。

附图说明

在附图中：

图1示出了根据本文描述的各个方面的工具验证系统的示意图。

图2示出了根据本文描述的各个方面的以另一种操作模式操作的图1的工具验证系统的示意图。

图3示出了根据本文描述的各个方面的另一工具验证系统的示意图。

图4示出了根据本文描述的各个方面的以另一种操作模式操作的图3的另一种工具验证系统的示意图。

图5是根据本文描述的各个方面的展示了验证不合格部件的方法的示例性方法流程图。

具体实施方式

本公开的各方面可以在用于验证不合格工具的任何环境，设备，系统，航空电子系统或方法中实现，而无论该工具或系统执行的功能如何。例如，本公开的方面可以应用于其他系统或行业，在该其他系统或行业中，系统更改受测试或认证的阻碍。这样的其他行业可以包括但不限于医疗保健行业或系统，化学，制造，加工和类似行业，银行行业或系统，运输行业或系统等。

尽管将描述“一组”各种元件，但是应理解，“一组”可包括任何数量的相应元件，包括仅一个元件。同样如本文所使用的，虽然传感器可以被描述为“感测”或“测量”相应的值，但是感测或测量可以包括确定指示相应值或与相应值有关的值，而不是直接感测或测量该值本身。感测或测量的值可以进一步提供给其它部件。例如，可以将该值提供给控制器模块或处理器，并且控制器模块或处理器可以对该值执行处理以确定代表值或代表所述值的电气特性。

连接参考(例如，附接，联接，连接和结合)将被广义地解释，并且除非另外指出，否则可包括元件集合之间的中间构件。这样，连接参考不一定推断出两个元件直接连接并且彼此成固定关系。在非限制性示例中，可以选择性地构造连接或断开连接以提供，启用，禁用等在各个元件之间的电连接。

如本文中所使用，“系统”或“控制器模块”可包括至少一个处理器和存储器。存储器的非限制性示例可以包括随机存取存储器(RAM)，只读存储器(ROM)，闪存或一种或多种不同类型的便携式电子存储器，例如光盘，DVD，CD-ROM等，或这些类型的存储器的任何适当组合。处理器可以被配置为运行被设计为执行各种方法，功能，处理任务，计算等的任何合适的程序或可执行指令，以启用或实现本文所述的技术操作或操作。该程序可以包括计算机程序产品，该计算机程序产品可以包括机器可读介质，该机器可读介质用于承载或具有存储在其上的机器可执行指令或数据结构。这样的机器可读介质可以是任何可用的介质，其可以被通用或专用计算机或具有处理器的其他机器访问。通常，这样的计算机程序可以包括例程，程序，对象，部件，数据结构，算法等，其具有执行特定任务或实现特定抽象数据类型的技术效果。

由于许多现代航空电子系统主要基于软件，因此需要特殊的软件认证要求。机载航空电子系统中使用的软件的安全性受到例如欧洲航空安全局(EASA)或联邦航空管理局(FAA)的指导。在一个示例中，EASA的文件ED-12C的应用可以提供指导。在另一个示例中，FAA的文件DO-178C的应用，机载系统和设备认证中的软件注意事项可以指导认证要求，可以提供指导。该文档用于指导确定给定软件在机载环境中是否将可靠运行。软件级别，也称为设计保证级别(DAL)，是通过检查特定系统中故障状况的影响，从安全评估过程和危害分析中确定的。故障状况按其对飞行器，机组人员和乘客的影响以从A到E的降序进行分类。在下面的讨论中，DAL A的合规性将被称为“高于”或“大于”DAL B，C，D和E的合规性，而DAL B或DAL C的合规性将被称为“低于”或“小于”DAL A的合规性。表1展示了DAL级别，故障状况以及故障对飞行器的影响。

表1：DAL级别和故障影响

单独的DO-178C并不旨在保证软件安全性。设计中的安全属性以及作为功能实现的安全属性必须接收其他强制性系统安全任务，以驱动和显示满足明确安全要求的客观证据。这些软件安全任务和工件是危险严重性和DAL确定过程中不可或缺的支持部分，将记录在系统安全评估(SSA)中。认证机构要求，并且DO-178C指定使用这些综合分析方法建立正确的DAL，以建立DAL级别A-E。正是软件安全分析驱动了系统安全评估，从而确定了DAL，而DAL则驱动了DO-178C的适当严格程度。此外，不同DAL级别的航空电子系统之间的交互必须包含数据和计算完整性保护，以确保认证的操作效率。因此，DO-178C的中心主题是在已建立必要的安全要求之后进行设计保证和验证。

证明对那些法规的合规性或合格性是昂贵的过程，其包括模拟，飞行测试，统计和分析。在许多情况下，开发DAL A兼容系统与DAL B或C兼容系统相比成本显著更昂贵且占用大量资源。例如，开发DAL A兼容飞行指导系统的成本估计比DAL B或C兼容飞行指导系统贵三倍。因此，DO-178C兼容软件的开发成本随着DAL级别的提高而增加。例如，虽然DAL E合规性可能比DAL A合规性便宜，但所有合规性系统的合格性均需承担费用。尽管为了理解而描述了DAL认证，但是在本公开的各方面中可以采用任何方法，机制，测试策略或合规性资格，标准等。工具合格等级可以类似于本文描述的DAL等级，并且同样增加了严格性，因此增加了变更成本。

在软件和硬件开发领域中，“工具”是用于开发或验证另一产品的软件或硬件项目。如本文所用，被验证的产品可以理解为“被测单元”或“产品”，并且对应于DO-178C开发的软件或DO-254开发的硬件。此外，“合格”工具是指软件或硬件项目，其中工具通过生产产品(即根据要求生成可执行代码)或验证产品(即，检查源代码的静态代码分析工具或检查系统功能的装备)来执行否则将由人执行的活动。在对机载产品进行镜像的过程中，使用工具合格等级(TQL)来使工具合格。因此，使TQL-1工具合格的成本比TQL-5的成本高。在工具环境中使该工具合格，并且对环境的任何更改都将被视为影响工具合格性。

因此，将检查，验证，确认或以其他方式使合格工具与其工具环境的交互的系统称为“工具验证系统”。从这个意义上说，工具验证系统可以配置为或可操作为识别或“标记”是否相对于环境的某些事项已变化，这将会降低其合格性，从而使得将不再保证合格工具会产生相同的输出。工具环境是运行工具的操作系统，其他应用程序和硬件。

示例性附图仅出于说明目的，并且所附附图中反映的尺寸，位置，顺序和相对大小可以变化。

图1示出了工具验证系统10，该工具验证系统10用于验证显示为合格工具12的工具与显示为第一测试系统14的系统之间的交互或通信。如本文中所使用的，“合格”工具12可以包括已经被测试，验证，确认，或者以其他方式被授权或批准以在特定工具环境或使用中操作的物理或虚拟工具。例如，飞行器和航空电子系统是受管制的系统，需要先对部件进行测试和确认，然后才能在飞行器上使用。测试和确认可以包括相对简单且便宜的过程(以时间或货币价值(例如美元)衡量)，复杂且昂贵的过程，或介于两者之间。例如，尽管电压传感器的测试程序可能不那么严格，以使飞行器或航空电子系统使用合格，但自动着陆或自动飞行软件应用可能要经过高度严格的测试程序，以确保可靠飞行器或航空电子设备使用的“合格”的合规性或能力。

在某些情况下，开发，验证或以其他方式使合格工具12合格的成本可包括开发，验证或以其他方式使任何基础软件或系统合格，合格工具12与任何基础软件或系统进行交互，通信或相对于其以其他方式操作。例如，在一个非限制性示例中，合格工具12可以在合规性合格期间与通信连接的计算机系统，例如测试系统14(例如，本文所述的工具环境)进行通信。在使合格工具12合格中，合格工具12还有资格在合格工具12操作期间根据需要与测试系统14可靠或可验证地交互。将理解的是，尽管使用“合格”来描述合格工具12，但是仅在测试系统14的特定环境内工具12(和任何其他工具)是“合格”的，并且仅在这种不变的环境(例如，仅针对特定的测试系统14)中被视为“合格”的。在环境变化的情况下，例如改变测试系统14(例如在“不合格”的测试系统中)，“合格”工具12可能不是严格合格的。然而，为了简洁和易于理解，即使与“不合格”测试系统配对，合格工具12也将被称为“合格”的。

随着时间的推移，可以更新合格工具12与之交互，通信，或相对于其以其他方式进行操作的软件或系统的各个方面。例如，软件或系统的更新可以包括安全更新，功能更新，错误或计算机“错误”的解决或“修复”，改进的性能等。在另一个示例中，在找不到，获取不到或无法修复原始部件(或原始合格部件)的情况下，可以替换旧的，遗留的，过时的，不可替换的或无法运行的硬件。然而，由于与合格工具12的认证或合格性(例如测试，重新测试，回归测试等)相关的成本，航空电子系统中可能不包括软件或系统的更新，因为它们不直接影响合格工具12。从软件的角度来看，即使可能对合格工具12的操作没有直接影响，也可能期望对软件进行更新以确保安全性，可靠性等。因此，可能期望能够实现一种用于测试或验证与合格工具12交互的更新软件的机制或方法，同时减少用于使新软件版本合格或验证新软件版本，或重新使新软件版本合格的总体范围，规模或成本。

因此，可以包括本公开的各方面，其中可以利用或采用工具验证系统10来确定原本不合格的系统部件的合格决定。从这个意义上讲，本公开的各个方面可以包括对合格工具12与原本不合格的系统部件或环境之间的交互的评估，以确定是否已经发生了任何将会影响合格工具12的事情，因此我们不需要重新使合格或仅部分重新使合格(受影响零件的回归测试)。这可以通过以两种操作模式操作工具验证系统10来进一步实现：第一“学习”模式(图1所示)和第二“监督”模式(图2所示)。图1示出了具有与第一测试系统14通信的合格工具12的工具验证系统10，该第一测试系统14可以包括先前合格或先前认证的测试系统14。如本文中所使用的，先前合格的测试系统14可以包括先前已经被断定或预定为根据飞行器操作的认证，合格性，批准或其他被授权的程序进行操作的测试系统14。换句话说，测试系统14可以包括或表示用于与合格工具12交互的合格系统。

合格工具12可以通过一组通信接口与测试系统14通信连接，该通信接口被示为工具接口18和测试系统接口20，其被启用以允许或实现各个部件之间的通信。该组接口18、20的非限制性方面可以包括物理接口，例如网络接口，端口，连接器，总线，外围部件互连(PCI)总线，无线接口或虚拟接口，例如软件接口，虚拟化接口，软件分区等。还示出了合格工具12具有至少一个软件部件22，例如，该软件部件22被适配，配置或以其他方式被启用以提供合格工具12的操作。

测试系统14示出为包括存储器24，处理器26，数据存储设备(例如数据盘28)和操作系统30。尽管示出了存储器24和数据盘28，但是本公开的非限制性方面可以包括仅一个数据存储部件，例如存储器24或数据盘28。操作系统30可以包括操作测试系统14的任何系统，包括但不限于Linux，Unix，Microsoft Windows等。操作系统30可以进一步包括一组系统调用32和应用编程接口(API)调用34。如本文所使用的，“系统调用”32是被配置或适配为提供或以其他方式使软件或程序能够与操作系统或其内核交互的程序机制。示例系统调用可以包括但不限于：进程创建或管理，主存储器管理，文件访问，目录系统管理，文件系统管理，输入/输出设备管理，联网命令等。“API调用”34是被配置或适配为提供或以其他方式使第一软件部件或程序能够与另一软件部件或程序交互的程序机制。API调用34的示例可以包括与数据服务器交换数据，执行例行程序功能，例如数学功能等。

通常，该组系统调用32和该组API调用34由操作系统30或其软件部件定义。例如，在操作系统30或其软件部件的单个版本中，通常不会更改，引入或删除系统调用32和API调用34。

在合格工具12和先前合格或先前认证的测试系统14的操作期间，合格工具12或其至少一个软件部件22可以例如通过通信的方式与测试系统14进行交互。在非限制性示例中，通信可以包括相应接口18、20之间的通信36，合格工具12与操作系统30之间的通信38，合格工具12与该组系统调用32或其子集之间的通信40，合格工具12与该组API调用34或其子集之间的通信42，或其组合。在一个非限制性示例中，可以通过相应的接口18、20或其通信36来有效地承载通信38、40、42。

此外，在合格工具12和先前合格或先前认证的测试系统14的操作过程中，合格工具12或其至少一个软件部件22可以与其他系统部件交互，其他系统部件示出为第一真实或实时部件62，也显示为虚拟部件64。如本文中所使用的，“真实”或“实时”部件62可以包括诸如在生产环境中发现的物理部件。例如，在包括自动着陆软件程序22的合格工具12的非限制性示例中，真实部件可以包括飞行管理计算机，终端，传感器，飞行员交互式设备(例如，驾驶舱控件)等。如本文所使用的，“虚拟”部件64可以包括被设计为作用为或以其他方式操作或模仿真实或实时部件的操作的模拟或近似软件部件。例如，在海拔保持稳定的测试环境中，海拔传感器日期可以由“虚拟”海拔传感器部件64生成。尽管仅示出了单个真实和虚拟部件62、64，但是本公开的方面可以包括任何数量的真实部件62或虚拟部件64，包括仅真实部件62或仅虚拟部件64的非限制性方面。

工具验证系统10还可包括工具验证部件16，该工具验证部件16包括测试程序集50，控制器模块51，存储器52和高精度计时器54。如本文所使用的，“高精度”计时器54可以包括具有高分辨率的计时器。例如，可以从虚拟机内部使用高精度计时器54，来查看“真实”(例如，一对一)的时钟时间。在虚拟机或模拟环境中，环境已虚拟化，因此时间的流逝是“明显”的时间流逝。通过与外部时钟通信，可以找到实际的处理速度和时序。例如，虚拟机中的10微秒在“真实世界”时钟时间中可能是1微秒。在一个非限制性示例中，工具验证部件16可以通过第一通信线路44与合格工具12通信连接，并且可以通过第二通信线路46与先前合格或先前认证的测试系统14通信连接。在另一个非限制性示例中，工具验证部件16或其存储器52可以与数据存储装置60通信地连接。

工具验证部件16可以被配置或适配为通过通信线路44、46可操作地控制合格工具12，先前合格的测试系统14或它们的组合。在一个非限制性示例中，工具验证部件16可以适于执行合格工具12、先前合格的测试系统14或其组合的特定操作。在另一个非限制性示例中，可以基于测试程序集50来指导合格工具12、先前合格的测试系统14或其组合的特定操作的执行。从这个意义上说，可以从合格工具12或先前合格的测试系统14传递，传达或以其他方式要求测试程序集50。在一个非限制性示例中，可以通过控制器模块51来执行或控制测试程序集50。

工具验证部件16还可以被配置或适配为获取，感测，测量，接收或以其他方式记录与由合格工具12和先前合格的测试系统14执行测试程序集50有关的数据或一组数据。例如，如图所示，工具验证部件16可以包括一组信号传感器56，其被配置或适于感测或测量通信36、38、40、42。可以包括能够对各个部件之间的通信进行感测，测量，接收等的任何信号传感器56。在一个非限制性实例中，信号传感器56可以被配置为感测到存在信号，或者可以被配置为感测所传递或传达的精确数据信号。在另一个非限制性实例中，信号传感器56可以是与物理部件相对的软件部件。

在这个意义上，合格工具12和先前合格的测试系统14的通信36、38、40、42可以指示或代表合格工具12相对于测试系统14的合格或认证操作。在一个示例中，在接收到感测或测量的通信36、38、40、42时，可以通过一组通信线路58将感测或测量的通信36、38、40、42提供，供给，递送等到工具验证部件16，感测或测量的值用从高精度计时器54接收的时间加上时间戳，并保存或存储在存储器52中，或者保存或存储在数据存储装置60中。

通过保存或存储感测或测量的包括精确时间戳的通信36、38、40、42，工具验证系统10或工具验证部件16可以准确地记录和保存一组通信，该一组通信指示或代表合格工具12和先前合格的测试系统14。换句话说，虽然工具验证系统10或工具验证部件16不执行和记录工具的典型操作(例如，有效或功能操作，无论它们可能是什么)，但工具验证系统10或工具验证部件16记录并存储与合格工具12和先前合格的测试系统14之间的精确(和时间戳)通信有关的数据。在另一个实例中，记录和存储的数据指示合格工具12和先前合格的测试系统14的合格或认证操作。

图1的合格工具12和先前合格的测试系统14的操作和描述涉及工具验证系统10的第一“学习”操作模式。在这种模式下，工具验证系统10或工具验证部件16可以被理解为是关于指示合格工具12和先前合格的测试系统14的合格或认证操作的通信的“学习”。

图2示出了根据本公开另一方面的另一工具验证系统110。工具验证系统110类似于工具验证系统10；因此，除非另有说明，否则将用增加100的相似数字来标识相似部件，应当理解，工具验证系统10的相似部件的描述适用于工具验证系统110。一个区别是，图2中的公开内容的方面包括第二测试系统114，该第二测试系统114可以包括不合格，未认证或相似的部件(例如，不合格的工具环境或“被测单元”)。例如，在一个非限制性实例中，第二测试系统114可以包括不同的操作系统130，例如类似于图1的操作系统30的操作系统130，但是具有任何数量的更新，错误修复，安全性增强等。换句话说，操作系统130可以是更新的安全系统30，其中核心或基本功能不变。从这个意义上讲，可能希望在生产环境(例如航空电子系统或飞行器)中合并更新，错误修复，安全性增强等，而无需对合格工具12进行任何更改或更新。然而，如前所述，测试系统114，操作系统130等的完全重新认证可能是昂贵的。尽管将不合格部件描述并示出为操作系统130，但是可以包括本公开的非限制性方面，其中任何基础部件，系统，操作，功能等可以是不合格工具。例如，在定制配置的系统中，对系统调用132或API调用134的更新可以单独地认为是不合格工具，适用于本公开的方面。

测试114的更改的其他非限制性示例可以包括但不限于工具运行但根据不同处理器模型或指令集进行操作的处理器26更改(或完全不同的处理器26)，处理器26或操作系统130针对处理器24中具有不同表示(例如，大端对小端)的不同模型更改，物理介质在盘28中更改(例如，不同大小的硬盘驱动器或介质类型的更改，例如从旋转硬盘驱动器到固态驱动器)，当工具是虚拟机时，将该虚拟机移动到另一个测试系统114，当工具从直接托管在硬件上移动到托管在虚拟机上时，接口更改，例如测试系统接口20，外围部件互连(PCI)总线上的ARINC 429卡到通用串行总线(USB)接口等。

可以包括本公开的各方面，其中，可以操作测试验证系统110或测试验证部件116，以识别，确定，估计或以其他方式建立诸如操作系统130的其他不合格部件是否与其他合格工具12兼容。这样的识别，确定，估计或建立可以基于例如合格工具12与不合格部件，第二测试系统114等之间的通信的比较。

例如，如关于图1所述，存储器52或数据存储设备60可以存储在已知的，预定的，预先建立的，先前合格的，或先前认证的合格工具12和合格测试系统14之间的一组感测或测量的通信36、38、40、42。可以由工具验证部件116中的存储器52或数据存储设备60调用相同的存储的一组感测或测量的通信36、38、40、42。在这种意义上，工具验证部件116可以通过第一通信线路44与合格工具12通信连接，并且可以通过第二通信线路46与不合格测试系统114通信连接。工具验证部件116可以再次被配置或适配为基于测试程序集50，通过通信线路44、46可操作地控制合格工具12，不合格测试系统114或其组合，例如适于执行合格工具12的特定操作。注意，测试程序集50可以与针对图1执行的测试程序集50一致或相同。从这个意义上讲，可以从合格工具12或不合格测试系统114传递，传达或以其他方式要求测试程序集50。在一个非限制性示例中，可以通过控制器模块51来执行或控制测试程序集5050。在另一个非限制性示例中，工具验证部件116可以被配置或适配为根据需要可操作地控制不合格测试系统114，以最佳地近似生产环境或先前合格的测试系统14。例如，工具验证部件116的非限制性方面可以可操作地控制不合格测试系统114的处理器速度，虚拟化硬件环境等。

以类似的方式，工具验证部件116可以获得，感测，测量，接收或以其他方式记录与由合格工具12的不合格测试系统114执行测试程序集50有关的数据或一组数据。因此，在类似的操作模式下，该组信号传感器56被配置为或适于感测或测量该组通信136、138、140、142，其是接口18、20之间的相应通信136，合格工具12和不合格操作系统130之间的通信138，合格工具12和该组不合格系统调用132或其子集之间的通信140，合格工具12和该组不合格API调用134或其子集之间的通信142，或其组合。尽管示出和描述了通信136、138、140、142，但是可以包括附加通信或与通信有关的数据。

在这个意义上，合格工具12和不合格测试系统114的该组通信136、138、140、142可以指示或代表合格工具12和不合格测试系统114的交互或操作是否可以基于该组通信136、138、140、142与合格测试系统14的该组通组36、138、140、142的比较而被确定，使合格，验证或以其他方式进行认证。例如，工具验证部件116可以保存或存储该组通信136，138，140，142，包括其精确的时间戳，并且通过控制器模块51比较多组通信36，38，40、42、136、138、140、142，来确定它们是否“对准”。

在非限制性示例中，合格测试系统14的该组通信36、38、40、42与不合格测试系统114的通信136、138、140、142的“对准”，“对齐”或“对准化”可以基于例如用于相似或可比较的通信(例如，发起的通信，终止的通信，通信的发起和终止之间的长度)，相似或可比较的通信内容(例如，是每个方向上通信的相同的消息或数据)的通用精度计时器，是否按预期正确接收和响应了通信内容(例如，系统调用132，API调用134等是否以类似方式使用，包括数据或消息特性，时序考虑因素，等)来限定。

此外，可以包括确定合格性决定中的其他考虑因素。例如，在非时间敏感的合格工具12应用中，延迟可能不被关注，只要它在宽的预定延迟范围内即可。因此，在合格工具12与不合格测试系统114之间的通信136、138、140、142不对时间敏感的情况下，比较中的差异或确定合格性决定中的差异可忽略精度时间戳中的差异。相反，在时间要求严格的合格工具12应用中，比较中的差异或确定合格性决定中的差异可以例如主要基于建立相似或可比较的延迟。

在另一个非限制性实例中，在确定合格性决定中的其他考虑因素可以基于由合格工具12使用的系统调用132或API调用134是否仍然存在并且可以被更新的操作系统130，更新的一组系统调用132或更新的一组API调用134访问。因此，本公开的各方面可以基于根据硬件参数，软件参数，交易参数(例如，通信)或其组合的任何组合的合格性决定的确定。

在又一个非限制性实例中，确定合格性决定中的其他考虑因素可以基于不同处理器26的更快或更慢的执行，在执行虚拟机处理之前未运行的计算或指令的不同准确性，导致误导或不正确的计算(例如，大端对小端)的数据的不同解释，基于盘28更改的读写访问延迟或盘容量要求，或(例如发生接口20更改时)的通信延迟的影响。

在此意义上，工具验证系统110或工具验证部件116可以以图2的“监督”模式操作，其中工具验证部件116监督合格工具12相对于不合格测试系统114的操作，并基于监督模式下的通信的比较，对更新的或原本不合格的测试系统114是否应该，可以或为可合格，可认证，甚至被合格或认证进行确定或决定。因此，可以包括本公开的非限制性方面，其中操作工具验证系统110或工具验证部件116的设备或方法可以确定针对不合格的测试系统114的合格性决定，从而使与先前认证的测试系统14类似但已更新或增强的不合格的测试系统114，可以在生产环境，飞行器或航空电子系统中实现，而无需执行完整的合格化处理。

本公开的各方面可以进一步应用在以下情况中，其中较旧的传统硬件不可用于部件制造商，将过时的硬件虚拟化在较新的硬件中，或者需要对基础硬件或软件进行更改以进行更新，错误修复，安全性增强等，以改善合格工具12环境的整体操作。

此外，尽管本公开的方面将一组信号传感器56描述为适于感测或测量接口18、20之间的该组通信136、138、140、142，但是可以包括本公开的非限制性方面，其中该组信号传感器56可以包括一组输入/输出信号传感器56。该组输入/输出传感器56可以被进一步配置或适配为不仅感测该组通信136、138、140、142，而且还提供，供给或以其他方式注入信号到该组通信136、138，140、142中。从这个意义上讲，可以包括本公开的非限制性方面，其中工具验证部件116可以通过主动地提供信号来使得能够受控地执行合格工具12，测试系统114或其组合的特定操作，以便感测或记录对这些信号的响应。例如，如在软件测试中所理解的，工具验证部件116可以提供一组中断测试信号，其被选择来触发或执行系统，API或其他“中断”动作。在这种意义上，工具验证部件116可以被动地(通过感测该组通信136、138、140、142)或主动地(通过注入已知的中断信号并响应中断信号来感测该组通信136、138、140、142)执行受控操作。此外，所描述的“主动”测试的非限制性方面可以进一步相对于图1的“学习”模式的各方面被包括，记录，并与图2的“监督”模式的各方面的结果进行比较，如本文所述。

图3示出了根据本公开的另一方面的另一工具验证系统210。工具验证系统210类似于图1的工具验证系统10(在“学习”模式下操作)；因此，除非另有说明，否则将用增加200的相似数字来标识相似的部件，应该理解，工具检验系统10的相似部件的描述适用于工具检验系统210。一个区别是，包括了图3中的本公开的方面，其中与图1的分开的可接口的合格工具12相比，合格工具212可以包括合格软件工具212。在另一个非限制性示例中，图3的合格软件工具212可以作为单独的分区270存在。在又一个非限制性示例中，在图3的公开的各方面中不包括硬件接口。

类似地，图4示出了根据本公开的另一方面的另一工具验证系统310。工具验证系统310类似于图3的工具验证系统110(例如，其中合格工具212可以包括不合格软件工具314；例如，不合格工具环境或“被测单元”)，以及图2的各方面(工具验证部件316以“监督”模式操作)；因此，除非另有说明，否则将用增加300的相似数字来标识相似的部件，应理解，工具验证系统110的相似部件的描述适用于工具验证系统310。

图5示出了展示验证不合格部件的方法400的流程图。方法400开始于410，由工具验证部件116、316接收先前合格的工具12、212与不合格部件之间的一组通信136、138、140、142、338、340、342。接下来，方法400可以包括在420，由工具验证部件116、316将所接收的该组通信136、138、140、142、338、340、342与先前合格的工具12、212与不合格部件的先前合格的版本之间的预定的一组通信36、38、40、42、238、240、242进行比较。

然后，方法400可以包括在430，基于比较来确定不合格部件是否在功能上根据不合格部件的先前合格的版本进行操作。最后，在440，方法400基于确定不合格部件在功能上根据不合格部件的先前合格的版本进行操作来确定不合格部件是合格部件。在这个意义上，确定不合格的(或在方法400开始时的先前不合格的部件)是合格部件可以包括分配合格或以其他方式认证的状态，基于合格状态实施或安装对生产环境，飞行器，航空电子系统等的更新，或根据需要将先前合格的部件更新为最近合格或新合格的部件。在非限制性示例中，可以生成，实施，执行等维护请求以提供实施，安装或更新活动。

方法400的另外的非限制性方面可以被包括在本公开的各方面中。例如，比较可以进一步包括识别在预定的一组通信中存在的，在所接收的一组通信中不存在的通信。在另一个非限制性示例中，识别不存在的通信包括识别系统调用通信，API调用通信或其组合。在又一个非限制性示例中，方法400可以包括当工具验证部件116、316接收到该组通信中的每一个时，通过高精度计时器54对该组通信标时间戳。

方法400的非限制性方面可以进一步包括将所接收的一组通信的时间戳与预定的一组通信的时间戳进行比较。在另一个非限制性方面中，进一步基于所接收的一组通信的时间戳与预定的一组通信的时间戳的比较，来确定不合格部件是否在功能上根据其进行操作。方法400可以进一步可选地包括：基于合格确定，将合格部件实施到生产环境中；或者基于合格确定，将生产环境中的不合格部件的先前合格的版本更新为合格部件。在此示例中，不合格部件可以包括更新的软件版本。

所描绘的序列仅用于说明性目的，并不意味着以任何方式限制方法400，因为应理解，该方法的各部分可以以不同的逻辑顺序进行，可以包括附加的或中间的部分，或者该方法的所描述的部分可以被分成多个部分，或者该方法的所描述的部分可以被省略而不背离所描述的方法。

除了上述附图中所示的之外，本公开还设想了许多其他可能的方面和配置。例如，虽然工具验证部件16、116、216、316被示出为与相应的测试系统14、114、214、314分开或分离，但是可以包括本公开的非限制性方面，其中相应的测试系统14、114、214、314包含，包括或以其他方式包含并操作工具验证部件16、116、216、316。

例如，在一个非限制性实例中，相应的测试系统14、114、214、314或工具验证部件16、116、216、316中的至少一个可以另外或替代地配置或适配为通过识别其软件部件中的更改来识别，感测，检测或以其他方式标记对合格工具12或至少一个软件部件22的更改或修改。例如，各个测试系统14、114、214、314或工具验证部件16、116、216、316中的至少一个可以适于对可执行软件，文件等进行加密哈希，并且将加密哈希与预定的合格工具或软件部件进行比较。验证工具12或至少一个软件部件22之间的任何差异可以通过哈希的比较来识别(该比较不一定识别出差异是什么，而仅仅是识别出存在差异)。该比较可以被本文中描述的系统以工具验证系统10或工具验证部件16识别，确定，估计或以其他方式建立诸如操作系统130的其他不合格部件是否与其他合格工具12兼容的方式而被将来利用或替代地利用，例如，如本文所描述的。

本文公开的方面提供了一种用于验证不合格部件的系统和方法。技术效果是，上述方面使得能够进行对否则为不合格部件的认证或验证，与先前合格的类似部件相比，其仅仅是对不合格部件的改进，更新，增强或增量推进。在软件示例中，错误修复，改进，安全性增强等通常会定期迭代到更新或改进的软件版本中，但是由于重新认证或重新使合格更新的成本，这些改进的软件版本可能无法在合格或认证的环境中实施。

可以在上述方面中实现的一个优点是，上述方面提供了一种能力，系统或部件，以通过验证更新的总体或功能操作不会影响合格或认证系统的性能或功能来验证或以其他方式使此类更新或改进合格(例如，验证它们不会对合格性能的合格性和符合性产生负面影响)，而无需重新认证系统的所有方面。因此，本公开的各方面可以操作以捕获并测量如果改变则可以指示工具行为的问题的合格性的相关参数。本公开的另一个优点可以包括改善或增加合格系统的功能或操作安全性，包括但不限于合格系统的访问安全性，病毒检测，抗攻击性或整体可靠性，其中改进来自发布的错误修复等。另一个优点可以包括增加遗留系统的合规性，否则由于寿命终止的考虑，该遗留系统将被终止或替换。另一个优点是大大减少了测试或实施改进或更新的部件的全部重新认证或重新整合的成本。

在尚未描述的程度上，各个方面的不同特征和结构可以根据需要彼此组合使用。不能在所有方面中都示出一个特征并不意味着解释为其不能有，而是为了描述简洁而这样做。因此，不管是否明确地描述了新方面，都可以根据需要混合和匹配不同方面的各种特征以形成新方面。本文所描述的特征的组合或置换被本公开覆盖。

本发明的进一步方面由以下条项的主题提供：

1.一种工具验证系统，包括：合格工具；测试系统，测试系统具有不合格部件，测试系统与合格工具通信地连接；和工具验证部件，工具验证部件配置成感测合格工具与不合格部件之间的一组通信，将感测到的一组通信与合格工具和先前合格的部件之间的预定的一组通信进行比较，并且基于比较，确定用于不合格部件的合格决定；其中，先前合格的部件是不合格部件的先前版本。

2.根据任何在前条项的工具验证系统，其中一组通信包括系统调用通信。

3.根据任何在前条项的工具验证系统，其中工具验证部件配置成基于系统调用通信不存在于预定的一组通信中、但在感测到的一组通信中不存在，来确定用于不合格部件的合格决定。

4.根据任何在前条项的工具验证系统，其中一组通信包括应用编程接口(API)调用通信。

5.根据任何在前条项的工具验证系统，其中工具验证部件配置成基于API调用通信不存在于预定的一组通信中、但在感测到的一组通信中不存在，来确定用于不合格部件的合格决定。

6.根据任何在前条项的工具验证系统，其中工具验证部件进一步包括精确计时器。

7.根据任何在前条项的工具验证系统，其中工具验证部件进一步配置成在感测时，利用来自精确计时器的时间，为感测到的一组通信中的每一个通信标时间戳。

8.根据任何在前条项的工具验证系统，其中工具验证部件进一步包括一组测试程序，一组测试程序能够由合格工具或不合格部件中的至少一个执行。

9.根据任何在前条项的工具验证系统，其中合格工具与先前合格的部件之间的预定的一组通信是基于由合格工具或先前合格的部件中的至少一个执行的一组测试程序的先前的合格执行。

10.根据任何在前条项的工具验证系统，其中工具验证部件进一步包括精确计时器，精确计时器配置成在感测时，利用来自精确计时器的时间，为感测到的一组通信中的每一个通信标时间戳，并且，其中工具验证部件配置成基于感测到的一组通信的时间戳，将感测到的一组通信与合格工具和先前合格的部件之间的预定的一组通信进行比较。

11.一种验证不合格部件的方法，该方法包括：由工具验证部件接收先前合格的工具与不合格部件之间的一组通信；由工具验证部件将接收到的一组通信与先前合格的工具和不合格部件的先前合格的版本之间的预定的一组通信进行比较；基于比较，确定不合格部件是否在功能上根据不合格部件的先前合格的版本进行操作；和基于确定不合格部件在功能上根据不合格部件的先前合格的版本进行操作，来确定不合格部件为合格部件。

12.根据任何在前条项的方法，其中比较进一步包括识别在预定的一组通信中存在的、在接收到的一组通信中不存在的通信。

13.根据任何在前条项的方法，识别通信包括识别系统调用通信。

14.根据任何在前条项的方法，其中识别通信包括识别API调用通信。

15.根据任何在前条项的方法，进一步包括当一组通信中的每一个通信被验证部件接收到时，通过精确计时器为一组通信标时间戳。

16.根据任何在前条项的方法，其中比较进一步包括将接收到的一组通信的时间戳与预定的一组通信的时间戳进行比较。

17.根据任何在前条项的方法，其中进一步基于将接收到的一组通信的时间戳与预定的一组通信的时间戳进行比较来确定不合格部件是否在功能上根据其进行操作。

18.根据任何在前条项的方法，进一步包括基于合格确定，将合格部件实施到生产环境中。

19.根据任何在前条项的方法，进一步包括基于合格确定，将生产环境中的不合格部件的先前合格的版本更新为合格部件。

20.根据任何在前条项的方法，其中不合格部件是更新的软件版本。

该书面描述使用示例来公开本公开的各个方面，包括最佳模式，并且还使本领域的任何技术人员能够实践本公开的各个方面，包括制造和使用任何设备或系统以及执行任何合并的方法。本公开的可专利范围由权利要求书限定，并且可以包括本领域技术人员想到的其他示例。如果这样的其他示例具有与权利要求的字面语言没有不同的结构元件，或者如果它们包括与权利要求的字面语言没有实质性差异的等效结构元件，则这些其他示例意图落入权利要求的范围内。

Claims (10)

1.一种工具验证系统，其特征在于，包括：

合格工具；

测试系统，所述测试系统具有不合格部件，所述测试系统与所述合格工具通信地连接；和

工具验证部件，所述工具验证部件配置成感测所述合格工具与所述不合格部件之间的一组通信，将感测到的一组通信与所述合格工具和先前合格的部件之间的预定的一组通信进行比较，并且基于所述比较，确定用于所述不合格部件的合格决定；

其中，所述先前合格的部件是所述不合格部件的先前版本。

2.根据权利要求1所述的工具验证系统，其特征在于，其中所述一组通信包括系统调用通信。

3.根据权利要求2所述的工具验证系统，其特征在于，其中所述工具验证部件配置成基于系统调用通信不存在于所述预定的一组通信中、但在所述感测到的一组通信中不存在，来确定用于所述不合格部件的合格决定。

4.根据权利要求1-3中任一项所述的工具验证系统，其特征在于，其中所述一组通信包括应用编程接口(API)调用通信。

5.根据权利要求4所述的工具验证系统，其特征在于，其中所述工具验证部件配置成基于API调用通信不存在于所述预定的一组通信中、但在所述感测到的一组通信中不存在，来确定用于所述不合格部件的合格决定。

6.根据权利要求1-3中的任一项所述的工具验证系统，其特征在于，其中所述工具验证部件进一步包括精确计时器。

7.根据权利要求6所述的工具验证系统，其特征在于，其中所述工具验证部件进一步配置成在感测时，利用来自所述精确计时器的时间，为所述感测到的一组通信中的每一个通信标时间戳。

8.根据权利要求1-3中任一项所述的工具验证系统，其特征在于，其中所述工具验证部件进一步包括一组测试程序，所述一组测试程序能够由所述合格工具或所述不合格部件中的至少一个执行。

9.根据权利要求1至3中的任一项所述的工具验证系统，其特征在于，其中所述工具验证部件进一步包括精确计时器，所述精确计时器配置成在感测时，利用来自所述精确计时器的时间，为所述感测到的一组通信中的每一个通信标时间戳，并且其中所述工具验证部件配置成基于所述感测到的一组通信的所述时间戳，将所述感测到的一组通信与所述合格工具和先前合格的部件之间的预定的一组通信进行比较。

10.一种验证不合格部件的方法，其特征在于，所述方法包括：

由工具验证部件接收先前合格的工具与所述不合格部件之间的一组通信；

由所述工具验证部件将接收到的一组通信与所述先前合格的工具和所述不合格部件的先前合格的版本之间的预定的一组通信进行比较；

基于所述比较，确定所述不合格部件是否在功能上根据所述不合格部件的所述先前合格的版本进行操作；和

基于确定所述不合格部件在功能上根据所述不合格部件的所述先前合格的版本进行操作，来确定所述不合格部件为合格部件。

Images