用于协调分配的MES订单管理的基于协商的方法和系统与流程

用于协调分配的mes订单管理的基于协商的方法和系统
1.本发明涉及用于协调制造执行系统(mes)的分配的订单管理的基于协商的方法和系统。最近，术语制造运营管理(mom)越来越多地用来代替术语mes。
2.如由制造企业解决方案协会(mesa国际协会)定义的，mes/mom系统“是如下动态信息系统”：通过管理“从订单交付制造的点到产品交付为成品的点的生产操作”并且通过“经由双向通信向整个组织和供应链中的其他方”提供“有关生产活动的关键任务信息”来驱动制造操作的有效执行。另外，isa
‑
95标准详细描述了制造过程必须考虑的有意义的资源，以优化和简化生产过程。特别地，重点放在材料、设备、工具和人员的管理上。通常，mes系统连接、监视和控制企业内的复杂的制造生产过程和数据流。mes系统的主要目标之一是确保制造操作的有效执行并提高生产量。
3.为了提高制造工厂的质量和过程性能，mes/mom系统通常包括的功能是资源分配和状态、调度生产订单、数据收集/获取、质量管理、维护管理、性能分析、操作/详细进度表、文件控制、人工管理、过程管理和产品跟踪。例如，西门子公司(sie
‑
mens corp.)在其simatic 产品系列下提供了广泛的mes/mom产品。诸如simatic it的mes或mom系统管理和监视各种各样的产品的生产。
4.传统的mes系统被设计为整体的、单工厂的和基于中央的应用，其中，中央模块包含所有决策能力，并且按照传统的客户端
‑
服务器范式设计和实现不同的mes模块之间的通信。
5.紧随围绕制造世界而出现的最新工业趋势(例如，客户和竞争对手的全局化)和新举措(例如，工业4.0)，新一代的mes系统要求一种新的生产过程范式。特别地，工业4.0引出了被称为智能工厂的概念。智能工厂概念的主要设计原则之一涉及分散决策，所述分散决策是一组系统自行做出决策并尽可能自主地执行其任务的能力。
6.这种新的范式推动了生产场所的更广泛的地理分布。传统的mes系统无法应对这样的分布式环境，在该分布式环境中，制造生产过程现在被描述为一组分解的功能，这些功能跨地理分布式企业而分层分布。
7.在整个一组mes功能中，订单(通常是生产订单)的管理是最重要和关键的功能之一。订单管理是一组企业过程，这些企业过程负责跟踪客户订单、提供能够满足订单需要的计划和合适的资源。在传统的mes系统中，订单管理是通常被称为订单管理系统(或生产订单管理系统)的单工厂的和整体的应用，该应用包含订单管理和订单执行两者。由于具有分布式环境的趋势，订单管理功能不能再被设计为整体的单工厂的应用，而必须针对新概念即分配的订单管理进行改变。
8.这种分配的订单管理产生一组分布式功能，这些功能用于实现不同的生产目标。换句话说，与订单管理是传统mes中的整个功能相反，根据本发明的订单管理被分为在分布式和分层系统中执行的若干个独立的功能(如下所述的全局订单管理和本地订单管理)。在分布式环境中，例如，为了满足全局(企业)目标而起作用的位于总部的中央模块的生产目标可以不同于为了满足本地(现场/区域(on
‑
area)/在线)目标而起作用的位于工厂的模块的生产目标。目标的示例是资源优化、生产质量提高、生产时间优化和可持续性优化。
9.因此，本发明的目的是提供一种用于在分布式生产环境内有效且可靠地管理生产订单的方法和系统。
10.根据本发明，该目的通过用于根据独立权利要求的目的协调分布式mes订单管理的基于协商的方法和系统来实现。从属权利要求呈现了本发明的其他优点。
11.在描述本发明的上下文的场景中，不同的模块或系统分布在不同的工厂之间，从而本地即在工厂级管理订单以及具有一定程度的自主权，其中，这样的模块或系统可以包括主动请求生产的位于工厂的功能，原因是：
12.a.位于工厂的功能知道生产将很快完成，并且由于资源优化，所述位于工厂的功能被配置为防止计划外停机时间；和/或
13.b.位于工厂的功能知道在一定的时间段内保持生产降低生产成本；和/或
14.c.位于工厂的功能知道保持连续(即，没有任何中断)生产可以减少污染(例如，污染物的排放)。
15.为了应付尤其由工业4.0和上述背景引起的新要求，本发明特别提出了一种优选地实现或嵌入在mes系统内的基于协商的系统，基于协商的系统尤其为mes系统提供能够在不同的企业级别协作的一组分布式的、自描述的和自主的功能。根据本发明的基于协商的系统特别提出了能够在不同的企业级别起作用的一组自主/独立和分布式功能，其中，所述功能至少包括本地订单管理功能和全局订单管理功能。本基于协商的系统使得能够在mes系统内进行订单(或服务)的分散管理，而不是基于整体方法的已知现有技术。所述订单管理的分散通过一种机制来实现，该机制协调并优化mes订单的管理，从而产生根据企业层次结构有效地分配和管理所述mes订单。
16.所述机制基于协商协议，协商协议被配置为总体上优化mes功能，特别地订单管理的分布和协调。通常，协商协议用于实现在其中可能发生参与者之间的冲突的通信协议。协商协议尤其被定义为迭代步骤的结构化序列，在迭代步骤的结构化序列中，执行要约和反要约直到达成协议或结束协商为止。
17.根据本发明，订单管理是一组自主能力的组合，其中，所述一组自主能力包括：全局订单管理功能，其被配置为提供全局订单计划和订单工程能力；以及本地订单管理功能，其被配置为提供本地订单计划和订单执行功能。
18.特别地，全局订单管理功能提供了一个如下入口点：用于从企业资源计划(erp)系统收集客户订单，以及从产品生命周期管理(plm)软件收集流程清单(bop)和物料清单(bom)数据(bop和bom数据分别指代制造产品所需的生产过程和所需的材料的定义)。全局订单管理功能还可以提供创建生产订单和将生产订单拆分为子订单的逻辑。另一方面，并且特别地，本地订单管理功能提供了本地订单计划功能，例如根据特定工厂的约束条件和生产订单安排订单以及生产订单步骤执行。从非常广泛的角度来看，全局订单管理功能和本地订单管理功能两者都可以具有在不同的企业级别同时运行的多个实例。
19.在企业层次结构的最高级别(例如，公司级别)执行的全局订单管理功能能够与在企业层次结构的最低级别(例如，站点、区域和生产线)执行的多个且分布式的本地订单管理功能交互。在这样的高分布式系统中，每个“子系统”(例如，高分布式系统的本地订单管理系统或全局订单管理系统)的自主的程度随着系统本身的复杂度和分布而增加，因为单个子系统必须交互的子系统越多，自主的程度越高，原因是其增加了所述单个子系统可以
交互的子系统的数目。
20.本发明提出通过基于协商的方法来解决由于分配的订单管理而出现的通信缺陷，该基于协商的方法被配置为自动协调分布式的全局和本地mes订单管理。实际上，协商过程是解决在全局订单管理和本地订单管理具有不同且可能相反的目标时的冲突的有效机制。
21.因此，根据本发明，特别地，通过基于协商的方法来实现前述目的，该基于协商的方法用于在尤其实现分布式功能的分布式系统的结构内管理mes订单，特别地生产订单，所述结构优选地是分布式系统的分层结构，所述分布式系统的结构包括：至少一个订单系统(以下称为os)(即，被配置为请求服务(例如，产品的生产)的系统，所述os优先地提供全局订单管理功能，并且例如是被配置用于在mes内的全局订单计划和工程的全局订单管理系统)；以及一个或若干个执行系统(以下称为es)(即，能够向os提供服务或产品的系统，所述es优先地提供本地订单管理功能，并且例如是可能从属于至少一个全局订单管理系统(或由其控制)并且被配置用于本地订单计划和执行的本地订单管理系统)，该方法包括以下步骤：
22.a)可选地，由os，例如通过全局订单管理系统接收对服务的请求，所述服务例如是产品的制造。该请求可以由客户(例如，客户系统)发送给os，os被配置为尤其在全局级别创建所请求服务的订单(例如，在包括若干个工厂的企业级别，所述若干个工厂可能分布在不同的位置，并且可能各自都能够提供所述服务)；
23.b)由os创建所述服务的订单，其中，所述订单包括至少一个可协商的要求，所述服务例如是产品的制造或提供用于制造产品的订单。如前所述，客户可以向全局订单管理系统发送制造产品的请求，并且然后全局订单管理系统创建用于制造所述产品的订单。根据该实施方式(以下称为第一实施方式)，全局订单管理系统是os。根据另一实施方式(以下称为第二实施方式)，可以通过本地订单管理系统(例如，通过在所述企业的工厂级别的本地订单管理系统)来创建订单，其中，一个或若干个工厂的本地订单管理系统通过所述订单请求一个或若干个全局订单管理系统来提供生产订单(例如，额外的生产订单)，以满足某些生产标准，例如减少计划外停机时间、减少能源消耗或减少污染物的排放。在这种情况下，所请求的服务不直接是产品的制造，而是提供用于制造产品的订单。在这种情况下，本地订单管理系统是os。通常，为了满足某些生产标准，本地订单管理系统将要求若干个全局订单管理系统提供新的用于制造产品的订单，并且将通过将在下面所述的协商过程接受由所述全局订单管理系统之一提供的最佳订单，在将接受满足第一预定义标准的订单的意义上的“最佳”；
24.c)os将所述订单分配给一个或若干个es。特别地，os被配置为首先例如根据数据库中存储的数据确定哪个或哪些es能够提供所请求的服务，并且然后将订单分配给能够提供所述所请求的服务的所述es中的每个es。根据第一实施方式，每个es是例如实现在属于全局企业的工厂中的本地订单管理系统。根据第二实施方式，每个es是负责为整个企业全局管理订单，例如生产订单的全局订单管理系统；
25.d)接收到所述订单的每个es对该订单进行评估。其自动确定是将接受订单(即，基于提供的订单直接找到协议)，还是必须生成针对所述服务的要约(即，启动每次涉及一个es和一个os的协商过程，其中，所述os和es将依次交换要约和反要约，直到达成协议或者要约拒绝为止)；
26.e)i)如果分配订单的es中的至少一个es接受该订单，则os将所述订单归于该至少一个es，并且向从所述es中的另一个es接收的任何要约发送拒绝。特别地，os将所述订单归于接受该订单的第一es；否则
27.ii)如果分配订单的所有es都没有接受该订单，例如在预定义的时间限制之后，则os开始与分配订单的es中的每个es进行针对所述可协商的要求的协商过程，其中，es和os两者均包括用于所述要求的协商过程的相同协商模型，并且其中，所述要求通过一个或若干个参数定义，其中，所述参数在所有es和os之间共享，但是其中，每个参数的值在不同的es和os之间可以不同，以使同一参数尤其根据时间对于不同的es和os具有不同的重要性(或权重)，其中，在协商过程中涉及的并且没有接受由os发送的订单的每个es被配置为尤其在所述预定义的时间限制之后，响应于分配的订单向os发送针对所述服务的要约，并且然后响应于从os接收的针对所述服务的任何后续反要约，向os发送要约或对所述后续反要约的接受，其中，由es发送的每个要约都包括所述要求的每个参数的要约值，其中，每当es接收订单或后续反要约时，就确定/计算所述要约值，直到由es接受反要约或由os接受要约或发送由os对要约的拒绝为止，其中，os被配置为接受由es接收的要约或响应于接收到的要约发送反要约或拒绝要约直到接受要约或反要约为止，其中，所述反要约包括所述要求的每个参数的反要约的值，其中，只要没有接受要约或反要约，就由os确定/计算所述反要约的值。根据本发明，在协商过程中涉及的参数的要约的值和反要约的值是由os和es自动确定的所述参数的新值，如稍后在讨论协商模型时更详细描述的。
28.此外，本发明的目的通过一种用于协调制造执行系统(mes)的分配的订单管理的基于协商的系统来解决，所述基于协商的系统包括分布式系统的结构，所述结构优选地是所述分布式系统的分层结构，所述分布式系统的结构包括至少一个os和至少一个es，其中，os包括：
29.‑
存储库，其被配置为尤其根据订单管理的mes域模型来存储计划和工程数据。有利地，存储库被配置为存储协商模型以及在es与os之间交换的每个协商线程。根据本发明，协商线程、要约和反要约的集合以及协商序列是相同的特征，因此具有相同的含义；
30.‑
订单计划和工程部件，例如全局订单计划和工程部件，其被配置为将业务逻辑应用于订单计划和订单工程，尤其用于订单的创建；
31.‑
在os的存储库内存储的协商模型，其中，所述协商模型被配置为使os与es之间的协商过程的协商步骤自动化。协商模型通常是为了提供协商能力而由os使用的推理模型；
32.以及es包括：
33.‑
存储库，其被配置为尤其根据订单管理的mes域模型来存储计划和执行数据。有利地，存储库还被配置为存储协商模型以及在es与os之间交换的每个协商线程；
34.‑
订单计划部件，例如本地订单计划部件，其被配置为将业务逻辑应用于订单计划。订单计划部件被配置为与os的订单计划和工程部件进行通信，并且还被配置为触发所接受的订单或反要约的执行；
35.‑
订单执行部件，例如本地订单执行部件，其被配置为当接受订单或反要约时将业务逻辑应用于订单执行；
36.‑
在es的存储库中存储的协商模型，其中，所述协商模型被配置为使os与es之间的协商过程的协商步骤自动化。协商模型通常是为了提供协商能力而由os使用的推理模型。
es和os的协商模型相同；
37.其中，基于协商的系统被配置为执行基于协商的方法的步骤。
38.现在将参照附图描述本发明的优选但非排他的实施方式，这些实施方式在以下附图中进行了描绘：
39.图1示意性地示出了根据本发明的基于协商的方法的优选实施方式；
40.图2示意性地示出了根据本发明的基于协商的系统。
41.本发明属于制造执行系统(mes/mom)的技术领域。图1示意性地描述了根据本发明的基于协商的方法的步骤，并且图2提供了基于协商的系统200的优选实施方式，所述基于协商的系统200包括os 210以及若干个es 220、230和240。基于协商的系统200可以具有结构化层次结构，其中，一个或若干个os 210被配置为向一个或若干个es 220、230和240提供服务的订单，其中，可以在包括由要约和反要约组成的若干轮的迭代协商过程期间协商订单的至少一个要求(例如，所述订单的一个或若干个参数)，直到在es中之一与os之间达成协议为止。
42.图2示出了os 210以及若干个es 220、230、240的结构化层次结构的示例。所述结构化层次结构表示例如包括一组不同级别(例如，公司总部、中心(区域总部)、站点、区域、生产线)的企业层次结构。os 210例如提供在诸如公司和/或中心的企业层次结构的最高级别运行的全局订单管理。然后，es 220、230、240提供在诸如站点、区域和/或生产线的最低级别运行的本地订单管理。
43.在优选的分层结构中，在os与es之间，例如在全局订单管理与本地订单管理之间存在多对多关系，全局订单管理与本地订单管理分布在企业的不同级别之间。在下文中并且出于简化的原因，然而将仅描述一对多关系的情况，即，一个os 210(例如，全局订单管理)，其部署在企业层次结构的最高级别之一(总部或中心)，并且通常作为在“全局”级别管理订单的单个实例运行，以及多个es 220、230、240(例如，本地订单管理系统)，其部署在企业层次结构的一个或更多个最低级别(例如，站点、区域或生产线)，并且作为在“本地”级别管理订单的多个实例运行。
44.在某个时间点，负责在企业级别的全局订单计划和订单工程的os 2010需要处理生产与一定数量的客户订单相关的一定数量的产品的请求。这些产品必须在某些要求下生产，所述要求是例如：
45.‑
生产质量要求；
46.‑
时间范围要求：例如，必须在所述时间段内完成客户订单生产；
47.‑
污染要求：例如，生产必须满足一些污染要求；
48.‑
能源消耗要求：例如，生产必须尽可能优化能源消耗；
49.‑
等等。
50.然而，企业层次结构的较低级别中的若干个工厂能够通过经过其es220、230和240提供本地订单计划和执行功能来生产所需产品。因此，每个工厂都能够在某些条件下提供所请求的产品，所述条件是例如：
51.‑
质量条件：例如，并非所有工厂都能够提供相同的生产质量，因为一些工厂是完全自动化的，而另一些工厂是完全手动的或处于“混合模式”；
52.‑
生产时间范围条件：例如，并非所有工厂都能够在规定的时间内完成生产，因为
工厂使用的设备彼此间不同，并且设备中的每个设备的可用性也不同；
53.‑
污染条件：例如，并非所有工厂都能够满足污染要求，因为当考虑到全球企业时，不同地区具有不同的法规；
54.‑
能源消耗条件：例如，并非所有工厂都能够提供相同的能源消耗优化，因为当考虑到全球企业时，不同地区具有与不同的能源提供商的不同的合同；
55.‑
等等。
56.因此，根据已经描述的第一实施方式，与生产请求相关的过程由os在企业级别发起。然而，该过程也可以在较低的级别例如，由一个或更多个工厂发起，在某种意义上说，一个或若干个工厂可能会要求另外的生产订单，以例如，减少计划外停机时间，和/或减少能源消耗，和/或减少污染物的排放。这对应于所谓的第二实施方式，在第二实施方式中，本地订单管理系统是创建服务订单的os，所述服务“提供(另外的)生产订单”，并且所述订单被分配给企业内的不同的全局订单管理系统以协商新订单的归属。
57.为了优化和协调多种多样的交互，这些交互在如在图2中所示的mes环境的这种分布式场景下出现并且涉及嵌入在os中的全局订单管理功能和嵌入在不同es中的本地订单管理功能，本发明提出了一种用于有效地优化和协调订单在不同es之间的分配的基于协商的方法。
58.协商被定义为(d.g.pruitt,negotiation behavior.academic press(学术出版社),1981年)：“a process by which a joint decision is made by two or more parties(由两方或更多方做出共同决定的过程).the parties first verbalize contradictory demands and then move towards agreement by a process of concession making or search for new alternatives(各方首先表达矛盾的要求，并且然后通过让步或寻找新的替代方案的过程达成协议).”。
59.根据本发明，协商是在mes环境内的os(例如，全局订单管理系统)与es(例如，本地订单管理系统)之间发生的双边过程。根据本发明的协商过程尤其使用协商协议和一组协商功能，并且基于一组双向互动，基于代表知识库的一组参数。知识库是在协商期间使用的一组参数。在简单的情况下，这些参数在全局功能和本地功能之间是相同的(即，对于参与协商过程的各方而言，知识库是相同的，但是每一方都对所述参数中的每个赋予了不同的重要性，并且对于每一方(例如，es或os)，这些参数也可以具有不同的值，其中，参数的值在协商过程期间被协商)。可选地，在非常复杂的协商情况下，每个协商者不共享其自己的一组参数。
60.根据本发明，协商过程将os和es包括在迭代过程中，该迭代过程被组织成由要约和反要约组成的若干轮，目的是使os与es达成共同协议。当与es达成协议或os拒绝es的要约时，则协商被认为终止。
61.为了启动所述协商过程，每个es和os尤其包括协商模型，该协商模型对于es和os是相同的。协商模型是协商过程所基于的推理模型。特别地，协商模型提供被配置为管理协商过程的业务逻辑。优选地，协商模型包括关于哪些本地订单管理模块可用以及其是否能够满足所请求的生产以及在哪些条件下的决定，其中，根据协商的结果在协商过程结束时确定所述条件，则os会知道能够满足所请求的生产以及在哪些条件下可用的es。优选地，协商模型被配置为使得能够自动创建服务的所述订单以及要约和反要约，并且被配置为自动
确定何时达成协议或者是否必须结束协商(例如，要约被拒绝)。
62.由os发送给es的订单包括由一个或若干个参数定义的可协商的要求，这些参数的值在协商过程期间被协商。在协商过程中使用的所述参数在所有es和os之间共享，特别地在全局订单管理级别和本地订单管理级别两者上共享。这意味着对于所有es和os，参数都相同，但是每个参数在os与es之间可以具有不同的重要性，并且在两个es之间，特别地在每个es之间也可以具有不同的重要性。优选地，由于这些参数可以反映实时情况(例如，产品的可用物质的实时量)，因此每个参数可以在协商期间根据时间而变化。例如，由于设备可用性或设备不可用性，因此可以由本地订单管理模块管理的订单的数目可能会随时间而变化。
63.由协商模型考虑的参数尤其是：
64.‑
生产质量参数，其值定义了产品在生产过程期间和/或结束时需要满足的质量；
65.‑
时间范围参数，其定义了必须完成生产订单的时间段；
66.‑
污染约束参数，其定义了在生产过程期间必须满足的污染约束条件；
67.‑
能源消耗参数，其定义了由生产过程所消耗的能源。
68.图2更详细地呈现了根据本发明的基于协商的系统200的os 210以及es 220、230、240。例如是全局订单管理系统的os 210优选地包括：
69.‑
存储库211，其中，特别地，所有计划和工程数据根据订单管理的mes域模型被存储。该存储库还可以被配置为存储协商模型和每个协商线程，并且优先地，存储协商模型所需的任何数据；
70.‑
订单计划和工程部件212，其被配置为将业务逻辑应用于优先地在企业的全局级别处的订单计划和订单工程。订单计划和工程部件212被配置为使用协商模型213，并且将订单计划和工程数据存储在存储库211中。订单计划和工程部件212可以包括处理器以及可选地包括存储器；以及
71.‑
协商模型213，其是由订单计划和工程部件212为了在协商过程期间提供协商能力而使用的推理模型。协商模型213还可以包括协商功能、协商协议、协商战略(strategy)和协商策略(tactic)。特别地，os 210使用存储库211的数据来运行协商模型213。
72.例如是本地订单管理系统的es 220、230、240包括例如：
73.‑
存储库221、231、241，其中，特别地，所有计划和执行数据根据订单管理的mes域模型存储。该存储库221、231、241还可以被配置为存储协商模型和每个协商线程，并且优选地存储协商模型所需的任何数据；
74.‑
订单计划部件222、232、242，其被配置为将业务逻辑应用于优选地在企业的本地级别处的订单计划。订单计划部件222、232、242以及订单计划和工程212被配置为尤其在协商过程期间彼此通信以建立和交换要约和/或反要约。订单计划部件222、232、242还被配置为使用协商模型213来触发订单执行，并且将订单计划数据存储在存储库221、231、241中。订单计划部件222、232、242可以包括处理器以及可选地包括存储器；
75.‑
订单执行部件224、234、244，其被配置为将所述业务逻辑应用于尤其在企业的本地级别处的订单执行。特别地，订单执行部件与订单计划部件进行通信，以从订单计划部件接收订单执行的请求，并且与工厂的一个或若干个执行系统例如制造机器人进行通信；
76.‑
协商模型223、233、243，其是由订单计划部件222、232、242为了在协商过程期间
提供协商能力而使用的推理模型。协商模型223、233、243还可以包括协商功能、协商协议、协商战略和协商策略。特别地，es 210使用存储库211的数据来运行协商模型223、233、243。
77.由es和os使用的协商模型尤其旨在优化和协调订单在mes系统内的分布。协商模型在本领域中是已知的，并且因此，技术人员可以决定哪种协商模型适合于特定的协商过程。将通过采用基于由以下技术公开的协商模型来说明本发明：h.raiffa(h.raiffa.the art and science of negotiation.harvard university press(哈佛大学出版社)，美国剑桥，1982年)和c.sierra等人(c.sierra，p.faratin和n.r.jennings.a service
‑
oriented negotiation model between autonomous agents.lecture notes in computer science
‑
collaboration between human and artificial societies，1999年)。当然，本发明不限于该特定模型，并且可以根据必须实现的协商来选择其他协商模型。
78.为了说明本发明，将通过考虑负责全局订单管理的os和负责本地订单管理的es来描述协商模型。然后，协商模型可以被描述如下：
79.让i成为协商伙伴，即os和es，其中i∈(g，l)，其中，g代表全局(即，表示os)，并且l代表本地(即，表示es)，并且j代表在协商下的参数，其中j∈(1，2，...，/n)。
80.让x
j
∈[min
j
，max
j
]成为参数j的通用值。所述通用值可以例如在os的存储库211和es的存储库221中预定义。
[0081]
让成为由os(i＝g)进行的全局订单管理或由es(i＝l)进行的本地订单管理的打分函数，其中，os和es是参与协商的伙伴，并且其中其中，min
j
和max
j
分别是参数j在相关协商伙伴之间的协商过程期间可以采用的最小值和最大值，其中，对于协商伙伴p，min
jp
是所述协商伙伴p的参数j可以采用的最小值，并且max
jp
是协商伙伴g的参数j可以采用的最大值。当在协商中考虑两个协商伙伴l和g时，则可以将[min
j
，max
j
]定义为min
j
＝min(min
jl
，min
jg
)(即，其采用min
jl
和min
jg
中的最小值)和max
j
＝max(max
jl
，max
jg
)(即，其采用max
jl
和max
jg
中的最大值)。打分函数是一种计算在接受的值的范围[0，1]内协商伙伴i给予参数j的分数的函数。每个伙伴必须为每个参数分配相关性(这意味着在不同的企业级别，相同的参数可以在目标实现中不同地贡献)。将参与协商的伙伴i赋予参数j的该相关性定义为其中然后，将打分函数定义为：
[0082]
其中x＝(x1，x2，...，x
n
)。
[0083]
打分函数验证，给定为参数j协商的协商伙伴g和协商伙伴l，其中，m1
j
和m2
j
是参数j的两个值，则打分函数满足以下条件：如果m1
j
，m2
j
∈[min
j
，max
j
]且m1
j
≥m2
j
，则当且仅当
[0084]
协商模型被配置为实现参数j的值的要约和反要约的一组迭代序列，直到要约或反要约被接受，或者要约被拒绝为止。要约和反要约的该序列由图1示出并且下面将进行详细描述。
[0085]
特别地，在时刻t，协商伙伴l从协商伙伴g接收订单，该订单包括参数j的值x
j
。在时刻t+1，协商伙伴l可以向g提出具有修改值x
j
的要约，或者可以接受由协商伙伴g发送的订单。作为响应，协商伙伴g可以在时间t+2接受要约，拒绝要约或提出反要约。在时间t的初始订单和每个要约(或反要约)由值的向量组成，并且可以表示为x(g，l，t)＝(x1(g，l，
t)，...，x
n
(g，l，t))，(x
i
(a，b，c)表示在时间c由协商伙伴a向协商伙伴b提出的参数j的值x)。例如，当协商伙伴l在时间t从协商伙伴g接收包括参数j的值x
j
(g，l，t)的初始订单时，相对于在时刻t的接收到的订单，其将在时刻t+1通过使用其打分函数对其要约进行评估，使用：
[0086][0087]
即，如果由os发出的订单(或任何反要约)具有如下打分函数：该打分函数的值高于将针对由es响应于该订单而做出的后续要约获得的打分函数值，则接受该订单，否则，要约被发送给os，该os将使用相同的方案来进行其评估，直到接受要约或反要约为止，或者直到os接受另一个es的要约并且因此拒绝其他es的要约为止。
[0088]
为了准备要约、相应地反要约，协商伙伴l、相应地协商伙伴g自动确定初始订单中包括的一个或若干个可协商参数的新值。所述新值尤其根据用于完成所请求的产品的生产的已知截止时间和/或可用资源的当前数量/量来确定，以及/或者根据由其他协商伙伴对所述参数进行的先前值改变来确定。一些策略是：
[0089]
特别地，根据用于完成所请求的产品的生产的已知截止时间来确定新值可以如下来实现：每个协商伙伴根据自发送和接收初始订单以来经过的时间以及由定义必须完成协商的时间的常数t
max
表示的截止时间来改变协商过程中包括的参数中的至少一个参数(优选地所有参数)的值：
[0090][0091][0092]
其中，函数满足：
[0093]
和
[0094][0095]
并且由以下定义：
[0096][0097]
其中，是当时间t等于0时的打分函数的值。通常，其是根据经验推断的经验值。β是协商过程的凸性程度。凸性定义了到达协商的结束的速度。如果β＞1，则协商者尝试非常快地到达协商的结束，而当β＜1时，协商者尝试非常慢地到达所述结束，并且每个要约都包括参数的接近先前要约的值的协商的值。
[0098]
用于根据必须完成协商的时间t
max
来确定参数的新值的上述方法是用于在协商过
程期间确定参数j的新值的许多合适示例中的一个示例。在协商过程期间，可以采用其他策略用于确定参数j的新值。
[0099]
图1更详细地示出了根据本发明的协商过程。协商过程由协商协议确定，该协商协议包括在协商模型中并且可以存储在存储库中。协商协议尤其用于以严格的方式使一组要约和反要约对于es和os如何必须发生进行正式化。
[0100]
根据优选的协商协议，协商过程100遵循以下步骤：
[0101]
‑
在步骤101处，os创建服务订单。所述服务通常是产品的制造，该产品的制造例如必须在预定义的时间段例如t
max
内完成。该订单包括由一个或若干个参数定义的可协商的要求，这些参数的值在协商过程期间可协商。通过创建该初始订单来初始化os的协商过程；
[0102]
‑
在步骤102处，os将所述订单发送给一个或若干个es。特别地，os能够例如通过根据存储在其存储库或数据库中的es的特性确定哪个es能够制造所述产品来确定哪些es将参加协商过程。一旦os确定了如下es：该es的特性使es能够制造产品或提供所需的服务，则os将所述订单发送给所述es；
[0103]
‑
在步骤103处，由os确定为能够提供所述服务或所述产品的制造的每个es接收订单。每个es可以例如从相同的os或从若干个os接收若干个订单。特别地，然后，每个es针对接收到的每个订单发起其协商过程；
[0104]
‑
在步骤104处，已经接收到订单的每个es对订单进行评估。特别地，每个es相对于接收到的订单自主地确定下一动作。特别地，下一动作是接受所述订单，或者是拒绝所述订单以及发送由os经由发送的订单订购的服务的要约；
[0105]
‑
在步骤105处，es在对订单进行评估之后接受该订单，或者拒绝该订单。接受订单意味着达成协议，而没有协商订单的可协商的要求。接受订单的es直接将所述信息传达给os，os在步骤106处又将所述订单归于es。优选地，在若干个es接受所述订单的情况下，os将订单归于已经传达了其接受订单的第一es。一旦os将订单归于es，则os将不会接受可能从在协商过程中涉及的es接收的以下任何要约，这意味着从es接收到的每个后续要约都将又接收到由os发送的拒绝。拒绝订单尤其会触发确定可协商的要求的至少一个参数的新值(要约值)。新值的这种计算由拒绝订单的每个es执行。拒绝订单的每个es通过计算或运行其协商模型来实现可协商的要求的参数的要约值的这种计算；
[0106]
‑
在步骤107处，拒绝订单的每个es向os发送要约，其中，所述要约包括可协商的要求的至少一个参数的要约值；
[0107]
‑
在步骤108处，os从在协商过程中涉及且尚未接受订单的每个es接收要约，并且对所述要约中的每个要约进行评估。特别地，os关于接收到的要约中的每个要约自主地确定下一动作。特别地，下一动作是如在步骤109处所述的接受所述要约之一，或者拒绝所述要约(步骤110)并且向es发送反要约(步骤111)；
[0108]
‑
在步骤109处，os在对要约进行评估之后接受要约或拒绝要约。优选地，os使用所述打分函数，以确定是否必须接受要约。优选地，在若干个要约可接受的情况下，则os可以接受首先接收到的可接受的要约，或者os可以接受具有打分函数的最高值的可接受的要约。在步骤110处，os将订单归于其要约已被接受的es并通知该es。一旦os将订单归于其要约已被接受的es，则os将向其要约不被接受的任何其他es发送要约的拒绝，这尤其触发了接收拒绝的es与os之间的协商过程的结束。只要没有接受要约，拒绝要约尤其都会触发确
定可协商的要求的至少一个参数的新值(反要约值)。只要没有接受任何接收到的要约，新值的这种计算就由os执行。os通过计算或运行其协商模型来实现可协商的要求的参数的反要约值的这种计算。特别地，os确定接收和拒绝的每个要约的反要约，其中，反要约可能取决于所述反要约中包括的反要约值而彼此不同；
[0109]
‑
在步骤111处，其要约未被os接受的每个es接收由os发送的反要约，其中，所述反要约包括可协商的要求的至少一个参数的反要约值。特别地，每个es可以例如从相同的os或从若干个os接收若干个反要约；
[0110]
该方法然后返回到步骤104并继续进行步骤104，将该步骤104应用于反要约而不是订单，即，在步骤104中，已接收到反要约的每个es都对反要约进行评估，其中，已接收到所述反要约的每个es都处理反要约，如按照后续步骤105至111处理订单那样，直到接受了反要约，或者接受了要约，或者接收了要约的拒绝为止。换句话说，根据本发明的方法因此包括循环l，在循环l中，针对每个反要约，迭代地重复步骤104至111，直到es接受了反要约，或者os接受了要约，或者es接收了要约的拒绝为止。在步骤104至111的该迭代期间，在协商中的参数的值由os和es尤其根据当前生产情况(例如，考虑到可用物质的量的变化或考虑到工厂的机器的故障)连续地更新(或重新评估)，使得os与每个es之间的不同的协商可能会导致在协商中所述参数的不同结果。
[0111]
为了更好地说明基于协商的方法，在下文中将该基于协商的方法应用于简化的制造情况，在该简化的制造情况下，考虑了一个os是全局订单管理系统，并且两个es是本地订单管理系统。
[0112]
全局订单管理系统需要根据不同组的定制订单来生产产品，其中，所述不同组对应于客户的不同要求。
[0113]
根据第一种情况，第一组的定制订单需要产品的生产，其中，生产质量是生产的最重要要求，而根据与第二种情况相对应的第二组的定制订单，所述生产的最重要要求是生产时间优化。还提供了其他要求，例如能源消耗优化要求、能源消耗优化要求和污染要求满足。
[0114]
这些要求中的每个要求都是可协商的要求，这些可协商的要求包括可以协商其值的至少一个参数。全局订单管理系统和本地订单管理系统分别具有所述参数的自己的一组值和该参数的自己的相关联权重，所述权重是所述参数对于所述本地或全局订单管理系统具有的重要性的函数。
[0115]
例如，然后，对于全局和本地订单管理系统，打分函数被定义如下：
[0116][0117]
其中，γ值与打分函数增加的速度相关，γ值越大意味着打分函数增加缓慢，而γ值越低意味着打分函数突然增加。这两个值都可能是启发式值。
[0118]
关于所需质量、所请求的生产时间优化、污染要求满足和所需能源消耗的参数的值由以下策略函数给出：
[0119][0120]
或
[0121][0122]
其中，
[0123][0124]
并且对于本地订单管理，β等于0.1，而对于全局订单管理，β等于0.01。优选地，β的这些值是启发式值。
[0125]
第一种情况(质量约束条件)
[0126]
对于第一种情况，企业的总部例如对以可能的最高质量进行生产感兴趣。因此，定义所需质量的参数是最重要的参数(例如，其权重0.4与为其他要求定义的其他参数的值相比是最高的
‑
参见表1)，并且“所需质量”参数的值是最高的。其他要求的其他参数不太重要，如在表1中所示。
[0127][0128]
表1
[0129]
表1示出了“所需质量”参数、“生产时间优化”参数、“污染要求满足”参数和“能源消耗优化”参数的不同组的值，这些值可能存储在全局订单管理系统的注册表内用于计算所述打分函数。另外，还提供了每个参数的权重。
[0130]
在所述企业内，第一工厂可以具有如下配置，在该配置下，生产质量是最重要的生产要求，即，与其他不太重要的生产参数相比，在工厂的本地订单管理系统的注册表内定义的“所需质量”参数具有最高的权重(例如，等于0.4)，并且如在表2中给出的。对于表1，表2示出了“所需质量”参数、“生产时间优化”参数、“污染要求满足”参数和“能源消耗优化”参数的不同组的值，如在第一工厂的本地订单管理系统内定义的。
[0131][0132]
表2
[0133]
在所述企业内，第二工厂可以具有如下配置：其中，分别具有权重0.25和0.45的“污染要求满足”参数和“能源消耗优化”参数是最重要的参数(参见表3)。发生这种情况的原因可能是，例如，由于第二工厂的地理位置引起的一些关于污染的政治限制或者关于能源消耗的一些本地工厂约束条件。对于所述第二工厂而言，生产的质量不是相关的参数，因为例如，生产是完全手动的，并且某些高质量的操作是不可能的。表3示出了“所需质量”参数、“生产时间优化”参数、“污染要求满足”参数和“能源消耗优化”参数的不同组的值，如在第二工厂的本地订单管理系统内定义的。
[0134]
第一工厂和第二工厂两者都能够生产所述产品。第一工厂和第二工厂两者的全局订单管理系统与本地订单管理系统之间的协商能够有效地确定生产所述产品的订单将归于的工厂以及在哪些条件下，即在哪些参数值下。
[0135][0136]
表3
[0137]
在表4中报告了第一工厂的全局订单管理系统与本地订单管理系统之间的协商，而在表5中报告了第二工厂的全局订单管理系统与本地订单管理系统之间的协商。
[0138][0139]
表4
[0140][0141]
表5
[0142]
因此，协商过程结束，以利于第一工厂的与全局订单管理系统达成协议的本地订单管理系统用于根据使质量约束条件作为主要要求的所述一组客户订单来生产产品。
[0143]
作为说明，通过将针对时间t的不同值计算并且由另一协商者发送的所考虑的参数x的每个值应用于接收要约的协商者的打分函数来获得在所呈现的表中提供的根据时间为而变化的值。通过应用考虑了参数x的最小值和最大值的策略函数来计算参数x的每个值，其中，系统首先针对每个参数和针对时间t的每个值计算策略函数的值(策略函数取决于每个参数的范围和时间t)，其中，针对接收到的值和将作为反要约发送的值两者计算策略函数，并且其次，其计算打分函数的每个项。打分函数是元素的加权总和，这些元素是考虑到先前应用打分函数计算的x值而计算的。
[0144]
第二种情况(生产时间优化)
[0145]
对于第二种情况，例如，所述企业的总部对以可能的最高生产时间优化(即，尽可能快)进行生产感兴趣。然后，“生产时间优化”参数是最重要的参数(例如，将0.6的权重归于在总部的全局订单管理系统的注册表内的该参数)，并且“生产时间优化”参数的一组值是最高的，如在表6中所示。其他参数不太重要，这意味着与和生产时间优化参数相关联的权重的值相比，相关联的权重值较低，如在表6中所示。
[0146][0147]
表6
[0148]
这次，第一工厂关于生产具有不同的要求：在本地订单管理系统内为“所需质量”参数定义了最高权重，该参数具有等于0.4的权重(参见表7)。其他生产参数不太重要，如在表7中所示，其中权重值低于为生产质量定义的权重的值。
[0149][0150]
表7
[0151]
相反，第二工厂被配置为优化能源消耗，并且因此其本地订单管理系统包括“能源消耗优化”参数，等于0.5的该参数的权重高于与其他参数中的每个参数相关联的权重(参见表8)。实际上，其他参数不太重要。
[0152][0153]
表8
[0154]
在表9和表10中分别报告了第一工厂和第二工厂的全局订单管理系统与本地订单管理系统之间的协商。
[0155][0156]
表9
[0157][0158]
表10
[0159]
这次，协商过程结束，以利于第二工厂的本地订单管理系统与全局订单管理系统达成协议，以用于根据使生产时间优化作为主要约束条件的一组客户订单来生产产品。
[0160]
在更复杂的情况下，其中，在协商过程中涉及不止一个本地订单管理系统，全局订单管理系统被配置为：
[0161]
‑
与协商过程具有较少次数的迭代的本地订单管理系统达成协议直到接受要约或反要约为止。例如，其通常将对应于首先提供被接受的要约或首先接受反要约的本地订单管理系统。有利地，较少次数的迭代步骤表明了协商伙伴之间的大的密切关系；
[0162]
‑
如果与不止一个本地订单管理系统的协商过程具有相同次数的迭代，则与在协商过程期间打分函数具有最高平均值的本地订单系统达成协议。
[0163]
总之，本发明有利地提供了一种用于优化和协调mes系统内的分配的订单的新构思。因此，其提供了一种通过协商协议来协调自主、自我描述和分布式mes功能的新颖方法。特别地，其可以用于根据由新的工业趋势(例如，客户和竞争对手的全球化)和新的举措(例如，工业4.0)给出的新要求来优化mes功能的分布，其优化资源利用率、缩短生产时间并提高制造工厂的利用率。