在生产线仿真模型里，如果只给设备配上加工时间和运输时间，往往还没办法把真实的产能情况给完整地反映出来，因为设备的突发停机、等待维修的耗时，以及修好之后重新恢复运行的过程，这些都会影响到排队的长短和最终的交货节奏。那么，在FlexSim中怎样去给设备加入故障的逻辑，恢复需要的时间又要怎么设置，比较常用的一个办法就是借助MTBF MTTR这个工具。它能够替一组设备去设定随机的故障发生间隔和恢复时间，同时也能指定设备在发生故障之后，会转成什么样一个停机状态，以及停机期间的运行行为是怎样的。
一、怎样去加入设备的故障
在动手加入设备故障以前，要先想清楚到底哪些对象会受到故障影响，然后再去设定故障发生的间隔规律。有一点要注意的是，不要把计划内的保养和这种随机发生的故障混在一起处理，如果是那种时间很固定的停机，更适合交给Time Table去安排，而随机停机才更适合用MTBF MTTR来模拟。
1、先把MTBF MTTR工具给调出来
在软件左侧切到【Toolbox】这个工具箱，去点一下顶部的【Add】按钮，再从下拉列表里面选中【MTBF MTTR】，这个工具就被加进来了。按官方文档里的说法，MTBF MTTR就是专门用来给一组三维对象，去设置那种带有随机性质的故障和恢复时间的。
2、把会发生停机的设备给加进来
接着，双击一下刚刚新建的那个MTBF MTTR组件，把它的属性窗口打开，然后切到【Members】这个成员页面，点一下用来勾选对象的那个按钮，在弹出的列表里面，把那些需要加入故障逻辑的对象一一打上勾，比如Processor一类的加工设备，或者别的什么对象。另外，也可以去点一下采样按钮，然后再到三维场景里面，一个一个地挑选设备，效果是一样的。
3、把故障发生的间隔给填上去
再切换到【Functions】这个功能页面，在【First Failure Time】那一项里，设定好第一次故障会发生在什么时间；然后在【Up Time】里，把两次故障之间机器能够正常运行的时长给填进去。至于这些时长到底要填多少，既可以直接给一个固定的数值，也可以根据现场实际收集到的数据，去挑选一种合适的随机分布来用。如果不想让第一次故障那么早出现，也可以想办法让First Failure Time返回一个负数，这样模型在初始阶段就不会触发故障了。
4、定好设备故障之后会变成什么状态
最后，来到【Breakdowns】这个故障页面，在【Down State】里头，把设备在停机时所要进入的那个状态给选出来。当同一个MTBF MTTR组件里面挂了好几台设备的时候，还要看一眼那个叫“成员独立停机”的选项有没有被勾上。如果把它启用了，那么每一台设备就会各自独立地去计算自己的停机和恢复时间；要是没有启用，那么里面的所有成员就会在同一个时间点一起趴下，然后再一起恢复回来。
二、设备的恢复时间要怎样去设定
管着恢复时间的那个参数，其实是放在【Functions】页面里的【Down Time】当中，它表示的就是设备在进入故障状态以后，还要在里面继续停留多长的时间，才能够重新恢复正常的工作。按照官方文档给出的定义，这个参数指的就是故障的平均修复时间。
1、照着现场的维修数据来填
如果现场的维修耗时一直都比较稳定，那可以先试着用一个固定的数值去跑跑看；要是平常波动挺明显的话，就建议根据历史上那些维修记录，去挑一个更贴合实际的随机分布来用。别为了想让最后跑出来的模型好看，就随意地把维修时间给改短，那样最后算出来的产能结果，会比实际的偏高不少。
2、把加工时间跟纯粹的时间流逝给区分开
有一些设备，只有在真正干活处于加工状态的时候才会产生磨损，那些空闲着等待的时间，其实不应该算进故障的间隔里去。碰到这种情况，就可以到【Breakdowns】页面里，把那个叫“将MTBF应用到一组特定状态”的选项给勾上，然后把像Processing这样的指定状态给圈进来，这样设备在闲置的时候，它的正常运行计时就不会继续往下走了。
3、碰上复杂的抢修过程就单独去建逻辑
要是设备在出故障之后，还牵扯到要去呼叫维修工人、等备件送过来，或者是移动工具车这一连串的动作，那么就可以结合Process Flow这块来一起处理了。FlexSim的文档里就提到过，MTBF MTTR可以负责去生成设备故障的那些事件，而Process Flow再对停机和恢复这些事件进行监听，从而去安排出一套更加完整的抢修流程出来，这样建出来的模型会更贴近实际。
三、故障设定好了要怎么去验证
等故障的逻辑全部加进去以后，不能只是瞅一眼设备有没有变成代表停机的那个颜色就完事了，还得再去核对一下整个过程中它到底停了几次、总共停了多少时间，还有它的产出量有没有发生变化，这些才是真正用来判断模型是否准确的依据。
1、先把相关时间设短一些来跑跑测试
刚开始的时候，可以临时把设备的正常运行时间，还有它故障修复的耗时，都改短一点，让模型先去跑一阵子，确认设备确实能够按照预想的停机和恢复之后，再把参数换回正式要用的那套数据。这样做，比直接就用长周期的数据去跑，更容易在早期就把配置上的一些错误和问题给暴露出来。
2、去看看设备是不是真的各自独立地在停机
当好几台设备共同挂在同一个MTBF MTTR组件下面的时候，就要站在模型里面观察一下，它们是不是真的在按照各自的规律分开停机。如果发现这些设备老是绑在一起同时趴窝，那就多半要回头去检查一下，那个叫“成员独立停机”的开关有没有被打开。
3、翻一翻Dashboard里面的统计图表
在Dashboard这个仪表板里面，把跟设备状态、产量还有利用率相关的那些图表都给加进来，对比一下故障逻辑引入前后，这些数字都发生了哪些变化。要是设备的停机动作已经触发了，可产量曲线却纹丝不动，那就得去核实一下故障到底加在没加对的对象身上，或者看一看它的下游序列里是不是囤着大量的缓存，把这部分波动给平滑掉了。
4、也别忘了检查Processor的容量
当Processor的Max Content被设成了比1大的数值时，用起来可就要格外留神了。FlexSim的文档里特别提醒过，在这种情况下，MTBF MTTR里面有关时间和状态的统计，说不定就没有办法被正确地计算出来。如果确实需要去模拟那种能够并行处理多件产品的设备，比较推荐的思路是，还是优先把它拆分成好几个各自独立的Processor来处理，这样跑出来的数据才更可靠。
总结
在FlexSim里面要加入设备故障，一般就是用Toolbox里头的MTBF MTTR功能，先把设备加进成员列表，然后再把第一次故障的时间、正常运行的间隔，还有停机后的状态，这几项逐一配置好。而恢复时间则主要是在Down Time这个字段里，根据实际的维修数据去填写，既可以是固定的数值，也可以采用一种随机分布。等全部设好之后，再回过头去核对一下设备在各个时间段的状态变化、总停机次数、利用效率，以及最终的产量波动这些关键指标，只有这样做，模型最终跑出来的结果，才会跟产线上的实际情况贴得更近。
