Problem with breakdowns using an operator

[jonas_fj]

[ FlexSim 20.0.10 ]

Debug_model.fsm

Hi,

I have a problem with a model where I'm using an operator (connected via a Dispatcher) to restore a Processor that breaks down by the use of a MTBF MTTR function.

Between the breakdowns I only want time spent in the state 'Processing' to count and I therefore make use of the possibility to chose 'Processing' only on the 'Breakdown' tab of the MTBF MTTR function, checking 'Apply MTBF to a set of states' and selecting 'Processing'.

When I set my model up like this I see, however, that the MTBF MTTR function does not function properly; it does not trigger nearly enough stops and the resulting TBF is much longer than what it should be, considering the TBF distribution used as input.

This happens when I chose 'Stop Object and Call Operators' as Down Function. If, on the other hand, I chose to abandon the use of an operator for the restoration event and select 'Stop Object' only, I find that the object stops with the correct frequency (obviously without using the operator).

Further investigation shows that I get a correct behaviour if I stick with 'Stop Object and Call Operators' as Down Function but do NOT check the 'Apply MTBF to a set of states'. So, if I could live with having all time count towards TBF this would be fine. But unfortunately that's not an option for me.

Interestingly, I find that checking 'Apply MTBF to a set of states' and selecting ALL states still leads to an incorrect outcome. Surely there should be no difference to running like this as opposed to not having the 'Apply MTBF to a set of states' checked at all?!

Either I'm completely missing something here (not entirely improbable) or there is a bug in the software.

Any help would be most appreciated!

I attach a test model trying to isolate this issue.

Thanks,

Jonas

Edit: I use Flexsim 20.0.6 but for some reason I couldn't specify that.

[joerg_vogel_HsH]

You can only choose as Version the latest Bugfix Release. This is 20.0.10. The Version you are using is 20.0.X. Where X is the Bugfix release version.

[joerg_vogel_HsH · Accepted solution]

@Jonas FJ, I would change the statistcal distribution to constant values in your model:

• interarrival time: 10s
• first breakdown: 120s
• time to repair: 30s
• time between failures: 120s
• process time: 4s
• I inserted a Network of two nodes with a virtual distance of 10
• I let travel the operator to an Network Node, if he gets available.

Now you will see that the down time is much smaller, if you count only processing times being responsible for a breakdown. The breakdown time depends on the time the operator has to travel and start repairing. And the down time is constant.

But there is not any difference if you add a dispatcher or assign tasks directly to an operator. If you need a total down time including the travel time, you must compensate this and reduce the down time by the time the travel lasts.

dbug_model_constant_values_breakdown_repair.fsm

There seems to be a bug if you choose apply to a set of states and then deactivate break down members individually.

typical ratio of breakdowns

strange behavior of shorter break downs. This diagram output is the result of this setting.

Additionally there is a whole downtime missing in a simulation run, if you choose all states selected for applying states to MTBF.

[joerg_vogel_HsH]

valid options with minor difference in statistical results

---

[jonas_fj]

@Jörg Vogel,

Thank you for taking your time to look into my problem!

I agree that it makes sense to remove the statistical distributions from a debug model, facilitating debugging! So, thanks for that!

From what I can see the model, as set up by you, works fine.

One of the changes you have made, however, seem to have a crucial effect; you significantly reduced the processing time. In my application I typically expect to see processing times far longer than the MTBF (say one hour process time and 10 minutes MTBF).

Due to the short processing time in your model the processor enters the state 'Idle' in between, which seems to save the TBF mechanism.

In your model, I tried with a process time of 1000 s and spotted the same issues I described in my post.

Again, I'm most grateful for your help and input!

Best regards,

Jonas

[joerg_vogel_HsH]

@Jonas FJ, you are right. There are missing several breakdowns during the long process time. Only the first occurs.

[jonas_fj]

I just noticed that in the case when we see missing breakdowns the seemingly long, uninterrupted process time is, in fact, interrupted. Hovering over the state in the Gantt chart reveals that the first part of the processing phase ends before next breakdown. It seems that this coincides with the processing time for the first flow item having elapsed. After this interrupt in the processing time the next stop is triggered according to the specified TBF input.

So, again it seems that the breakdown mechanism is temporarily restored by this output of the flow item so that a correct sampling of the time to next stop can be carried out. Thereafter it breaks again.

[jason_lightfoot_adsk]

Hi Jonas,

Can you post the model you have configured to show the issue so that we can check it?

[jason_lightfoot_adsk]

Also - should we update software centre so you have the latest LTS version?

[jonas_fj]

dbug-model-constant-values-breakdown-repair_JF.fsm

Hi Jason,

Long time! Hope you are doing well!

Model attached.

Since I'm not normally involved with simulation work any more, I really can't say whether we should update the software center. I shall have to talk to the others.

Cheers,

Jonas

[jason_lightfoot_adsk]

Thanks for this Jonas - it does indeed look like a bug with that function when the timer event MTBF_MTTR_FINISH_DOWN_TIME_NO_RESUME gets called. I'll report it and once confirmed it should get fixed but unfortuinately not in that version - hopefully it will be in 21.0.6 and 21.1.3

[jonas_fj]

Thanks Jason, for looking into this! Much appreciated!/Jonas

[eric_m3]

Hi @Jonas F, was Joerg Vogel's answer helpful? If so, please click the red "Accept" button at the bottom of their answer. Or if you still have questions, add a comment and we'll continue the conversation.

If we haven't heard back from you within 3 business days we'll auto-accept an answer, but you can always unaccept and comment back to reopen your question.