CN101095089A - 监督处理控制数据获取系统中活动冗余引擎的透明重定位 - Google Patents

Abstract

公开一种在监督处理控制数据获取应用运行时间环境中用于在启用冗余的主机的数据获取客户机的故障切换主机伙伴之间提供透明性的系统。所述系统包括：名称解析表，用于将独立于位置的参考名称映射到网络位置特定的地址。将独立于位置的名称分配到启用冗余的主机，所述主机包括活动主机伙伴和备用主机伙伴。消息收发基础结构服务于启用冗余的主机的客户机。所述消息收发基础结构维护名称，所述名称用于客户机对于启用冗余的主机上的预订数据的每个参考的地址翻译，从而不必考虑哪个启用冗余的主机伙伴当前活动，将相同的名称用于参考启用冗余的主机上的数据。

Description

监督处理控制数据获取系统中活动冗余引擎的透明重定位

技术领域

本发明总的说来涉及联网的计算机化处理控制(process control)系统的领域。更具体地说，本发明涉及监督处理控制和制造信息系统。这种系统在处理控制系统中通常在控制层以上执行，以向较低级的控制元件提供指导，作为示例，所述较低级的元件诸如可编程逻辑控制器。

背景技术

工业上越来越依赖高度自动化的数据获取和控制系统，以确保工业处理高效、安全和可靠地运行，同时降低工业处理的整体生产成本。数据获取开始于多个传感器测量工业处理的各个方面并周期性地将它们的测量报告回数据收集和控制系统时。这种测量有各种形式进入。作为示例，由传感器/记录器产生的测量包括：温度、压力、pH、海量/大量物料流、在航线等待的包裹的结算清单或工厂车间的照片。通常，复杂的处理管理和控制软件检查进入数据，产生状态报告，并且在许多情况下，通过将命令发送到传动器/控制器来进行响应，其中，所述传动器/控制器调整至少一部分工业处理的操作。由传感器产生的数据还允许操作者执行多个监督任务，包括：响应于变化的外部条件(包括原料的成本)加工处理(例如，制定新的设置值)，检测低效/非最佳操作条件和/或即将发生的设备故障，以及采取补救措施，所述补救措施诸如按照需要使设备进入并离开服务。

典型的工业处理极端复杂，并接收相当大量的信息，所述信息多于任何人可能以它的未处理形式进行提要的信息。作为示例，惯例作法是使得成千上万的传感器和控制元件(例如，阀动器)监视/控制工业车间内的多阶段处理的各个方面。这些传感器具有变化的类型并且对处理的变化的特征作出报告。它们的输出在以下方面类似地变化：它们测量的涵义、为每个测量发送的数据量以及它们测量的频率。关于后者，为了保证精度并实现快速响应，这些传感器/控制元件中的某些每秒进行一次或多次测量。当成千上万的传感器/控制元件相乘时，将导致过多的数据流入复杂的数据管理和处理显像技术所需的处理控制系统。

当今存在高度发展的人机界面/处理显像系统，它们被链接到诸如上述传感器和控制器的数据源。所述系统获取上述的处理数据并对其进行提要(例如，过滤)。经过提要的处理数据依次驱动由人机界面呈现的图形显示。这种系统的示例是众所周知的WonderwareIN-TOUCH^人机界面(HMI)软件系统，其用于进行显像并控制各种工业处理。IN-TOUCH HMI处理显像应用包括一组特定处理的图形示图。每个示图又包括一个或多个图形元件。图形元件的显示状态响应于相关/链接的数据源而随时间改变，从这个意义上说，这些图形元件是“动画”的。例如，精炼处理的示图潜在地包括槽(tank)图形元件。所述槽图形元件具有可视指示符，其显示包含在槽内的液体的水平，图形元件的水平指示符响应于由指示槽内的液体水平的槽水平传感器提供的数据流而上升或下降。动画图形图像由数据流内的不断改变的处理数据值来驱动，其中，槽水平指示符仅是一个示例，对观察人员而言，这种动画图形图像比数字流更加容易理解。为此，诸如IN-TOUCH的处理显像系统已变成监督处理控制和制造信息系统的必要部件。

访问处理控制系统的数据的丢失必然使得HMI系统(并由此使得管理人员)无法得知处理控制系统的当前状态。因此，保持由上述HMI系统对处理控制元件的可靠的不中断访问即使对于监督处理控制系统的整体生存性不是必要的，但也是非常重要的。结果，许多系统将冗余和自动故障切换机制并入它们的数据/控制通路，以确保人们对自动处理控制系统的访问不会由于单个通路/机器故障而被打断。

这种冗余/故障切换功能已经在系统中实现，其中，完全相同的部件并行地操作于相同网络区域中的分离的机器上。在一冗余数据传送主机实现中，第二数据传送主机系统作为主要数据传送主机系统的等同副本来操作。这种实现需要完全相同的通信、硬件和软件。此外，冗余对于数据传送系统的客户机而言不是透明的。结果，冗余数据传送系统的每个客户机需要意识到截然不同地标识/命名的活动和备用系统。配置/实现/重新定位所述系统中的冗余主机相当大地增加了系统以及这种系统在其中操作的网络的成本。

发明内容

本发明针对以下潜在需要，即，提供较好的方式来实现驻留并操作于监督处理控制环境内的主机中的冗余(例如，数据/消息传送服务)，作为示例，所述环境支持用于监视和管理受控的工业处理的元件的显像应用。本发明有助于在监督处理控制和制造信息系统中配置和部署冗余主机对，其中，将冗余主机对中指定的冗余主机看作从数据获取系统客户机/订户看来的单个逻辑实体。这种透明性潜在地使得与数据源改变时进行故障切换到备用引擎相关的程序成流线型。然而，由于故障切换对的每个伙伴被相同的名称参考，所以由客户机使用的参考串不会受故障切换影响。

上述优点由以下系统以及所述系统执行的有关方法来促进实现，所述系统在监督处理控制数据获取应用运行时间环境中提供启用冗余的主机的数据获取客户机的故障切换主机伙伴之间的透明性。所述系统包括名称解析表，用于将独立于位置的参考名称映射到网络位置特定的地址。将独立于位置的名称分配到启用冗余的主机，所述主机包括活动主机伙伴和备用主机伙伴。消息收发基础结构服务于启用冗余的主机的客户机。消息收发基础结构维护名称，所述名称用于客户机对于启用冗余的主机上的预订数据的每个参考的地址翻译，从而不必考虑哪个启用冗余的主机伙伴当前处于活动状态，而将相同的名称用于参考启用冗余的主机上的数据。

这里公开的系统和方法的其它发明方面针对所述系统的配置以及它们的运行时间行为，包括经由冗余消息通道在故障切换对之间传递的同步信息的内容，所述冗余消息通道使得备用伙伴能够在给订户/客户机对于由启用冗余的主机提供的数据的最小限度的中断的情况下接管活动状态。

附图说明

尽管所附权利要求具体阐述了本发明的特点，但是可通过以下结合附图进行的详细描述最佳地理解本发明连同它的目的和优点，其中：

图1是示出包括多层监督处理控制和制造信息系统的示例性监督处理控制网络内的部件的主管/分级关系的示意图；

图2示出用于主管实现本发明的示例性系统内的平台和引擎上的应用的多层对象主管布置；

图3是概括用于配置和部署冗余主机，更具体地说，用于配置和部署主管一组应用对象的应用引擎的一组示例性步骤的流程图；

图4是与配置能够启用冗余的主机/应用引擎相关的示例性用户界面；

图5是与部署用于主管备份应用引擎的节点相关的示例性用户界面；

图6是与在主管故障切换引擎对的备份伙伴的节点上配置冗余消息通道(网络接口卡的IP地址)相关的示例性用户界面；

图7是与部署配置的故障切换引擎对相关的示例性用户界面；

图8是包括概括将启用故障切换的引擎对部署到它们各自的主机的一组示例性步骤的流程图；

图9是概括用于实现故障引擎伙伴的操作的状态机的一组示例性步骤和转换的状态图；

图10是概括在故障切换引擎状态机处于备用-丢失心跳(Heartbeat)状态内时执行的逻辑的流程图；

图11标识与监视故障切换引擎对以及故障切换引擎对通过其通信的网络和节点的状态相关的一组定时器；

图12是概括用于在启用冗余的主机中实施故障切换的一组示例性步骤的流程图，所述启用冗余的主机将对实时数据、历史数据和告警数据的访问提供给一组客户机/订户；以及

图13包括支持冗余故障切换主机对的一组示例性接口/方法。

具体实施方式

以下描述基于本发明的实施例，并且不应将以下描述看作关于没有在这里明确描述的替换实施例来限制本发明。作为示例，将本发明并入监督处理控制和制造信息环境内，其中，由应用对象代表各个数据源。在Resnick等人的第2002/0198920-A1号美国专利申请公开“SUPERVISORY PROCESS CONTROL AND MANUFACTURINGINFORMATION SYSTEM APPLICATION HAVING A LAYEREDARCHITECTURE”中详细描述了所述系统的示例，所述申请的内容通过引用全部合并于此，包括其中标识/包含的任何参考文献的内容和教导。然而，如本领域的技术人员将根据所公开的示例性实施例所理解的，本发明潜在地可应用于各种替换监督处理控制环境，其包括可标识的数据源，所述数据源提供驱动一组动态图形元件的实时处理数据，所述元件代表至少一部分观察/受控的工业处理。

参照图1，示意图示出在包括并入故障切换引擎对的多层监督处理控制和制造信息系统的示例性监督处理控制网络内的部件的主管/分级关系。在对示例性网络环境进行更加详细的描述之前，通常应注意到：在该实施例中，作为示例，按照接收状态信息的应用对象105和应用对象’107的形式来提供数据源。此外，在由配置数据库124(例如，Wonderware’s Galaxy Repository)保存的全局名称表125内标识应用对象105和应用对象’107，所述配置数据库124的内容经由在配置PC 120上执行的显像应用开发工具127(例如，Wonderware’sINTOUCH软件)对于开发者可用。在本发明的实施例中，显像应用开发工具127提交对于驻留在配置数据库内的特定信息的查询，以便有助于提供由开发者并入特定应用(例如，制造处理线)的一个或多个处理显像示图/窗口的可用数据源(例如，应用对象105)。一旦建立之后，处理显像应用潜在地在连接到图1中示意性示出的监督处理控制网络的一组工作站中的任何一个上执行。

继续参照图1，第一应用服务器个人计算机(PC)100和第二应用服务器PC 102共同合作地执行冗余分布式多层监督处理控制和制造信息应用，其包括第一部分104和第二部分106。应用部分104和106分别包括装置集成应用对象PLC1Network和PLC1以及PLC1Network’和PLC1’。PLCxNetwork装置集成对象有助于数据访问服务器(例如，OPC DA服务器116和118)的配置。作为OPC客户机操作的PLC1和PLC1’装置集成对象访问OPC DA服务器116和118的缓冲器内的数据位置。数据访问服务器116和118以及装置集成对象合作地从诸如PLC或其它现场装置的外部处理控制部件导入数据并对所述数据进行缓冲。

在本发明的实施例中，由在连接到网络119的PC(例如，PC 120)上执行的人机界面软件提交对于驱动代表车间场所设备状态的图形显示的车间场所信息的请求。由在个人计算机100和102上执行的各种应用对象105和107访问数据访问服务器116和118的数据缓冲器。作为示例，应用对象的示例包括：离散装置、模拟装置、现场参考等。在示出的示例中，经由网络119在PC 100和102(在车间场所)与PC 120之间传递对于车间场所信息和响应数据的请求。

根据本发明的实施例，应用引擎主管应用对象(经由在这里称为“区域”的逻辑群组对象)。由位于监督处理控制和制造信息应用的下一较低级的平台对象来轮流主管引擎。由通配引导部件108和110轮流主管应用部分104和106。以下将在这里参照图2来描述所有上述部件。

在实现本发明的示例性系统中，包括部分104和106的多层应用以通信方式链接到受控处理。具体说来，经由车间场所网络115将第一应用服务器个人计算机100和第二应用服务器个人计算机102以通信方式耦合到第一可编程逻辑控制器112。应注意到：所示出的经由车间场所网络115从PC 100和102到PLC 112的连接代表逻辑连接。这种逻辑连接相应于直接和间接物理通信链路两者。例如，在特定实施例中，PLC 112包括以太网LAN上的节点，个人计算机100和102也连接到所述LAN。在其它实施例中，将PLC 112直接链接到PC 100和102上的物理通信端口。

在图1所示的示例性实施例中，PC 100和102分别执行数据访问服务器116和118。数据访问服务器116和118获得/提取由PLC 112提供的处理信息，并将所述处理信息提供给包括部分104和106的应用的应用对象(例如，PLC1Network、PLC1、PLC1Network’和PLC1’)。作为示例，数据访问服务器116和118是OPC服务器。然而，本领域的技术人员将容易地理解到，各种自定义数据格式/协议和标准化数据格式/协议潜在地由数据访问服务器116和118来实施。此外，示例性应用对象通过到数据访问服务器116和118的连接代表PLC网络和PLC本身的操作。然而，应用对象包括可执行对象的类的实际上无限的频谱，所述可执行对象在监督处理控制和制造信息应用的环境中执行期望的监督控制和数据获取/集成功能。

例如，由执行数据库(例如，SQL)服务器122的配置个人计算机120来加强监督处理控制和管理信息应用，所述服务器122保存用于应用对象以及包括通过其例示应用对象的模板的其它有关信息的监督处理控制和管理信息应用配置数据库124。配置数据库124还包括全局名称表125，其有助于将独立于位置的对象名称绑定到源于位置的句柄，这有助于在图1所示的系统内的对象之间路由消息。配置PC120和相关数据库服务器122支持：对多用户环境的管理监视、修订历史管理、集中的许可证管理、包括新对象和它们的相关软件的部署和安装的集中的对象部署、全局名称表125的保存以及导入/导出对象模板和实例。

经由集成开发环境(IDE)126来实施应用的配置，所述应用包括故障切换应用引擎的创建和部署(将在下面进一步讨论)。IDE 126是一种实体(潜在地包括多个部件)，通过该实体，包括应用对象和引擎的处理控制和制造信息应用被定义，创建和部署到各种平台/引擎，作为示例，所述平台/引擎包括应用服务器PC 100和102。监督处理控制和制造信息应用的开发者通过IDE 126实施各种应用设计功能，包括：导入新的对象和模板类型，从现有模板配置新的模板，定义新的应用对象以及将应用对象部署到主机应用引擎(例如，应用服务器PC 100上的AppEngine1)。

图1所示的示例性监督控制网络环境还包括连接到网络119的一组操作者站130、132和134，其提供对于处理和处理的部分的示图，所述处理和处理的部分由作为PC 100和102上的一组分层对象安装并执行的监督处理控制和管理信息应用来监视/控制。原料PC 130提供代表示图，所述代表示图能够实现监视监督工业处理的原料区域。生产PC 132提供监督工业处理的生产部分的代表示图。完成产品PC134提供与完成的产品相关的生产设施的区域的代表示图。操作者站130、132和134中的每一个包括用于每个特定操作者站平台的引导主机。操作者站130、132和134中的每一个包括处理图形信息的示图引擎，所述图形信息用于提呈观察的工业处理或工业处理的部分的图形表示。

在本发明的实施例中，PC 102提供对PC 100的故障切换支持。作为示例，故障切换支持发生在应用引擎级(例如，AppEngine1和AppEngine1’)。因此，当PC 100上的AppEngine1出现故障/关闭时，将PC 102上的AppEngine1’(在全局名称表125中具有与AppEngine1相同的分配的参考名称)配置为接管先前分配到AppEngine1的责任(例如，主管应用对象)。应用引擎级上的故障切换支持提供应用对象的高度可用性，所述应用对象在故障切换引擎对的当前活动引擎的运行时间故障期间由启用故障切换的引擎对配置来主管。在本发明的实施例中，在配置阶段期间为故障切换启用/指定应用引擎。在配置期间，只有主要引擎是可配置的(例如，将应用对象分配到主要引擎)。在登记启用故障切换的应用引擎之后，将应用引擎故障切换对的主要应用引擎和备份应用引擎部署到第一平台和第二平台(驻留在截然不同的联网的机器上)。在运行时间环境中，通常向主要引擎分配启用故障切换的应用引擎对的活动角色，并由此启动/主管/执行一组被管理的应用对象。

另一方面，在配置/部署期间被分配备份角色的应用引擎提供对故障切换对的冗余支持。备份引擎通常在运行时间被分配启用故障切换的引擎对的备用角色，所述备份引擎确保应用引擎对的至少一个引擎和被管理的应用对象的高度可用性。当登记配置故障切换的应用引擎时，创建备份引擎。备份引擎和它在运行时间的类似的备用引擎包含用于创建/主管应用对象实例的必要部件(例如，软件和数据)，所述应用对象实例与启用故障切换的应用引擎相关。然而，在本发明的实施例中，在故障切换引擎对的备份引擎上既不启动也不执行应用对象。在运行时间期间，启用故障切换的应用引擎的备用引擎在活动引擎不再操作的情况下考虑接管执行由启用故障切换的应用引擎对主管的应用对象时监视主要引擎的状态和检查点临界数据。当检测到当前活动应用引擎的故障时，备用引擎(例如，PC 102上的AppEngine1’)变成活动引擎并执行与主管启用故障切换的应用引擎对上的应用对象相关的任务。具体说来，在承担活动引擎角色时，目前的活动引擎调用被管理的应用对象上的启动方法，并开始执行应用对象，所述应用对象替代启用故障切换的应用引擎对的故障伙伴。作为示例，当备用引擎获取活动引擎的角色时，其接管对于参考的责任，所述参考有助于修改属性，监视属性的改变并从属性检索数据。这种参考与监督、用户和系统参考集合相关，所述集合与被管理的应用对象相关。

这里公开的启用故障切换的应用引擎对的一方面是备份引擎和备用引擎的相对透明性。在本发明的实施例中，用户为备份引擎指定主机。然而，在没有用户干预的情况下自动执行对备份引擎的部署。用户通常通过对主要/活动引擎的操作来实施对启用故障切换的应用引擎的控制/配置。此外，活动引擎和备用引擎在监督控制系统运行时间环境内共享单个的全局名称。因此，在进行故障切换到备用应用引擎的情况下，不需要改变用于标识启用故障切换的应用引擎对的任何参考。尽管对被管理的应用对象的访问可能在故障切换期间临时丢失(在备用引擎获取主动角色并启动被管理的应用对象/基本要素的同时)，客户机没有意识到切换到备用(目前活动)应用引擎，并且尽管响应应用对象的物理位置已改变，仍继续使用一组相同的全局参考来访问由启用故障切换的引擎对支持的资源。

根据本发明的实施例，启用故障切换的应用引擎对执行同步操作以有助于备用引擎到活动引擎状态的角色改变。同步数据的示例包括：检查点文件(包括活动引擎上的配置/调整值、告警限制和部署的对象)、告警状态(戳记的时间)、订户列表(对于由被管理的对象提供的数据)、实况数据以及存储器和转发缓冲器内的数据(例如，将被传递到处理状态历史数据库)。一旦被首次加载，活动引擎就跟踪对于同步信息的改变(例如，检查点的变量增量)并且仅发送所述改变(与传递同步信息的完整副本相对比)。仅发送改变大大减少了通过链路140的通信量(以下将在这里进一步描述)。由于本发明的实施例考虑单个PC(例如，PC 102)来主管活动引擎或备用引擎的多个实例，所以上述效果是特别重要的。在将多个应用引擎配置为两个PC(例如，PC 100和PC 102)上的故障切换对的情况下，由用于实施与故障切换引擎的故障切换功能有关的通信的所有故障切换引擎来共享链路140。

作为示例，经由在这里称为冗余消息通道(RMC)的链路140从PC 100(运行主要引擎)和PC 102(包含备份引擎)传递检查点数据。链路140(例如，以太网链路、802.11x无线链路等)在物理上与插件场所网络115分离并且截然不同于车间场所网络115，所述链路140支持以高数据率在PC 100与PC 102之间传送必要信息，以实施故障切换/备份功能。在本发明的实施例中，启用故障切换的引擎(例如，PC 100上的AppEngine1)包括系统属性(远程伙伴地址或“RPA”)，所述系统属性有助于指定与链路140的备份引擎方相关的网络接口的互联网协议地址。在启动时，主要引擎(例如，AppEngine1)采用RPA属性将消息发送到指定的主机名称或IP地址，以便经由冗余消息通道(RMC)首次联系主管它的故障切换引擎伙伴(例如，AppEngine1’)的平台，所述RMC在图1中由链路140代表。这一初始消息向备份/备用引擎(或包括用于备份/备用引擎的平台主机的任何其它感兴趣的实体)通知主要引擎的主机平台的IP地址。在本发明的实施例中，在指定备份引擎的节点/平台之后，计算RPA。因此，在启用故障切换的配置被加载到网络上指定的平台上的情况下，在配置阶段期间或者在部署阶段期间潜在地指定RPA。在示例性实施例中，将单个RPA分配到平台(PC)的物理网络接口，所述平台(PC)潜在地主管多个应用引擎。然而，将截然不同的参考(例如，句柄、名称等)分配到每个故障切换应用引擎，以区分由单个平台主管的多个应用引擎。

应注意到：以上描述的图1所示的系统仅仅是用于监督处理控制和制造信息系统的多层分级结构的示例，所述监督处理控制和制造信息系统包括冗余/故障切换应用服务器，用于确保将数据从车间场所网络115连续提供给网络119上的人机界面计算机。本发明并不受限于具体公开的应用/系统，事实上，本发明不需要以所示的示例中显示的多级应用的形式来实施。还应注意到：图1呈现为安装的包括软件和物理计算硬件的部件之间的主管和/或容纳相互关系的逻辑示图。例如，本发明可应用于以下系统，在所述系统中，配置设备和监督处理控制显像应用两者均运行在链接到受控处理的单个计算机系统上。

参照图2，类示图示出与计算机(例如，PC 100或102)相关的分层软件的分级主管布置，所述计算机(PC 100或102)执行至少一部分监督处理控制和制造信息应用。每个计算机在分级的最低级执行诸如微软的WINDOWS的操作系统200。操作系统200主管引导对象202。将引导对象202加载到计算机上，并且与由操作系统200执行的启动程序相关地被激活。作为平台类对象204的主机，引导对象202必须在开始平台类对象204的操作之前被激活。引导对象202开启并停止平台类对象204。引导对象202还提呈由平台类对象204采用的服务，以开启并停止由平台类对象204主管的一个或多个引擎对象206。

平台类对象204是一个或多个引擎对象206的主机。在本发明的实施例中，平台类对象204对于所述一个或多个引擎对象206代表执行特定操作系统的计算机。平台类对象204保存在平台类对象204上部署的引擎对象206的列表，开启并停止引擎对象206，如果引擎对象206发生碰撞则重新启动引擎对象206。平台类对象204监视引擎对象206的运行状态并向客户机公布状态信息。平台类对象204包括系统管理操纵诊断设备，其能够对执行平台类对象204的计算机系统执行诊断和管理任务。平台类对象204还向分布式告警子系统提供告警。

引擎对象206主管一组应用对象210，所述对象210实施与应用相关的监督处理控制和/或制造信息获取功能。引擎对象206开始所有应用对象210的启动。引擎对象206还在调度器对象208的帮助下调度应用对象210相对于彼此的执行。引擎对象206向用于执行的调度器对象208注册应用对象210。调度器对象208基于由引擎对象206中相应的引擎对象指定的配置来相对于其它应用对象执行应用对象。引擎对象206监视应用对象210的操作，并将不正常工作的应用对象置于隔离状态。引擎对象206通过保存/恢复由自动对象对配置文件进行的运行时间应用的改变来支持检查点。引擎对象206保存名称绑定服务，其将属性参考(例如，tank1.value.pv)绑定到应用对象210中适当的应用对象。

引擎对象206最终控制应用对象210中相关的应用对象的执行如何发生。然而，一旦引擎对象206确定应用对象210的执行调度，就由调度器208控制它们的执行的实时调度。调度器208支持包含方法RegisterAutomationObject()和UnregisterAutomationObject()的接口，该方法RegisterAutomationObject()和UnregisterAutomationObject()使得引擎对象206向调度器208的调度操作列表添加应用对象中的特定应用对象/从调度器208的调度操作列表去除应用对象中的特定应用对象。

应用对象210包括执行业务逻辑的各种对象，所述业务逻辑有助于在作为示例的工业处理控制系统的环境下实施特定处理控制操作(例如，打开泵，开动阀)和/或信息聚集/管理功能(例如，基于接收的现场装置输出信号值来提出告警)。处理控制(自动)应用对象的示例包括：模拟输入、离散装置和PID环对象。应用对象210的类经由装置集成对象(例如，OPC DA服务器118)作用于由诸如PLC的处理控制系统提供的数据。集成对象的功能在于提供处理控制/制造信息源与监督处理控制和制造信息应用之间的桥接。

在示例性实施例中，应用对象210包括由引擎对象206和调度器208访问的应用接口。引擎对象206访问应用对象接口，以初始化应用对象，启动应用对象和关闭应用对象。调度器208使用应用对象接口来开始相应应用对象的调度的执行。

在描述了示例性监督处理控制和制造信息网络环境的主要部件之后，将关注在图3中概括的一组示例性步骤，所述步骤部分地经由诸如先前提到的IDE 126的监督处理和制造信息系统部件配置装备来交互地执行。在所示的示例中，配置设备包括图形用户界面，所述图形用户界面展示与定义和部署启用冗余/故障切换的主机(特别是启用故障切换的应用引擎对)相关的一组参数。在随后的部署(或重新部署)故障切换主机/应用引擎对期间采用由用户通过所述界面指定的参数值。应注意到：尽管所示的示例针对应用引擎，但是本发明潜在地可应用于各种主机对象，并试图提供流线型用户友好方式的配置系统中的冗余以及确保在监督处理控制和制造信息系统中主机部件的备份可用性。此外，步骤的顺序意为示例性的。本领域的技术人员将容易地理解根据本发明的替换实施例来修改完成以下在这里描述的各个阶段的顺序的能力。

步骤300：在配置期间启用对应用引擎的故障切换

首先，在步骤300期间，用户启用并自定义所选择的应用引擎对象的故障切换行为。当登记和部署应用引擎配置选择时，由配置设备(例如，IDE 126)注册在步骤300期间为应用引擎指定的选择/值，以便以后使用。参照图4，作为示例，通过由用户经由配置设备产生的冗余属性接口提交的一组值来启用和自定义应用引擎故障切换行为。

在所示的示例中，配置设备用户界面提供与应用引擎402(在图4的配置用户界面的部署示图区域中所选择的)的配置有关的多个标签。用户在配置设备界面上选择冗余标签400，以展示在属性示图401中示出的一组参数，所述参数与定义用于当前选择的应用引擎(AppEngine_001)402的冗余/故障切换行为相关。在本发明的实施例中，用户通过“检查”启用冗余检查栏404来指定用于选择的应用引擎402的冗余。响应于故障切换指定，将故障切换动态基本要素添加到应用引擎对象，并将所述引擎指定为故障切换对的主要引擎。尽管没有在图4中示出，但是在部署示图中首先将用于应用402的备份引擎分配到未分配的主机405。用户随后将备份引擎(经由拖放)重新分配到在部署示图中示出的实际平台节点。在步骤360期间保存/登记(解除对象上的编辑锁)应用引擎402的配置(以下在这里进行描述)并且通过调用对象上的生效方法而使得所述配置生效之后，由所述系统内管理对象的设备来创建备份引擎对象。

图4所示的示例性故障切换配置界面还支持一组用户指定的参数，所述参数定义应用引擎402的故障切换行为。强制的故障切换超时406使得用户能够指定时间周期，其间，给出当前活动的应用引擎以执行到备用应用引擎的用户开始的故障切换，所述备用应用引擎否则在备用状态下等待。缓冲的最多检查点变量增量408使得用户能够指定最多数量的检查点变量增量封装，所述变量增量封装将在开始对检查点信息进行完全的重新同步之前被缓冲。最多检查点变量增量408的典型值是0(当扫描循环期间存在足够的带宽以将检查点变量增量封装传送到备用引擎时)，并且所述典型值用于处理诸如缓慢同步链路的异常情况。缓冲的最多告警状态改变410使得用户能够指定最多数量的告警状态改变封装，所述告警状态改变封装将在活动应用引擎开始对告警状态的完整的重新同步之前被缓冲。

由示例性配置用户界面展示的冗余/故障切换参数包括与由活动应用引擎和备用应用引擎发送/广播到其它系统部件的心跳有关的一组参数。所述心跳是周期性的传输，接收方不需要对其作出响应，所述心跳确保心跳发送方是可操作的。备用引擎心跳周期412和活动引擎心跳周期414指定由所述两种引擎角色类型中的每一个进行的心跳消息传输之间的周期。从活动引擎丢失的最多连续心跳416和从备用引擎丢失的最多连续心跳418指定多个连续过去的心跳周期，所述多个连续过去的心跳周期在注册故障切换对通信故障之前由收听者注册(即，心跳传输的预期接收方)。所述故障潜在地由监督脚本来处理，所述监督脚本执行各种操作中的任何一个，作为示例，所述操作包括：产生对于监视器的警告/告警消息，开始进行故障切换到备用伙伴引擎，以及重新部署(自动地或根据来自用户的指示)非响应的故障切换引擎伙伴。以下将在这里进一步讨论故障切换方案中心跳的使用。

直到备用引擎变为活动，从活动引擎到备用引擎的传送责任才开始。如果当客户机引擎意识到主要/活动引擎的故障时与当客户机引擎接收到备份/备用已变为活动的通知时之间的时间延迟超过配置的限制，则与故障引擎相关的所有参考的质量被设置为不确定。由用户经由用于在故障之后保存较好的质量的最长时间参数420来指定配置的时间延迟限制。而作为另一参数的用于发现伙伴的最长时间422使得用户能够指定在经由RMC发出连接请求之后注册故障之前，主要引擎花费多长时间等待来自它的备份引擎的响应。强制故障切换命令424使得用户能够指定字母数字串，当由监督者/管理者提供所述字母数字串时，其在不等待当前活动引擎出故障的情况下，强制将活动状态从当前活动引擎传送到当前备用引擎。

步骤310和320：用于备份引擎的新平台主机的配置

继续参照图4所示的示例性示例，必须将应用引擎402和它的备份引擎部署到分离的平台/节点。如果在步骤310，用于主管应用引擎402(在部署示图中标识为“Node_A”的平台上)的备份的平台仍旧不存在，则控制进行到步骤320，其中，将平台配置/创建为主管用于应用引擎402的备份引擎。如树结构403所示(示出包括多个联网的计算节点的系统中应用部件的配置的物理部署示图)，仍旧不存在第二物理联网的计算装置节点/平台对象，其用于主管用于应用引擎402的备份应用引擎，所述应用引擎402被部署到在树结构403中标识为“Node_A”的平台对象。因此，在步骤320期间，用户通过将$WinPlatform模板407的副本从模板工具条树拖放到部署示图区域来创建新的节点/平台。

简要地参照图5，在用户创建用于主管应用引擎402的备份引擎的新的节点/平台(Node_B)之后，示例性部署示图示出冗余引擎对配置，其中，所述参考引擎402驻留在节点A上。在创建Node_B之后，通过将“AppEngine_001(备份)”从未分配的主机目录拖放到所示的部署示图树上的Node_B平台，将用于应用引擎(AppEngine_001)402的备份置于Node_B上。如图5所示，节点B将主管节点A上的应用引擎(AppEngine_001)402的备份(AppEngine_001(备份))。当完成创建/配置用于主管备份应用引擎的新的平台时，控制从步骤320进行到步骤330。

另一方面，如果用于备份引擎的主机平台已经存在，则控制从步骤310直接进行到步骤330。

应注意到：在配置环境的部署示图中创建应用部件(例如，节点/平台、引擎、应用对象等)是截然不同于将部件“部署”到网络内的物理计算机器的操作。继续参照图5，“对象”菜单500包括“部署”选项502，用于实施对从部署示图选择的一个或多个部件的实际部署。当结合先前选择的“Node_A”选择“部署”选项时，与部署示图中的Node_A相应的平台以及Node_A下的所有部件被安装在与Node_A相应的联网的计算机器上。以下将在这里进一步描述应用部件的这种部署。

步骤330/340：配置备份平台上的RMC

除了备份引擎主机之外，故障切换应用引擎对还依赖于故障切换通信链路，特别是冗余消息通道(RMC)。RMC提供故障切换伙伴的主机平台之间的通信通路，通过所述通路，主要引擎和备份引擎交换信息，作为示例，所述信息包括：检查点、状态和命令/控制信息。向RMC上的每个主机平台分配唯一的物理网络地址。在所示的示例性实施例中，RMC采用PC之间的网络通路，所述网络通路在物理上与主要一般网络路径分离，主机PC采用所述主要一般网络路径以实现各种其它目的。作为示例，RMC采用链路140(例如，以太网链路)，所述链路140在物理上与网络119分离。在替换实施例中，采用主要一般网络(例如，网络119)。然而，由于与RMC相关的附加工作量对网络119的性能的影响，在许多实例中不太期望使用一般网络119。

为了实施故障切换/冗余引擎有关的通信的目的，由多个故障切换对潜在地使用RMC。在使用RMC来处理多个故障切换对的一示例中，考虑共享链路140来帮助“N on 1”的故障切换配置，其中，单个平台主管用于为故障切换配置的一组N个主要应用引擎的备份副本。实际上，主要应用引擎不需要出现在相同的主机PC上。相反，单个平台(例如，应用服务器2PC平台)潜在地主管用于具有不同主机PC的多个主要引擎的备份引擎。在所述实例中，作为示例，链路140包括多点网络总线，并且主管主要或备份引擎的每个平台共享用于它们的RMC的公共网络(相应于链路140)。对工作量进行平衡以确保：在多个故障切换的情况下，激活单个平台上的多个备用引擎不会造成当备用引擎呈现活动引擎角色时备用引擎的主机上的扫描超过限度。这种可能发生的行为潜在地通过对主管故障切换备份引擎的平台执行监督脚本来处理，以便监视工作量并将备份引擎重新定位到其它可用的平台。响应于检测的负载来重新定位备用引擎避免了平台(计算装置/节点)的超载，随着多个主要/活动引擎接连发生故障，所述平台被强制支持多个活动应用引擎。

或者，在单个平台主机上主管多个备份的情况下，可为单个平台主机提供多个RMC(以及具有截然不同的网络地址的相应网络适配器)，从而想每个故障切换对分配单独的RMC。在其它实施例中，由单个平台主机支持专用和共享的RMC的组合。

继续参照图3，在步骤330期间，如果仍没有在备份主机(Node_B)上建立RMC，则控制进行到步骤340。在步骤340，配置设备提供用户界面，所述用于界面展示一组参数，所述参数使得用户能够指定与RMC上的备用引擎的主机平台(Node_B)相应的网络地址。参照图6，用于平台(例如，Node_B)的配置界面包括一组“冗余”配置字段，用于指定RMC通道。具体说来，冗余消息通道IP地址600使得用户能够指定与分配到RMC链路上的平台(例如，Node_B)的网络地址/名称相应的物理(IP)地址(例如，192.168.001.102)。冗余消息通道IP地址600中的值是用于节点A的RPA。此外，用户指定冗余消息通道端口602和冗余主要通道端口604。这些是用于保存通过RMC和主要通道的心跳的端口。RMC IP地址600先前已经在上面被称为“远程伙伴地址”(RPA)。在登记启用故障切换的引擎对并将其部署到适当的平台之后，由主要引擎的主机采用RPA，以经由RMC联系相应的备份引擎主机。

在本发明的实施例中，平台上的消息路由服务将引擎名称解析到地址。在引擎的主机平台上执行的消息路由服务检测穿过指向相应的故障切换伙伴引擎的RMC的通信，并将所述通信指向适当的引擎。此外，用于在相同RMC上的不同引擎之间进行区分的消息路由服务的能力(通过对它们的截然不同的名称的名称解析操作)有助于N on1故障切换情况以及将启用故障切换的引擎透明地重新定位到新的平台。

图6包括涉及主要网络上的Node_B的一般操作的一组字段(用于与各种其它主机节点通信)。网络地址可以是物理(例如，IP)地址或名称，其相应于主要网络上的Node_B的地址。历史存储转发目录字段指定Node_B上的存储转发数据的位置，以便当主要网络停用或者太慢以致无法处理Node_B的数据传输流时，对传输的数据进行缓冲。

图6还包括涉及在Node_B所附的主要网络上实施的消息交换服务的一组字段。消息超时值标识在呈现发送的消息丢失之前，Node_B花费多长时间来等待响应。NMX心跳周期允许缓慢的网络在心跳由于缓慢的链路而潜在地丢失/延迟时避免超时。连续丢失的心跳是乘数。

应注意到：在图6所示的示例中，为备份引擎主机的RMC指定物理地址。然而，在本发明的替换实施例中，在步骤340期间，用户指定主机名称，所述主机名称与RMC IP地址600中的物理IP地址相应，随后由名称服务将所述名称解析到相应的物理IP地址。在用于备份引擎主机的RMC上设置地址之后，控制进行到步骤350。另一方面，如果在步骤330，已经为备份引擎主机(Node_B)建立了RMC上的地址，则控制进行到步骤350。

步骤350：设置主要引擎上的RPA

在步骤350期间，补充主管主要引擎(例如，应用引擎402)的配置的平台，以包括RMC上的备份引擎(应用引擎402的)主机平台的地址(上述的RPA属性)。RPA属性有助于主要引擎开始与它的相应备份引擎的连接。

步骤360：登记冗余配置

然后，在步骤360期间，在配置数据库124上“登记”已经启用冗余的应用引擎。登记应用引擎的处理解除了锁定机制，所述锁定机制防止其它人在检验的应用引擎作为示例被配置/编辑的同时改变所述检验的应用引擎。登记启用冗余的应用引擎还触发备份引擎实例的创建(假设当前不存在用于特定应用引擎的备份引擎实例)。将属性从主要引擎复制到新创建的引擎实例，并将备份“角色”属性分配到新的引擎实例。在以下在这里描述的步骤370期间，在将引擎伙伴部署到它们各自的平台期间，备份角色属性将备份引擎与它的主要引擎伙伴区分。在示例性实施例中，首先将备份引擎分配到默认平台，但是可经由IDE 126将所述备份引擎重新分配到另一平台。将备份引擎分配到与主要引擎相同的“区域”(与处理控制和制造信息系统的紧密相关部件的群组相应)。

作为复制为主要引擎指定的参数的结果，备份应用引擎具有与它的伙伴主要引擎相同的配置数据。因此，如果在启用冗余的情况下登记主要引擎的时候已经存在备份引擎，则系统检验备份引擎，将更新的配置数据(属性)从主要引擎复制到检验的备份引擎，并登记修改的备份引擎。因此，备份引擎具有主要网络的配置的部署封装的副本。

备份引擎中的配置信息基本上与主要引擎相同。所述一般声明的例外是冗余基本要素的“远程伙伴属性(RPA)”。在主要应用和备份应用两者均已被部署到它们各自的平台之后，首先为主要引擎指定截然不同的RPA属性(在步骤350期间)，随后在备份引擎中指定截然不同的RPA属性(在步骤380期间)。

尽管以下处理不是图3所示的步骤的一部分，但是当在禁用冗余选项(例如，启用冗余404)的情况下登记备份引擎的主要伙伴时，删除仍没有部署的备份引擎。由于客户机潜在地具有与备份引擎相应的当前引擎和平台标识，所以将备份引擎的去除广播到具有对启用冗余的主要应用引擎的参考的当前客户机。在系统的部署配置示图中，应用引擎将不再可视地指示其是故障切换对的主要伙伴。另一方面，如果在禁用冗余选项的情况下登记应用引擎，并且应用引擎在部署的状态下具有备份引擎，则登记主要引擎的处理将发生故障。因此，在去除备份引擎之前，必须将备份引擎解除部署。

步骤370：部署配置的冗余引擎(如果必要，还部署配置的主机)

继续参照图3，在登记启用冗余的应用引擎配置之后，在步骤370期间，用户调用对配置的冗余应用引擎对的部署操作。作为示例，当用户通过在选择包含应用引擎的Galaxy(例如，参见图7的部署树700中的“MyGalaxy”)之后选择“对象”菜单上的部署选项来调用全局部署操作时，开始对冗余应用引擎配置封装的部署。部署冗余应用引擎对-使得从配置环境转换到运行时间环境-包括将文件以及与参考引擎相关的信息(如果必要，还包括平台文件)复制到适当的主机机器。

实现本发明的故障切换基础结构的示例性示例在配置、部署和运行时间期间采用对冗余的基于角色的方式。在配置期间将主要/备份角色首先分配到冗余应用引擎。简要地参照图7，将主要引擎和备份引擎的截然不同的角色并入启用冗余的应用引擎的配置/部署示图。具体说来，对于被配置以主管一组应用对象的应用引擎，应用引擎(AppEngine_001)702节点(代表主要应用引擎)枚举一组应用对象作为应用引擎702节点下的叶。在运行时间环境下(以下将在这里描述)，应用对象仅在活动应用引擎上执行(配置/部署环境中主要引擎的运行时间类似物)。通过在配置/部署示图中不显示应用引擎备份(AppEngine_001)704节点下的应用对象，在图7中可视地代表备用引擎(配置/部署环境中备份引擎的运行时间类似物)上的应用对象的受限功能/存在。

部署故障切换引擎对

参照图8，在步骤370期间，一组步骤概括将启用故障切换的应用引擎对部署到它们各自的主机。在示例性实施例中，当在步骤370，冗余应用引擎被部署到它们各自的平台时，在配置期间建立的主要角色和备份角色确定操作的顺序。当用户请求部署主要引擎和备份引擎时，系统确保：在部署主要引擎的相关备份引擎之前，完整地部署主要引擎。这还确保：主要引擎将呈现活动引擎的角色，备份引擎将首先检测操作的活动应用引擎的存在并获取备用角色。

在本发明的特定实施例中，在步骤800期间，部署服务器首先调用部署命令，所述命令指定与主要应用引擎相关的部署封装。作为响应，在步骤802期间，获取信息，所述信息用于标识平台、文件、节点名称和与主要引擎相关的应用对象。随后在步骤804期间，将主要引擎对象本身以及由主要引擎对象采用的文件和信息传送到包含主管主要引擎的平台的节点(如果尚未存在于所述节点上)。在步骤804期间，在所述节点上创建并发起主要引擎对象。在完成步骤804时，在步骤806期间，将主要引擎的状态设置到“已部署”。在这一点上，没有由主要引擎主管的应用对象被部署到主要引擎。相反，在运行时间环境下执行对应用对象的部署，在所述环境下，启用故障切换的应用引擎对之一已获取“活动”运行时间状态。

在示例性实施例中，通过首先部署主要引擎随后部署故障切换应用引擎对的备份引擎来顺序地实施部署。应该将主要应用引擎和备份应用引擎部署到截然不同的平台。在示例性实施例中，在成功地部署主要引擎之后，部署备份引擎之前，在步骤808，将为主管主要引擎和备份引擎指定的平台进行比较。如果不同的平台被指定，则控制进行到步骤810，其中，部署服务器调用部署命令，所述部署命令指定与备份应用引擎相关的部署封装。然后，对于备份应用引擎实施步骤812和814，所述步骤相应于上面描述的步骤802和804。然后，在步骤816，将备份引擎配置状态设置到“已部署”状态。备份应用引擎如同主要应用引擎在完成步骤816时并不主管任何应用对象。控制随后进行到“结束”。

另一方面，如果在步骤808，相同的平台被指定为主管冗余对(由于单个平台存在于任何机器上，所以指的是相同联网的机器的等同物)的主要引擎和备份引擎，则控制进行到步骤818，其中，部署备份应用引擎被绕过，并且注册/报告用于部署冗余故障切换引擎配置的部分成功/失败。控制随后进行到“结束”。

由IDE 126支持的“解除部署”命令(参见图7中的对象菜单下的“解除部署”选项)来促进对故障切换对的解除部署。可通过每个引擎的各个选择或同时使用解除部署对话中的“解除部署两者”选项来解除部署故障切换对。当“解除部署两者”选项被选择时，首先对备用引擎解除部署，然后对活动引擎解除部署。当发生硬件故障而造成故障切换时，用户典型地从故障节点对启用故障切换的引擎解除部署，随后在新的节点上重新部署所述引擎。用户将引擎标记为已解除部署，以便将所述引擎重新定位到新的主机平台。当故障时将引擎标记为已解除部署的处理应用于故障切换对中的任一引擎。

步骤380：经由RMC建立主要引擎与备份引擎之间的连接

参照图3，在完成部署步骤370之后，应用引擎在运行时间环境下存在于它们各自的平台上，在所述运行时间环境中，故障切换对的活动引擎和备用引擎彼此通信，并通过RMC监视彼此的状态。因此，在步骤380期间，主要应用引擎发出用于连接到它的故障切换备份引擎的请求。在本发明的实施例中，经由RMC发出连接请求，并且所述请求在目的地字段(在步骤350期间在主要引擎上所配置的)中包括远程伙伴地址(RPA)，所述远程伙伴地址相应于备份引擎的主机平台。源字段标识主管主要引擎的平台的物理地址。初始连接请求用于向备份引擎(或备份引擎的主机平台)通知RMC上它的主要引擎的物理地址，备份引擎基于在连接请求的源字段中指定的地址来更新它的RPA属性。

步骤390：将应用对象和有关文件部署到活动引擎

将分配到故障切换应用引擎对的特定引擎的截然不同/区别的角色并入运行时间环境中(以下将在这里参照图9描述)，在所述运行时间环境中，每个故障切换应用引擎对的一个引擎被分配/获取“活动引擎”的角色，另一引擎被分配/获取“备用引擎”的角色。故障切换对的活动引擎可以是故障切换引擎对的主要引擎或备份引擎。然而，在任何时间，所述两个应用引擎中仅有一个可以是活动引擎。

应用引擎的当前运行时间角色(例如，活动或备用)确定将应用对象和有关部件(例如，文件)提供给主管故障切换引擎对的应用引擎的实例的平台的方式。在步骤390期间，该步骤可出现在主要应用引擎可操作之后的任一点(甚至在建立RMC的步骤380之前)，将应用对象和有关部件从配置数据库/文件存储库经由主要网络(例如，图1中的网络119)部署到启用故障切换的对的活动引擎。

以下概括示例性的步骤序列，所述步骤用于将应用对象和相关/需要的部件从启用故障切换的应用引擎配置部署到特定活动应用引擎。响应于用于将指定的应用对象部署到启用故障切换的应用引擎对的指示/命令，确定主要应用引擎和备份应用引擎两者的状态(例如，活动或备用)。然后，获得节点的节点名称(或地址)，在所述节点中驻留有(部署的主要引擎和备份引擎对的)活动应用引擎。接着，获取进一步的信息，所述信息涉及节点、平台和活动应用引擎。此外，获取指定的应用对象和节点上的应用对象(将使用应用对象部署的)所需的任何部件(例如，文件)的信息，所述节点包含将主管部署的应用对象的活动应用引擎。然后，将标识为支持例示和执行活动应用引擎上的应用对象所需的部件部署到所述节点。

在具体实施例中，对部署用于例示和执行特定活动应用引擎上的应用对象所需的部件的处理被最优化，以标识已经存在于主管活动应用引擎的目标平台上的部件(例如，文件)。在步骤390期间仅传送尚未存在于目标平台上的部件。此外，如果在目标主机引擎上已经部署特定应用对象，则将先前加载到与应用对象相关的节点上(并且没有被其它应用对象使用)的部件从所述节点解除部署，并且更新所述节点上的已部署部件(例如，文件)的表，以反映解除部署的部件被去除。然后，将最新的一组与应用对象相关的部件部署到所述节点。更新所述节点上已部署部件的表，以包括加载的部件。

在接收上述部件(例如，文件)之后，在步骤395期间，活动应用引擎将应用对象以及有关部件部署到第二节点，在所述第二节点上驻留有备用应用引擎。在部署期间，活动引擎的主机获得由备份引擎用于主管应用对象所需的部件的列表。主要引擎经由RMC将列出的部件部署到备用引擎。应注意到：运行备用应用引擎的平台潜在地主管其它应用引擎。因此，在步骤390期间，主管备用引擎的节点潜在地具有例示和执行在活动引擎上部署的应用对象所需的一组部件中的某些或全部。因此，当通过RMC传送部件时，发送方首先确定所需的部件中的哪一些已经存在于节点上，在所述节点上驻留有备用引擎。在步骤395期间，仅传送尚未存在于备用引擎的节点上的部件。

已经描述了启用故障切换的主机的配置和部署，更具体地说，已经描述了分级应用环境中主管一组应用对象的应用引擎，将关注这里描述的故障切换设备的运行时间方面。在将应用引擎部署到它们各自的平台之后，在运行时间环境中，在主机机器上，(如果合适)创建，例示并发起与配置的故障切换引擎对相关的对象实例(例如，平台、应用引擎和应用对象)，以便实施与当前特定角色(例如，活动/备用)和故障切换应用引擎对的每个伙伴的状态(例如，就绪/未就绪)相关的适当运行时间功能。

如以下所述，一旦部署完毕，应用对象的操作/行为就基本上基于应用对象的主机应用引擎的运行时间状态(例如，活动或备用)而不同。在示例性实施例中，并不是操作两个等同的主机(应用引擎)副本，而是在运行时间期间，仅是故障切换应用引擎对的活动引擎调用启动，并执行与一组应用对象相关的方法。备用应用引擎在具有执行所述一组应用对象所需的所有必要部件的同时呈现备用角色，在备用角色中，执行预备操作，所述操作用于执行应用对象，但是应用对象的执行并不开始。

作为实例，以下概括应用对象被部署到备用引擎后的操作。在完成步骤395时，备用引擎验证：在节点上安装运行部署的应用对象所需的所有部件(例如，节点模块)。在确认所有部件实际存在时，将部署的应用对象添加到由故障切换引擎对的备用应用引擎保存的检查点文件。在预备开始应用对象时，创建称为基础运行时间部件服务器的预安装应用对象。与部署的应用对象相关的基本要素被例示(通过调用关于基本要素的构造器)。在每个基本要素上调用初始化方法。

然而，在与备用引擎上的应用对象相关的基本要素上没有调用与应用对象(例如，启动、执行、扫描状态、句柄等)的活动执行相关的方法。调用所述与活动执行应用对象相关的方法的处理被推迟，直到产生对于备用引擎的需要，所述备用引擎用于呈现活动应用引擎角色/状态。通过不启动和执行备用引擎上的应用对象，在完成调用的预备方法之后，驻留有备用引擎的节点上的工作量实质上被减少(基于每个应用对象)。减少的与备用应用引擎相关的稳定状态的工作量有助于使单个平台/节点主管多个备用引擎。

当应用引擎从备用角色切换到活动角色时，调用组成每个被管理的应用对象的基本元素上的启动方法。在示例性实施例中，将参数传递到启动方法，所述启动方法在故障切换事件的情况下通知基本元素其正在启动。接着，在基本要素上调用集合扫描状态方法。对象和(目前活动的)应用引擎的扫描状态确定将“真”值还是“假”值传递到集合扫描状态方法，以确定基本要素将在扫描中(真)还是不在扫描中(假)。在主机活动应用引擎的监督下，周期性地执行与应用对象相关的所有在扫描中的基本要素。

相反，当活动引擎变成备用引擎时，被管理的应用对象回复到非活动的就绪状态。具体说来，所有应用对象被设置为不在扫描中。在与应用对象相关的每个基本要素上调用关闭方法，并且应用对象的执行停止。基本要素的界面没有被解除，这有助于在应用引擎重新获取故障切换应用引擎对的活动角色的情况下的快速启动。

在示例性实施例中，通过状态机来跟踪/掌管故障切换对的每个伙伴引擎的当前/下一角色以及当前/下一状态。以下描述的图9概括启用故障切换的应用可占用的故障切换状态以及示例性状态集合之间的潜在转换。通常，可将状态的示例性集合划分为两类：(1)“概要”状态和(2)“细节”状态。在处于概要状态时，提供故障切换状态信息，所述信息用于确定特定引擎的当前一般操作状态。在所示实施例中，概要状态包括：确定故障切换状态900、备用-未就绪状态902、备用-就绪状态904、以及活动状态906。在处于细节状态时，提供(与概要状态相比)相对更加详细的信息，所述信息关于故障切换引擎伙伴的操作状态。具体说来，细节状态指示活动引擎或备用引擎为什么进入特定子状态。在所示实施例中，细节状态包括：备用-与活动同步910、备用-同步代码912、备用-同步数据914、备用-丢失的心跳(从活动引擎)916以及活动-备用不可用(引擎)918。以下将在这里进一步描述每一个细节状态。

确定故障切换状态900是当引擎启动时启用故障切换的引擎的状态机的初始状态。在处于确定故障切换状态900内时，具有当前确定的状态的引擎查询故障切换服务，以检索它的故障切换伙伴的故障切换状态。作为响应，故障切换服务执行以下算法，所述算法尝试确定引擎的故障切换伙伴的状态，并最终确定引擎进入备用-未就绪状态902还是活动状态906。

作为示例，故障切换服务通过首先尝试经由所述RMC来联系故障切换伙伴来确定引擎的故障切换伙伴的状态。然而，如果无法在配置的超时周期内(经由RMC)获得故障切换伙伴引擎的状态，则故障切换服务尝试经由主要网络确定故障切换伙伴引擎的状态。如果无法在配置的超时周期内(经由主要网络)获得故障切换伙伴引擎的状态，则开始端引擎将假设无法到达故障切换伙伴引擎。在可确定伙伴引擎的状态的情况下，故障切换服务执行逻辑，所述逻辑导致故障切换对中的两个引擎中的一个占用活动状态，另一个占用备用状态。除了伙伴引擎的状态(状态/子状态)之外，这种逻辑还考虑伙伴引擎是主要引擎还是备份引擎。以下将在这里描述示例性状态选择情况。

如果故障切换伙伴引擎无法达到确定它的状态，则所述引擎确定它是否可变为活动。在以下情况下，引擎可变为活动：(1)存在代表引擎的最后已知运行状态的有效检查点，以及(2)在运行引擎的节点上存在从检查点恢复对象所需的所有节点模块。如果引擎无法变为活动，则引擎将继续尝试确定它的故障切换伙伴的状态。

引擎保持在确定故障切换状态900，直到故障切换服务建立适当的故障切换状态，引擎进入活动状态906或备用-未就绪状态902。以下概括脱离确定故障切换状态900的通路。如果无法到达故障切换伙伴引擎，并且所述引擎可变为活动，则所述引擎：从检查点恢复所有被管理的对象；调度被管理的对象以执行；将恢复的对象置于它们的适当扫描状态，所述状态如由标识引擎的最近扫描状态的检查点值所确定的；开始执行对象；以及转换到活动-备用不可用状态918。

如果已知故障切换伙伴状态，则引擎进入的下一状态取决于伙伴的故障切换状态。如果伙伴的故障切换状态是备用-未就绪状态902、备用-与活动同步状态910或备用-就绪状态904中的任何一个，则状态机从确定故障切换状态900转换到活动状态906。另一方面，如果伙伴的故障切换状态是活动-备用不可用状态918、活动状态906或备用-丢失心跳状态916中的任何一个，则状态机从确定状态900转换到备用-未就绪状态902。如果伙伴引擎的故障切换状态是确定故障切换状态900，则在伙伴引擎被配置为故障切换对的备份引擎的情况下，故障切换服务将指导它的引擎从确定状态900转换到活动状态906。如果伙伴引擎是主要引擎，则引擎的状态机进入备用-未就绪状态902。

关于活动状态906，当已经检测到活动伙伴引擎上的故障切换时，故障切换引擎状态机从备用-就绪状态904转换到活动状态906。在处于活动状态906内时，引擎调度被管理的应用对象，并将包括检查点数据和订户列表更新的同步更新经由RMC传递到备用引擎。如果被命令变为备用引擎，则引擎状态机从活动状态906转换到备用-未就绪状态902。或者，如果引擎无法联系伙伴引擎或者与伙伴引擎失去联系，则引擎状态机转换到活动-备用不可用状态918。

关于备用-就绪状态904，备用引擎在从备用-未就绪状态902经过一组中间同步状态/阶段910、912和914(以下将在这里描述)进行转换之后，备用引擎进入备用-就绪状态904，在所述中间同步状态/阶段中，代码和数据与活动伙伴引擎同步。在处于备用-就绪状态904时，应用引擎执行一组任务，所述任务不同于由活动应用引擎执行的任务。

作为示例，在处于备用-就绪状态904时，应用引擎监视活动伙伴引擎的故障(例如，在配置的超时周期内验证通过主要网络和通过RMC两者从活动引擎接收的心跳)。此外，在处于备用-就绪状态904内时，备用引擎试图通过逐渐增加的更新将特定信息保存为与备用引擎的活动伙伴的所述特定信息同步。然而，在某些情况下，并不仅执行逐渐增加的更新，而是故障切换对对它们的信息执行完全的重新同步。在这种情况下，当备用引擎被通知它的信息(经由RMC更新的)与它的活动伙伴失去同步时，备用引擎从备用-就绪状态904转换到备用-与活动同步状态910。备用引擎通过RMC从活动引擎接收同步信息。同步信息包括来自活动引擎的检查点变量增量/改变。检查点变量增量是扫描期间检查点属性值的改变，所述检查点属性值与由活动引擎主管的应用对象相关。检查点数据的示例包括：涉及应用对象的配置和调整信息、告警限制以及在引擎上部署的一组应用对象(包括由应用对象使用的任何需要的代码/数据文件)。备用引擎还确定来自活动引擎的检查点变量增量是否已丢失，并且备用引擎确保其具有一致的检查点瞬象。除了上述的检查点变量增量之外，备用引擎潜在地经由RMC从活动引擎接收其它同步信息，包括：当客户机引擎向活动引擎预订/从活动引擎解除预订时的通知、告警状态改变(戳记的时间)和在活动引擎的存储转发存储器中放置的历史块。

故障切换应用引擎配置的一种预期的使用涉及向数据获取服务提供故障切换功能，所述数据获取服务将数据传送到联网的处理管理信息数据库。在应用引擎被配置为管理用于数据获取服务器的存储转发操作的情况下，配置故障切换存储转发引擎设备和保存活动引擎的存储转发存储器的副本的处理限制了所述的丢失，当发生故障切换时，所述数据被从活动引擎的存储转发存储器传送到历史数据库。此外，如果在活动引擎处于存储转发模式下的同时发生故障切换，则备用引擎接管并继续处于存储转发模式，直到存储转发数据(例如，处理信息数据库)的预期目的地变得可用。当目的地数据库变得可用时，将由故障引擎获取的存储转发数据以及接着由当前活动(先前备用)引擎获取的存储转发数据转发到数据库。

以下概括了包括存储转发功能的活动应用引擎和备份应用引擎的行为。当从活动引擎到历史数据库服务器的数据路径被阻碍/中断时，存储转发功能有助于存储历史处理和制造信息。当没有检测到故障时，在启用故障切换的引擎上与在未启用故障切换的引擎上同样地处理历史数据。仅从活动引擎将历史数据发送到历史数据库服务器。当数据库服务器可用时，活动引擎处理历史数据并将其发送到历史数据库服务器。如果历史数据库变得不可用(或者发送数据缓冲器由于缓慢的链路而变为备份)，则活动引擎在本地存储历史数据，并当历史变得可用时转发所述数据。应注意到：在所示的实施例中，与历史数据库的连接的丢失不会开始故障切换。如果活动引擎丢失与历史的连接并且它的备用引擎可连接到历史，则活动引擎进入存储转发模式，将开始经由RMC发送存储转发更新，并且不会进行故障切换。

当活动应用引擎进入存储转发模式的操作时，活动引擎将它的存储转发数据与它的伙伴备用引擎同步。备用引擎从它的活动引擎接收它的所有存储转发数据。因此，在通知开始于备用模式下时，备用引擎进行检查，以察看其存储转发存储器内是否具有数据。如果存在这样的数据，则将其清空，并且备用引擎在初始数据同步阶段期间等待来自它的活动伙伴引擎的存储转发数据。

在本发明的实施例中，根据可配置的重复周期在活动引擎与备用引擎之间执行存储转发信息同步。作为示例，每30秒将存储转发数据写入活动引擎中的存储器中。每30秒还进行对活动/备用引擎之间的存储转发存储器的同步。在这种更新方案下，在引擎故障切换期间仅仅丢失30秒的来自先前活动引擎的存储转发信息。

在故障切换的情况下，激活由备用引擎主管的数据获取服务，并取代由原来的活动引擎主管的数据获取服务。如果数据获取服务的先前活动引擎处于存储转发模式，则新的活动引擎将能够在没有连接到历史的情况下继续存储转发功能。当到历史数据库的连接被恢复时，将由故障切换对的任一引擎收集的同样的存储转发数据从当前活动引擎转发到数据库。

为了帮助在多次故障期间收集的存储转发数据的管理，并且为了改进诊断，应用引擎状态信息包括概括引擎的当前存储转发状态的属性。作为示例，属性指定以下值，所述值指示：已经为引擎收集存储转发数据，存储转发数据当前与备用引擎同步，存储转发数据没有与备用引擎同步以及存储转发数据的时间间隔(由开始时间和结束时间标识)。

继续描述在备用-就绪状态下由引擎执行的任务，备用引擎还验证其是否与活动引擎同步。在以下情况下备用引擎与它相应的活动引擎同步：(1)在备用节点上安装在活动引擎的节点(通过部署操作指定的)上安装的文件；(2)存在于活动引擎的检查点文件中的所有检查点也存在于备用引擎的检查点文件中；以及(3)备用引擎已验证其没有丢失任何变量增量检查点、告警状态改变或历史块。在所示的实施例中，当备用引擎验证文件的同步时，其仅考虑作为到活动节点的部署操作的结果而安装在活动节点上的文件。在部署操作以外安装的文件不被考虑。

存在多个从备用-就绪状态904的出口通路。应用引擎状态机响应于接收的用于变为活动的命令，转换到以上在这里描述的活动状态906。或者，状态机响应于接收的不再与活动引擎同步的通知，状态机进入备用-与活动同步状态910。当可配置的一组心跳已经从活动引擎丢失时，另一转换通路将状态机带入备用-丢失心跳状态916。

关于备用-未就绪状态902，引擎从多个状态中的任何一个进入备用-未就绪状态902。在处于备用-同步数据状态914时，如果备用引擎确定其已从活动引擎丢失检查点和/或告警状态改变，则状态机转换到备用-未就绪状态902。这种通信故障典型地由RMC中的通信故障造成。然而，所述故障的其它源包括：检查点、告警状态以及历史块和告警状态改变，其中，发送历史块的速度快于备用引擎可处理它们的速度，并且告警状态改变被发送地如此快，以致备用引擎不能足够快地处理它们。可通过添加/增加用于经由RMC转发的数据的缓冲器的容量来避免所述故障。

当新的对象被部署到活动引擎时，状态机还转换到备用-未就绪状态902。将新的对象部署到活动状态906下的引擎促使在活动引擎上创建检查点并且安装部署的对象所需的代码模块。如果在新的文件需要被安装在备用引擎上时状态机处于备用-就绪状态904，则状态机转换到备用-未就绪状态902(或者，如果已经检测到活动引擎，则直接转换到备用-与活动同步状态910)。在备用引擎完成同步并进入备用-就绪状态904之间，如果备用引擎检测到经由RMC与活动引擎的通信丢失，则状态机还从以下状态中的任何一个进入备用-未就绪状态902：备用-与活动同步状态910、备用-同步代码状态912或备用-同步数据状态914。

在处于备用-未就绪状态902内时，备用引擎试图在成功经历状态910、912和914的同时，通过将代码模块和数据与活动引擎同步来执行最终转换到备用-就绪状态904所需的任务。在所示的本发明的实施例中，所述过程开始于在建立经由RMC与活动引擎的通信之后，从备用-未就绪状态902转换到备用-与活动同步状态910。

关于活动-备用不可用状态918，应用引擎状态机从活动或备用状态转换到活动-备用不可用状态918。当发送以下同步信息(检查点变量增量、预订通知或告警状态改变)时，如果感测到经由RMC与备用引擎的通信故障，则状态机从活动状态906转换到活动-备用不可用状态918。将存储转发历史块发送到备用引擎的故障不会导致从活动状态906转换到备用不可用状态918。

活动引擎周期性地从它相应的备用引擎接收心跳。如果用于从备用引擎接收心跳的(可配置)时间周期届满，则活动引擎状态机从活动状态906转换到活动-备用不可用状态918。此外，在本发明的实施例中，心跳是状态良好的平台/节点的指示符，因此，不会将多个心跳从主管多个备用引擎的平台发送到主管相应活动引擎的节点。相反，将一个心跳消息从主管多个备用引擎的平台发送到主管相应活动引擎的平台。从具有备用引擎的节点Y发送到具有活动引擎的节点X的心跳的频率是用于部署到节点X的所有活动引擎的最小配置的超时，其中，所述节点X具有部署到节点Y的备用引擎。或者，在心跳意在指示每个引擎的状态的情况下，为每个故障切换引擎发出分离的心跳。在这样的实例中，在主管多个备用引擎的第一平台与主管相应的活动引擎的第二引擎之间发出多个心跳。

如果活动引擎经由RMC接收备用引擎不可用的通知，则应用引擎状态机从活动状态906转换到活动-备用不可用状态918。当发生这种转换时的示例包括当备用引擎关闭并不再运行时。

如果备用引擎丢失了经由RMC来自活动引擎的可配置数量的连续心跳(造成备用引擎的状态机首先从就绪状态904转换到丢失心跳状态916)，则备用引擎的状态机从备用-丢失心跳状态916转换到活动-备用不可用状态918，并且独立的监视器发出命令到备用引擎，以变为活动。以下将在这里进一步讨论对活动引擎的故障的监视。

在处于活动-备用不可用状态918时，活动应用引擎主管应用对象的执行，所述应用对象在扫描中被部署到应用引擎。活动应用引擎周期性地进行检查，以查看是否可经由RMC联系备用引擎。因为没有备用引擎，所以无法将活动应用引擎手动切换到备用(因为缺少当前备用引擎)。此外，活动应用引擎将不再试图将典型传递的检查点变量增量(改变)、预订通知、告警状态改变和存储转发历史数据块经由RMC发送到备用引擎。

如果与可操作的相应备用引擎重新建立了连接，则状态机从活动-备用不可用状态918转换到活动状态906。

关于备用-丢失心跳状态916，如果在配置的超时周期内备用引擎没有从活动伙伴的故障切换服务经由RMC或主要网络接收到心跳(例如，通过心跳超时限制参数值和连续丢失的心跳参数值确定)，则备用引擎从备用-就绪状态904转换到备用-丢失心跳状态916。与将心跳从备用节点发送到活动节点的配置一致，将单个心跳从主管多个活动引擎的节点发送到主管它们的相应备用引擎的另一节点。从活动节点X上的活动引擎的故障切换服务发送到备用节点Y的心跳的重复周期是部署到节点X的所有活动引擎的最小配置的超时，其中，所述节点X具有部署到节点Y的备用引擎。促使转换到备用-丢失心跳状态916的其它潜在事件包括：活动引擎故障或挂起(由通过单独的超时机制的活动引擎的故障切换服务来确定，参见以下描述的活动引擎超时1140)；以及活动引擎适度地关闭。在后者的实例中，备用引擎将被通知其将转换到活动-备用不可用状态918。

在处于备用-丢失心跳状态916内时，执行逻辑，以确定备用引擎为什么丢失心跳以及用于备用引擎的状态机将转换到活动模式的操作还是保持在备用模式下(转换到备用-就绪状态904或备用-未就绪状态902)。参照图10，参照图10，在步骤1000期间，用于备用引擎的故障切换服务检查/监视通过主要网络和RMC两者(例如，图1的网络119和链路140)来自活动引擎的心跳。在步骤1002，如果已丢失经由RMC发送的当前配置的数量的连续心跳，则控制进行到步骤1004。在步骤1004，故障切换服务确定是否可经由主要网络到达活动引擎的节点。如果可经由主要网络到达活动引擎的节点，则假设RMC链路关闭，并且控制进行到步骤1006，其中，引擎的状态机进入备用-未就绪状态902。

否则，如果在步骤1004无法到达活动引擎，则控制进行到步骤1007。在步骤1007，如果无法经由主要网络到达至少一个其它节点，则在备用引擎的主机中可能存在通信问题，控制进行到步骤1006，并且状态机进入备用-未就绪状态902。如果可经由主要网络到达至少一个其它节点，则执行进一步的测试，以确定当前活动引擎是否出现故障，由此，控制进行到步骤1008。在步骤1008，如果另一平台节点可访问活动引擎的节点，则假设活动引擎仍旧可用(并且问题在于备用引擎的节点)，控制进行到步骤1006。否则，如果在步骤1008没有节点可以看到活动引擎的节点，则故障很可能源于活动引擎的节点。因此，控制进行到步骤1010，其中，备用引擎进入活动引擎节点。因为假设故障切换伙伴在服务之外，所以在步骤1010期间，状态机从备用-丢失心跳状态916转换到活动-备用不可用状态918。

返回步骤1002，如果经由RMC发送的当前配置的数量的连续心跳没有丢失，则控制进行到步骤1020，其中，故障切换服务检查经由主要网络发送的心跳是否已丢失。如果可配置数量的心跳没有丢失，则控制进行到步骤1006，并且备用引擎进入备用-未就绪状态(由于不存在明显的支持活动引擎与备用引擎之间的通信的RMC连接的问题)。

然而，如果经由主要网络的连续心跳已丢失，则控制进行到步骤1020到步骤1022。在步骤1022，执行连接测试，以确定活动引擎和备用引擎是否可经由主要网络到达至少一个其它平台。然后，在步骤1024，如果活动引擎的节点可经由主要网络到达至少一个平台，则控制进行到步骤1026。在步骤1026，如果备用节点可经由主要网络到达至少一个其它平台，则假设在主管活动引擎和备用引擎的节点之间存在主要网络方面的连接问题。因此，控制从步骤1026进行到步骤1028，并且备用引擎的状态机进入备用-就绪状态904。否则，在主管备用引擎的节点与所有其它节点之间明显地存在连接问题，控制从步骤1026进行到步骤1006，并且状态机从备用-丢失心跳状态916转换到备用-未就绪状态902。

返回步骤1024，如果活动引擎的节点无法到达主要网络上的任何其它节点，则控制进行到步骤1030。在步骤1030，如果可从备用节点经由主要网络到达至少一个节点，则活动引擎的主要网络适配器明显地出现故障，备用引擎应该接管出故障的活动引擎以服务于来自应用引擎的客户机的请求。因此，控制从步骤1030进行到步骤1032。在步骤1032，指示当前活动引擎进入备用模式，命令备用引擎进入活动模式。控制随后从步骤1032进行到步骤1010。否则，如果备用节点甚至无法经由主要网络到达一个节点，则控制从步骤1030进行到步骤1006。

返回图9，将一系列状态与经由RMC将备用引擎和它相应的活动伙伴引擎同步相关。当通过备用引擎的主机经由RMC检测到活动引擎时，从备用-未就绪状态902进入备用-与活动同步状态910。如先前所述，备份/备用引擎不会经由主要网络接收用于支持应用对象的代码模块，而是经由RMC从主要/活动引擎接收所述代码模块。在位于备用-与活动同步状态910时，备用应用引擎将它的代码模块与活动引擎同步。因此，没有存在于活动引擎上的备用引擎上的任何代码模块被卸载，没有安装在备用引擎上的活动引擎上的任何代码模块被安装在备用引擎的节点上。一旦代码模块被同步，状态机转换到备用-同步代码状态912。

在位于备用-同步代码状态912内时，备用引擎将它的检查点数据和其它瞬象信息与活动引擎同步，所述其它瞬象信息包括订户信息。所述同步包括：在不存在于活动引擎中的备用引擎的记录中删除检查点数据(包括对象信息)或订户信息；以及将检查点数据(包括对象信息)或订户信息添加到存在于活动引擎上而不存在于备用引擎上的备用引擎的记录。如果在状态机处于备用-同步代码状态912的同时通过RMC的通信丢失，则状态机转换到备用-未就绪状态902。然而，在成功完成对对象信息、检查点数据和订户喜讯你的同步时，状态机转换到备用-同步数据状态914。在操作于备用-同步数据状态914内时，备用应用引擎完成它的数据同步处理(例如，根据传送的同步信息来更新数据库和目录)，并转换到备用-就绪状态904。然而，如果在状态机处于备用-同步数据状态914的同时，主要引擎与备用引擎之间的通信丢失，则状态机转换到备用-未就绪状态902。

在操作于故障切换模式下时，活动引擎和备用引擎通过告警保持对彼此状态的认识。以下在这里提供对掌管转换和状态机的操作中的各种告警状态和它们的角色的概要。

以下是与故障切换相关的各种告警，当备用引擎和活动引擎在先前描述的故障切换状态之间进行转换时，报告所述告警。对报告的所有告警的告警描述包含：引擎故障切换伙伴的节点名称、可应用情况下的概要状态和细节状态、报告告警的引擎的节点名称和报告告警的引擎的名称。为了简化表1，仅标识概要状态。从先前状态到当前状态或当前子状态的任何转换将导致发生所述告警。

表1

告警名称	先前状态	当前状态	当进入以下状态时清除告警	报告告警者
					备用未就绪	活动	备用-未就绪	备用-就绪	活动引擎
备用不可用	活动	活动-备用不可用	活动	活动引擎

关于备用未就绪告警，活动引擎经由RMC监视备用引擎的状态，以确定何时提出表1中提到的告警。此外，如果活动引擎处于备用不可用状态，则不产生所述告警。

表2概括每当产生故障切换时报告的告警。

表2

告警名称

提出告警的时间

清除告警的时间

报告告警者

发生故障切换	当备用引擎变为活动时	在活动引擎的下一扫描期间	活动引擎
				备用历史数据不同步	当活动引擎不能用历史块更新备用引擎时	当活动引擎和备用引擎中的历史数据同步时	活动引擎
备用告警数据不同步	当活动引擎不能用告警数据更新备用引擎时	当活动引擎和备用引擎中的告警数据同步时	活动引擎

除了上述告警之外，将提供通过RMC丢失的连续心跳和通过主要网络丢失的连续心跳，作为可由用户扩展的属性，以便需要时报告告警。

简要地参照图11，标识一组定时器/显示，其与故障切换引擎相关。采用这些定时器以确保适当地跟踪故障切换引擎对以及所述故障切换引擎对通过其通信的网络和主机的状态。当引擎试图经由主要网络(例如，网络119)确定它的故障切换伙伴的状态时，作为实例，由引擎在确定故障切换状态900的同时使用主要网络通信超时1100。主要网络超时是可以独立配置的，并且作为可在配置时间和运行时间修改的属性存在的。

作为实例，由活动引擎在处于活动状态906时使用备用引擎心跳超时1110，以确定活动引擎是否已丢失经由RMC与备用引擎的通信。心跳超时在运行时间和配置时间两者均是可从活动引擎来配置的，心跳超时被部署到活动引擎，持续到引擎重新启动，并被分配2秒的默认值。

作为示例，由备用引擎在处于备用-就绪状态904时使用活动引擎心跳超时1120，以确定备用引擎是否丢失了经由RMC来自它的故障切换伙伴的心跳。如果在由活动引擎心跳超时指定的时间周期内备用引擎没有经由RMC从它的活动引擎伙伴接收到心跳，则注册丢失的心跳(并且备用引擎转换到备用-丢失心跳状态916)。活动引擎心跳超时在配置时间和运行时间两者均是可从活动引擎来配置的，所述心跳超时持续到引擎重新启动，并被分配5秒的默认值。

丢失的连续心跳限制1130指定经由主要网络或RMC在活动引擎与备用引擎之间丢失的连续数量的心跳(在备用-丢失心跳状态916期间采用)。丢失的连续心跳限制在配置时间和运行时间可从活动引擎来配置，其持续到引擎重新启动，并具有2秒的默认值。默认值2意味着必须连续丢失2个心跳，才导致丢失的心跳的连续数量条件变为“真”并造成故障切换。丢失单个心跳使得备用引擎的状态机进入备用-丢失心跳状态916。

活动引擎超时限制1140指定超时周期，在所述超时周期内，活动引擎必须通知它的故障切换服务活动引擎仍然可操作，其中，所述故障切换服务运行在与活动引擎相同的平台上。如果超过所述超时周期，则系统将确定活动引擎已发生故障或刮起，并开始故障切换顺序，其中，命令配置故障切换的引擎的备用伙伴变为活动，将与故障切换有关的事件通知客户机/订户。活动引擎超时限制在配置和运行时间期间可配置，其持续到引擎重新启动，并在基本要素规范中指定默认值。

预订引擎节点连接超时1150指定由备用-丢失心跳过错解析方案(见图10)用来等待来自节点的响应以确定它们是否能够看到活动引擎的周期，其中，所述节点将引擎预订到活动引擎。预订引擎节点连接超时在配置和运行时间可配置，其持续到引擎重新启动，并且在基本要素规范中指定默认值。

检测影响客户机/订户的活动引擎故障

故障切换主机对的运行时间操作的另一方面在于可靠地检测活动主机故障，并确保当故障切换发生时，客户机/订户及时地重新连接到(先前的)备用主机。以下将在这里描述监视方案，其减少与监视活动主机的操作状态相关的通信负载，同时保持了较高的可信度，从而当活动主机停止作用时，检测到故障，并且出现故障的活动主机的客户机很快地重新连接到故障切换对的(先前的)备用主机。

感测引擎/主机故障的第一方面涉及检测当前驻留有活动主机的节点的故障。一种监视节点的状态的方式为使用心跳。然而，心跳消耗网络资源并占用计算资源。因此，在示例性实施例中，对于心跳的预期接收方限制与节点状态相关的心跳。心跳没有被公布者(例如，应用引擎)发送到客户机/订户。例如，心跳没有被发送到车间场所显像应用实例，所述实例预订关于由引擎主管的应用对象的标签。在客户机/订户和公布者处于不同节点的情况下，在主管公布者(引擎)和有关客户机/订户的节点(平台)之间发送心跳。当节点期待心跳而在配置的时间周期内没有接收到心跳时，则监视机制假设：节点或它的网络适配器出现故障，并且两个节点之间的网络通路出现故障。在运行时间和配置时间两者可在平台上配置两个节点之间的心跳发送率(在运行时间，限制到具有调整允许的用户)，所述心跳发送率持续到平台重新启动，最小值为250毫秒，并且默认值为2500毫秒。

当丢失可配置数量的连续心跳时，感测到差错。由主管感兴趣的活动引擎的节点丢失的连续心跳的数量可在运行时间和配置时间两者在平台上进行配置(在运行时间限制到具有调整允许的用户)；所述连续心跳的数量持续到平台重新启动；并具有默认值2。如果来自节点的配置数量的连续心跳丢失，则假设节点出现故障，其中，从所述节点期待心跳，并且通过驻留在它们的主机节点上的监视服务向期待来自所述故障节点的数据的所有客户机通知假设的故障。

感测引擎/主机故障的第二方面涉及检测引擎本身的故障(在它的主机节点/平台没有停止的情况下)。不同于使用心跳，单独的监视处理确定特定引擎对于各种情况不再可用，并将其通知给客户机。所述情况的示例包括当应用引擎停止，出现故障(例如，意外地碰撞)或挂起时(即，尽管在操作中，但是没有接收由驻留有应用引擎的平台传递给它的消息/响应于所述消息)。

参照图12，步骤序列概括与监视并响应于活动应用引擎故障相关的阶段的程序，其通过将服务客户机/订户的消息收发基础结构(例如，WONDERWARE的INTOUCH人机接口)通知给位于其它网络节点的引擎，从而用于客户机.订户的消息收发基础结构可采取用于更新数据连接的步骤以参考故障切换引擎配置的(先前的)备用伙伴。总之，并不是依赖发送周期性心跳到每个客户机，而是在与活动引擎相同的机器上执行的单独处理监视活动引擎的状态。当检测到活动引擎的故障时，监视处理通知备用引擎的故障切换服务。然后，故障切换服务向到达被故障切换的引擎的服务客户机/订户的消息收发基础结构通知新的活动引擎的状态。

在阶段1200期间，单独执行的监视处理(例如，在计算系统上的引导处理，在所述计算系统上运行应用引擎)监视活动应用引擎的状态。监视处理根据时间间隔从活动应用引擎接收周期性的通知。所述间隔可在运行时间和配置时间两者对于每个引擎分别进行配置。然而，运行时间配置不会限制到具有调整允许的用户，所述间隔持续到引擎重新启动。由在相同节点上操作的处理来监视引擎的状态与经由心跳分别通知客户机引擎的状态的方案相比，减少了网络工作量。

在阶段1210期间，监视处理检测活动应用引擎已停止，碰撞或挂起。作为响应，在阶段1220，监视处理开始通知备用引擎：先前的活动引擎不可操作。作为示例，监视处理通知它自己的机器上的故障切换服务，所述机器反过来通知(经由RMC)与备用引擎相同的平台上的故障切换服务：备用引擎变为活动。

在阶段1225期间，备用引擎上的故障切换服务采用先前经由RMC传递的订户/客户机信息，向用于出现故障的引擎的每个客户机/订户的消息收发基础结构(例如，本地消息交换-LMX)发出活动引擎故障通知。活动引擎故障通知消息标识：故障引擎(通过句柄)、新的活动引擎(通过句柄)和时间周期，在所述时间周期内，新的活动引擎将完成启动。

在步骤1230，备用引擎从备用-就绪状态904转换到活动状态906(见图9)。作为示例，故障切换服务更新备用引擎的状态，以反映所述引擎正转换到活动状态(在图9中，从备用-就绪904到活动906的状态转换)。然后，故障切换服务指导备用引擎开始在活动状态下运行(例如，调用关于它被管理的每个应用对象的启动方法等)。当活动引擎的启动程序完成时，当先的活动应用引擎通知故障切换服务。作为响应，故障切换服务更新“转换”引擎的状态，以反映：所述引擎目前活动(见活动状态906)并执行它被管理的应用引擎。

然后，在步骤1240，用于目前的活动(先前备用的)引擎的故障切换服务采用先前经由RMC传递的订户/客户机信息，通知用于订户/客户机(例如，INTOUCH车间/处理显像应用)的消息收发基础结构(例如，LMX)：先前备用的引擎是目前的活动伙伴。到达服务预订客户机的消息收发基础结构的活动状态通知消息包括：目前的活动引擎的引擎标识(通过句柄)和“活动”状态标识符。

然后，在步骤1250，在对客户机/订户完全透明的情况下，消息收发基础结构对于受新的活动引擎的改变影响的所有参考更新它们的路由表。由与故障切换对的新的活动引擎上的参考相应的句柄来代替先前与故障引擎相关的每个数据/属性参考的消息交换句柄。接着，在不改变由客户机/订户使用的任何参考串的情况下(即，在客户机透明的情况下)，将与故障活动引擎的所有数据预订重新路由/连接到新的活动引擎。

在以上描述的基于角色的冗余引擎布置中，主要引擎和备份引擎在由截然不同的物理平台主管的同时，被看作全局/统一名称空间内的单个逻辑实体(例如，对在引擎对伙伴上主管的对象/属性的客户机参考不会在构成故障切换引擎对的两个实体之间进行区分)。将相同的名称分配到故障切换对的主要引擎和备份引擎两者，并且由基于它们的当前角色/状态执行的操作来区分所述引擎。因此，冗余引擎的客户机/订户向逻辑上启用故障切换的引擎实体发出它们的请求，其中，所述实体包括主要引擎和备份引擎两者。消息收发和命名服务在完全不知晓客户机的情况下，以透明方式将参考/名称串解析为启用故障切换的引擎对的当前活动应用引擎的标识符。这潜在地导致对于以下的流线型处理：切换故障切换对中的活动服务器/公布者引擎，以及将应用引擎对象重新定位到网络内的新的平台。

在接收到备用引擎目前在活动状态下运行的通知时，作为示例，消息收发部件(例如，消息交换机)将一组三种不同类型的对属性的参考从故障引擎切换到新的活动引擎。

监督参考-包括对以下的参考：修改属性(不遵循安全性的监督设置)，监视属性的改变(监督在预订情况下所得到的)以及从属性检索数据(监督在没有预订的情况下所得到的)。

用户参考-包括对以下的参考：修改属性(与遵循安全性的登陆用户相关的用户设置)，监视属性的改变(用户在预订情况下所得到的)，从属性检索数据(用户在没有预订的情况下所得到的)以及预绑定参考。

系统参考-包括对以下的参考：修改属性(诸如与系统信息的全局网络存储库/数据库相关的系统设置)，监视属性的改变(系统在预订情况下所得到的)以及从属性检索数据(系统在没有预订的情况下所得到的)。

在示例性实施例中，切换参考的处理对于消息交换客户机是透明的。客户机采用来自全局名称空间(由全局名称表125保存)的独立于位置的名称，以参考与启用故障切换的应用引擎相关的属性。结果，当发生故障切换到不同网络节点上的备用引擎时，没有由客户机使用的参考名称发生改变(由于参考名称可等同地应用于激活的主要应用引擎或备份应用引擎)。

当先前备用的引擎开始作为活动引擎操作之后，客户机接收用于预订的数据更新，其包含关于新激活的引擎的属性的当前值。如果当客户机引擎接收到活动引擎的故障的通知时与客户机引擎接收到备用引擎已变为活动的通知时之间的变量增量/延迟时间超过配置的限制，则与所有参考的属性相关的数据的质量将被设置为“差”，直到从新激活的引擎接收到数据更新为止。配置的限制(具有15秒的默认值)可在运行时间和配置时间对于全局名称空间的范围内的所有引擎可配置，并且持续到引擎重新启动。

全局名称空间/重新定位活动引擎

通过对应用引擎进行基于名称的访问将上述故障切换引擎配置和部署结构与全局/统一名称空间集成，所述名称空间支持网络位置独立。通过独立于位置的名称来标识引擎。在全局名称空间中，由名称服务将参考从独立于物理位置的参考解析到网络地址。在这种情况下，当引擎重新定位时，仅需要向名称服务通知用于命名的引擎的新地址。与重新定位的引擎相关的名称/参考独立于位置，因此，当将引擎移动到网络内的新平台时，所述名称/参考不会改变。由重新定位的应用引擎的客户机通过提交到命名服务的重新绑定请求来建立与重新定位的应用引擎的联系。

参照图13，概括配置数据库接口，其在处理控制和制造信息系统环境下，有助于主机(例如，支持一组应用对象的应用引擎)中的上述故障切换功能。

IFialOverConfiguration接口1300是用于创建故障切换主机(例如，应用引擎对)的主要接口。IFailOverConfiguration接口1300包括一组方法，所述方法包括CreateBackupEngine方法1310。CreateBackupEngine方法1310在配置数据库124中创建备份故障切换引擎。如果成功的话，则CreateBackupEngine方法1310将指针/参考返回到用于新创建的备份引擎对象的标识。DeleteBackupEngine方法1320从配置数据库124中删除先前创建的备份故障切换引擎对象。在应用引擎的配置期间，如果用户没有检查启用冗余检查栏404，则调用DeleteBackupEngine方法1320，GetBackupEngine方法1330将参考返回备份引擎对象。ValidateHostedEngines方法1340使分配到标识的平台的所有应用引擎生效(检查它们的配置)。

IPackageManager接口1350作为管理配置数据库124内的对象封装的一般接口包括GetFailOverPartnerId方法1360。GetFailOverPartnerId方法1360接收作为输入的故障切换伙伴引擎对象的标识。GetFailOverPartnerId方法1360将参考返回伙伴引擎对象。ObjectStatus方法1370返回与应用引擎的目前状态相应的一组状态位。示例性状态喜讯你包括所述对象是否是：模板、隐藏、被检验、未决更新、部署、主要引擎、备份引擎和启用故障切换。

根据可应用本发明的原理的许多可行实施例，应该认识到：在这里参照附图描述的实施例仅仅是示例性的，不应被看作对本发明的范围的限制。此外，可在不脱离本发明的情况下修改、补充和/或重新排序所示的步骤。因此，如这里所述的发明包括可落入所附权利要求及其等同物的范围的所有那些实施例。

Claims (20)

1、一种在监督处理控制数据获取应用运行时间环境中用于在启用冗余的主机的数据获取客户机的故障切换主机伙伴之间保持透明性的方法，所述方法包括步骤：

在名称解析表内进行存储，所述名称解析表用于将独立于位置的参考名称映射到网络位置特定的地址；

将独立于位置的名称分配到启用冗余的主机，所述主机包括活动主机伙伴和备用主机伙伴；以及

为启用冗余的主机的每个客户机提供消息收发基础结构，其中，所述消息收发基础结构维护名称，所述名称用于客户机对于启用冗余的主机上的预订数据的每个参考的地址翻译，从而不必考虑哪个启用冗余的主机伙伴当前活动，而将相同的名称用于参考启用冗余的主机上的数据。

2、如权利要求1所述的方法，还包括：

由消息收发基础结构接收通知：启用冗余的主机的备用伙伴目前是活动伙伴；以及

响应于接收到通知，用与目前为活动伙伴的备用伙伴相应的位置特定地址来更新以下位置特定地址，该位置特定地址在名称解析表内与分配到启用冗余的主机的独立于位置的参考名称相应。

3、如权利要求2所述的方法，其中，在相同计算节点上分别作为备用主机操作的故障切换服务向消息收发基础结构发出所述通知。

4、如权利要求1所述的方法，其中，消息收发基础结构包括本地消息交换机。

5、如权利要求4所述的方法，其中，对关于启用冗余的主机的属性的客户机参考包括监督参考。

6、如权利要求4所述的方法，其中，对关于启用冗余的主机的属性的客户机参考包括用户参考。

7、如权利要求4所述的方法，其中，对关于启用冗余的主机的属性的客户机参考包括系统参考。

8、如权利要求1所述的方法，其中，消息收发基础结构确定在指定的周期内是否完成到先前备用的主机伙伴的故障切换，如果备用伙伴变为活动所过去的周期超过指定的周期，则指明对数据客户机的警告。

9、如权利要求1所述的方法，其中，独立于位置的参考名称在由消息收发基础结构覆盖的网络范围内是唯一的。

10、如权利要求1所述的方法，其中，启用冗余的主机包括主管一组应用对象的应用引擎，所述应用对象仅在启用冗余的主机的活动主机上执行。

11、一种在监督处理控制数据获取应用运行时间环境中用于在启用冗余的主机的数据获取客户机的故障切换主机伙伴之间保持透明性的系统，所述系统包括：

名称解析表，用于将独立于位置的参考名称映射到网络位置特定的地址；

分配到启用冗余的主机的独立于位置的名称，所述主机包括活动主机伙伴和备用主机伙伴；以及

服务于启用冗余的主机的每个客户机的消息收发基础结构，其中，所述消息收发基础结构维护名称，所述名称用于客户机对于启用冗余的主机上的预订数据的每个参考的地址翻译，从而不必考虑哪个启用冗余的主机伙伴当前活动，而将相同的名称用于参考启用冗余的主机上的数据。

12、如权利要求11所述的系统，还包括：在消息收发结构内，有助于以下操作的可执行程序部件：

由消息收发基础结构接收通知：启用冗余的主机的备用伙伴目前是活动伙伴；以及

响应于接收到通知，用与目前为活动伙伴的备用伙伴相应的位置特定地址来更新以下位置特定地址，该位置特定地址在名称解析表内与分配到启用冗余的主机的独立于位置的参考名称相应。

13、如权利要求12所述的系统，其中，在相同计算节点上分别作为备用主机操作的故障切换服务向消息收发基础结构发出所述通知。

14、如权利要求11所述的系统，其中，消息收发基础结构包括本地消息交换机。

15、如权利要求14所述的系统，其中，对关于启用冗余的主机的属性的客户机参考包括监督参考。

16、如权利要求14所述的系统，其中，对关于启用冗余的主机的属性的客户机参考包括用户参考。

17、如权利要求14所述的系统，其中，对关于启用冗余的主机的属性的客户机参考包括系统参考。

18、如权利要求11所述的系统，还包括数据质量管理逻辑，其确定在指定的周期内是否完成到先前备用的主机伙伴的故障切换，如果备用伙伴变为活动所过去的周期超过指定的周期，则指明对数据客户机的警告。

19、如权利要求11所述的系统，其中，独立于位置的参考名称在由消息收发基础结构覆盖的网络范围内是唯一的。

20、如权利要求11所述的系统，其中，启用冗余的主机包括主管一组应用对象的应用引擎，所述应用对象仅在启用冗余的主机的活动主机上执行。

Images