arena中文教程第5章

第5章详细作业建模在第四章里展示了用“基本操作”面板里的模块可以创建的模型种类。这些模块都是一些相对高层而且容易使用的模块，但离建立足够详细的模型还有很长的距离。有时这些高层模块对读者们来说已经足够了。但有时还不行。在建模获得一些经验、所建模型越来越大、越来越复杂、越来越详细时，可能会发现需要对较低层的、更详细的、或者与“基本操作”面板的模块所提供的对象不同的事物进行控制或者建模。Arena不会让你被迫接受这些固定的建模构件，也不会强迫你为考虑模型的各个方面而不得不学习一门编程语言或编程语法。相反地，它提供了几个不同的建模层次，从而为建立一些特殊逻辑结构的模型提供了较大灵活性。一种好的办法就是从高层模块开始，它们能走到哪儿你就建到哪儿（可能自始至终就是一层）。当你需要比它们更高的灵活性时，就到更低、更详细的层次中去。这种结构允许你随意开发容易的高层建模结构，也允许你在需要的时候到低层建模。标准的Arena提供了所有这些建模能力，你能熟练掌握它们的用法。这一章探讨了一些（当然不是所有）在“高等操作”（AdvancedProcess）面板和“操作块”（Block）面板中包含的低层详细建模构件；后一种面板提供了最底层的建模逻辑，其中的模块与作为Arena基础的SIMAN仿真语言中的程序块一致。这里我们采用的例子是一个很复杂的汽车修理与维护车间的模型。我们也会谈到一点非平稳（时间相关）到达过程，模型调试，以及更高层的动画定制等重要问题。5.1节中给出了这个系统的描述，5.2节讨论了如何用一些新的Arena建模概念对这个系统建模，5.3节描述了一些基本的建模策略，5.4节给出了模型逻辑，5.5节讨论了模型调试问题，5.6节给出了一些调整动画细节的方法，以得到一些非标准的效果。在5.7和5.8节，我们对模型进一步完美化，并提出了几种新的Arena建模概念。在5.9节，我们向你展示了如何修改原始模型，以创造出更精美的模型。本章于5.10节结束，我们在这一节中提出了一种完全不同的模型，库存系统，并借此机会展示了如何使用Arena最底层和最详细的建模层次，即包含了SIMAN仿真语言的“操作块”面板。在读完本章后，你应该可以建立非常详细和复杂的模型，也可以探索出Arena建模的丰富而又深入的层次结构。模型5-1：汽车维护与修理车间位于某中等城市市区的大型汽车修理商，由于其维护与修理业务增长太快而使得当前的设施不足，因此决定要扩建其汽车维护与修理车间。由于当前所处的位置的限制，他们考虑在郊区再建一个有三个修理间的新车间。新建的车间不仅应能提供额外的维护与修理能力，而且应位于现有多数顾客的附近。为了能够对工作流进行更好的控制，由位于市区的车间对两个地方的工作进行安排，而且主要的修理工作也将继续在市区车间进行。根据该计划，允许顾客最多提前三个工作日在新的郊区车间打电话提出预约服务（在预约的当天不提供服务）。例如，在周三打电话预约的顾客可以在周四、周五或周一得到服务。如果无法为顾客在给定的后续三天时间安排服务的话，他们可以第二天再打一次电话，或者在市区预约要进行的工作。该汽车修理商具有顾客服务需求的大量数据，对这些数据的分析表明，顾客要求服务的呼入电话平均每天29次，全天都服从（平稳的）泊松过程（也就是说，呼入电话的时间间隔独立、且服从相同的指数分布）。对数据的分析还表明，55%的呼叫者希望在第二天得到服务，30%希望在第三天；剩下的15%希望在第四天。如果不能安排在其选择的某一天内提供服务的话，他们有90%的可能性希望安排在之后的一天。大部分顾客（80%）会选择全天将车辆放在这里，而少数顾客（20%）愿意一直等到服务完成。如果顾客选择等待，他们将会给定一个近似的等待时间。这个等待时间等于预计的完成工作的服务时间（被称作预定时间（BookTime））再加上放宽因子（一个小时）。建立这个新车间的目标之一就是使顾客具有很高的满意度。因此，公司决定每天最多安排5个希望就地等待服务完成的顾客预约。无论实际服务时间是多少，该汽车修理商都用一组标准的估计服务时间（BookTimes）来计算服务成本。各类服务活动的预定时间可用一个带有位移和比例因子的β-分布来表示（44+90*BETA(2，3)，单位为分钟，且截断取整）。实际的服务时间与预定时间（BookTimes）有些不同，它服从伽马分布GAMM（BookTimes/1.05，1.05）。该汽车修理商想使新车间盈利，但不知道每天应该安排多少预约服务，现在的处理是基于每天所能安排的预定时间（BookTime）小时数的最大数量来进行的。这个值是基于三个修理间、每间每天可用的服务时间是8小时来计算的。因为实际服务时间往往与预定时间有所不同，所以最后确定每天可供安排的时间为24小时。假定每周有五个工作日，每天工作八个小时，每个修理间每小时的成本估计为45美元（包括所有的资本和劳动）。对顾客按预定时间的每小时78美元收费。因为实际服务时间与预定时间有一定的不同，所以该汽车修理商希望在修理开始的当天完成已安排好的服务。为了补偿服务时间的差异，每一个修理间每天最多可以加班3个小时。但是，加班的成本是每车间每小时120美元。如果服务在这个时间内无法完成，顾客的车辆就会在修理间放置过夜，服务在第二天完成。如果发生此事，那么汽车修理商会为顾客提供一辆替代车，为每辆替代车每天将花费修理商35美元。如果修理商的负荷较大，导致某车在当天的预约服务不能开始，此时假设顾客将自己的车开回家，第二天再开过来，因而就不需要替代车辆了。对该系统所关心的统计量有：每天的利润，每天的预定时间，每天的实际服务时间，每天的加班时间，以及每天安排就地等待服务的顾客中没能完成的作业数量。5.2新的建模特性从仿真的观点来看，这个问题与我们在第三章和第四章所研究的非常不同。最明显的区别是这个系统是一种服务性质的企业，而前面的系统是面向制造业的。虽然SIMAN仿真语言最初的版本（Arena是以该仿真语言为基础的）是为制造业的应用而开发的，但是现在Arena的能力也应用到了服务系统的精确建模，包括快餐店、银行、保险公司、服务中心和很多其它的企业。尽管这些系统都有各自的一些特点，但是基本的建模需求很大程度上与制造系统相同。现在，让我们看一下汽车车间，然后找出新的需求。随着工作的继续进行，会发现我们已有的建模结构还不足以完成如此详细的系统建模。5.2.1多路径决策进行服务预约时，将它安排到合适的工作日，然后等待这一天的到来。为此，根据预约日的要求，我们需要将实体或预约送到该模型的五个不同的部分。虽然我们可以通过用一系列的“决策”模块（Decide）实现它，但是模型会变得难看而且也没有必要。你也许仍然还不太清楚，其实在第四章前三个模型里用到的Decide模块中可以含有三个或者更多的分支。5.2.2集合随着模型越来越复杂，经常会发现需要模拟实体到达一个位置或站时，需要从几个相似（但是不完全等同）对象中选择一个。最常见的情况是从一组资源中选择可用的资源。假设有三个操作员：Shelley、Lynn和Charity。他们中的任何一个都可以完成需要的任务，这时，只要他们当前都是空闲的，则可以选择这三个中的任何一个。“集合”模块（Set）为实现这种功能性提供了基础。Arena的集合包含了一组相似对象，这些对象可以通过集合名称和相应的下标来引用。这些对象构成了集合，每个对象是集合的一个成员。特定集合的成员都必须是同种类型的对象，例如资源、队列、图形等等。根据建模需要，可以将几乎任何一种Arena的对象收集到一个集合之内。一个对象也可以出现在一个以上的集合之内。例如在操作员集合（Operators）中包括了Lynn，但她又能作为一个调整人员，因此，可能会定义一个被称为“调整”（Setup）的资源集合，其中包括Lynn和Doug（Doug不是一个操作员）。现在，如果需要一个操作员，就从名为Operators的集合中选取，如果需要调整人员，就从名为Setup的集合中选取。因为Lynn是同属于两个集合中的一个成员，所以可能会在任何一个情景下选择她。用户可以按需要任意选择集合的数目或集合间是否有重叠。对修理中心来说，我们用集合来建立修理间模型、描述实体图形和预约队列。5.2.3变量与表达式在很多模型中，可能会在多个不同的地方重复使用数据。例如，在一个模型中有几个地方可能需要生成来自相同分布的服务时间，并将它们输入到需要的模块中去。但是如果要在实验中更改这个分布的参数（或者分布本身），就必须打开每一个包括该服务时间的对话框来改变参数值。有时，我们可能需要跟踪系统中实体总数变化的情形。还有的时候，我们可能在整个模型中需要使用很复杂的表达式，例如，可能根据零件类型来确定加工时间。Arena的“变量”（Variable）和“表达式”（Expression）模块可以容易地实现这几种要求。“变量”模块（Variable）允许用户定义自己的全局变量并赋初始值，而且还可以按照它们的名称加以引用。它们也可以被指定为一维或二维的数组。“表达式”模块（Expression）允许用户定义各类表达式和它们所关联的值。与变量相似，表达式也可以在模型中以它们的名称引用，可以被指定为一维或二维的数组。虽然变量和表达式看起来很相似，但是它们具有不同的功能。用户定义的变量可以存储一些能够在仿真运行期间重新赋值的量。例如，我们可以定义一个叫做WaitTime的变量（用以表示等待时间），其初始值为2，在需要使用该量的地方输入变量名即可。我们也可以定义一个叫做NumberinSystem的变量（用以表示系统中的零件数），其初始值为0。每次新零件进入这个系统，就在这个变量上加1；每次一个零件退出系统就减1。对汽车车间来说，我们用一个名位Day的变量来跟踪这一周的当前日。我们还会用很多变量来控制如何获得预约，如何在运行结束时收集用于计算统计量的信息。与此不同，用户定义的表达式不能存储数值，而是提供了一种将某个名称和特定的数学表达式关联起来的方式。当名称在模型中被引用时，相关的表达式就会被计算出来，并返回其数值。例如，表达式可被用来计算一些分布或复杂等式的值，而计算公式中又包含了实体的属性值或者系统变量值的当前值。如果在模型中数学表达式只用在一个位置，将它输入到相应的位置可能会更容易。但是，如果表达式被用在几个位置或者要用的表达式的形式依赖于实体的属性，那么用户定义表达式通常会更好。对汽车车间来说，我们会用Expression模块（在“高等操作”面板中）来定义所生成的预定时间、实际服务时间和预定需求的类型（等待还是离开）这些表达式。变量和表达式有很多其它的用处，随着你们对Arena的进一步熟悉，这一点会越来越明显。5.2.4子模型在开发庞大而复杂的模型时，通常将模型分割成小的模型是有好处的，这种小的模型被称为原模型的子模型（submodels），它们之间可能互相有交互，也可能没有。这会为建模与测试过程提供便利。例如，我们可以将汽车车间模型分割成五个明显的（我们认为它们很明显）子模型：生成预约呼叫、进行预约、服务活动、更新性能变量和控制逻辑。Arena以子模型的形式提供了这种分解能力。这种特点允许将模型分成不同层次的视图，也即子模型，每一个都在屏幕上有自己完整的工作空间。你既可以一次观看一个子模型，也可以观看模型全景（也即顶层(Top-Level)模型）。每一个子模型都可以包括常规的模型窗口（例如“电子数据表格”模块、静态图形和动画元素）所支持的各种对象。子模型本身也可以包括更低层的子模型；可以无限地嵌套下去。子模型可以连接到其它的模块中去，也连接到其它的子模型中去，或者孤立地处于一个Arena模型中。在顶层模型视图和每一个子模型视图中，为了在逻辑区和动画区的不同区域中提供容易的导航，可以建立带有相关热键的“命名视图”。工程工具栏的“导航”面板（Navigate）可显示出列有顶层模型、所有的子模型、以及它们所以命名视图的树状结构。点击一个命名视图的或子模型视图即可显示该模型所在的区域，这使得在视图内和视图间的导航变得非常容易。虽然以