用于订单产生和管理以促进决策问题解决方案的设备和方法

专利名称：用于订单产生和管理以促进决策问题解决方案的设备和方法
技术领域：
本公开一般涉及计划、调度和其它决策系统。更具体地说，本公开涉及用于订 单产生和管理以促进决策问题的解决方案的设备和方法。
背景技术：
经常需要处理设施和其它实体来执行计划和调度操作。计划和调度通常涉及定 大小、定序、分配和定时判定，使得满足理想规定的到期日和最后期限。例如，计划可 涉及确定到特定最后期限要产生的产品量，而调度可涉及确定将如何随着时间的过去生
.、r .、口
广广口口。

发明内容
本公开提供用于订单产生和管理以促进决策问题的解决方案的设备和方法。在第一实施例中，一种系统包含配置成解决决策问题的多个层级层。每个层级 层配置成产生表示与决策问题相关联的子问题的可能解决方案的解决方案数据。每个层 级层还配置成接收订单并在产生解决方案数据期间使用订单。订单包含基于来自较高 层级层的解决方案数据的订单、基于来自较低层级层的反馈的订单和/或外来提供的订 单。在具体实施例中，每个层级层配置成使用订单简化对由那个层级层解决的子问 题的可能解决方案的搜索。例如可使用订单通过排除与订单不一致的解决方案来简化对 可能解决方案的搜索。在其它具体实施例中，至少一些层级层在不同时界(time horizon)上执行决策。在又一些具体实施例中，至少一个层级层还配置成基于由那个层级层接收的订 单产生导出订单。在又一些具体实施例中，订单包括确立在过程系统中执行的某些操作是初级还 是次级操作的订单。还有，层级层之一包含配置成产生第一提议的协调器，其中第一提 议标识特定操作是初级还是次级操作。层级层中的另一层包含配置成接收第一提议并使 用第一提议确定是否可基于第一提议解决与那个层级层相关联的子问题的协作器。协调 器还配置成当协作器指示不能基于第一提议解决子问题时产生第二提议。协调器调整哪 些操作是初级或是次级操作以产生第二提议。在附加具体实施例中，层级层包含在计算装置上运行的软件应用程序，其中计 算装置分布在过程控制系统中的多级。
在第二实施例中，一种方法包含在第一层级层接收订单，其中第一层级层配置 成使用订单解决与决策问题相关联的第一子问题。所述方法还包含产生表示第一子问题 的可能解决方案的第一解决方案数据，并输出第一解决方案数据。所述订单包含基于第 二解决方案数据的订单、基于反馈的订单和外来提供的订单。从配置成解决与决策问 题相关联的至少一个第二子问题的至少一个第二层级层接收第二解决方案数据和/或反 馈。在具 体实施例中，第一层级层接收的至少一个订单由用户提供。用户例如可提 交至少一个订单以指导决策问题的解决方案。在第三实施例中，在计算机可读介质上包含计算机程序。计算机程序包含用于 在第一层级层接收订单的计算机可读程序代码，其中所述订单与决策问题相关联。计算 机程序还包含用于使用订单产生第一解决方案数据来解决与决策问题相关联的第一子问 题的计算机可读程序代码。第一解决方案数据表示第一子问题的可能解决方案。计算机 程序还包含用于输出第一解决方案数据的计算机可读程序代码。所述订单包含基于第二 解决方案数据的订单、基于反馈的订单和/或外来提供的订单。从配置成解决与决策问 题相关联的至少一个第二子问题的至少一个第二层级层接收第二解决方案数据和/或反 馈。本领域的技术人员根据如下附图、说明书和权利要求书可容易地明白其它技术 特征。


为了更全面理解本公开，现在参考如下结合附图的说明书，附图中图1例证根据本公开的示例过程控制系统；以及图2至图5例证根据本公开用于订单产生和管理以促进生产调度或其它决策问题 的解决方案的示例技术。
具体实施例方式下面论述的图1至5以及在本专利文档中用于描述本发明原则的各种实施例仅作 为例证，并不应视为以任何方式限制本发明的范围。本领域技术人员将理解，本发明的 原则可用任何类型适当布置的装置或系统实现。本公开给出了用于订单管理的技术，其可用于帮助找到生产调度或其它决策问 题的解决方案。生产调度在企业、工厂或其它实体内经常是用于决策的非常重要的工 具。例如，生产调度经常是加工工业中制造商或其它人的必要或者期望的决策组件。作 为具体示例，对于从供给商接收原料、将那些原料经过某种程度的处理(诸如混合、反 应或分离)以产生产品库存并将处理的产品库存分发给客户或其它工厂同时管理中间库 存或阶段产品的工厂，经常需要生产调度。生产调度可涉及像计划(诸如确定到特定最后期限要生产的产品量)和调度(诸 如确定随着时间的过去将如何生产产品)的操作。生产调度解决起来经常是复杂的问 题，通常涉及大量的变量。这些变量可包含要生产的各种产品、要用于生产产品的工业 设备的各种部件以及要生产产品的各种最后期限。除了大量变量，在生产调度中还存在许多其它挑战。这些挑战可包含分为部分的或分散的调度系统的无缝整合、用户调度的 有效交互作用以及有关基础数学或优化模型(其表示正在调度的系统)的复杂性管理的综 合制度化。本公开在生产调度和其它决策问题中使用“订单”的概念，这可有助于解决 这些或其它类型的挑战。图1例证根据本公开的示例过程控制系统100。图1中所示的过程控制系统100 的实施例仅用于例证。可以使用过程控制系统100的其它实施例，并不脱离本公开的范围。在这个示例 实施例中，过程控制系统100包含促进至少一个产品或其它材料的 生产或处理的各种组件。例如，过程控制系统100在此用于促进对多个工厂IOla-IOln 中组件的控制。工厂IOla-IOln表示一个或多个处理设施(或其各部分)，诸如用于生产 至少一个产品或其它材料的一个或多个制造设施。一般而言，每个工厂IOla-IOln可实 现一个或多个过程，并且可单独或共同称为过程系统。过程系统一般可表示配置成以某 种方式处理一个或多个产品或其它材料的任何系统或其部分。在图1中，使用过程控制的普渡(Purdue)模型来实现过程控制系统100。在这 个模型中，“级0”可包含一个或多个传感器102a和一个或多个致动器102b。传感器 102a和致动器102b表示可执行各种功能中任何功能的过程系统中的组件。例如，传感器 102a可测量过程系统中的各种特性，诸如温度、压力或流率。再者，致动器102b可改变 过程系统中的各种特性，诸如加热器、电机或阀门。传感器102a和致动器102b可表示 任何适当过程系统中的任何其它或附加组件。每一个传感器102a包含用于测量过程系统 中一个或多个特性的任何适当结构。每一个致动器102b包含用于操作在过程系统中的条 件或影响它的任何适当结构。至少一个网络104耦合到传感器102a和致动器102b。网络104促进与传感器 102a和致动器102b的交互作用。例如，网络104可从传感器102a传输测量数据，并向 致动器102b提供控制信号。网络104可表示任何适当网络或网络的组合。作为具体示 例，网络104可表示以太网、电信号网(诸如HART或基础现场总线网)、气动控制信号 网络或任何其它或(一种或多种)附加类型的(一个或多个)网络。在普渡模型中，“级1”可包含一个或多个控制器106，这些控制器耦合到网络 104。其中，每个控制器106可使用来自一个或多个传感器102a的测量控制一个或多个 致动器102b的操作。例如，控制器106可从一个或多个传感器102a接收测量数据，并 使用测量数据产生用于一个或多个致动器102b的控制信号。每个控制器106包含任何 硬件、软件、固件或它们的组合以便与一个或多个传感器102a交互作用并控制一个或多 个致动器102b。每个控制器106例如可表示多变量控制器，诸如鲁棒多变量预测控制技 术(RMPCT)控制器或其它类型的控制器。作为具体示例，每个控制器106可表示运行 MICROSOFT WINDOWS操作系统的计算装置。两个网络108耦合到控制器106。网络108促进与控制器106的交互作用，诸 如通过向和从控制器106传输数据。网络108可表示任何适当网络或网络的组合。作为 具体示例，网络108可表示一对以太网或一对冗余以太网，诸如来自霍尼韦尔国际公司 (HONEYWELLINTERNATIONAL INC)的容错以太网(FTE)网络。至少一个交换机/防火墙110将网络108耦合到两个网络112。交换机/防火墙110可从一个网络向另一个传输业务。交换机/防火墙110还可阻止一个网络上的业 务到达另一个网络。交换机/防火墙110包含用于提供网络之间通信的任何适当结构， 诸如霍尼韦尔控制防火墙(HONEYWELL CONTROL FIREWALL) (CF9)装置。网络112 可表示任何适当的网络，诸如一对以太网或FTE网络。在普渡模型中，“级2”可包含耦合到网络112的一个或多个机器级控制器 114。机器级控制器114执行各种功能以支持可与工业设备(诸如锅炉或其它机器)的特 定部件相关联的控制器106、传感器102a和致动器102b的操作和控制。例如，机器级控 制器114可记录由控制器106收集或产生的信息，诸如来自传感器102a的测量数据或用 于致动器102b的控制信号。机器级控制器114还可执行控制控制器106的操作的应用程 序，由此控制致动器102b的操作。此外，机器级控制器114可向控制器106提供安全访 问。每一个机器级控制器114都包含任何硬件、软件、固件或它们的组合，以便提供与 机器或设备的其它各个部件相关的访问、控制或操作。每一个机器级控制器114例如可 表示运行MICROSOFT WINDOWS操作系统的服务器计算装置。尽管未示出，但可使用 不同的机器级控制器114来控制过程系统中设备的不同部件(其中设备的每个部件都与一 个或多个控制器106、传感器102a和致动器102b相关联)。一个或多个操作员站116耦合到网络112。操作员站116表示向机器级控制器 114提供用户访问的计算或通信装置，控制器114然后可向控制器106(或可能向传感器 102a和致动器102b)提供用户访问。作为具体示例，操作员站116可允许用户使用由控 制器106和/或机器级控制器114收集的信息查看传感器102a和致动器102b的操作历 史。操作员站116还可允许用户调整传感器102a、致动器102b、控制器106或机器级控 制器114的操作。此外，操作员站116可接收和显示由控制器106或机器级控制器114 产生的报警、警告或其它消息或显示。每一个操作员站116包含任何硬件、软件、固件 或它们的组合，以便支持用户访问和系统100的控制。每一个操作员站116例如可表示 运行MICROSOFT WINDOWS操作系统的计算装置。至少一个路由器/防火墙118将网络112耦合到两个网络120。路由器/防火墙 118包含用于提供网络之间通信的任何适当结构，诸如安全路由器或路由器/防火墙的组 合。网络120可表示任何适当的网络，诸如一对以太网或FTE网络。在普渡模型中，“级3”可包含耦合到网络120的一个或多个单元级控制器 122。每个单元级控制器122通常与过程系统中的单元相关联，其表示一起操作以实现至 少部分过程的不同机器的集合。单元级控制器122执行各种功能以支持较低级中组件的 操作和控制。例如，单元级控制器122可记录由较低级中组件收集或产生的信息，执行 控制较低级中组件的应用程序并向较低级中组件提供安全访问。每一个单元级控制器122 包含任何硬件、软件、固件或它们的组合以便提供与多个机器或加工单元中设备的其它 部件相关的访问、控制或操作。每一个单元级控制器122例如可表示运行MICROSOFT WINDOWS操作系统的服务器计算装置。尽管未示出，但可使用不同的单元级控制器 122控制过程系统中的不同单元(其中每个单元与一个或多个机器级控制器114、控制器 106、传感器102a和致动器102b相关联)。对单元级控制器122的访问可由一个或多个操作员站124提供。每一个操作员 站124包含任何硬件、软件、固件或它们的组合以便支持用户访问和系统100的控制。每一个操作员站124例如可表示运行MICROSOFT WINDOWS操作系统的计算装置。至少一个路由器/防火墙126将网络120耦合到两个网络128。路由器/防火墙 126包含用于提供网络之间通信的任何适当结构，诸如安全路由器或路由器/防火墙的组 合。网络128可表示任何适当的网络，诸如一对以太网或FTE网络。在普渡模 型中，“级4”可包含耦合到网络128的一个或多个厂级控制器130。 每个厂级控制器130通常与工厂IOla-IOln之一相关联，工厂可包含实现相同、相似或不 同过程的一个或多个加工单元。厂级控制器130执行各种功能以支持较低级中组件的操 作和控制。作为具体示例，厂级控制器130可执行一个或多个制造执行系统(MES)应用 程序、调度应用程序或者其它或附加工厂或过程控制应用程序。每一个厂级控制器130 包含任何硬件、软件、固件或它们的组合以便提供与加工厂中一个或多个加工单元相关 的访问、控制或操作。每一个厂级控制器130例如可表示运行MICROSOFT WINDOWS 操作系统的服务器计算装置。对厂级控制器130的访问可由一个或多个操作员站132提供。每一个操作员站 132包含任何硬件、软件、固件或它们的组合以便支持用户访问和系统100的控制。每一 个操作员站132例如可表示运行MICROSOFT WINDOWS操作系统的计算装置。至少一个路由器/防火墙134将网络128耦合到一个或多个网络136。路由器/ 防火墙126包含用于提供网络之间通信的任何适当结构，诸如安全路由器或路由器/防火 墙的组合。网络136可表示任何适当的网络，诸如企业用(enterprise-wide)的以太网或 其它网络或者更大网络(诸如因特网)的全部或部分。在普渡模型中，“级5”可包含耦合到网络136的一个或多个企业级控制 器138。每个企业级控制器138通常能够执行工厂IOla-IOln的计划操作并控制工厂 IOla-IOln的各个方面。企业级控制器138执行各种功能以支持工厂IOla-IOln中组件的 操作和控制。作为具体示例，企业级控制器138可执行一个或多个订单处理应用程序、 企业资源计划(ERP)应用程序、先进计划和调度(APS)应用程序或者任何其它或附加的 企业控制应用程序。每一个企业级控制器138包含任何硬件、软件、固件或它们的组合 以便提供与多个工厂的控制相关的访问、控制或操作。每一个企业级控制器138例如可 表示运行MICROSOFTWINDOWS操作系统的服务器计算装置。对企业级控制器138的访问可由一个或多个操作员站140提供。每一个操作员 站140包含任何硬件、软件、固件或它们的组合以便支持用户访问和系统100的控制。每 一个操作员站140例如可表示运行MICROSOFT WINDOWS操作系统的计算装置。在这个示例中，历史存储器(historian) 141还耦合到网络136。历史存储器141 可表示存储关于过程控制系统100的各种信息的组件。历史存储器141例如可存储在生 产调度问题解决和其它决策问题解决期间所用的信息(如下面更详细描述的)。历史存储 器141表示用于存储和促进信息检索的任何适当组件。尽管显示为耦合到网络136的单 个集中式组件，但是历史存储器141可位于系统100中的别处，或者多个历史存储器可分 布在系统100中的不同位置。在具体实施例中，图1中的各种控制器和操作员站可表示计算装置。例如，每 一个控制器可包含一个或多个处理器142和用于存储由(一个或多个)处理器142使用、 产生或收集的命令和数据的一个或多个存储器144。每一个服务器还可包含至少一个网络接口 146，诸如一个或多个以太网接口。再者，每一个操作员站可包含一个或多个处理器 148和用于存储由(一个或多个)处理器148使用、产生或收集的命令和数据的一个或多 个存储器150。每一个操作员站还可包含至少一个网络接口 152，诸如一个或多个以太网
接口。
在操作的一个方面，一个或多个复杂决策问题可能需要发生在过程控制系统100 的各个部分中(或遍布整个过程控制系统100)。例如，生产调度操作可能需要由企业级 控制器138、厂级控制器130或过程控制系统100中的任何其它控制器执行。为了支持找到生产调度或其它决策问题的解决方案，过程控制系统100中的一 个或多个组件包含层级问题解决应用程序154。问题解决应用程序154可表示系统100的 不同组件中的不同功能。例如，在下面更详细描述的，要解决的生产调度问题可分解成 不同元素的层级，每个元素可执行不同功能以帮助解决总的生产调度问题。相同类型的 分解可类似地用于解决许多问题。这样，问题解决应用程序154支持使用分解作为处理 要解决的大的或复杂问题的方式。下面提供有关问题解决应用程序154的附加详情。问 题解决应用程序154包含任何适当硬件、软件、固件或它们的组合以便执行与标识要解 决的生产调度或其它问题的解决方案相关的一个或多个功能。尽管图1例证了过程控制系统100的一个示例，但是可对图1进行各种改变。 例如，控制系统可包含任何数量的传感器、致动器、控制器、服务器、操作员站、网络 和生产调度或其它应用程序。再者，图1中的过程控制系统100的组成和布置仅用于例 证。根据具体需要可在任何其它适当配置中添加、省略、组合或放置组件。此外，图1 例证了可使用生产调度或其它问题解决的一个操作环境。这种功能性可用在任何其它适 当装置或系统中(不管是否与过程控制有关)。图2至5例证了根据本公开用于订单产生和管理以促进生产调度或其它决策问题 的解决方案的示例技术。下面提供的有关订单产生和管理的详情仅用于例证。可以在不 脱离本公开的范围的情况下使用其它订单产生和管理技术。再者，虽然下面相对于解决 生产调度问题描述了订单产生和管理技术，但是相同或相似技术可用于解决其它类型的 问题。在生产调度期间进行决策经常可与各种问题相关，诸如·定大小应该处理和存储多少材料；·分配应该在哪并且应该处理和存储什么材料；·定序处理期间应该遵循哪个系列的操作；以及·定时应该何时处理材料。这些判定经常依赖于是静态的信息和/或是动态的信息。静态信息可对应于过 程系统的固定特性或属性，并可包含诸如配置数据(像定大小、定时和规定)、连接性数 据和兼容性数据的信息。静态信息可统称为“模型数据”。动态信息可包含在调度时界 期间或在时界内的一个或多个循环期间可改变的特性。作为动态信息的示例，在调度时 界期间可存在以不同到达时间的相同原料的几个收到。在调度时界期间可存在以不同离 开时间的相同产品库存的几个装运。动态信息可统称为“循环数据”，因为它可根据某 单个或重复循环随时间变化(尽管这并不要求)。本公开中提供的订单管理技术基于“订单”的概念。订单一般表示在将来某时要执行的时间序列或交易需求。在生产调度或其它决策问题中使用订单可提供各种好 处，诸如以下好处。第一，订单可使在企业中能够整合各种决策层。第二，订单可有助 于增大模型的透明度以及调度的所有权或终端用户的其它解决方案。第三，订单可帮助 简化和管理生产调度或其它问题。具体地说，订单可通过允许在优化时固定、禁止或释 放连续和/或二进制变量来帮助组织和处理解决生产调度或其它问题中的数学复杂性。 这例如可有益于混合整数线性编程(MILP)或连续线性编程(SLP)。层级决策层经常存在于企业或其它组织中，并可用于帮助解决复杂生产调度或 其它问题。图2示出了示例层级，其例证具有四层202-208的层级200。这些层包含较 长期策略和战术计划层202、较短期操作调度层204、先进过程控制和优化层206以及过 程控制层208。在图1的系统100中可支持这种类型的层级200，诸如当普渡模型的不同 级对应于层级200的不同级时。作为具体示例，较长期策略和战术计划层202可实现在 普渡模型的“级5”中(诸如在控制器138中)，而其余层204-208可实现在普渡模型的 较低级中(诸如在控制器130、122、114中)。在这些实施例中，图1中各种组件中的问 题解决应用程序154可实现或支持图2中所示的层202-208。可能要注意，虽然图2中示出了每层202-208的单个实例，但是每层实际上可涉 及多个装置上的多个组件。例如，较长期策略和战术计划层202可实现在企业级控制器 138中。多个较短期操作调度层204、先进过程控制和优化层206以及过程控制层208可 实现在不同工厂IOla-IOln中的控制器内。这样，层级200可表示在过程控制系统100 或其它系统内的各种组件中使用的分布式层级。这些层202-208中的每层经常都能影响生产调度。显然，在随着时间计划和调 度产品生产中直接涉及上层202-204，因此这些层202-204明显影响生产调度。然而，甚 至下层206-208也能影响生产调度，诸如当下层206-208的决策影响过程系统中的存货水 平时。层级200中的每一层202-208通常都涉及与其操作相关的不同调度时界或时间周 期。层202中的较长期策略和战术计划经常在周、月或年的时界上进行。层204中的较 短期操作调度经常在时、日或周的时界上进行。层206中的先进过程控制和优化经常在 秒、分或时的时界上进行。层208中的过程控制经常在亚秒、秒或分的时界上进行。在分布式生产调度或其它问题解决期间，在确立企业的可行生产调度或其它解 决方案时可涉及层级200中的所有各种层202-208。在这种类型的层级200中，下层经常 包含更复杂的微模型或分子模型，但是上层包含宏模型。结果，在生产调度或其它问题 解决期间，经常需要或期望对于下层考虑较短的时界，使得可在合理的计算时间内(诸 如实时或接近实时)解决问题。如果孤立执行，则图2的层级200中的每层202-208有可能产生与其它层的决策 不一致的结果。因为这个，孤立执行层202-208通常导致产生不可行的(多个)解决方 案，如果它可行，则导致总体性能损耗(诸如由于资源的优化过度和优化不足引起的)。为了支持更有效的分布式生产调度或其它问题解决，图2的层级200中的每层 202-208互连到具有各种前馈和反馈机制的其相邻层。例如，如图2中所示，每一层 202-206 一般接收模型数据和循环数据。模型数据表示对应于过程系统固定特性或属性 的静态信息。循环数据采取订单的形式。层202-208接收的订单可包含外来定义的订单(诸如由用户或外部系统提供的订单)，它们在图2中表示为“订单(将来)”。层 204-208接收的订单还可包含基于来自前一层的解决方案数据的订单。解决方案数据表 示由前一层解决的决策子问题的解决方案(在这个示例中是由前一层产生的生产调度子 问题的解决方案)。层202-206接收的订单还可包含基于来自后一层的反馈的订单。这 样，层级200中的决策层202-208之间的整合可使用图2中所示的订单形式化实现。这 可使在层级200中能够进行更有效的生产调度或其它问题解决。订单还可用在单层内。例如，在例证的实施例中，过程控制层208被分解成或 分成构成组件(即加工、操作和维护组件)。这可以是适当的，因为生产设置经常包含具 有技术人员和专用工具的加工、操作和维护部门。这些不同部门之间的交互作用可采用 订单的概念，诸如安全订单、工作订单、维护订单和购买订单(只举几个例子)。除了促进层级200中的层202-208的整合，可使用订单增大对用户的生产调度或 其它问题的透明度和控制。同时，订单还增大了调度或其它解决方案的可说明性的用户 的感觉。用户能够与决策解决方案交互作用或将决策解决方案“转向”他们的需要。由 于订单可由用户以及从其它系统外来放置订单，所以可以应用过程系统的用户的更详细 知识，这可大大影响和操纵解决方案。而且，可通过插入适当的订单移除生产调度或其它问题中的大量退化。例如， 退化增大了问题的搜索空间或范围，并因此潜在地减慢了找到调度或其它解决方案的时 间。这在MILP核心进行分支限界或隐式枚举搜索中可能特别真实。一个简单示例是具 有并行的两个同样和专用单元的过程，其中如果考虑到生产要求，仅单个单元在整个调 度时界都是必须的。如果放置禁止其中一个单元在调度时界期间分配的订单，则在整个 调度时界的分配判定是无足轻重的，因为仅一个单元操作起来是自由的(其是用户选择 的那个)。在某种意义上，订单可用作“对称断路器”以消耗调度或其它问题中的自由 度。此外，调度和其它类型的问题实质上可能是组合的，并因此经常表示非常具有 挑战性的优化问题。通过在问题被解决之前从问题中移除某些逻辑判定变量可大大减小 调度或其它问题的大小或复杂性。换句话说，可通过排除与订单不一致的解决方案来使 用订单简化问题。作为简单示例，假设可以使用设备的两个部件来加工材料，但是用户 发起在整个调度时界占用部件之一的订单(其可以进行以使得能够执行维护)。这简化了 任何其余订单的调度问题，因为所有订单都必须在调度时界期间在设备的一个其余部件 上进行调度。将排除依赖于设备的两个部件的调度问题的任何可能解决方案。图3例证了用于解决生产调度问题的示例方法300。相对于图2中示出的层级 200例证和描述方法300。然而，方法300可容易地修改用于任何其它适当层级的生产调 度或其它决策系统中。如在图3中所示，在步骤302，在较长期计划层接收数据。这例 如可包含在较 长期策略和战术计划层202接收模型数据和循环数据。模型数据可表示静态数据，而循 环数据可包含各种订单。下面提供由层级中的各种层接收、产生和使用的订单类型的示 例。在步骤304，较长期计划层使用数据来产生表示较长期计划的解决方案数据。这例 如可包含较长期策略和战术计划层202确定在相对比较长的调度时界上产生的产品量。 作为简单示例，较长期策略和战术计划层202可以确定，在一个月中需要生产100个单位的产品，并在后一个月中需要生产150个单位的产品。在此产生的解决方案数据表示正 在解决的总体调度问题的子集或部分。在步骤306，在较短期调度层接收数据，并且在步骤308，使用数据产生表示较 短期调度的解决方案数据。这例如可包含在较短期可操作调度层204接收模型数据和循 环数据。循环数据可包含基于来自较长期策略和战术计划层202的解决方案数据的订 单。这还可包含较短期可操作调度层204确定用于在给定时间周期内或规定最后期限 内产生规定量产品的调度。如上面提到的，这个步骤可涉及多个组件操作在多个工厂 IOla-IOln,允许调度以企业级方式发生。 在步骤310，在先进过程控制(APC)和优化层接收数据，并且在步骤312，使 用数据产生表示控制和优化目标的解决方案数据。这例如可包含在先进过程控制和优化 层206接收模型数据和循环数据。循环数据可包含基于来自较短期可操作调度层204的 解决方案数据的订单。这还可包含先进过程控制和优化层206确定如何基于接收的数据 控制和优化工业设备的操作。如上面提到的，这个步骤可涉及多个组件操作在多个工厂 IOla-IOln,允许对企业进行先进过程控制和优化。在步骤314，在过程控制层接收数据，并且在步骤316，使用数据产生表示控制 信号的解决方案数据。这例如可包含在过程控制层208接收模型数据和循环数据。循环 数据可包含基于来自先进过程控制和优化层206的解决方案数据的订单。这还可包含过 程控制层208确定如何基于接收的数据控制工业设备。在步骤318，可向上层提供反馈。反馈例如可来自过程控制层208，并被提供 给其它层202-206。反馈可根据反馈目的地而改变。例如，到两个上层202-204的反馈 可包含当前存货水平，而提供给层206的反馈可包含从工业设备获得的测量数据。反馈 可采取订单的形式，其还可由上层202-206进一步处理以产生新的或修订的解决方案数 据。在这点，可重复方法300，诸如通过返回到步骤302以基于来自过程控制层208的反 馈处理订单。这样，生产调度或其它问题可被分成层级层，并分布在控制系统或其它系统 内。还有，使用订单可帮助形式化层级200中层202-208的整合，使层202-208能够协 作，并更高效而有效地将解决方案定位于生产调度或其它问题。下面描述在层级200中可使用的一些类型的订单。在这个讨论中，使用单元操 作端口状态超结构(UOPSS)和数量逻辑质量范例(QLQP)表示或形式化生产调度或其它 问题的复杂性。这个建模框架的核心观点是将设备或机器表示为单元、将任务或活动表 示为操作、将单元上的进口流和出口流表示为端口并将状态表示为任何种类的资源(诸 如库存、设施、工具或劳动力)。可以各种方式表示系统中的量，诸如装料大小、批量大 小和批大小。可以各种方式表示系统中的逻辑，诸如起动、设置、切换和关闭。可以各 种方式表示系统中的质量，诸如成分、属性和条件。订单可分配给这些目标中的任何目标或与之相关联(单元中的任何量、逻辑或 质量、操作、端口和状态)。订单其特征还可在于起始时间或开始时间和结束时间或完成 时间。然后可使用订单通过按照判定变量限制和约束对问题施加要求来操纵或整理调度 或其它问题的解决方案。如上面提到的，如果系统属性、特性或参数从调度的开始到结束都具有恒定值，并且不 改变，或者在时界内是不变的，则它被认为是其自身基础模型的一部分，并 归类为模型数据。在调度时界内改变的信息被称为循环数据。订单通常是循环数据的 一部分，因为它们用定时来定义。在一些实施例中，订单可归类为原子、聚集和汇编订单。原子订单(atomic order)表示与单个单元、操作、端口或状态相关联的订单。原 子订单可分类成量、逻辑或质量订单。量订单与表示资源的定大小量诸如流、流率、滞 留量(holdup)和产量的变量相关联。流、流率和滞留量可以是外延变量，并可用系统的 总大小定标。产量可以是量的集中表示。逻辑订单是指工厂或企业中的逻辑判定，并可 由二进制判定(诸如开/关、是/否、打开/闭合或活动/不活动)定义。逻辑订单可包 含模式订单(用于分散流路径单元)、材料订单(用于收敛流路径单元)和移动订单(用 于在附于单元的端口之间的移动)。质量订单是指资源的规范，诸如其集中成分、属性和 条件。单元操作上的过程或操作条件(诸如温度或压力)也可在质量订单中考虑(诸如 当订单在明天中午开始两个小时内将反应器温度保持到500°C )。汇聚订单(aggregated order)表示在相同UOPSS维度内原子订单的集合或汇聚。 换句话说，原子订单的汇聚可在一维(单元、操作、端口或状态)执行，诸如在具有相同 操作的单元上或在同一单元操作上但在不同时间周期上执行。汇聚订单还可归类为基于 量、逻辑或质量。具体操作维度上的聚合量订单的一个示例是确立在特定材料操作或服 务中在几个油箱单元上总滞留量的上下限。更特定的示例是当聚合量订单用于限制炼油 厂的所有油箱单元中普通汽油的总量时，其可由于短时(fugitive)排放约束引起。如果在不同UOPSS维度上进行订单的组合，则产生汇编订单(assembled order)。汇编订单的示例是市场订单(供给和需求)，它们是具有模式订单(逻辑订单) 的流订单(量订单)的聚集，并且如果需要的话，还有成分订单和/或性质订单(质量订 单)。汇编订单的其它示例是维护订单(其中单元在时界期间的给定量时间内不可用)、 移动订单(确立给定操作模式中单元端口之间的流)以及排序订单(确立用户所规定的各 个单元上的模式/材料操作的序列或顺序)。排序订单可特别用于操作为流水车间或多产 品/多阶段布置的工厂部分。一旦这些各种类型订单被提供给层级200或在其中创建了，用户就可确定调度 或优化系统(使用层202-208实现的)应该响应于订单的方式。例如，当解决调度时， 可能需要调度或优化系统满足某些订单(称为“普通订单”)。普通订单可包含需要在 规定时界期间实施的原子、聚集或汇编订单。还存在“可选订单”，它们表示订单组、 集合或集(在规定时界期间从其中仅实施组、集合或集的子集)。在MILP中，可选订单 可通过创建每个可选订单的额外二进制变量并结合对这些额外二进制变量的单用或多用 基数约束以确保仅选择一个或有限数量的可选订单来实现。由此，可能存在与在基数约 束中规定的一样多的从一组可选订单实施的订单。在这种情形下，调度或优化系统可从 订单池中选择几个订单以在搜索解决方案期间实现。可选订单因此相当于管理捷径，因 为它们在隐式枚举搜索期间被加到问题上或从问题中移除。它还有可能用于经称为订单导出的过程根据其它订单创建层202-208中的各种 类型的订单。一种类型的导出订单(称为“获得的订单”)可从层202-208中的模型和 循环数据中导出。用这些类型订单，有可能从不排除调度或其它问题的全局优化解决方案的无关的用户规定的普通订单自动产生相关的普通订单。这可通过将数学导出原理与 UOPSS超结构定义的数据导航模型组合来进行。换句话说，所获得的订单(相关订单) 对应于从可应用于原始问题以便减少对解决方案搜索努力的模型和循环数据导出的有效 捷径(或不等量)。下面给出获得的订单的一些示例。·从普通市场订单产 生的获得的模式订单当市场订单存在时，可在邻近对于 订单的相同持续时间创建订单的单元的单元上产生模式订单。这些获得的模式订单例如 可通过将与模式操作相关联的二进制变量固定到值一(用于现有市场订单)或通过将与相 邻单元上的所有其它模式操作相关联的二进制变量固定到O (用于当不存在市场订单时的 补充情形)来实现。·从普通市场订单产生的获得的排序订单市场订单可具有顺序出厂日期和到 期日(最后期限)，意思是市场订单的出厂日期晚于之前市场订单的到期日。如果这是真 实的，则可对于作为市场订单的结果运送(空运/船运)材料的上游或下游单元确立获得 的排序订单。排序订单对应于确立在具体单元上的模式操作的序列或订单，无需确立单 元将在那些模式操作中的时间，允许适当地同步吞吐量和存货量的协调。·从普通维护订单产生的获得的维护订单在单元具有对于给定时间周期定 义的维护订单的情况下，这个单元的任何单元直接上游和下游不能向/从那个单元流材 料。因此，也可对于这些相邻单元创建获得的维护订单。·从普通模式订单产生的获得的模式订单在某些情况下，在给定单元上的模 式操作定义在几个上游和下游单元上的操作模式。这例如可以是每个产品库存遵守批量 单元中的特定处理顺序(也称为配方)的批量加工工业中的情况。因此，在存在没有中 间存储器或“零等待”的一系列固定处理时间批量单元的生产环境中，如果模式订单放 在给定批量单元上，则批量行(一行批量单元)中的所有单元也都可使它们的模式操作 得以确定。在这种情况下，可在适当时间对于在批量行中涉及的单元创建获得的模式订 单。如果存在并行批量单元，则可产生获得的模式订单，除了与上游和下游单元模式订 单相关联的操作，它们不允许任何模式操作。这暗示，如果并行单元之一要起动，则它 可能仅处于与相邻单元一致的模式操作。·从普通性质订单(property order)产生的获得的模式订单如果在单元上的给 定模式操作具有位于质量订单以外的规定的性质上下限，则这个模式操作可在性质订单 的持续时间内从解决方案搜索中排除(诸如通过将模式二进制变量设置为零)。·从普通移动订单产生的获得的模式订单如果移动订单具有零量或者如果维 护订单放在两个端口之间的连接上，则可对于相邻单元在普通移动订单的持续时间内产 生获得的维护订单。可能要注意，可以迭代方式导出获得的订单。例如，在第一迭代中，可产生普 通订单，其对应于放在系统中的外延用户定义的订单。在第二迭代中，来自前一迭代的 获得的订单可被加到普通订单集中，并且从所有(老和新)普通订单集导出新获得的订 单。这个迭代过程可继续，直到所有可能的获得的订单都已经被加到系统(诸如当对于 特定迭代所产生的获得的订单数为零时)。在具体实施例中，在服务定向体系结构(SOA) 的上下文中，获得的订单可实现为中央订单数据服务。在这种类型框架中，获得的订单 “服务”将接收模型和循环数据作为输入，并在处理之后服务将输出在随后的优化中要用的获得的订单。 另一种类型的导出订单(称为“编排的订单”)可从层204-208中的解决方案数 据中导出。在调度时界期间，可能存在通常在正常环境下不希望出现在调度或其它解决 方案中的在单元上的模式操作或材料操作。例如，果汁处理工厂可能在具体调度循环期 间仅接收葡萄汁的市场订单，这可能不是常规的。果汁混合器单元因此可能在那个循环 期间仅预期使用葡萄汁材料操作进行操作。可能不需要在混合器单元上进行苹果汁材料 操作，因为不存在将要生产苹果汁的可能性。在这种情况下，特定单元上的某些材料操 作可标记或指定为初级(主要)材料操作(诸如混合器单元上的葡萄汁材料操作)，而其 它材料操作可标记为次级(次要)材料操作(诸如苹果汁或梨汁材料操作)。可能要注 意，一个调度循环中的初级材料操作可指定为另一个循环中的次级材料操作，取决于配 置用于所讨论的循环的订单。这表明，获得的订单的另一个示例是例如作为普通市场订 单的函数向单元上的模式/材料/移动操作自动分配初级或次级标记。这些类型的导出 订单被称为编排订单。编排订单背后的一般想法是，仅通过在每个问题解决迭代使单元上的几个模 式/材料/移动操作使能或自由，而其余操作被设置成预先规定的固定值，来降低调度 或其它问题的复杂性。如果正确进行了初级和次级操作的分配，则编排订单可在小数 量迭代中产生可行调度(但是这不一定要保证，诸如对于组合和非凸问题(non-convex problem))。如上面提到的，从部分问题解决方案的解决方案数据中产生编排订单。解决方 案数据可对应于无效捷径，其有希望引导解决方案搜索或用户到达有用的局部优选解决 方案(其目标函数可能没有最佳可能解决方案那么好但在合理的时间找到并具有合理质 量的解决方案)。在MILP中应用编排订单的一个优点是，在每次MILP迭代，问题大小 都减小了，从而降低了问题的复杂性，并由此减少了找到整数可行解决方案的时间。可使用图4中所示的框架说明编排订单。在图4中，要解决的复杂问题(诸如 生产调度问题)被分解成层级分解400。在这个示例中个，层级分解400包含协调层402 和协作/合作层404。可关于层404使用术语“协作”，当层404中的元素没有彼此的任 何知识时，诸如当元素与信息透视完全分开时。当层404中的元素可交换与正在解决的 问题相关的至少一些信息时，可关于层404使用术语“合作”。图4中的两个层402-404 可表示图2中所示的任何两个相邻层或其它层，其中层正在使用编排订单。当解决问题时协调层402 —般可负责较高级功能，而当解决问题时协作/合作层 404—般可负责较低级功能。例如，协调层402可用于向编排订单分配初级和次级操作， 并且协作/合作层404可用于确定那些分配是否使能够找到可行生产调度或其它解决方 案。在如下论述中，协调层402中的组件一般可称为协调器406，并且协作/合作层404 中的组件一般可称为协作器408。再者，协调器406和协作器408在它们的操作期间分别 可使用模型410和412。模型一般表示与正在解决的问题相关联的一个或多个系统。例 如，模型410可表示更大量过程系统和/或更大部分过程系统，并且模型412可表示各个 过程系统和/或更小部分过程系统。可能要注意，协作器408还可用作协作器406，诸如 当层204中的协作器充当层206中另一个协作器的协调器时。协调器406和协作器408可如图5中所示操作以支持编排订单的使用。在图5中，方法500包含在步骤502协调器禁止使用次级模式操作。这例如可包含协调器406阻 止次级模式操作形成部分调度或其它解决方案。在MILP的情况下，这可以转换成将次 级操作的所有操作二进制变量设置成零，或通过放松那些二进制变量使得它们变成0与1 的边界内的连续变量。这样，协调器406最初尝试将模式操作限于初级模式操作。
在步骤504，协调器向至少一个协作器提供提议。提议表示协调器406正在解 决的问题的可能解决方案(其中协调器问题是使用分解400正在解决的一般问题的子问 题)。在这个示例中，这可包含协调器406向单个协作器408发送模式、材料和移动订 单，规定仅初级操作在解决方案可以是活动的。这些模式、材料和移动订单可表示从图 2中的一层传到另一层的解决方案数据。然后在步骤506解决协作器问题。这例如可包含协作器408使用来自协调器406 的订单解决生产调度或其它子问题。如果协作器问题用可行解决方案解决了，则方法500 结束。在这点，可仅使用初级模式操作产生可行调度或其它解决方案。如果协作器问题不可行(意思是使用提议无法找到解决方案)，则在步骤510， 在协调器处从协作器接收任何解决方案和相关联的不可行性。不可行性标识协作器408 没有任何能力满足由协调器406规定的要求。不可行性因此指示来自协调器406的提议 是否已经由协作器408接受。注意，当找到可行解决方案时，不可行性可设置成0。在步骤512，协调器决定如何按照不可行性修订提议。这例如可包含协调器406 接收模式、材料或移动发生事件，它们定义如何不可能满足模式、材料或移动订单。发 生事件可参考协作器408的相关解决方案数据。通过决策和操纵，协调器406然后可产 生另一个提议。作为具体示例，协调器406可决定对于方法500的下一迭代，哪些初级 和次级操作将禁止，以及哪些初级操作将是自由的。在步骤504，作为这个决定的结果， 从发生事件产生附加模式、材料和移动订单，并使用这些订单形成另一个提议，其被发 送到协作器。方法500可继续，直到协作器找到一个或多个可行解决方案，或者直到达 到时间到时。注意，可以使用任何适当的技术确定在方法500的下一迭代中允许哪些初 级和次级模式操作。任何类型的订单与问题的循环数据的结合都可大大降低其复杂性并增大其可理 解性，因为实质上变量的值是固定的或禁止的。当然，通过将操作归类或分类为初级和 次级，并使用上面描述的编排订单算法，可以在ω解决包含单元上所有操作的潜在大问 题或(ω解决几次较小问题之间进行折中。这种折中可逐情况进行评估。虽然以上描述已经描述了各种类型订单的产生和使用，但是可以任何适当方式 存储与订单相关联的信息(称为订单存货)并在各级间进行交换(称为订单互换)。在生 产调度以及其它工业决策问题中，分布式多协作器/合作器环境是非常普遍的。这种分 散可能发生，因为沿这三个维度管理系统的复杂性、不确定性和层级，这三个维度可涉 及巨大量的交互和强度。企业可能具有任何数量的计划员和调度员，他们基于不同的刺 激并对于工厂或企业的不同部门，决定不同的策略。可能还存在可变程度的交叠、交叉 或共同性，具有或没有总协调器。因此，可能重要的是设计一种方法或策略来按照订单 管理处理这些交叠。就像模型、循环和解决方案数据的情况一样，可以许多不同的方式存储订 单或进行数据银行(data-banked)存储。这些可包含使用数据库(诸如ORACLE、SQLSERVER或SYBASE数据库)、数据书(诸如一组电子表格)或数据块(诸如文件 夹)。这些结构中的任何结构都可集中化(诸如在历史存储器141中)或分散和分布在整 个过程控制系统100或其它系统。订单存货因此可以及时、准确而容易地为相关用户得 至IJ。再者，可以适当地允许通过定义谁能够添加、删除和更新信息来保护和保证数据的 安全。订单存货还可用于提供历史化和保持力级别，从那可以执行连续改进或计划执行 完美研究，以提高系统的总体经济性、高效性和有效性。订单互换可用于促进层级200中层202-208之间的订单传送。订单互换可对 应于用订单“填充”数据库和“描绘”订单的数据库的过程。这例如可根据通常在供 给、生产和需求链中发现的材料 流路径概念进行。层级中的每个元素可具有检索相关 订单、审查订单的不一致性、如果可能的话产生其它内部订单并向适当的数据库发送订 单(如果存在几个分布式数据库而不是一个集中式数据库的话)的责任，使得实现订单 的共享。这种填充和绘制或互换订单也可类似于系统中涉及的各种用户之间的前馈和反 馈。例如，另一个工厂的原料工厂下游的供给市场订单可具有上游工厂的对应需求市场 订单。两个工厂都可以接收这个信息作为前馈，但是如果一个或两个工厂在所需的时间 不能装运或接收所需量和质量的存货，则发出反馈信息(诸如障碍物、减量(outage)和分 离物(outlier))，使得在层级200中的两个元素之间实现某种可接受级别的可行性、一致 性或和谐性。尽管图2至图5例证了用于订单产生和管理以促进生产调度或其它决策问题的解 决方案的技术的一个示例，但是可以对图2至5进行各种改变。例如，虽然图2中示出了 四层，但是生产调度或其它决策问题可涉及任何适当数量的层级层。再者，层级200中 的每一层都可接收任何适当的输入，并产生任何适当的输出(例如，一层不可能接收外 来定义的订单、反馈和解决方案数据所有这三个)。再者，虽然仅示出反馈从最低层208 到其它层202-206，但是反馈可从任何(多个)下层被提供给任何(多个)上层。另外， 虽然图3和5例证了具有序列步骤的方法，但是图3和5中的各个步骤可以交叠，并行发 生，以不同顺序发生，或发生任何适当数量的次数。此外，图4中的层级分解400可包 含任何数量和类型的协调器和协作器。在一些实施例中，由计算机可读程序代码组成并包含在计算机可读介质中的计 算机程序实现或支持上述各种功能。短语“计算机可读程序代码”包含任何类型的计算 机代码，包括源代码、目标代码和可执行代码。短语“计算机可读介质”包含能够由计 算机存取的任何类型的介质，诸如只读存储器(ROM)、随机存取存储器(RAM)、硬盘 驱动器、压缩盘(CD)、数字视频盘(DVD)或任何其它类型的存储器。可能有利的是，阐述本专利文档通篇使用的某些词语和短语的定义。术语“耦 合”及其衍生词是指两个或更多元件之间的任何直接或间接通信，不管那些元件是否彼 此物理接触。术语“应用程序”和“程序”是指一个或多个计算机程序、软件组件、订 单集、过程、功能、对象、类、实例、相关数据或其适合于用适当计算机代码(包括源 代码、对象代码或可执行代码)实现的部分。术语“发射”、“接收”和“通信”以 及它们的衍生词涵盖直接和间接通信。术语“包含”和“包括”以及它们的衍生词意 思是包括但不限于。术语“或”是包含，意思是和/或。短语“与之关联”和“与其 关联”以及它们的衍生词可以是指包含、包含在内、与之互连、含有、含在内、连接到或与之连接、耦 合到或与之耦合、可与之通信、与之协作、交织、并置、接近、绑定到 或与之绑定、具有、具有...属性等等。术语“控制器”是指控制至少一个操作的任何 装置、系统或其部分。控制器可以用硬件、软件、固件或它们中至少两个的某种组合来 实现。与任何具体控制器相关联的功能性可以是集中式或分布式的，无论是本地还是远程。 虽然本公开已经描述了某些实施例以及一般相关联的方法，但是本领域技术人 员将明白这些实施例和方法的变化和改变。从而，示例实施例的以上描述不定义或限制 本公开。其它改变、替换和变化也是可能的，并不脱离由如下权利要求书定义的本公开 的精神和范围。
权利要求
1.一种系统，包括多个层级层(202-208)，配置成解决决策问题；其中每个层级层配置成产生表示与所述决策问题相关联的子问题的可能解决方案的 解决方案数据；并且其中每个层级层配置成接收订单并在产生所述解决方案数据期间使用所述订单，所 述订单包括如下至少一项基于来自较高层级层的所述解决方案数据的订单、基于来自 较低层级层的反馈的订单和外来提供的订单。
2.如权利要求1所述的系统，其中每个层级层配置成使用所述订单通过排除与所述 订单不一致的解决方案来简化对由该层级层解决的所述子问题的所述可能解决方案的搜 索。
3.如权利要求1所述的系统，其中至少一个层级层还配置成基于由该层级层接收的所 述订单产生导出订单。
4.如权利要求3所述的系统，其中所述订单包括确立在过程系统中执行的特定操作是初级还是次级操作的订单； 所述层级层之一包括配置成产生第一提议的协调器(406)，第一提议标识所述特定操 作是初级还是次级操作；所述层级层中的另一层包括配置成接收第一提议并使用第一提议确定是否可基于第 一提议解决与该层级层相关联的所述子问题的协作器(408)；以及所述协调器还配置成当所述协作器指示不能基于第一提议解决所述子问题时产生第 二提议，所述协调器调整哪些操作是初级或是次级操作以产生第二提议。
5.如权利要求1所述的系统，其中所述层级层包括在计算装置上运行的软件应用程 序，所述计算装置分布在过程控制系统(100)中的多级。
6.—种方法，包括在第一层级层(202-208)接收(302，306，310，314)订单，第一层级层配置成使用 所述订单解决与决策问题相关联的第一子问题；产生(304，308，312，316)表示第一子问题的可能解决方案的第一解决方案数据；以及输出第一解决方案数据；其中所述订单包括如下至少一项基于第二解决方案数据的订单、基于反馈的订单 和外来提供的订单；并且其中从至少一个第二层级层(202-208)接收第二解决方案数据和所述反馈中的至少 一个，所述至少一个第二层级层配置成解决与所述决策问题相关联的至少一个第二子问题。
7.如权利要求6所述的方法，其中所述层级层与不同时界相关联。
8.如权利要求6所述的方法，还包括在第一层级层基于由第一层级层接收的所述订单产生导出订单； 其中产生第一解决方案数据包括使用由第一层级层接收的所述订单和由第一层级层 产生的所述导出订单。
9.如权利要求6所述的方法，其中第一层级层接收的至少一个所述订单由用户提供，所述用户提交所述至少一个订单以指导所述决策问题的解决方案。
10. 一种包含在计算机可读介质上的计算机程序，所述计算机程序包括 用于在第一层级层(202-208)接收订单的计算机可读程序代码，所述订单与决策问 题相关联；用于使用所述订单产生第一解决方案数据来解决与所述决策问题相关联的第一子问 题的计算机可读程序代码，第一解决方案数据表示第一子问题的可能解决方案；以及 用于输出第一解决方案数据的计算机可读程序代码；其中所述订单包括如下至少一项基于第二解决方案数据的订单、基于反馈的订单 和外来提供的订单；并且其中从第二层级层(202-208)接收第二解决方案数据和所述反馈中的至少一个，第 二层级层配置成解决与所述决策问题相关联的第二子问题。
全文摘要
一种系统包含配置成解决决策问题的多个层级层(202-208)。每个层级层配置成产生表示与决策问题相关联的子问题的可能解决方案的解决方案数据。每个层级层还配置成接收订单并在产生解决方案数据期间使用订单。订单包含基于来自较高层级层的解决方案数据的订单、基于来自较低层级层的反馈的订单和/或外来提供的订单。每个层级层可配置成使用订单诸如通过排除与订单不一致的解决方案来简化对由那个层级层解决的子问题的可能解决方案的搜索。
文档编号G06F17/00GK102016797SQ200980115834
公开日2011年4月13日 申请日期2009年2月16日 优先权日2008年3月7日
发明者D·蔡恩吉尔, J·D·凯莉 申请人:霍尼韦尔国际公司