arena中文教程第4章.doc

第四章 建立基本操作及输入模型上两章介绍了一种简单加工系统（模型3-1），其中第二章介绍了一个手工完成的仿真，第三章检验了这一Arena模型。本章将开始介绍如何建立与实际系统更加接近的Arena模型，包括如何在简单模型的基础上，通过增加复杂度和引入一些新概念，来建立几种不同版本的模型。本章还讨论了怎样为实际系统确定合理的输入概率分布。4.1节对电子器件装配与测试系统进行了描述，在此基础上介绍了如何对简单模型进行扩展，引入了一些新的Arena概念，建立了新模型，并展示了如何运行所建立的模型以及观察输出结果。现在，读者应该开始着重留意建模技巧了。4.2节对上述模型进行了扩展：在模型中增加了调度、故障、资源状态等要素，并且介绍了不同的结果分析方法。4.3节讲解了如何进一步完善动画效果。4.4节概述了实体如何运动，并介绍了“站”(Stations)、非零传送时间的实现以及传送过程的动画表示。最后，4.5节介绍了如何确定输入数据，包括如何选择驱动仿真的随机数概率分布模型。完成本章学习之后，读者应能自己建立具有一定细致程度的模型，并能合理确定与符合实际的随机数作为模型输入。4.1 模型4-1：电子装配与测试系统这里描述的电子装配与测试系统（如图4-1所示），表示的是两种需要封装的电子产品的最后一道工序。到达产品需进行预处理，然后再装配。第一种产品（即Part A）是由模型之外的另一临近部门生产的，它按照均值为5的指数分布时间间隔到达（所有时间单位为分钟）。产品达到后，它们被立即送往产品A的预处理区域，并在这一区域内完成保证封装作业的匹配及产品清理工作，产品A的预处理操作时间满足三角分布TRIA(1, 4, 8)。之后，产品被立即送往封装台。第二种产品（即Part B）是由本模型外的另一工厂生产，它以每批4件的方式成批输送进入模型。批量的到达间隔时间服从均值为30的指数分布。产品到达产品B的的预处理区域时，被分解为四个单件产品后分别进行处理。在产品B的预处理区域的操作与产品A类似，处理时间服从三角分布TRIA(3, 5, 10)。之后，产品被送往封装台。原书P104图4-1 电子装配与测试系统在封装操作中，首先将电子产品插入箱盒，再进行箱体组装与封装，然后对封装后产品进行检测。所有这些操作的处理时间因产品不同而异：对产品A的操作服从三角分布TRIA(1, 3, 4)，而对产品 B的操作服从威布尔分布WEIB(2.5, 5.3)的 (其中，比例参数，形状参数，其含义参见附录D)。91%的产品能顺利通过检测，并被立即运送；产品能否通过检测与其他产品通过与否无关。未通过检测产品被送往返工区域进行拆卸、修理、清理、组装及重新检测。80%的返工产品能通过检测，并作为返工合格产品发运，其余不合格产品则被送往废品区。无论返工产品最终合格与否，每件产品返工花费的时间服从均值为45的指数分布。我们希望通过仿真获得每个工作区域的资源利用率、队长、排队时间，以及产品的系统逗留时间等统计数据。仿真开始时，设置模型的终止运行条件为连续运行8小时(即1920分钟)。4.1.1建模方法的扩展搭建仿真模型仅仅是一个完整仿真项目的一个组成部分，仿真项目的两个首要问题为设定研究目标及系统定义，本书将在第13章专门讲述仿真项目整体方面的内容。本书将教你学会如何使用Arena来建立自己的仿真模型。尽管上面已经给出了系统定义，但在实际问题中，需要扩展这种定义，并且还需要收集和分析那些与指定输入参数及其分布（参见4.5节）相关的数据。下面将介绍模型扩展的方法。对于实际问题，首先需要定义数据结构，系统的模型分解，或者控制逻辑的扩展。这里我们仅需选择哪个Arena模块能够提供我们所需要的功能，并确定系统的细致程度。此外，我们还需要确定不同零件封装操作的不同操作时间。为简化这一操作，可以将模型分解为如下几部分：到达部分，预处理区域，封装操作，返工，离开及动画部分。并且，我们可以假设所有系统中的实体代表了正在被加工的产品。因为模型中存在两类到达实体，每种产品的到达服从不同时间分布，所以分别采用两个独立的Create模块来生成到达的产品。各类产品的封装操作时间因产品不同而异，因此我们使用两个“赋值”模块来定义“封装时间”（Sealer Time）属性，这一属性在Create模块生成零件的同时给封装操作时间赋以相应的值。当产品接受封装操作时，就可以使用与Sealer Time属性关联的时间值，而不像模型3-1中那样在操作时刻才生成这个时间值。与模型3-1类似，两个预处理区域和封装操作都有各自的Process模块。封装操作完成后要实施检查，通过“投币”选择来决定产品下一步进入哪个区域。这里使用一个基于投币原理的“决策”（Decide）模块，因此返工区域拥有Process和Decide两个模块，以及“通过”和“未通过”等选项。模型中使用三个单独的“记录”（Record）和“处理”模块（装运、返工合格、废料处理），这样就可以按照装运、返工合格以及废品处理等几部分进行分类统计。所有这些模块都包含在“基本操作”面板中。4.1.2 建立模型建立模型时，首先打开一个新的模型窗口，将需要建立的模块放置于屏幕上：两个Create模块、两个Assign模块、四个Process模块、两个Decide模块、三个Record模块以及三个Dispose模块。当你将这些模块按照一定顺序放置好之后，如果你建立了连接或选择了“自动连接”（Object 菜单中），则建立的模型窗口应与图4-2相似。不同模块的内部编号根据你放置模块的先后顺序不同而异，因为这时所有模块的连接关系是“空白”，因此不影响模型的最终连接关系。完成之后，点击FileSave将模型保存到你选择的目录下。完成上述工作后，分别打开每个模块，输入模型所需的信息。首先是产品A的实体到达模块Create 1。输入界面4-1提供了完成这一模块需要的信息（关于“输入界面”的介绍详见3.4.4节的描述）。这一步骤与模型3-1的Create模块非常相似。原书P106图 4-2 建立模块的视图我们给这个模块命名，并指定实体类型为Part A。设置到达间隔时间为均值5的随机数（即服从指数分布），单位设置为分钟（Minutes），其余项采用默认值，完成后点击OK键接受模块设定。原书P106输入界面4-1 完成后的产品A Create模块对话框原书P106输入界面4-2 完成后的产品B Create模块对话框产品B到达的Create模块设置与产品A类似，如输入界面4-2（由于步骤几乎相同，因此不再敖述）。由于产品B是以每4个为单位成批到达，因此需要填充一个附加字段（每批到达的实体）来体现批量数为4，这一项将使得每次到达的是4个单独实体而非1个实体。原书P107输入界面4-3 指定产品A的封装时间和到达时间创建了到达产品之后，紧接着给它定义一个Sealer Time属性，并给封装操作时间赋值，操作时间因产品类型不同而异。我们在先前放置的Assign 1和Assign 2模块中进行赋值。产品A的赋值如输入界面4-3所示，我们定义一个新的属性并给它赋值为TRIA(1, 3, 4)的三角分布函数。我们还需定义Arrive Time属性，这个属性用来记录实体的到达时间。Arena的TNOW变量用来提供仿真时钟当前值，这个时间就是产品到达的时间。（TNOW又称当前仿真时钟，观察TNOW值的方法是：鼠标右键点击Assign模块Assignment对话框中的New Value域，选择Build Expression，点击Date and Time Functions，它在列表中被描述为Current Simulation Time。）为产品B的Sealer Time和Arrive Time属性赋值的过程如输入界面4-4所示。尽管前述模块为产品到达创建了四个实体，但每个实体都在赋值模块中的Sealer Time分布属性中分别赋予不同（相互独立）的值。原书P107输入界面4-4 确定产品B的封装时间和到达时间创建了两种产品到达模块并给封装时间赋值之后，接下来可以利用先前放置的两个Process模块来建立两个预处理区域的模型了。Prep A Process区域的完成对话框如输入界面4-5所示。Process模块有四个可能的活动类型选项：Delay，Seize Delay，Seize Delay Release以及Delay Release。Delay会产生一个经历指定时间延迟的活动，这个活动不需要占用资源。由于预处理区域需要占用机器或资源，因此需要一个活动来实现排队等待，直到获得预处理区的资源，然后延迟至操作时间完成为止。Seize Delay活动提供了等待和延迟功能，但它在操作完成后并不释放资源给下一实体使用，使用这个活动的前提是，资源必须在下游的某一个模块中能得到释放。Seize Delay Release选项提供了准确建立预处理区域的各种活动的组合。Delay Release活动假设实体先前占用了一种资源，在此处经历一段延迟后，释放了这种资源。原书P109输入界面4-5 产品A的预处理操作对话框当选择最后三个选项之一时，会在活动（Action）选择框下面的空白处出现一个列表框。单击Add按扭来输入资源信息。在输入数据时，希望尽可能使用下拉式列表功能。因为当你输入一个名称时，必须与先前输入的名称完全一致。Arena中的名称不区分大小写，而是根据名称拼写或插入空格来区分的。因此从下拉式列表中选取名称可以保证你所使用的名称和先前输入名称的一致性。如果在输入名称中稍微出错，则Arena会在首次运行模型时给出错误信息（更糟糕的情况是，尽管模型可以运行，但结果却是错误的）。当新建一个模块时，Arena会自动为这个模块赋上默认名和默认值。这些默认名是带有附加序号的对象名称（如模块、资源等）。同一对象名称的附加序号是依次递增的，如Progress 1，Progress 2，。这样做是基于以下两个原因：其一是方便起见 你既可以接受默认资源名称，也可以修改它；其二是因为Arena中无论对象类型一致与否，所有的对象名称都必须是确定唯一的。为帮助使用，Arena做了许多自动命名工作，而其中的大多数读者都不必理会。例如，当你单击查看队列数据模块就会发现，Arena将零件A预处理区域的队列命名为Prep A Precess.Queue。大多数情况下，你可以自己命名，而不必使用默认的名称。当你选择两个包含Seize活动中的任意一个，并确认接受时，Arena会在相关Process模块附近自动弹出一个动画队列（一个在右端带有小竖线的水平线）。这种功能可以使你在仿真运行时动画显示队列中等待的实体。如果单击此队列，就可以显示出该队列的名称。第二个Process模块除了名称（Prep B Process）、资源名（Prep B）和操作时间参数（3, 5, 10）外，建立过程都与前一模块一样。因此没有给出其输入界面。下一步工作是给封装操作输入数据，这是我们放置的第三个模块。输入的对话框如输入界面4-6所示。由于我们在上游的赋值模块中创建到达产品时，给它定义了Sealer Time属性，因此当实体占用（Seizes）资源时，就会产生一个数值上等于Sealer Time属性值的时间延迟。输入界面4-6. 封装对话框我们利用第一个Decide模块实现封装操作之后的检测。由于只有“通过”或“未通过”两个选择，因此我们选用默认的类型 2-way by Chance。这里需要在对话框中输入一个逻辑为“真”（True）值的百分比，通过它来决定离开模块实体的去向。这个例子中，我们将真值百分比输入为9，这样就会有9%的实体流向真值对应的分枝（这里的“真”值对应的是未通过检测的产品），其余的91%流向逻辑“假”（False）值对应的分支（即通过检查的产品） 我们在本例中采用True表示未通过，而False表示通过。同样我们也可以将模型中的真值百分比设为91（再将模块的名称改为Passed Sealer Inspection就可以实现True表示通过、False表示不通过的设定了）。通过检查的产品直接送去装运，而未通过的产品则被送去返工。Decide模块的数据输入如输入界面4-7所示。原书P111输入界面4-7. 封装检查对话框接下来是建立返工活动的Process模块，Process模块的数据输入如输入界面4-8所示。这个模块除名称、资源名和表达式外，其余部分都与产品A和产品B的Process模块相似。输入界面4-8. 返工操作对话框输入界面4-9. 返工产品检查对话框第二个Decide模块是用来分离返工合格产品与废品，模块中的数据输入如输入界面4-9所示。我们用“真”值表示废品（20%），“假”值表示返工合格产品。在定义了上述操作模块之后，接下来应该完成Record和Dispose模块了。我们仿真的目的之一是获取资源利用率、队长、排队时间等统计数据。这三个统计数据可以利用每个需要资源的带有活动选项的Process模块来实现（假设模块中的Report Statistics框被选中，这可在 RunSetupProject Parameter菜单中定义）。我们还需要获得直接合格产品、返工后合格产品以及废品的系统逗留时间（cyclic time），Record模块可通过累加器完成这些量的统计。从下拉菜单中选择Time Interval类型，累加器默认名称与模块名称相同，这样Arena就会自动进行累加统计：统计产品到达时间（Arrive Time）属性值与它到达Record模块的时间之差（即实体在系统中的时间）。完成输入后的废品累加器对话框如输入界面4-10所示。剩下的两个模块分别是Record Salvaged Parts和Record Shipped Parts。由于它们几乎与输入界面4-10中的Record Scrapped Parts模块完全相似，此处不再敖述。原书P112输入界面4-10. 废品记数对话框最后的三个模块是对实体离开系统时做后续处理的模块。当我们建立这个模块时，可以将所有实体都指向同一个后续处理模块（Dispose）。后续处理模块的特征之一是在模块的右下脚处有动画变量，动画变量将显示仿真运行中通过这个模块的实体数量，并且还可以显示通过这个模块的实体在整个系统实体中所占的比例。Scrapped后处理模块的数据输入如输入界面4-11所示。我们默认选中Record Entity Statistics框，但当我们仅需要保留装运产品（包括返工后合格品）的实体流统计数据时，就必须清除这个框的选项（选中保留其它两个后处理模块相应选项）。这样操作后就可以只选中需要进行自动统计的产品。只有确保Entity框是按照RunSetupProject参数进行选择的前提下，才能获得这些统计结果数据。原书P113输入界面4-11. 废品Dispose对话框可按照类似方法完成其他两个Dispose模块Salvaged和Shipped的设置。你可能已经准备好运行这个模型了吧，尽管你已经完成了不少工作，但等你习惯Arena的使用后就会明白，在运行模型之前还必须花些时间完成其他一些准备工作。这时候的模型的确可以运行，但开始运行后，Arena不知道何时停止仿真！你必须通过RunSetup为模型设定运行参数。Run Setup对话框用五个表页的参数来控制仿真的运行。第一个表是Project Parameters（如输入界面4-12所示）。在这个表中输入项目标题和分析员姓名后，在Project Description部分可输入简要的项目描述。在Statistics Collection区，去掉Entities选项，因为在我们的分析中不需要这些数据（我们不需要按照实体类型对系统进行统计）。你也可以选中这个框来观察选择前后输出报告的差异。原书P114输入界面4-12. 项目运行参数的设置设置仿真运行长度是在Replication Parameters表中完成的，这里我们将Replication Length设为32小时（4个连续的8小时轮班），Base Time Units选取Minutes，其他域使用默认值，设置完成后的结果如输入界面4-13所示。对RunSetup中的其它三个参数表则使用默认值：Run Speed，Run Control和Reports。你可以打开这些参数表来了解其中的参数选项。在运行新模型前，还必须进行最后的调整。由于我们有两种不同类型的产品，因此如果在动画显示中能加以区别则效果就更好了。在基本操作面板中的Entity数据模块中，你会发现两类产品的初始图像都定义为Picture.Report上，因此当我们运行模型时，所有产品在实体的动画显示中都会出现同样的图标。原书P115输入界面4-13. 重复运行的参数表设置单击产品A的初始图像单元格(Initial Picture)，从列表中选择一个别的图片。这里我们给产品A选择是蓝色球，而产品B选择的是红色球，以便在动画显示时可以方便地分辨出两种产品，完成后的效果如输入界面4-14所示。如果你还想进一步了解这些图标的形状，从屏幕上面的主菜单中选择EditEntity Pictures选项来打开实体的图形窗口，这样就可以从当前屏幕的左下栏中观察到图标的形状。我们在后续章节中还将对这一功能作进一步介绍。最终建立的模型如图4-3所示。原书P115输入界面4-14. 实体模块原书P116图4-3 模型4-1的最终形式4.1.3 运行模型在运行模型之前，必须进行对模型加以检验，单击运行交互工具栏中Check按扭（），或选择RunCheck命令，或用键盘上的F4键都可以对模型进行检验。如果庆幸的话，检验完毕后会弹出一个小的消息窗口显示“模型中无错误或警告”(“No errors or warnings in model”)；否则会弹出一个描述错误的消息窗口，这时你就需要选择Find选项（如果它可选的话）。这些功能将提示你Arena“认为”可能出错的地方。建议读者有意往模型中加入一个错误来验证这些功能。对这些功能的使用会随你所建立模型复杂程度的提升而增多。如果模型检验无错，现在就可以准备开始运行仿真了。运行仿真的方式有四种，但我们只讲解其中的三种。第一种是动画仿真，点击标准工具条中的“运行”按扭（），或RunGo命令，或使用F5键都可以启动动画仿真。如果你还未检验模型，或是在检验之后又做了修改，Arena会首先检验模型，然后使用你的数据对模型进行初始化，再开始运行模型。为使你的注意力集中于动画显示，Arena在运行过程中隐藏了一些图形。不过没关系，这些图形在运行结束前会重新出现（或者你可以在仿真过程中通过ViewLayers命令来查看这些图形）。如果你激活了屏幕底部的状态栏，就可以观察Arena当前的执行操作了。状态栏中主要包含以下三方面信息：重复仿真次数，当前仿真时钟以及仿真状态。仿真运行开始后，如果你想改变仿真运行速度，可以按“”键来加快仿真运行速度。 如果你按了其中一个按键的话，在状态栏左端就会出现当前动画速度因子值。你还可以通过Run Setup对话框中的Run Speed表来控制动画速度因子（Animation Speed Factor）：在这个表的选项中键入精确的速度因子数值。在仿真运行过程中，可以使用运行工具条中的“暂停”按扭（）来暂停运行，或者使用RunPause命令，或者直接用Esc键来暂停。这样可以暂时中断仿真运行，同时状态栏中会显示“用户中断”(User interrupted)的消息。在暂停模式下，可以双击一个实体动画打开一个Entity Summery对话框，这个框中罗列着每个实体的属性值，因此暂停功能对于调试模型来说非常有用。此外，你还可以使用运行工具栏中的“单步运行”按扭（|）来实现实体在系统中的单步运行（即每步只运行一个时间单位）。如果想恢复仿真的“正常”运行，只需按下“运行”按扭即可。上述的这种仿真手段尽管提供的信息量非常巨大，但却需要较长的仿真时间，而仿真运行时间取决于动画速度因子。可以选择暂停并按下运行工具栏中的“快进”按扭（）加快仿真速度，或者通过RunFast-Forward命令来实现这一功能，这样做可以使仿真在不更新动画图象的情况下大大提高运行速度。还可以在按下暂停按扭后，重新返回到动画模式的运行。使用快进模式可以大大缩短仿真运行时间，但如果你仅仅对仿真结果的数值感兴趣，那么可以干脆连动画效果一起关掉，选择RunRun ControlBatch Run(No Animation)命令就可以实现这个功能。通过RunRun Control选项还可以设置其它一些运行时间选项。当选择Batch Run(No Animation)选项并重新观察上级选项时，你会发现在左侧多了个复选项：选中此项并点击Run键，仿真运行速度会非常快。这种设置的唯一不足之处是当你想要恢复动画显示时，必须终止仿真运行，重新设置动画显示后才能恢复。如果你的模型比较大且仿真运行时间较长，并且你仅对数值结果感兴趣的话，选用这个功能就非常合宜了：这种模式比快进模式的运行速度更快。当你建立模型时，可能希望多数的工具栏在窗口中方便可见，但当你运行模型进行仿真时，这些工具栏就会白白占用空间：因为仿真运行时并不激活这些工具栏。为此，Arena专门附带了组织工具栏：它会记录你建立每个模型时对工具栏的设置，因此当你开始运行后，可以暂停运行后移去这些工具栏，仿真运行结束后，它们会重新出现在原先的位置上。4.1.4 观察结果如果选择RunGo菜单（或者点“运行”按扭），你会发现仿真运行中，系统中除了蓝球和红球（分别代表产品A和产品B）之外，还会出现几个不断变化的计数器。每个Create模块、Process模块和Dispose模块都各有一个计数器，而每个Decide模块会有两个计数器。Create模块、Dispose模块以及Decide模块的计数器在实体离开该模块时自动增加一个单位；而Process模块的计数器则代表了当前模块中的实体数，包括排队等待资源的实体数与当前接受操作的实体数之和。如果你选择的是RunFast-Forward模式（或者使用Fast-Forward按扭），这些计数器就不再更新，直至仿真运行结束或你暂停并改变模型运行的观察模式时才会更新。本模型计数器的最终运行结果如图4-4所示。模型运行结束时，Arena会“询问”你是否想查看结果。如果你选择Yes，系统会弹出一个总结报告的窗口（默认报告）。当报告的首页出现时，你会发现一条内容为“无法获得总结统计”(No Summary Statistics Are Available)的奇怪消息。这是因为在Arena系统中，系统总结统计的是实体，而我们在“运行设置”对话框（输入界面4-12）中的“项目参数”表中没有选择Entity选择，也就自动放弃收集这些统计数据。因此，当你改变这些选项时，请留意输出报告内容的改变。原书P118图4-4模型4-1的动画结果当你需要浏览报告内容时，可以通过左侧的“报告”窗口查看表内的树形列表，或是通过报告窗口左上角的方向按扭（ ）来实现。这个报告提供了Run Setup对话框选项中的分类统计量（在“项目参数表”，“统计收集区”中定义）。在我们所建模型中，你可以找到操作、排队、资源和用户指定等选项区域，之所以会出现用户指定区，是因为我们的模型中包含了用于离开类型的Record模块的缘故。同第三章一样，我们的统计报告中出现了三种类型的统计量：tally，time-persistent和counter类型。当多次重复仿真时会出现第四个统计量（outputs），第六章讲解多次重复仿真时再对这部分进行详细介绍。这里的记数型统计量包括我们Record模块所收集到的几个操作时间、排队时间和间隔时间。时间持续型统计量包括队长，资源利用率等。计数统计量包括累计次数，进入系统数，离开系统数以及总占用数量。记数型统计量与时间持续型统计量提供了均值、置信度为95%的区间半长、最小值和最大值。正如前两章所介绍那样，除了区间半长外，上述这几项都一目了然。在每次重复仿真结束时，Arena都会用一种批平均（batch means）（详见7.2节）方法为每个观测统计量的稳态期望值计算出一个95%的置信区间。Arena首先检查是否收集了足够多的数据，以判别能否满足使用批平均值法的临界统计假设（批量无关性）。结果中会偶尔出现这种情况：如果不满足该假设，则报告中会出现“不足(Insufficient)”的提示，且不会产生置信区间半长；结果中还会出现几次这样的情况：如果检验批量无关性的数据足够多，但未通过检验，则会出现“相关(Correlated)”的提示，同样也不会计算区间半长；此外，还可能出现的情况是：如果有足够多的数据进行批量无关性检验，且通过了检验，则会产生一个长期（稳态）期望值统计量的置信度为95%的区间半长。如上所述，即便从纯计算角度出发，可以计算出结果，但Arena会拒绝报告不可靠的区间半长值。这些检验的细节和重要性将在7.2.3节作进一步的深入介绍。如果通过这样的单次短时间的运行就想得出结论的话，未免会出现偏差，因为我们还没有考虑类似运行长度、重复运行次数、甚至长时间稳态结果的合理性等问题（这部分内容将在7.2节介绍）。如果观察排队等待时间、排队等待数等结果的话就不难发现，返工操作因等待时间和队长比其它操作时间过长而拖后（你可以通过观察总结报告中操作和资源部分的拥挤情况来证实这一失调现象）。这就意味着，要么返工区没有能力处理它应完成的工作，要么这个操作存在大量的可变性，我们将在下面的4.2节中考虑这个问题。顺便提一下，请注意图4-5，当多于一种类型的实体进入模型时（本例中的进入类型就不止一个），总结报告给出的是一个平均值的图。原书P120图4-5模型4-1的排队总结报告4.2 Model 4-2: 改进的电子装配与检测系统建立和运行模型后，接下来应该对“代码”（Arena文件）进行验证以确保无bug2 当然，你可能对“bug”一词在计算机程序中指代错误的意思非常熟悉，但你确切知道这个来源于昆虫学词源的词汇吗？自瓦萨大学著名的Grace Murray Hopper是最先在计算机中使用“bug”一词的学者，他用这个词指代那些早期计算机继电器盘面板上触电而死的飞蛾，因为飞蛾的触电常常导致计算机短路。飞蛾触电后的残骸图片见/images/Bug.GIF。，并且对概念模型是否真实代表了我们研究的系统进行确认（见2.7节和13.6节）。本例中模型的验证和确认还算比较容易，通过检查使用模块中的逻辑结构，将他们与问题定义进行比较即可；而对于大型复杂系统，这项工作就非常具有挑战性了。动画演示在模型验证和确认阶段往往非常有用，因为当它运行时，你可以综观整个系统的构建情况。运行我们建立的模型，观察动画可以发现它呈现给我们的运行情况与我们希望描述的系统极为相似。但如果模型验证很困难的话，对它的完全确认（下一步骤）就会非常困难（甚至不可能进行确认），这是因为“确认”暗含着仿真可以完全表现真实系统的运作行为，而如果真实系统不存在的话，当然无法进行确认了。即便真实系统存在，你也必须从其中获取输出性能数据，以此来说服那些和你一样持怀疑态度的人：你所建立的模型是来源于真实系统，它能对真实系统进行预测。我们将在第13章对验证和确认两个步骤作更为详细的介绍。现在，当你把辛苦建立的模型及其运行结果交给产品部经理的时候，她首先看到的是你还没有给系统如何运作给出一个全面的定义。当初给出问题定义时仅考虑了单班操作的情形，但现在的系统却是每天两班制，且第二班的时候会有两个操作员被分配给返工操作。这也验证了我们当初预计返工操作能力不足的想法。产品部经理清楚，因为封装机器会时常出现故障停顿，所以在封装操作中会出现故障情况（failure）。工程师不久前检查了这个问题，收集数据后确定了封装操作对系统的影响。由于他们认为封装操作不是一个瓶颈操作，因此对它的故障改进不会对整个问题的解决带来明显的改善，但他们还是记录了所观测的结果以供其他人参考。假设两次故障间的平均间隔时间为120分钟，时间分布服从指数分布（顺便提一句，如果故障在整个期间运行按照均匀概率发生，则通常使用实际的故障间隔时间模型）。修理时间同样服从均值为4分钟的指数分布。另外，产品部经理暗示她考虑购买特殊的货架来放置那些在返工区域等待处理的产品。假设每个货架上能放置10套产品的话，经理想知道应该购买多少货架比较合适。下面对模型进行修改：增加使用三个Arena附加功能。为了能将这些修改加入到已有模型中，我们需要引入一些新的概念。由单班运转改为两班运转非常容易，在模型4-1中，我们将运行长度设置为每班8小时，并且未对运行过程中的每天轮班交接进行跟踪，这是因为我们假设第一班末交接时的当前系统状态与紧接的下一班初始系统状态完全相同，并且假设交接不需要花费时间。而我们现在需要建立明确的换班模型，因为第一个返工班次中只有一个操作员，而第二班则增加为两个操作员。我们通过给返工资源引入资源调度 (Resource Schedule) 的方式完成上述模型的改进。资源调度通过调整资源能力来自动改变整个运行过程中的返工资源数量。当我们做这些改变时，还应该增加仿真运行长度，这样我们就可以完成两天以上的双班操作模型的仿真了。我们使用资源故障(Resource Failure)来建立封装台故障的模型，这样我们就可以改变资源的可用能力（与资源调度类似），同时还有另外表示设备故障的特殊功能。最后，通过频率统计(Frequencies statistic)所获取的信息来决定需要购买的货架数量。4.2.1资源表示的扩展：调度与状态到目前为止，我们建立的所有资源模型都是固定能力为1的单资源模型（预处理区域，封装和返工）。我们对资源模块中的这些信息采用的都是默认值。我们可以通过将返工资源能力设置为2来实现增加的返工操作，但这样的话我们就总有两个可用的操作员。我们需要做的是在第一个班次安排一个返工操作员（假设每班次为8小时），而在第二个班次安排两个返工操作员。Arena通过内部的调度结构可以实现这个功能，调度功能允许你在一段时间内根据设定好的方式改变资源的可用能力。资源调度是与时间相关的资源能力改变序列。我们还需要在模型中描述封装台的周期性随机故障情形。同样可以使用调度（schedule）实现这个功能：定义正常运转期间的可用资源能力为1，定义修理期间的可用资源能力为0。此外，Arena还设计了专门的内部结构来描述故障。首先，我们先来介绍资源状态的概念。Arena自动定义了四个资源状态：闲（Idle），忙（Busy），不可用（Inactive）和故障（Failed），为了作统计报告，Arena对资源处于四个状态的时刻进行了全程跟踪。如果资源未被实体占用，则称资源状态为空闲；一旦它被实体占用，则状态改变为忙；如果Arena使资源的分配状态变为不可用，则资源状态改变为不可用，通过调度将能力改变为非0来结束资源的不可用状态；如果资源不能被分配，则它会被Arena置为故障状态。当出现故障时，Arena使整个资源都变得不能使用，假若资源能力是2，则在修理期间，两个能力单元都会被置为故障状态。4.2.2资源调度在将返工操作资源调度加入模型前，先来定义新的16小时工作日。在RunSetup选项中的“重复参数表”中将每天小时数（Hours Per Day）的值从24改为16即可（此处忽略了关于日期的警告）。在这个对话框中，还需将仿真运行长度时间单位(Time Units)改为天（Days），再将仿真运行长度(Replication Length)设为10天。可以在资源（Resource）或调度（Schedule）数据模块中定义资源调度，这里我们在Resource数据模块中进行定义。当你点击基本操作面板中的Resource数据模块时，屏幕底部模型窗口中的电子数据表中会显示模块的当前资源信息。点击返工资源栏的类型列，从列表中选择Based on Schedule后，Arena会在电子数据表中自动增加两列：调度名称和调度规则。因为能力由调度来确定，因此返工资源的能力单元格为暗灰色（不可设置）；其它三种资源由于能力固定，所以这两列单元格也为暗灰色。接下来，需要在返工资源的调度名称单元输入调度名称（如Rework Schedule）。最后，还需要选择调度规则(Schedule Rule)，通过它来实施调度。调度规则有Wait（等待，默认选项）、Ignore（忽略）和Preempt（优先占用）三个选项。如果需要将能力减少x单位，且当前至少有x单位的资源处于空闲状态，则所有三种选项下都会立刻将x单位的资源状态变为不可用状态；但如果当前空闲的资源不足x单位，则调度规则将视选项情况而定（图4-6对三种情况做了图示说明）： Ignore选项会立刻减少资源能力，但正在进行的服务仍然继续（不受资源减少的影响），直到当实体释放资源单位后，这些单位的资源才会被置为不可用状态。但若实体释放资源单位前，资源能力又已重新增加，则这一选项不会产生任何作用。这个选项的效果是使实际资源能力调度的时间缩短了。 Wait选项在实际资源开始减少前，一直处于等待状态，直到操作中的实体释放资源单位为止，因此资源能力减少的时间总是等于调度规定的时间，但两次时间减少的间隔可能会增加。 Preempt选项优先从最近占用资源的实体手中将资源抢占过来。如果优先占用成功，且一个单位的能力足够满足需要，则能力减少立即开始。被抢占资源的实体将在Arena内部等待至资源重新可用，届时实体将被重新分配资源并继续剩余的操作。这种方式提供了一种正确的调度和故障建模方式，因为在许多实际情况下，当交接班或资源出现故障时，操作产品往往需要暂停等待处理。如果优先抢占不成功或需要的资源单位多余一个，则剩余的能力将使用忽略（Ignore）准则。原书P123图4-6 Ignore, Preempt与Wait的说明何时使用这些准则呢？我们推荐你仔细观察实际操作并选择最能资源能力下降或故障真实情况的选项。如果你所考虑的资源是系统的瓶颈资源，则你的选择会显著影响系统得到的结果。但当你不清楚实际情况，又没有严格指导方针时，本书推荐一些可能会有所帮助的准则：首先，若能力减少的时段相对操作时间而言非常大，选用忽略（Ignore）选项比较合适；若能力减少的时间间隔相对减少的时间段而言较大，建议选用等待（Wait）选项；本模型中，我们选用的是Ignore选项，因为在多数情况下，操作员在离开前会完成他的工作。电子数据表中的前四行如输入界面4-15所示（实际上右边还有一栏附加项，此处未显示）。还可以用对话框形式输入数据，该对话框可以通过鼠标右击Name栏中的返工单元后，选择Edit via Dialog选项打开。原书P124输入界面4-15 Resource数据模型：选择一种资源调度在给调度命名、指定了调度规则后，还必须定义资源实际遵循的调度信息，点击“调度”（Schedule）数据模块，输入电子数据表的调度信息可以实现这一功能。表中会新增一行反映我们新定义的返工调度（Rework Schedule）的内容。点击持续时间（Durations）栏可以打开“图形调度编辑器”（Graphical Schedule Editor），它是一个输入调度数据的图形界面。横坐标表示日历时间或仿真时钟（请注意，我们在运行设置（Run Setup）对话框中设置一天工作长度为16小时）；纵坐标表示资源能力。可以点击x-y（坐标）位置来输入表示为天、小时和资源能力值的数据。这时会弹出一个代表此小时内期望能力的兰色实心条；你可以使用重复点击、保持或拖拽来完成前8小时数据项的输入，将第9-16小时段内的调度数据能力值输入为2。第二天的数据输入不是必须的，因为第一天的数据会自动在剩余的仿真运行中重复使用。完成的调度如图4-7所示。可使用Options按扭将纵坐标最大值（能力）从10减小到4；其它参数可用选项（Options）对话框来更改，这些参数有单位时间条（slot）的宽度、时间条的数目以及调度是否从头开始重复或自始至终保持一固定能力水平等。原书P125图4-7 图形调度编辑器：返工调度 也可以使用鼠标右键选中Schedule模块电子数据表中的“时段”栏后，选择Edit via Dialog选项手动输入这些数据。选择这个选项后，首先输入调度名称，然后点击Add按扭打开持续时间（Durations）窗口，定义组成调度（能力，持续时间）的数据对。本例中的两组数据分别是（1，8）和（2，8）（参见输入界面4-16），即在仿真开始的前480分钟能力为1，而其后的480分钟能力为2，如此交替变化，直至整个仿真结束。还可以用多个（能力，持续时间）数据对来准确描述系统，如可以在调度中添加操作中断和午饭时间等。一个需要特别留意的警告或功能3 如果你有意利用这个特性，就称它为功能；如不小心出错，则称它为错误。是，如果实体未被赋予持续时间长度，则系统默认持续时间为无限长。这个功能可以让资源在整个仿真运行期间保持这个能力。如果你已使用图形调度编辑器来创建调度，然后打开对话框，你会发现系统已自动输入了数据。当模型中有非整数的持续时间值或需要使用表达式输入的项目（如由随机变量生成的持续时间值）时，你就不能使用图形调度编辑器了。原书P126输入界面4-16 Schedule数据模块对话框4.2.3资源故障调度根据换班、故障、休假、会议等因素有计划地改变资源的可用属性，而故障主要是建立随机事件导致的资源不可用模型。可以在资源或故障数据模块中给出故障的定义，故障（Failure）数据模块可以在高级操作面板中找到（如果项目栏中的这一项还没有的话，就需要通过按扭或FileTemplate PanelAttach菜单将其加入）。我们首先为封装故障建立故障数据模型。在项目栏中选中“高级操作面板”，从中选择Failure数据模块，双击鼠标来添加一行。选择名称列中的故障名称，用一个有意义的故障名称替换它（如Sealer Failure）。接着在类型单元(Type cell)中选择故障类型为基于记数型的故障(Count-based)，或基于时间型故障(Time-based)。基于记数型故障是当系统中有一定数量的实体使用过资源后触发故障发生，这个触发数量是给定的数，或者由表达式来确定。基于记数型的活动在实际的工业模型中非常普遍。例如，工具复位、清洁以及机器调整等活动都是基于操作产品的数量，而不是基于过程时间。尽管人们通常不认为这些活动是“故障”，但它们确实是周期性的，并且阻止了产品占用资源。另一方面，我们也常常建立基于时间的故障模型，因为我们通常是按照时间类型收集故障数据的。在我们的模型中，故障类型采用基于时间的类型，点击类型单元并选择Time选项可以完成这项设置。这时，电子数据表右侧列中的内容会发生变化，以此来显示两种选项之间数据要求的差异。我们的正常运行时间（Up time）和停机时间（Down Time）分别服从均值为120分钟和4分钟的指数分布，此外，还需将正常运行时间单位和停机时间单位从Hours转换为Minutes。下面介绍最后一个域，我们可以借助“指定状态”（State Only）中的正常运行时间定义那些“计入”正常运行时间的资源状态。如果这个域采用默认设置，则所有状态都会被认为是“正常运行时间”，这个功能的使用依赖于建立模型的数据收集方式及日期选择方式。多数故障数据是简单的日志数据，假如仅标识故障时间，则节假日、午餐休息时间和空闲时间统统都计入故障时间，此时用缺省值即可。只有当故障间隔内的时间可以被直接与特定的状态关联时，你才需要选择这个选项。许多时间设备供应商会提供基于实际操作时间的故障数据，在这种情况下，你就需要选择这个选项，并将它指定为“忙”（Busy）状态。但提醒你注意的是：如果你选择了这个选项，就必须用高级操作面板中的状态设定（StateSet）数据模块来定义忙状态。最终得到的封装台故障电子数据表如输入界面4-17所示。原书P127输入界面4-17. 封装台故障电子数据表完成了封装台故障的定义之后，接下来需要将它关联到封装台资源上。返回到基本操作面板，打开Resource数据模块后，点击封装台资源行的故障栏，打开“故障”电子数据表的另一个窗口。双击鼠标添加一行，从故障名称单元的列表中选择Sealer Failure，然后从Ignore、Wait或Preempt三种准则中选择故障准则。这些选项与调度中的准则相同，你只需做同样的选择即可。接着返回到对故障规则选项的处理，因为我们期望的正常运行时间（120分钟）远大于故障持续时间（4分钟），因此我们选择等待（Wait）准则。最终的电子数据表如输入界面4-18所示。如果你用同一个故障描述关联了多个资源，则它们可以使用同一个故障名称。尽管使用了相同的描述，但它们在仿真运行过程中还是使用各自独立的随机抽样。原书P128输入界面4-18 封装台资源数据模块：故障电子数据表4.2.4 频率统计频率是用来记录Arena中变量、表达式或资源状态随时间离散变化的发生频度。我们可以利用频率(Frequencies)类型统计量来获取返工区域需要的货架数目信息。由于我们对等待返工队列的状况特别感兴趣 需要购买多少个容量为10的货架来满足产品存放要求，因此，我们关注各种情况下的队长值：队长为0（即不需要货架）、队长大于0小于10（需要一个货架）、队长大于10小于20（需要两个货架）等。频率统计是由“高级操作面板”中的“统计”（Statistic）数据模块来完成的，单击这个数据模块可以打开其电子数据表，初始表格是空白的，双击鼠标来添加一行。首先输入名称Rework Queue Stats；接着从类型列表中选择Frequency，默认缺省频率类型为数值型（Value）。当选择类型时，报告表单元会自动给出与名称单元相同的名字：Rework Queue Stats，我们在最后