Problem with breakdowns using an operator

Question

question

Jonas F asked May 21, '21 Ben Wilson commented Jun 29, '21

Problem with breakdowns using an operator

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.

Software Version:

FlexSim 20.0.10

operator flexsim 20.0.10 breakdown

debug-model.fsm (142.8 KiB)

· 2

Joerg Vogel commented · May 21, 2021 at 10:10 AM

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.

0 ·

Eric M commented · Jun 07, 2021 at 03:06 PM

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.

0 ·

Answer 1 · 2021-05-21T11:13:49Z

Joerg Vogel answered May 21, '21 Ben Wilson commented Jun 29, '21

@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.

typical-ratio-of-breakdown-processing.png (4.4 KiB)

atypical-ratio-of-breakdown-processing.png (4.5 KiB)

causing-strange-short-breakdows.png (9.8 KiB)

dbug-model-constant-values-breakdown-repair.fsm (55.1 KiB)

· 9

Joerg Vogel commented · May 21, 2021 at 11:49 AM

valid options with minor difference in statistical results

0 ·

valid-options-a-mtbf-mttr.png (6.5 KiB)

valid-options-b-mtbf-mttr.png (6.7 KiB)

Jonas F commented · May 21, 2021 at 11:54 AM

@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

0 ·

Joerg Vogel Jonas F commented · May 21, 2021 at 12:02 PM

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

1 ·

missing-breakdowns-while-long-lasting-process-time.png (3.6 KiB)

Jonas F Joerg Vogel commented · May 21, 2021 at 01:09 PM

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.

0 ·

Show more comments

question