Processor repair during the scheduled downtime

Processor repair during the scheduled downtime

nathaniel_pech
Observer Observer
329 Views
4 Replies
Message 1 of 5

Processor repair during the scheduled downtime

nathaniel_pech
Observer
Observer

Hello,

 

I am working in FlexSim 24.0. I have several processors that follow a schedule, and I have assigned MTBF/MTTR values to these processors. The problem is that when a processor fails just before a scheduled downtime period in the schedule (for example, a weekend), the repair of that processor continues during that downtime period, so that it is repaired when the schedule returns to operational mode. Do you know if it is possible to pause the processor repair during the scheduled downtime and resume it once the scheduled downtime is over?

 

Thank you for your help 🙂

0 Likes
330 Views
4 Replies
Replies (4)
Message 2 of 5

joerg_vogel_HsH
Mentor
Mentor

There two parameters you can set for down function in template editor ID and Priority. They are introduced to override such problems.
Please refer to descriptions about stop method or stopobject command 

EDIT:

But infact this does not solve your request, because the breakdown event is not suspended. It still ends while scheduled dowtime lasts. You see next in this post some inserted lines of code that delays the breakdown event over the time of scheduled down. Unfortunately this duration is counted twice in default statistical state output. You have to customize state charts by a customized calculated table to reduce the breakdown state output value by the amount of delayed duration. 

/**Stop Object*/
int id = /***tag:id*//**/1/**//**/;
double priority = /***tag:priority*//**/2/**//**/;
// inserted
if(downobject.stats.state().value = 11) {
	delayeventsofobject(Model.find("Tools/MTBFMTTR/MTBFMTTR1"),duration);
}
// inserted end
stopobject(downobject ,state, id, priority, stateprofile);

 This code lines are from Timetable Down Function. 
There are some more restrictions on this solution. The delayed events of object belongs to an MTBFMTTR1 tool and not its member. So all members get delayed. This approach works only if there is only one member in each MTBFMTTR Tool. 

2nd Edit: the statistical problem occurs, when there are more members in time table tool. if there is only one object, then the state chart is resolved correctly. 

0 Likes
Message 3 of 5

nathaniel_pech
Observer
Observer

Ok thanks, so there is no possibilty if I have all my processors member of the same MTBF/MTTR tool ?

0 Likes
Message 4 of 5

joerg_vogel_HsH
Mentor
Mentor

No, because delay events of objects will delay all events of mtbf/mttr. This can have an effect on next breakdown time. 

0 Likes
Message 5 of 5

FelixMoehlmann
Collaborator
Collaborator

A possible solution would be to make the MTTR use an operator to fix the processor. In that case the repair time becomes the duration of a delay task of the operator. If the operator is attached to the same schedule as the processor, the delay task will be paused during the scheduled downtime and resume afterwards.

 

Edit: Sorry, forgot that you are working in 24.0. Added a second example model. Also, I'd like to emphasize that MTBF/MTTR and Time Table must use different stop IDs for the state to get reset back to "Breakdown" after the scheduled downtime. It's an easy thing to miss/forget.

0 Likes