ExtendSim VS. Arena一个小模型运行结果的差异

focuscon

把同一个系统用不同的软件建模，可以发现很多有趣的地方。
这是一个人力资源调度的小模型。
8 W; w- }7 e9 z8 {按题目要求分别用ExtendSim和Arena建模，结果发现离开系统的实体数量有差异3个，参数和时间我已经检查过了，没有差异。已知Arena模型没有错，谁知道ExtendSim输出结果为何会有差别？难道是Shift里面的时间点设置有问题吗？
题目：
, Z$ S# h+ A' lAt the DMV photo license center, the current “rule of thumb” is to get the drivers in and
out as fast as possible. Therefore, when drivers come to get their photo ID, the following
activities occur: Drivers go to a large counter, pick up a blank form, and fill it out. (We’ll
# y0 S/ [8 i6 b' Tassume the counter is large enough that any number of drivers can obtain and complete
the form at one time.) The drivers then wait in line for an available photo clerk.
0 B; _7 v/ ]. R4 Y% m% UThe drivers are serviced by: 1 part-time clerk (Rich) who works daily from 10 a.m. to
2 p.m., 1 full-time clerk (Ann) who works daily from 8 a.m. to 5 p.m. with an hour break
between 10:30 a.m. and 11:30 a.m., and the site manager (Dina) who only helps when
everyone else is busy and there are more drivers to be served. The manager works daily
like Ann, but gets her break from 1:15 p.m. to 2:15 p.m. Due to budgetary constraints,
there are only 2 computers available at the facility. (Don’t worry about using sets for this
9 |; y" \6 a6 x: @, _/ Y  Mresource.) The computers are used to capture the driver’s signature and to print the
, m+ F8 X) w$ L+ N0 E# z8 u! rlicense.  
The process goes as follows:  The clerk reviews the form with each driver, takes the
driver’s photo, captures the driver’s signature, and prints the completed license. (Note:  A
computer is needed for both the signature capture and for printing the license.) The DMV
8 P' \% c8 D- M. U# ]0 Z5 gmanager knows that it normally takes 3 minutes (some as short as 2 minutes, others as
long as 4 minutes) to review the form and take a driver’s photo, and anywhere between
30 and 60 seconds to capture the driver’s signature electronically. It then takes exactly
45 seconds to print and seal the new photo driver’s license.

iesim

软件之间有差异是很正常的，主要原因有
8 v. q+ n- d. n* T( x9 X3 j  U
7 N) Y- R7 v5 ~' s# Q* c（1）随机数产生机制不一样
（2）对同时刻事件处理的机制不一样

iesim

我没有arena 软件，只能看看你的extendsim 模型。目前输出169个，如果差3个，大概 1.7% 左右，应该是和我上面说的两个原因有关，其中尤其以随机数影响最多。每个仿真软件的随机数产生算法都是不一样的。

focuscon

Jeff，我用的是 V12学生版，可能是比较新的版本。
8 Z8 O6 f4 u9 K& F5 M王老师，我担心是模型做的有问题，一般情况下差异在什么范围内才算正常呢？
我发现ExtendSim和Arena在很多方面处理的机制差别好大。
' k9 T# [! k  A( D; f比如说Arena is an entity-driven language. The entities represent any person, object, or thing,
1 Z' z' L; F0 h- G( l, m. h; @whether real or imaginary, whose movement through the system causes a change in the
# f" P2 M; l9 o0 I- x# p& q. v3 Fstatus of the system. 这一点和ExtendSim很不同。

iesim

有几种方法来判断

（１）把所有随机因素都变成固定数值
2 ]$ d2 S" H$ s6 |4 j  v（２）不止比较一个指标，多比较一些指标，比如说关键瓶颈的利用率，关键队列平均等待时间等等，这些都会给出一个更全面、更准确的比较。

focuscon

在ExtendSim中，我把所有的处理时间都改成1秒，结果还是产出169个，说明人力资源是瓶颈；
在Arena中，把所有的处理时间都改成1秒，结果进入系统173（比之前的175变少了），产出也是173（之前是172），人力资源不是瓶颈。
ExtendSim的批到达是一下子全“推”进来了，仿真时间内到达总数是193。
7 c- f: h% H- m. s+ l而Arena似乎是按一定的速率一个一个被“拉”进来的，可见两种软件事件处理的机制不一样。
- j' a+ y: z2 b( Q  O7 V另外，人力的利用率也不相同，可能我的ExtendSim模型没有做细，兼职人员不在岗的时间应该剔除吧。

iesim

ExtendSim 里面也可以处理 Pull 类型的到达，只是看看题目是怎么要求的，是同一时刻全部到达？还是按照一定间隔到达？还是由后面的操作拉动？

focuscon

只告诉1~9个小时里面每个小时总共到达客户的数量，我直接按Schedule成批到达建模了，您说的pull类型是指使用Resource Item模块吗？
我感觉如果把Create+Queue看做一个整体的话其实也相当于一个Pull类型（后面有空就出去一个）。
7 O" X; k! x2 \; J2 ^& M; b! P
我发现在人力调度上有问题，我这样做的结果是服务人员存在排队等待浪费，而Arena里面直接隐性的设置资源，服务人员不用排队，这可能是产出数量比较少的原因，看来我要修改模型了。

谢谢王老师的启发，我才发现了这个问题！

iesim

实现 Pull的方式不需要 resource item, 也不需要queue, 直接在 create 当中设定 create item infinitely 就可以了，后面需要跟一个activitiy 模块。只要 activiity 为空，create 就产生一个小球。

focuscon

1 v1 a6 f& _+ Z5 m6 u* m) Q# d
用create item infinitely的时候如果要by Schedule的话还是要其他的模块配合。
) Z5 x! d  q4 O我用Resource Pool做资源调度，两种方法的结果怎么一样的？但是人员的利用率完全不同，其中第二种方法和Arena比较接近。怎么会有这样的差别呢？难道是处理机制不同? 模型如附件。

iesim

匆匆看了一下，问题可能出现在第一个模型的 [38] Queue 模块上，这个模块会让所有Resource Item 模块过早释放Resource 以至于利用率偏高。
2 v7 |  y3 k& p8 Y0 K8 y
/ G( \. Y: P9 E等有空再仔细研究一下。很有趣的题目。

focuscon

/ ~) Z2 f. R& g* J$ ~. {( }3 j) A

我没有看模型。但是Resource Item 模块统计利用率的机制我的教材里有，也就是，如果你在batch模块没有选择delaykit，那么资源只要有就会跑到batch，此时就算使用了，即使batch模块需要的另一个实体还没有到。 ...
4 A+ \* P- y8 c) l5 }6 Rqtbgo 发表于 2009-7-7 11:32

秦老师，
谢谢您的这个提示，记得之前也这样考过我，确实和这个相关。
5 M$ z1 ]) }0 E3 A  m+ M
  Z" T5 b& g; `! S' q8 E7 Q, F王老师，
! X+ E3 Z+ R; j6 K; w2 l, r起初是没有这个Queue的，如果把这个Queue去掉的话，就必须在Batch里面选择相应的Delay kit，否则第一个人就会在一开始被强迫使用，而事实上这时候此人并没有排班。但是如果两个Delay kit都选中的话（At least one of the Delay kit choices in the dialog must be left unselected.   The exception to this rule is if all the connectors are expecting to be receiving just one incoming item. In this case, the block does support turning on all of the Delay kit connectors at the same time.），模型就会报警说必须在Select Item In 【30】后面放一个Queue，所以我就加了一个Queue，这样就不会有强迫使用的情况。

% ~: C* b, I2 Z8 _) F: f最大的问题是，即使把这个Queue去掉，再把对应的Delay kit选择上，第一个人（Rich）的利用率还是差异比较大，而其他两个没有问题。

/ o# a& y' c8 x% F# X3 H根据大家的提示，我仔细看了看，发现Resource Item 和 Resource Pool在被shift调度时有一个很大差异，假设Resource Item 初始设置一个Item，当shift为OFF时这个Item会一直在里面等待，所以利用率是不准确的。而Resource Pool----- 当shift为OFF时可利用Item的数量为0，不存在等待。解决的办法就是用Shift的输出状态控制Resource Item的Total Resources输入端口。 归根到底是我对这些机制掌握的不透，不好意思！附上改善后的模型。

iesim

Focuscon,    进步神勇，非常厉害，问题和解决方案都有创意。我非常佩服同意你的修改。

focuscon

王老师，
! q! l* Z) s" E* C- f8 l$ j谢谢您的鼓励！
0 a. X9 \2 M3 C1 m6 C多亏大家的提醒，谢谢。我争取以后多弄些有趣的东西来大家讨论。

7 X1 G  ~8 ]- j: Y% I& ]+ _Linwei，
确实是这样，把所有的随机数设成一样还是无法消除这个微小的误差，说明还是有点差异，但这个结果和Arena建模的结果已经很接近了。

' R; f- {4 ?1 {0 M) C0 [经过对这个简单系统用两种软件建模，我的感觉是：
1. Arena比较隐性的设置队列，资源和Schedule等，做起来比较简单但是模型看起来不直观，不易被别人理解，跟个数学方程没什么太大的区别。而ExtendSim比较灵活，可以用多种方法建模，里面的小逻辑设计也有很大发挥空间，逻辑是可以看见的，比较有趣一些。
2. 同样一个模型，Arena模型文件的大小是ExtendSim的2~3倍，即使Arena用了更少的模块。在这一点上ExtendSim比较环保。
3. 人力资源调度方面（其他的我不了解）建模的效率似乎Arena更高一点。但ExtendSim的日历格式比较人性化。
4 Z- ?+ Y( S2 I9 J4. 开发环境的操作方面，Arena没有ExtendSim好用，可能不太熟悉的缘故。
5. Arena有一些小功能比较实用，比如统计系统里面的实体数量。用ExtendSim似乎稍微麻烦一点。
  z! R9 K5 p- x5 i了解的不多，不能再多说了。欢迎上砖。。。

focuscon

我觉得两种建模方法，对资源的统计还是有区别的，看附件第一个模型  和 第三个模型，除了使用资源的方法不一样，其他都一样，但是就是资源利用率不一样。还有使用batch模块，delay kit 打不打钩，对后面统计都有影响 ...
linweixu168 发表于 2009-7-7 15:47

这个问题不知是怎么回事，我也觉得很奇怪。不解，继续找。。。