挑战
作者：George Thiers、Timothy Sprock 和 Leon McGinnis（佐治亚理工学院）；Adam Graunke（波音研究与技术公司）；Michael Christian（波音公司）
在 2016 年冬季模拟大会上发表
一个多年研究项目的重点是一家全球航空航天公司从设计到生产的转变，特别是如何在项目设计周期中比现在更早地回答与生产相关的问题。一个基本的困难是，制定适当的分析模型需要时间和专业知识，这妨碍了模型的常规使用，尤其是在新项目开发中。该项目的目标是降低这些要求，到 2014 年底，已开发出一套按需生成分析的方法，用于回答有关生产系统的常规问题。2015 年开展了一个试点项目，以证明该方法的有效性，即在产品规格、其流程计划、计划设施和可用资源经常变化的情况下，实施该方法实际上可以以可重复的方式将回答一个常见问题所需的时间至少减少一个数量级。本文总结了该方法、试点项目的实施情况和初步结果。
引言
一家全球航空航天公司希望通过在产品生命周期早期解决关键问题来改进其生产系统的设计。计算机辅助设计（CAD）和工程（CAE）工具为产品设计师提供了一键式功能，可评估候选产品设计的机械、航空航天、热和其他类型的指标。然而，为生产系统设计人员提供按需分析能力的计算工具却非常有限。因此，公司的愿景是加强对生产系统设计、诊断和持续改进的工具支持，首先让设计人员能够通过按钮评估 "可生产性 "指标和问题，包括
- 如果一架飞机的设计包括新型材料，是否有能力以一定的速度和成本生产所需的部件？
- 如果一个主要的子组件被分割成不同的部分，由不同的供应商制造，并在总装时连接起来，那么交付时间表应该如何平衡对供应中断的高稳健性和低库存成本？
- 要以一定的生产率制造某个子组件，需要在工具、夹具、层叠模具和其他资源上投入多少资金？
无论问题的清单是什么，研究的主题都是如何按键式地回答这些问题，而有几个因素导致按键式回答变得困难。 首先，按键式能力需要制定和求解各种运筹学分析模型，包括统计、离散事件模拟和优化分析模型。文献中对求解方法和算法进行了深入研究，但对如何以自动化、稳健和可重复使用的方式，在给定分析中立的系统描述和系统问题的情况下建立分析模型却没有深入研究。其次，在早期设计阶段，产品规格可能只存在于较高的抽象层次，这意味着按钮功能必须适应不同数量的细节。第三，虽然产品生命周期管理系统（PLM）可以严格采集产品和流程信息，但资源和设施信息却往往无法采集--许多公司的生产知识往往是非正式的、隐性的和短暂的。 如果公司的骨干架构包括 CAD、产品数据管理（PDM）、制造执行系统（MES）和制造资源计划（MRP），这些系统的组合仍然缺乏回答许多可生产性问题（包括上述问题）所需的信息。因此，当设计人员按下按钮时，他们还应该期望提供额外的信息，这就提出了信息到底是什么、信息应该使用什么语言和格式、信息的细节有哪些灵活性等问题。
公司的愿景可以类比为增强个人助理（如苹果的 Siri、谷歌的语音搜索或微软的 Cortana），为其提供回答候选设计可生产性问题所需的附加功能。要了解所需的功能与现有功能有何不同，请考虑到许多向个人助理提出的问题都可以通过简单的数据库或网络搜索来回答。更高级的机器也有个别例子，其中最常见的是计算驾驶路线。有关民用交通网络导航的问题，通常不是通过在数据库中搜索预先录制的路线来回答，而是通过制定最短路径网络流优化分析、求解（可能使用带有启发式算法的 Dijkstra 算法），并在几秒钟内完成，而且终端用户不会察觉。以此类推，上述因素可归纳为两大挑战：(1) 个人助理分析和求解能力的必要普及和扩展；(2) 建模。由于个人助理已经掌握了民用交通网络的详细信息，因此可以回答有关行车路线的问题。然而，它们对任意公司的专有产品、流程、资源和设施一无所知--即使它们能够访问公司的信息系统，这些系统也并不完整，通常也无法发挥实验设计环境所需的作用。
到 2014 年底，已经开发出一种方法来应对这些挑战，尤其是建模方面的挑战。该方法可通过自动制定多种不同的分析模型类型，以按钮式方式回答可生成性问题，但试点项目只侧重于制定离散事件仿真模型，这与尼尔森的观点一致，即 "仿真越来越成为分析、设计、评估或控制我们感兴趣的大规模、复杂、不确定系统的唯一方法"（Taylor 等，2013 年）。公司要求使用现成的商用（COTS）工具来自动建立仿真模型，包括 Simio 和 Tecnomatix 工厂仿真。
解决方案
1.1 以前的工作：模型生成和建模
许多工程分析人员都尝试过在工作流程中加入自动化功能，他们采用的模式是将系统描述 与系统分析分离开来，以一种可能更简便的方式编写系统描述，然后根据需要将其自动 转换为特定分析语言的语义和语法。Yuan 等人（1993 年）介绍了一种 SIMAN 语言的 "离散运行系统 "仿真模型生成器，该模型是用 "运行网络 "和 "运行方程 "建模的。Son 和 Wysk（2001 年）介绍了用 Arena 语言自动建立仿真模型，以回答制造车间控制问题的方法，使用一种称为 "基于消息的零件状态图 "的网络抽象来捕捉通过车间资源的潜在路径。Fournier（2011 年）介绍了使用核心制造仿真数据（CMSD）标准自动构建各种语言（QUEST、Arena、ProModel、FlexSim）的仿真模型，Bergmann 等人（2012 年）将 CMSD 映射到 SLX 仿真语言。Dong 和 Chen（2001 年）根据计算机集成制造开放系统架构（CIMOSA）行为规则生成面向对象的 Petri 网，Deavours 等人（2002 年）根据与 Mobius 框架兼容的建模形式生成随机活动网络（SAN）。输入 SysML 语言系统模型的仿真分析模型生成器有 Batarseh 等人（2015 年）和 Kapos 等人（2014 年），后者可生成可执行的离散事件系统规范（DEVS）模型。
请注意上述引文中系统描述语言的多样性。除了 "离散运行系统"、"基于消息的部分状态图"、CMSD 等，还有许多其他候选语言，从研究构想到采用标准，不一而足。用于交换生产计划和调度数据的 OASIS 标准是（OASIS 2011）。ISO TC 184/SC4 委员会的成果包括用于机器可读捕获和共享产品数据的 ISO 10303 标准（Pratt，2001 年）。AutomationML 是生产设施中工程工具之间交换数据的标准中的标准（Drath 等人，2008 年）。这些工作对数据模式进行了标准化，同时也对语义和本体进行了标准化。将业务流程语义正规化的 OMG 标准是业务流程模型和符号（BPMN）（OMG，2011 年）。供应链委员会将供应链管理语义正规化的标准是《供应链运营参考》（SCOR）（SCC，2012 年）。有关制造语义正规化的建议包括制造语义本体（MASON）（Lemaignan 等人，2006 年）、Molina 和 Bell（1999 年）、Cutting-Decelle 等人（2007 年）以及 Guerra-Zubiaga 和 Young（2008 年）。
Tanenbaum（1981 年）指出："标准的好处在于你有很多选择。"在研究项目的最初几年，作者们试图为生产系统找到一种单一而 "完美 "的系统描述语言（Thiers 和 McGinnis，2013 年），从各种引用的文献中总结经验，填补空白。然而，由于具体与抽象之间的根本矛盾（前者是用户可访问性的需要，后者是稳健性和可重用性的需要），以及语言不可避免地受其作者在某一时刻的用例影响等原因，作者们从未开发出一种能让全世界都使用的语言。不可避免的是，使用情况和时间都会发生变化，语言必须不断发展，与语言紧密耦合的转换程序必须中断，作者必须维护他们早已遗忘的代码（如果还能找到原作者的话）。只有当人们最终认识到，用于生产系统的单一而 "完美 "的系统描述语言可能永远不存在，并设计出一种方法来容纳大量相似但不同的系统描述语言时，进展才得以恢复。
1.2 COTS 离散事件仿真工具的挑战
除了有大量的系统描述语言可供选择之外，离散事件仿真分析也有大量的语言可供选择--不像优化分析领域有一种标准语言 "数学编程语言"（AMPL）（Fourer 等人，1993 年），据作者所知，离散事件仿真领域没有这种标准语言，而且每种语言在语义和语法上都与其他语言不同。如果系统描述语言有 m 种选择，仿真分析语言有n 种选择，那么从系统描述到仿真分析的转换就会有m n 种排列组合，严重限制了编写和维护每种语言的投资回报。本文介绍的方法将m减少到1，但仍允许使用m 种系统描述语言，方法是增加一个中间转换步骤，将每种语言与后端桥接抽象语言松散地连接起来。
在第 1.1 节中提到的自动生成仿真模型的努力中，转换 "智能 "的位置有相当大的差异--它可能位于系统描述语言的上游（有效地将该语言与下游分析语言混为一谈）、转换本身（如通用模型到模型转换语言和工具，包括 QVT (OMG 2016) 和 ATL (EMF 2016)），或者位于系统分析语言的下游（有效地将该语言与上游描述语言混为一谈，这是许多 COTS 仿真工具供应商的实际方法）。在某些情况下，研究人员试图通过编写自己的离散事件仿真语言和求解器来简化转换，如 Biswas 和 Narahari（2004 年）、Chatfield 等人（2006 年）以及 Schonherr 和 Rose（2009 年），从而使用直接的一对一映射将系统描述转换为仿真分析。据作者估计，在有合适的 COTS 工具（即使其语言不方便）的情况下，开发临时分析工具似乎不是一条可持续发展的道路。本文描述的方法将大部分转换 "智能 "置于模型到模型转换本身，但提出了向前迈出的一小步，即尽可能使用模型库块（桥接抽象模型元素的可执行版本）构建仿真模型。
方法论
方法论是相关流程、方法和工具的集合（Estefan，2008 年），本文方法论的流程如图 1 所示。左上方的系统模型和中间上方的桥接抽象模型都是纯描述模型，两者实际上由两个不同层次的建模抽象组成，在面向对象的软件术语中，可称为模式和数据或元模型和实例模型，或类定义和对象实例。第 1.1 节中详细讨论的系统描述语言是上层模式或元模型层，这种区分非常重要，因为模型到模型的转换只依赖于这一层，而且在任何符合要求的数据或实例模型下都应有效。桥接抽象元模型是一种抽象的创造，它捕捉了所有离散事件物流系统（制造系统、供应链、仓储与配送系统、运输与物流系统、医疗保健服务系统等）所共有的基本共性。一个重要的观察结果是，工业工程中研究的大多数系统都具有网络结构，对它们进行的大多数运筹学分析都是基于网络的分析。桥接抽象元模型自诞生以来已发展成为一个分层模型集合，但作者将最初的基本层称为令牌流网络，其节选如图 2 所示。
桥接抽象模型的引入是为了调和具体与抽象之间的基本矛盾--系统模型应尽可能具体，以满足可访问性的需要；桥接抽象模型应尽可能抽象，以满足健壮性和可重用性的需要，而其有效性则取决于两者之间易于创建和维护的映射关系。映射是模型到模型转换的声明性规范，根据新的或不断演变的系统模型更新映射必须尽可能简单、快速。用软件术语来说，增加中间步骤的作用是减轻系统描述语言和系统分析语言之间的紧密耦合，从而在系统描述语言不可避免地要随用例和时间变化而变化时减轻成本。在图 1 中，桥接抽象模型和分析模型之间的第二阶段耦合将保持紧密，但系统模型和桥接抽象模型之间的第一阶段耦合应尽可能松散，以适应新的或不断发展的系统模型。重要的是，由于桥接抽象模型的稳定性，编写和维护第二阶段转换的任务应该有足够的投资回报，可以由专门的团队来完成，而不是由不同的分析师来完成。
许多新想法都是旧想法的变种，图 1 中的流程可以归类为旧想法的变种，是从软件工程到系统工程最佳实践的移植。该方法的新颖之处在于它的方法和工具，这些方法和工具解决了系统工程中存在的巨大研究挑战：
- 桥接抽象元模型--一种明确的、分析中立的、人机可读的元模型，它捕捉到了所有离散事件物流系统共有的基本共性。随着研究项目的发展，人们很快就意识到，桥接抽象模型将在未来数年内反复开发。系统结构建模通常是难度最低的工作，行为建模（如流程）通常更具挑战性，而控制建模（如业务规则）通常最具挑战性。此外，编写元模型的大多数候选语言（UML、SysML、Ecore、OPM、实体关系图等等--语言中的语言）都是面向对象的，而面向对象的系统建模可能是一种陌生的思维方式。
- 模型到模型的转换。要将图 1 中的系统模型转换为桥接抽象模型，其机制已从 UML 定型应用发展到通用转换语言（包括 QVT 和 ATL）中的声明性规范，再到第 3 节中进一步描述的定制模型到模型转换语言和引擎。
- 了解生产系统的问题空间以及能够回答这些问题的分析。这一挑战与深层领域知识密切相关。如果该方法的实施能够支持大量的常规生产性问题，新的挑战就会出现--如何通过提出正确的问题来有效利用 "问题解答精灵"。作者认为，这将需要捕捉更高层次的流程（诊断、持续改进、设计等）以及在执行这些流程的每个步骤中提出的问题。
有关该方法的流程、方法和工具的广泛讨论可参见 Thiers (2014)、Sprock and McGinnis (2014) 和 Sprock (2016)。对新方法和工具的探索和尝试仍在继续，例如，在没有典型语言的领域中构建分析模型时，尽可能使用模型库块的方法，该模型库块是桥接抽象模型元素的可执行版本。
试点项目
到 2014 年底，该方法论在纸面上已经成熟，2015 年开展了一个试点项目，以证明其有效性，即在产品规格、流程计划、计划设施和可用资源不断变化的情况下，该方法论的实施实际上可以以可重复的方式将回答一个常见问题所需的时间减少至少一个数量级。具体步骤如下
第 1 步：让用户选择一种经常遇到的情况，在这种情况下，按钮式离散事件仿真模型对回答各种问题可能非常有价值。本项目的情况涉及评估复合材料部件制造的生产能力，经常提出的问题是："支持给定生产率所需的最少资源数量是多少？复合材料铺层模具和高压釜资源是一个值得关注的问题，对于大型航空航天零件来说，这些资源可能非常昂贵，而且采购周期较长。
第 2 步：针对所选方案，创建系统描述语言。这一步需要捕捉分析中立的语义，用户使用这些语义来谈论他们的业务，并在信息系统中进行表述。这种语言在试点项目中不断迭代发展，其最终迭代时的状态如图 3 所示。请注意，这是一个模式级模型，而不是任何生产系统实例的模式级模型--它是设施、生产流程、替代方案、未来理想状态等的通用定义。
图 3 中的语言是否可以作为描述任意生产系统的抽象元模型？当然不是--这是一个特定用户的模式，而且是针对特定用例的最小模式，在语法甚至语义上都可能与其他用户的模式不同。重要的功能包括在高压灭菌器上进行分批（按零件体积，或按零件类型和数量的特定清单），以及通过多个流程步骤（从铺层前到固化后的复合铺层模具）将资源与零件配对。这些语义还能将物理设施与功能流程定义区分开来，因为产能问题的一个关键要素是流程计划不是在真空中执行的，而是在特定设施中执行的，这些设施同时执行多个流程计划，并共享共同资源。不包括但在其他情况下可能很重要的语义包括有截止日期的作业、设施内和设施间的旅行网络、作业和资源的路由控制等。该方法的创新之处在于，分析生成器程序与图 3 中的系统描述语言只是松散地耦合在一起，其效果是这些程序可以在语言发展的同时继续工作（在试点项目中，语言的发展经历了大约八次迭代，每次迭代间隔为一个月）。换句话说，这种方法减轻了在投资依赖于系统描述语言的分析生成器程序之前，必须使其 "完美 "的负担。
第 3 步：使问题精确化。一旦工具支持达到一定的成熟度，这一步就会变得多余，但在早期试点项目中，这一步是必不可少的。任务是确定提问者希望在答案中得到哪些信息，以及如何从模拟输出中提取或推断出这些信息。对于"支持给定生产率所需的最少资源数量是多少？"这个问题，假设返回的答案是"'平均每月支持 20 架飞机所需的最少资源 A 和 B 的x 和y 单位'。这就足够了，还是还需要风险限定语，如"x 和 y 单位的 A 和 B 型资源在 α% 的月份只能生产 19 架飞机，在 β% 的月份只能生产 18 架飞机"？未来开发的一个重要项目是返回带有解释、风险限定词等的答案。该方法是一种决策支持工具，而不是决策工具，因为决策应反映人类对风险的评估，这可能是某种形式的帕累托前沿图上的 x 轴，作为问题的答案返回。
要使问题准确无误，还需要付出第一个项目所特有的努力。由于大部分工作是软件开发，因此采用了螺旋式开发模式，迭代周期约为一个月。在一系列里程碑式的问题中，"支持给定生产率所需的最少资源数量是多少？
- 某项（工作）的（预期）（原始周期时间）是多少？要回答这个问题，离散事件仿真模型是最简单有趣的。
- 定期执行某项（工作）的（预期）（吞吐量）是多少？要回答这个问题，只需要进行流程仿真，而不需要考虑生产设施、该设施中同时执行的其他流程计划、资源共享范例等。
- 在某个（设备）中生产某些（产品）的（预期）（吞吐量）是多少？要回答这个问题，需要模拟一个制造工厂，在共享公共资源的同时，同时执行多个工艺计划。回答这个问题与毕业设计问题的区别只是增加了一个优化器来搜索最小资源数。
- 支持一定吞吐量所需的最少资源数量是多少？有趣的是，实际上并没有添加优化器；试点项目的发起人认为这是一个简单的扩展，并选择更好地利用时间来增加系统描述的保真度，进而自动生成仿真模型。
第 4 步：将前端系统模型映射到后端桥接抽象模型，尽可能多地回答问题。 该方法的有效性取决于这两个模型之间尽可能松散的耦合，而我们能想象到的最松散的耦合是模型到模型转换的声明性规范，图 4 是其中的一个例子。
图 4 中的 XML 是一种低层次的表述，用户不应直接与之交互--可用性的改进应使模型到模型转换的声明性规范的编写和更新更加方便用户。在项目开始时，作者曾设想通过 UML 定型应用机制来执行这些映射（Batarseh 等人，2012 年）。然而，由于缺乏灵活性，这种设想很快就变得站不住脚了--应用 UML 定型有效地定义了一对一的转换规则，这就限制了系统模型和桥接抽象模型看起来非常相似，只是在语法上存在有效差异。作者接下来考虑了通用和标准化的模型到模型转换语言，包括 QVT 或 ATL，但转换规范相当冗长，而且很快就意识到，结合转换目标的知识可以极大地简化转换。这种简化损失了灵活性，但灵活性并不是必需的，这与 Cleenewerck 和 Kurtev（2007 年）的结论一致，即 "模型驱动工程中的转换语义问题最好使用特定领域的转换语言，而不是通用语言"。"未来的工作包括将定制的特定领域转换语言与 QVT 等标准相协调。
第五步：创建实例模型并按下 "开始"按钮。 要按下 "开始 "按钮回答可生产性问题，最后一步需要快速描述问题的主题--产品、流程、资源和设施的实例。图 3 中的元模型类似于软件类定义，可以产生大量的对象实例，而这一步需要创建这些对象实例。在试点项目中，这一步是在类似 Excel 的表格环境中完成的，图 5 是其摘录。
图 5 中的表格及其模式符合图 3 中的元模型--操作映射到表格，每个属性映射到列。实例模型的表格和模式是通过对象关系映射生成的，用户通过填写表格来描述问题的主题。这种建模环境可以从许多可用性改进中获益；其中之一是，显示给用户的表格实际上是原始的关系数据库表格，添加视图层可以简化、组织和隐藏冗余数据（例如，多重性上限大于 1 的任何属性的连接表）。另一项改进是，虽然图 5 显示了图 3 中每个元模型元素的表和列，但由于了解了用户的问题，因此可以只对与回答该问题相关的表和列进行可视化过滤。另一项改进是增加可视化功能，无论用户的系统模型是什么，随着表格行的填充，后台都会构建一个桥接抽象模型，至少流程和设施视图应该可以实现可视化。要最大限度地减少回答常规可生产性问题所需的时间和专业知识，改进该环境的可用性至关重要。
图 6 显示了一个离散事件模拟模型和实验的示例，按 "开始 "按钮后，模型和实验会自动生成。
业务影响
结论和未来工作
从设计到生产的转变是一个复杂的业务流程，本文所描述的研究通过让设计人员在程序设计周期中更早地了解设计决策对生产的影响来支持这一流程。我们开发了一种方法来实现按键式可生产性问题解答，其新颖之处在于它的分离程度--它将系统描述与系统分析分离开来，另外还将具体的前端系统描述与抽象的后端描述分离开来。试点项目的实施支持以 Ecore 语言编写的系统模型、第 3 节中列举的问题集，以及以 Simio、SimEvents 和 Tecnomatix 工厂仿真语言按键生成的仿真模型和实验，以回答这些问题。试点项目的问题涉及资源数量（参数变化），实施过程中还演示了如何适应结构变化，包括流程计划的变化、工作-工作站分配的变化、资源类型的细化、抽象层次的描述等。在撰写本报告时，参数变化和结构变化在功能上并无区别，因为在实例模型发生任何变化时，实施方案都会完全重新生成仿真模型，不过为了提高效率，未来可能会变得更加复杂。
试点项目结束后，概念验证软件实施部署给了试点客户。客户估计，对于生产系统的常规问题，使用该方法的工具实施可以大幅减少使用模拟和其他分析类型来回答这些问题所需的时间、成本和专业知识，至少可以减少一个数量级。这些减少的时间可以节省下来，也可以用来评估更多的生产方案及其影响，考虑更多的改进意见和替代方案，探索更多的生产系统设计空间。不过，客户也指出，要达到先进的技术就绪水平（TRL），并生产出分析人员在日常工作中欢迎的工具，还需要进行一些改进。该工具是一个建模和模型转换环境，需要对语言和用户界面进行改进，以创建系统描述模式、符合要求的系统实例模型、向桥接抽象模型的转换以及自动分析制定流程。这些改进将有助于确定哪些类型的生产系统问题实际上属于 "例行 "问题，而这可能是一组令人惊讶的问题。
我们希望这项研究能扩大运筹学分析的市场。统计、离散事件模拟和优化分析可以回答至关重要的问题，但在现状中使用这些方法所需的时间、成本和专业知识，除了最大的公司外，可能会让其他公司望而却步。未来的工作有很多途径，作者认为最紧迫的是将系统描述从主要的结构发展到包括行为和控制在内的更成熟的模型，以及了解包括设计、诊断和持续改进在内的更高层次的流程。对工业工程系统的深刻理解，加上根据需要经济高效地运用运筹学分析的能力，是使生产系统的设计与产品本身的设计一样复杂的先决条件。
致谢
本文所报道的研究得到了佐治亚理工学院制造系统 Gwaltney 讲座、Rockwell-Collins 基金以及联合技术研究中心和 Boeing-Georgia Tech 战略大学合作伙伴资助的研究项目的支持。