第5章详细作业建模

1、目录第 5 章 详细作业建模2模型 5-1：汽车维护车间35.2 新的建模特性45.2.1 多路径决策45.2.2 集合45.2.3 变量与表.55.2.4 子模型65.2.5 实体副本75.2.6 保持实体75.2.7 统计量和动画75.2.8 终态和稳态.85.3建模方法95.4 建模115.4.1 定义数据125.4.2 创建子模型175.4.3 生成预约呼叫185.4.4 预约服务225.4.5 服务活动265.4.6 更新性能指标变量29逻辑325.4.75.5 找出并纠正模型中的错误335.6 为汽车修理店模型添加动画效果435.7 模型 5-2：善汽车维修店模型485.8 模型

2、5-2 建模中的新问题495.8.1 集合与逻辑495.8.2 非平稳达到过程505.9 构建模型 5-2525.9.1 构建修理间模型525.9.2 对顾客到达过程建模555.10 模型 5-3：（s，S）库存系统.605.10.1 系统描述60模型625.10.25.11 小节725.12 习题72第 5 章 详细作业建模在第四章里展示了用“基本操作”面板里的模块可以创建的模型种类。这些模块都是一些相对而且容易使用的模块，但离建立足够详细的模型还有很长的距离。有时这些模块对读者们来说已经足够了。但有时还不行。在建模获得一些经验、所建模型越来越大、越来越复杂、越来越详细时，可能会发现需要对较

3、低层的、更详细的、或者与“基本操作”面板的模块所提供的对象不同的事物进行或者建模。Arena让你被迫接受这些固定的建模构件，也强迫你为考虑模型的各个方面而不得不学习一门编程语言或编程语法。相反地，它提供了几个不同的建模层次，从而为建立一些特殊逻辑结构的模型提供了较大灵活性。一种好的办法就是从高层模块开始，它们能走到哪儿你就建到哪儿（可能自始至终就是一层）。当你需要比它们更高的灵活性到更低、更详细的层次中去。这种结构你随意开发容易的建模结构，也你在需要的时候到低层建模。标准的 Arena 提供了所有这些建模能力，你能熟练掌握它们的用法。这一章探讨了一些（当然不是所有）在“高等操作”（Advanc

4、ed Process）面板和“操作块”（Block）面板中包含的低层详细建模构件；后一种面板提供了最底层的建模逻辑，其中的模块与作为Arena基础的SIMAN语言中的程序块一致。这里我们采用的例子是一个很复杂的汽车修理与维护车间的模型。我们也会谈到一点非平稳（时间相关）到达过程，模型调试，以及更的动画定制等重要问题。5.1节中给出了这个系统的描述，5.2节讨论了如何用一些新的Arena建模概念对这个系统建模，5.3节描述了一些基本的建模策略，5.4节给出了模型逻辑，5.5节讨论了模型调试问题，5.6节给出了一些调整动画细节的方法，以得到一些非标准的效果。在5.7和5.8节，我们对模型美化，并提

5、出了几种新的Arena建模概念。在5.9节，我们向你展示了如何修改原始模型，以创造出更精美的模型。本章于5.10节结束，我们在这一节中提出了一种完全不同的模型，库存系统，并借此机会展示了如何使用Arena最底层和最详细的建模层次，即包含了SIMAN语言的“操作块”面板。在读完本章后，你应该可以建立非常详细和复杂的模型，也可以探索出Arena建模的丰富而又深入的层次结构。模型 5-1：汽车维护车间位于某中等城市市区的大型汽车修理商，由于其维护业务增长太快而使得当前的设施不足，因此决定要扩建其汽车维护车间。由于当前所处的位置的限制，他们考虑在郊区再建一个有间的新车间。新建的车间不仅应能提供额外的维

6、护能力，而且应位于现有多数顾客的附近。为了能够对工作流进行更好的，由位于市区的车间对两个地方的工作进行安排，而且主要的修理工作也将继续在市区车间进行。根据该计划，顾客最多提前三个工作日在新的郊区车间打提出预约服务（在预约的当天不提供服务）。例如，在周三打预约的顾客可以在周四、周五或周一得到服务。如果无法为顾客在给定的后续三天时间安排服务的话，他们可以第二天再打一次，或者在市区预约要进行的工作。该汽车修理商具有顾务需求的大量数据，对这些数据的分析表明，顾客要求服务的呼入平均每天29次，全天都服从（平稳的）泊松过程（也就是说，呼入的时间间隔、且服从相同的指数分布）。对数据的分析还表明，55%的呼叫

7、者希望在第二天得到服务，30%希望在第三天；剩下的15%希望在第四天。如果不能安排在其选择的某一天内提供服务的话，他们有90%的可能性希望安排在之后的一天。大部分顾客（80%）会选择全天将车辆放在这里，而少数顾客（20%）愿意一直等到服务完成。如果顾客选择等待，他们将会给定一个近似的等待时间。这个等待时间等于预计的完成工作的服务时间（被称作预定时间（Book Time）再加上放宽因子（一个小时）。建立这个新车间的目标之一就是使顾客具有很高的满意度。因此，公司决定每天最多安排5个希望就地等待服务完成的顾客预约。无论实际服务时间是多少，该汽车修理商都用一组标准的估计服务时间（Book Times）

8、来计算服务成本。各类服务活动的预定时间可用一个带有位移和比例因子的-分布来表示（44+90*BETA(2，3)为分钟，且截断取整）。实际的服务时间与预定时间（Book Times）有些不同，它服从分布GAMM（Book Times/1.05，1.05）。该汽车修理商想使新车间，但不知道每天应该安排多少预约服务，现在的处理是基于每天所能安排的预定时间（Book Time）小时数的最大数量来进行的。这个值是基于三个修理间、每间每天可用的服务时间是8小时来计算的。因为实际服务时间往往与预定时间有所不同，所以最后时确定每天可供安排的间为24小时。假定每周有五个工作日，每天工作八个小时，每个修理间每小时

9、的成本估计为45包括所有的和劳动）。对顾客按预定时间的每小时78。因为实际服务时间与预定时间有一定的不同，所以该汽车修理商希望在修理开始的当天完成已安排好的服务。为了补偿服务时间的差异，每一个修理间每天最多可以加班3个小时。但是，加班的成本是每车间每小时120。如果服务在这个时间内无法完成，顾客的车辆就会在修理间放置过夜，服务在第二天完成。如果发生此事，那么汽车修理商会为顾客提供一辆替代车，为每辆替代车每天将花费修理商35。如果修理商的负荷较大，导致某车在当天的预约服务不能开始，此时假设顾客将的回家，第二天再开过来，因而就不需要替代车辆了。对该系统所关心的统计量有：每天的利润，每天的预定时间，

10、每天的实际服务时间，每天的加班时间，以及每天安排就地等待服务的顾客中没能完成的作业数量。5.2新的建模特性从的观点来看，这个问题与我们在第三第四章所研究的非常不同。最明显的区别是这个系统是一种服务性质的企业，而前面的系统是面向制造业的。虽然SIMAN语言最初的版本（Arena是以该语言为基础的）是为制造业的应用而开发的，但是现在Arena的应用到了服务系统的精确建模，包括快餐店、保险公司、服务中心和很多其它的企业。尽管这些系统都有各自的一些特点，但是基本的建模需求很大程度上与制造系统相同。现在，让我们看一下汽车车间，然后找出新的需求。随着工作的继续进行，会发现我们已有的建模结构还不足以完成如此

11、详细的系统建模。5.2.1 多路径决策进行服务预约它安排到合适的工作日，然后等待这一天的到来。为此，根据预约日的要求，我们需要将实体或预约送到该模型的五个不同的部分。虽然我们可以通过用一系列的“决策”模块（Decide）实现它，但是模型会变得难看而且也没有必要。你也许仍然还不太清楚，其实在第四三个模型里用到的Decide模块中可以含有三个或者的分支。5.2.2 集合随着模型越来越复杂，经常会发现需要模拟实体到达一个位置或站时，需要从几个相似（但是全等同）对象中选择一个。最常见的情况是从一组中选择可用的。假设有三个操作员：Shelley、Lynn和Charity。他们中的任何一个都可以完成需要的

12、任务，这时，只要他们当前都是空闲的，则可以选择这三个中的任何一个。“集合”模块（Set）为实现这种功能性提供了基础。Arena的集合包含了一组相似对象，这些对象可以通过集合名称和相应的下标来。这些对象了集合，每个对象是集合的一个成员。特定集合的成员都必须是同种类型的对象，例如、队列、图形等等。根据建模需要，可以将几乎任何一种Arena的对象收集到一个集合之内。一个对象也可以出现在一个以上的集合之内。例如在操作员集合（Operators）中包括了Lynn，但她又能作为一个调整，因此，可能会定义一个被称为“调整”（Setup）的集合，其中包括Lynn和Doug（Doug不是一个操作员）。现在，如果

13、需要一个操作员，就从名为Operators的集合中选取，如果需要调整，就从名为Setup的集合中选取。因为Lynn是同属于两个集合中的一个成员，所以可能会在任何一个情景下选择她。用户可以按需要任意选择集合的数目或集合间是否有重叠。对修理中心来说，我们用集合来建间模型、描述实体图形和预约队列。5.2.3 变量与表在很多模型中，可能会在多个不同的地方重复使用数据。例如，在一个模型中有几个地方可能需要生成来自相同分布的服务时间，并将它们输入到需要的模块中去。但是如果要在实验中更改这个分布的参数（或者分布本身），就必须打开每一个包括该服务时间的框来改变参数值。有时，我们可能需要跟踪系统中实体总数变化的

14、情形。还有的时候，我们可能在整个模型中需要使用很复杂的表，例如，可能根据零件类型来确定时间。Arena的“变量”（Variable）和“表”（Expression）模块可以容易地实现这几种要求。“变量”模块（Variable）用户定义的全局变量并赋初始值，而且还可以按照它们的名称加以。它们也可以被指定为一维或二维的数组。“表”模块（Expression）用户定义各类表和它们所关联的值。与变量相似，表也可以在模型中以它们的名称，可以被指定为一维或二维的数组。虽然变量和表看起来很相似，但是它们具有不同的功能。用户定义的变量可以一些能够在运行期间重新赋值的量。例如，我们可以定义一个叫做Wait Ti

15、me的变量（用以表示等待时间），其初始值为2，在需要使用该量的地方输入变量名即可。我们也可以定义一个叫做Number in System的变量（用以表示系统中的零件数），其初始值为0。每次新零件进入这个系统，就在这个变量上加1；每次一个零件系统就减1。对汽车车间来说，我们用一个名位Day的变量来跟踪这一周的当前日。我们还会用很多变量来如何获得预约，如何在运行结束时收集用于计算统计量的信息。与此不同，用户定义的表不能数值，而是提供了一种将某个名称和特定的数学表关联起来的方式。当名称在模型中被时，相表就会被计算出来，并返回其数值。例如，表可被用来计算一些分布或复杂等式的值，而计算公式中又包含了实体

16、的属性值或者系统变量值的当前值。如果在模型中数学表只用在一个位置，将它输入到相应的位置可能会更容易。但是，如果表被用在几个位置或者要用的表的形式依赖于实体的属性，那么用户定义表通常会更好。对汽车车间来说，我们会用Expression模块（在“高等操作”面板中）来定义所生成的预定时间、实际服务时间和预定需求的类型（等待还是离开）这些表。变量和表有很多其它的用处，随着对Arena的进一步熟悉，这一点会越来越明显。5.2.4 子模型在开发庞大而复杂的模型时，通常将模型分割成小的模型是有好处的，这种小的模型被称为原模型的子模型（subms），它们之间可能互相有交互，也可能没有。这会为建模与测试过程提供

17、便利。例如，我们可以将汽车车间模型分割成五个明显的（我们认为它们很明显）子模型：生成预约呼叫、进行预约、服务活动、更新性能变量和逻辑。Arena以子模型的形式提供了这种分解能力。这种特点将模型分成不同层次的视图，也即子模型，每一个都在屏幕上有完整的工作空间。你既可以一次一个子模型，也可以模型全景（也即顶层 (Top-Level) 模型）。每一个子模型都可以包括常规的模型窗口（例如“电子数据表格”模块、静态图形和动画元素）所支持的各种对象。子模型本身也可以包括更低层的子模型；可以无限地嵌套下去。子模型可以连接到其它的模块中去，也连接到其它的子模型中去，或者孤立地处于一个Arena模型中。在顶层模

18、型视图和每一个子模型视图中，为了在逻辑区和动画区的不同区域中提供容易的导航，可以建立带有相关热键名视图”。工程工具栏的“导航”面板（Navigate）可显示出列有顶层模型、所有的子模型、以及它们所以命名视图的树状结构。点击一个命名视图的或子模型视图即可显示该模型所在的区域，这使得在视图内和视图间的导航变得非常容易。虽然以上汽车车间模型还不像很多实际模型那么大，也没有那么复杂，但是我们仍然用子模型来组织流程，并阐明概念。5.2.5 实体副本在开始更复杂的建模时，通常会发现创建“实体复本”的必要性。这些实体通常被用作实体，可以完成许多功能。这种用法的一个很好的例子将在9.3节介绍，在那里会讲到实体

19、的受阻离开和中途等现象。也有的时候需要在模型的某处将一批实体集一个实体（也即将零件装盘），然后在模型的另一处再将成批实体分成单个。在9.4节加以说明。在汽车车间模型里，我们需要创建实体副本，让它代表要求预约的来电。可使用“基本操作”面板中的“分离”模块（Separate）来创建或克隆实体的副本。5.2.6 保持实体模型中有时需要将实体保持在某个位置，直到系统这些实体行进的特定情况发生为止。我们已经看到其中的一种形式 ¾ 实体在排队等待空闲。但在此我们考虑更一般的情况，实体被保持的位置是由模型中其它地方的活动所决定的，如系统时间或系统条件。Arena提供了两种不同的保持实体的方法。第法

20、是实体被保持到由另一个实体发出行进信号为止；第二种方法是实体被保持到某些系统条件出现为止。在汽车车间模型中采用第法，可通过使用“保持”模块（Hold）和“信号”模块（Signal）来实现，也即将顾客的预约一直保持到安排对他进行服务的为止。第二种方法将在9.4节介绍。5.2.7 统计量和动画我们需要的统计量也是比较平常的，与前面模型中收集到的没有很大不同。但是，系统的类型和分析需求却截然不同。先看一下分析需求。在分析服务系统时常见的目标是利润最大化或顾客满意度最大化，还有成本最小化（当然，从意义上讲，它们是相互的目标）。该汽车修理车间顾客满意度的关键测度的是在所承诺的完成服务时间以外的等待服务的

21、顾客数。很明显，我们的目标就是使其最小化。影响这些测度的关键因素是各天所安排的等待服务的最大顾客数。创建模型后，我们可以很容易地增加或减小这个数，并确定其对性能指标的影响。我们需要认真考虑要运行多长时间，以及所要建立的系统的类型。下一节会涉及到这些。分析和提高利润是一个更加的问题。预约是基于Book Time的，而各天所需要的实际服务时间可能有很大的不同。因此，我们如果想要模型变量以提高利润，那需要知道改变这些变量所造成的影响。通常的输出总结报告是直接给出这个信息的。但是我们可以通过增加一些统计量来收集和提供所需信息，这不难做到。查看动画运行应该是很有帮助的，就像在观测实际系统一样。遗憾的是，

22、与以前的模型不同，一般很难为这种系统加上动画效果以使其展示运行状况。我们可以用动画模拟预约的队列和，但是相应的动画却是非常跳跃的，而且也不能提供我们所需要的时间方面的信息。虽然经常也这类系统的动画，但是这些动画一般都是用来“展示”而不是进行分析的。不过既然已经提及，我们还是会在5.6节介绍如何给这种模型加上动画的。5.2.8 终态和稳态大部分（尽管不是所有的）可以被分为终态和稳态两大类。这主要是研究的意图或目的方面的问题，与模型内部的逻辑或架构没有多。终态（terminating simulation）是模型规定了特定的开始和结束条件的，这些条件是对实际系统需求的真实反映。正如它的名字所体现的

23、，会按照模型规定的特定规则或条件终止运行。例如，一个商店在上午9点开门，开门时店内没有顾客；在晚上9点关门，并继续服务到所有的顾客都离开。再看一个车间的例子，它则运行到生产出订单所规定的500个装配件为止。这一类型的关键是有一个明确定义的（虽然在开始时可能是未知的）、自然的结束的时间，也有一个明确定义的启动方式。与终态不同，稳态（steady-state simulation）则是通过长时间运行来对某些性能指标加以估计的形式；也就是说，理论上的时间应该是无穷大。上，这种的初始条件是无关紧要的（虽然通常在实际中不是这样）。当然，稳态也必须在某一个时间点停止，不过正如所那样，会运行很长时间，因此需

24、要设法保证它运行的时间足够长。在7.2节讨论这个问题。有关稳态的例子也很多，例如一个儿科室在实际中永远停止或重新开始，因此稳态对此会很合适。有时候某些系统在实际中会有终止状态，但为了设计其某种最坏的或者负荷最大的情况，仍可以采用稳态仿真模式进行。现在为汽车修理车间模型选择应该用哪种形式。虽然根据定义能看出终态系统和非终态系统的差别很明显，但在实际很少如此。一些系统刚开始时采用一种类型，但是更进一步检验后却发现它们实际上属于另外一种。再加上有些系统同时包括两种类型的因素，这就使得这一更加复杂了，此时往往依据分析所处理的问题的类型来确定的分类。例如，考虑一个在上午11点开门，晚上11点关门的快餐店

25、。如果对该快餐店的日常问题感，就可用非平稳泊松到达过程，并将系统看成是终态进行分析。如果只对发生在午饭前后两个小时内的期的感，则可以假设系统是一个以峰值到达率到达的平稳过程，并可将这个系统作为稳态系统进行分析。乍一看，汽车修理车间很像是一个终态系统，这个系统似乎可以以态开始和终止。但也有可能某天不能完成所有的工作（记住我们只三个小时的加班）。需要在车间放过夜的车辆会对第二天的初始条件有很大影响，因此我们可以将系统考虑成稳态的。假如情况并非如此，会继续在第六章将汽车车间问题作为终态系统进行分析。5.3建模方法在第一章的图1-2中，简要讨论了Arena的层次结构。这种结构将任何层次的建模构建组合在

26、一个模型中。在第三第四，我们基本上都是利用“基本操作”面板中的构件来开发我们的模型，尽管在处理故障或其它特殊统计量时确实也用到了几种在“高等操作”面板里的数据模块。在创建模型时，我们推荐一般情要尽可能维持在最高的层次上构建模型。但是，当发现这些构件已无法描述必要的细节时，你就应该将模型的某些部分移到下一层，而不能牺牲模型的准确性。你可以将不同层次和面板中的的建模构件同一个模型中混合使用。随着对各种面板（和建模层次）的进一步熟悉，你会发现能够很自然地这么做。在继续建模工作进行之前，先简要讨论一下可用的面板。“基本操作”面板（Basic Process）提供了最环境。使用该面板可以既迅速又容易地创

27、建大部的模型。“创建”模块（Create）、“操作”模块（Process）、“决策”模块（Decide）、“赋值”模块（Assign）、“”模块（Record）、“分批”模块（Batch）、“分离”模块（Separate）和“清除”模块（Dispose）的综合运用可具有很大的灵活性。实际上，如果研究一下这些模块，就会发现有很多其他的特点我们还没有探讨。在很多情，仅单独使用这些模块就能提供项目需要的所有细节。因为这些模块提供了几乎所有模型都需要用到的常见功能，因此不管所希望的建模细节处于哪一层，你都有可能用到以上模块。“高等操作”面板（Advanced Process）提供了其他一些更详细的建模

28、能力，补充了“基本操作”面板的功能。例如，“占用-延时-”模块（Seize-Delay-Release ）的组合就提供了与Process模块基本相同的建模逻辑。“高等操作”面板中的模块的一个有用特点就是你可以将它们放在模型中几乎所需要的任意组合体中。实际上，很多有经验的建模都是从这一层开始，因为他们感觉由此建立的模型对用户来说会更明晰。“高等运送”面板（Advanced Transfer）提供用于物料搬运活动方面的构件（如运送设备和传送设备）。与“高等操作”面板提供的一般的建模能力相似，“高等运送”面板中的模块在为物料搬运系统建模时也具有很高的灵活性。“操作块”面板（Blocks）提供了更低层

29、次的建模能力。实际上，它提供了用来创建“基本操作”面板、“高等操作”面板和“高等运送”面板中所有模块的基本功能。另外，它还提供了很多在模块中不能实现的其它特殊用途的建模构件。如“while”循环、概率和逻辑组合分支、以及自动搜索等特征。你可能注意到其中的几个模块与那三个面板中的模块有相同的名称。尽管名称一样，但模块却是不同的，能够通过颜色和形状来区分这两种模块。如果你以前用过SIMAN语言，并在其中分别定义过模型文件和实验框架（即使在Arena中你也可以这么定义），那么“操作块”面板和“基本操作”面板、“高等操作”面板以及“高等运送”面板之间的差别就很容易解释了。这些差别最好通过两类面板中的A

30、ssign模块来阐明。在使用“基本操作”面板的Assign模块时，你可以随意选择合适的赋值类型。如果给一个新的属性赋值，Arena会自动定义这个新的属性并将它加入到模型各处的“属性下拉列表”中。尽量在最建模的一个就是“操作块”面板中的模块没有这么方便，其中的Assign模块只能完成简单的赋值，不能定义新的属性。虽然有这样的缺点，但在“操作块”面板中的模块仍具有一些其它面板所不具备的强的特征。另外，“构模元素”面板（Elements）中也有实验框架方面的模块。例如，在这里可以利用Attributes模块定义新属性。由于建模时可与更次面板中的模块相混合使用，所以实际中很少需要这些功能。但是如果某些

31、特殊问题需要建立一个最低层的模型（如使用VisualBasic、C、和FORTRAN等程序设计语言的功能），则也可通过Arena接口加以调用。“操作块”面板和“构模元素”面板也提供了为连续系统建模而设计的模块，这些内容将在第11章介绍。现在让我们返回到汽车维修车间模型中，该模型确实要用到“基本操作”面板中的模块所不具备的特点。在开发模型时，我们会同时用到“基本操作”面板和“高等操作”面板中的模块（在本章的结尾，会用“操作块”面板和“构模元素”面板个库存模型）。在一些情，确实需要用到较低层的构件；而在其它情，就只是展示一下它们的特性。在创建含有低层构件的模型时，开发模型的稍有不同。 如果仅有较的

32、构件，一般可对活动进行分组，然后再使用适当的模块加以建模。而如果含有较低层的构件，就需要对实际活动有细致的描述。从某种意义上说，你的模型要能成为刻画这些活动的详细的流程图。不过要做到这一点并不容易，除非你对各种模块的逻辑非常熟悉。5.4 建模在此，我们把模型分成几个部分，分别直接对各个部分进行开发，同时介绍各部分的功能。以下按顺序分别介绍七个部分：5.4.1节：定义数据，5.4.2节：创建子模型，5.4.3节：生成预约呼叫，5.4.4节：进行预约，5.4.5节：服务活动，5.4.6节：更新性能指标变量，5.4.7节：逻辑。数据一节包括建模所需要的数据模块，接下来一节会说明如何创建子模型，剩下的

33、五部分每一个作为子模型加以开发。最后得出的顶层模型窗口外观上类似于图5-1。因为以后才给模型加上动画，所以我们这里先删除包含在模块中的所有动画对象。当读完下面有关建模的七个部分后，你可能能感觉到，这是个模型所遵循的基本步骤。理想情，人们总希望能够先对模型的结构有一个比较好的，以使其比较容易建立。但是在实际中，你会常常返回到先前完成的部分，不断对模块或数据加以增、删、及修改。因此在开发复杂模型时，一定不要指望能一次就（我们当然也）。5.4.1 定义数据让我们从Run>Setup菜单框开始。在Project Parameters表页中的Project Title栏内输入项目名称。在Repli

34、cation Parameters表页中，我们随便设定为重复运行10次，每次仿真20天。因为希望输出报告中的是小时，所以这里选择Hours作为基准时间（BaseTime Unit）。由于实际系统开始是空的（除非有车辆放过夜，以及在随后3天有预约）， 因此可令预备运行时间的长度（Warm-up Period）为0。因为设定了多次重复运行，所以需要告诉Arena在相邻两次重复运行之间要做什么。有四种可能的选项。选项1：初始化系统（是），初始化统计量（是）这会进行10次统计上而且相同的重复运行并生成相应的报告，每一次都是在时间0时开始且系统初始状态为空，每一次都运行240个小时。随机数发生器（见12

35、.1节）在重复运行之间连续产生同分布的（IID）随机数。在前一次结束时可能需要放过夜的车辆在下一次重复开始不被保留。选项2：初始化系统（是），初始化统计量（否）这会进行10次重复运行，每一次都在时间为0时开始且系统初始状态为空，每一次都运行240个小时，但输出报告中的统计结果是各次累积的。因此，报告2会包括前两次重复运行的统计结果，报告3会包括前三次重复运行的统计结果等等。这里的随机数发生器的运行也象在选项1中一样。选项3：初始化系统（否），初始化统计量（是）这会进行10次运行，第一次从时间0开始，第二次从240开始，第三次从480开始等等。因为系统在多次重复运行之间没有进行初始化，所以时间会

36、连续增加，任何放过夜的车辆都会被带到下一次重复运行中。报告只包括单独一次重复运行的统计量，而不是多次累积的结果。选项4：初始化系统（否），初始化统计量（否）这样也会进行10次运行，第一次从时间为0开始，第二次从240开始，第三次是从480开始等等。因为系统在多次重复运行之间没有初始化，所以时间将连续增加，任何放过夜的车辆都会被带到下一次重复运行中。但这时输出报告中的结果是累积的。第10次报告的结果将与做一次时间为2400个小时的单次运行是一样的。理想情，我们不希望有很多车辆在修理间过夜，因而希望采用的重复运行模式。这意味着要么选择选项1，要么选择选项2。此处将选择选项1（有详细情况见第6章）。

37、本例共有三项（间）。所有这三项都是可变容量的（在4.2节已作过讨论）。我们可以为每一种单独定义一个容量调度；但是由于它们的容量调度形式是一样的，所以可以简单地重复使用单个调度（尽管这么做会使你的模型在将来可能产生变化时减少了灵活性）。在建立这种容量调度时，可使用图示调度编辑器（Graphical Schedule Editor），在Options框中将time slots的个数设定为12，将图中y轴的um capacity设定为2（我们实际上可以设定它为1）。容量调度如图5-2所示。你可能注意到，该容量调度要求这3个修理间每天有11小时可用，每天工作8小时，再加上可能有3个小时的加班。在每天的

38、第一个小不能用，因为要用这一个小时来调度未来的预约，并当天的顾客在这个时候到达。就是定义。我们为容量调度类型选择“优先抢占”（Preempt）选项，因为车辆在标准的8小时工作和的3小时加班后有可能仍未完成服务。在这种情，将停止对该车辆上的工作，并选择在第二天完成该项工作。最后的电子数据表格视图如图5-3所示。定义完以后，就可以用“基本操作”面板中的“集合”模块（Set）来定义集合了。利用Set模块可以定义集合、计数器集合、计数型统计量集合、实体类型集合以及实体图形集合，也可以利用“高等操作”面板中的“高等集合” 数据模块（Advanced Set）来定义其它的Arena对象集合。点击Set模块

39、，然后在电子数据表格视图中双击相应位置以添加一个新的条目，这样就可以定义一个集合。我们会带你详细了解创建该集合的细节。在Name单元格中输入Bays，从Type单元格的下拉列表中选择Resource。接下来定义集合中的成员，点击Member栏的“0 Rows”按钮，打开包含所定义的各项的电子数据表格，然后双击相应位置打开一个新的空行。因为已经定义了，所以可以用下拉列表中选择每个成员的名称。已完成的Bays集员的电子数据表格视图如图5-4所示。下面定义两个实体图形的集合，Customer（顾客）和Vehicles（车辆）。每一个集合都有两个成员，分别表示在等待的顾客和将车辆留下来的顾客。已完成的

40、Set数据模块如图5-5所示。我们还需要创建一个队列集合以存放将来的预约。首先，需要用“基本操作”面板中的“队列”模块（Queue）定义五个队列（周一预约队列到周五预约队列）。然后，利用“高等操作”面板中的Advanced Set模块来定义队列集合。在Name单元格中输入AppointmentQueues，从Type单元格的下拉式列表中选择Queue。然后在电子数据表格中输入五个队列成员的名称，类似于前面的集合。该集合的五个成员如图5-6所示。，用“基本操作”面板中的“变量” 数据模块（Variable）来定义变量。应该指出的是我们没有必要一定利用这个模块定义变量。当你在所需的某处（例如Ass

41、ign模块）定义一个新变量时，Arena会将这个新变量的信息自动输入到Variable数据模块中。但是，如果需要定义数组变量或所定义变量的初始值不为零，那必须要使用这个模块来设定所需要的数组大小或变量初始值。本例将总共定义15个变量。前六个变量是用来模型的：保存当前日期的变量（Day），初值为4（后面再详加叙述）；用来保存当天预约作业的预定时间（Book Time）当前值的数组变量（Day Load）；预定时间小时数的最大值（Max Load），初值为24；等待服务完成的顾客数的最大值（Max Wait），初值为5；用来保存当天等待作业数的当前值的数组变量（Wait Load）；以及每天打入要

42、求预约的平均顾客数（Calls Per Day），初值为25。下面三个变量（以及最后两个变量）将在运行结束时用来计算累积输出值：到现在为止完成的预定时间小时数的总数（Day BookTime）；到现在为止完成的实际服务时间小时数的总数（Day Actual Time）；到现在为止完成的加班时间小时数的总数（Day Overtime）；当前在修理间存放过夜的车辆的存放总天数（Total OT）；被延期的等待作业的当前数量（DayWait Late）。中间的四个变量将被用于逻辑：中当前工作日的序号（Work Day）；当日的工作开始时间（Day Start Time）；当日的正常工作（不包括加班）

43、结束时间（Day End Time）；用来决定等待作业是否被延期的宽放量（Wait Allowance），初值为1。最后的电子数据表格视图如图5-7所示。我们还需利用 “高等操作”面板中的“表” 数据模块（Expression）来输入模型所需的几个表，包括用于确定每个呼入顾客的预定时间的表，用于确定顾客是否想要等待的车辆的表，以及确定实际服务时间的表。这样就可以很容易地根据需要将这些分布直接输入到模型中去。从上一段讨论的第一个表开始。打开Expression模块，在Name单元格为第一个表达式输入名称Book Time Expression，然后在Expression Values单元格输入A

44、INT (44+90* BETA(2,3) ) /60。可以简单地将上式用键盘敲入，或者用“表构造器”为其输入。因为大部分汽车修理车间的预定时间都是以整数分钟表示的，所以我们用Arena中的表AINT截去小数部分，返回一个不大紧邻该数的整数（AINT函数是Arena的很多内置数学函数之一，这些函数完整的可以在帮助菜单中的“数学表”（Mathematical Expressions）主题下找到）。注意，结果除以60，以把时间转化为小时。第二个表（Wait Priority Expression）用来决定顾客是否会一直等到其服务完成。其表DISC（0.20,1,1.0,2），它将会以0.2的概率返

45、回1，以0.8的概率返回2。在这种情况下，1就意味着顾客会等到服务完成。最后一个表与前面的表有关，因为它需要用到第一个表得出的值。在生成预定时间它在一个叫做Book Time的实体属性中。随后将把Book Time属性值带入GAMM（Book Time/1.05,表Service Time，用于生成实际服务时间，其表Actual1.05）。最终的数据项需要“高等操作”面板中的“统计”模块（Statistic）。其中所有的条目都是输出类型的（Output Type），这就意味着这些值只能在每次重复运行结束时求取。前面三个条目以小时为计算每天服务所需的平均预定时间、平均实际服务时间和平均加班时间。

46、利用前面定义的变量就可以计算这些值。第四个表是求取平均每天被延期的等待作业数量。最后一个统计量由三项组成，用于计算平均每天的利润。第一项（Day Book Time / WorkDay）*78，表示根据预定时间按每小时78计算的已完工工作的收入。第二项（DayOvertime / Work Day）*120，表示因加班而导致的成本。最后一项的前半部分（Total OT / WorkDay）*35是由于需要为没能在预定时间内完成服务的顾客提供替代车辆而造成的损失，第二部分24*45是资金和人力成本。这些表可以直接输入，也可以用“表构造器”输入。最终的电子数据表格视图如图5-8所示。以上完成了所需

47、的数据定义工作，现在可以建立模型逻辑了。5.4.2 创建子模型通过选择菜单Objects>Subm>Add Subm可创建子模型。此时鼠标指针将会变成十字形，将它移到你想放置子模型的那个模型窗口中，点击一下就可将其放好，如图5-9所示。这个子模型对象的名字是Subm跟着1个数字，该数字随着子模型的添加而递增。若要将子模型对象的名字按的要求定义，则鼠标右击该子模型，选择Properties项打开子模型属性窗口，如输入界面5-1所示。第一个子模型命名为Generate AppointmentCalls（生成预约呼叫）。新的子模型默认有一个进入点和一个离开点。对第一个子模型来说，将进入点

48、数量改为0，因为这个特殊的子模型仅被用来利用Create模块为模型的其它部分生成呼叫。可以在Description栏输入对子模型的一些描述，不过由于这个模型很简单，仅用名字就描述得足够清楚了，所以此处就不输入的描述了。按照以上过程创建剩下的四个子模型，使得最后的视图看起来如图5-1所示。在创建过程中，你可能需要注意该图中每一个子模型进入点和离开点的个数。一旦将所有子模型放在合适的位置，并赋予它们正确的属性，就可以开始构造模型逻辑了。若要打开子模型并添加或编辑模型逻辑，只需要双击子模型或者用“工程栏”中的的“导航”（Navigate）面板在子模型和顶层模型之间来回切换即可，如图5-10所示。若要

49、关闭子模型窗口，你可以用Navigate切换，或在子模型窗口中的空白处右击鼠标，并选择Close Subm即可。现在我们已经可以建立实际模型了。5.4.3 生成预约呼叫这个子模型会生成每天的预约呼叫，并将它们传送到下一个预约处理的子模型。除了第一天以外，逻辑过程都是非常直观的。在子模型成单个的实体（每12个小时一个），确定当天呼叫的次数，变量Day递增，创建足够多的实体副本使当天的离开实体数量等于呼叫的数量，最后为每一个离开的实体赋必要的属性值。回忆一下，顾客只预约未来三个工作日中的某一天。因为我们假定没有预备时间（Warm Up），所以我们应当认为在第一天开始时已经有预约了。因此我们首先需要

50、检查一下是否处在第一天。如果是的话，就创建三个实体副本当作将要处理的预约。因为Day变量初值为4（周四），所以它将被递增到5（周五），并且初始时相当于包含了三天的顾客预约呼叫（周一、周二或周三）。接下来会将变量Day重置为周一，并让初始实体生成预约呼叫。生成预约呼叫、并为变量和属性赋值的模块如图5-11所示。我们已经使用过这些模块类型中的大部分，其中两个新的模块，“延时”模块（Delay）和“分离”模块（Separate），分别来自“高等操作”面板和“基本操作”面板。该子模型的逻辑过程可以总结如下：第一个模块是Create，用以在每天的开始时创建实体，如输入界面5-2所示。在Name和Enti

51、ty Type栏输入相应的名称和实体类型，常数12小时表示的到达间隔时间（每天的时间长度），以及第一次创建实体的时间（第0.01小时）。剩余数据接受默认值。我们希望在建立了逻辑子模型后，再解释为什么在创建第一个实体时加入了微小的延迟，要不然等到那里时你可能就已经忘了这件事了！在第一个Assign模块中，对变量Day递增1，并令变量Call Number（呼叫数）的值为1，如输入界面5-3所示。然后，这个实体被送到名为Check for Startup的Decide模块，这个模块能使实体的运动按照某种可能性或条件而产生分支。分支的目的地是由图形连接定义的。到达实体将检查每一个所定义的分支选项，并

52、前往满足条件的第一个分支的目的地。如果所有的指定条件都没满足，实体将会自动从模块底部的False离开点离开。在此处的Decide模块中（如输入界面5-4所示），我们在Type处选择了2-Way by Condition选项，以检验当前是否处在运行的开始时间，也即当前的时间是否是小于1的。如果是，就将实体送到下面的Separate模块；否则，就将它送到为呼叫数量赋值的Assign模块。一个条件可以是任何有效的表，但是典型情会包含一些比较运算。这些条件可以包括表5-1中的任何符号，以及逻辑表。表5-1 Decide模块中的条件符号描述语法选项描述语法选项与 大于小于等于或大于等于小于等于不等于.A

53、ND.GT.LT.EQ.OR.GE.LE.NE.><= =>=<=<>如果是处在开始时刻，实体将被送到后面的Separate模块（在“基本操作”面板中），如输入界面5-5所示。Separate模块可以对到达实体进行，也可以将组批的实体分拆成为其初始的单个实体（内容详见9.4节）。在模型中，创建三个实体复本，以生成前三天的预约。要实现这一点，可在Type中选择Duplicate Original选项，在# ofDuplicates栏输入3作为副本数量。注意，该模块有两个离开点，原先的实体将从上面的点离开，而三个实体复本将从下面的点离开。现在跟着这三个实体复本，它们被送到后面的Assign模块，在这个模块中用泊松分布来生成呼叫数量（Number of Calls），泊松分布的均值储存在前面定义的变量Calls per Day中，如输入界面5-6所示。然后，实体被送到第二个Decide模块，在这个模块里，检验变量Day的当前值有没有超过5，如输入界面5-7所示。这个变量保存了当前处于本周的第几个工作日，范围从1到6。在第一个Assign模块对此变量