In short: Is there a way to specify the time consumption of failure intervals more detailed than by FailureMode. I wan't to consume failure time of a ParallelProc based on that ParallelProcs ProcessingTime AND based on another SingleProcs processing time.
One Idea I have is to deactivate and activate the Failures of the parallel procs based on whether there is a MU on the Single Proc. Thus, another question is how the activation and deactivation of failures impacts the consumption of failure intervals and failure times.
In long: I have an automatic line process with several processing stations. The line is loaded manually by an operator piece by piece. The operator always loads the entire content of a steel cage and then proceeds to get the next steel cage and load the content of this one. Several hundred pieces may be in a steel cage at once.
I have implemented this using 1 SingleProc modelling the manual loading. The SingleProc simply processes according to a fixed cycle time per piece multiplied with the custom QTY attribute of the steel cage. So the SingleProc doesn't deal with pieces but with steel cages. The rest of the line is modelled using ParallelProcs for the subsequent process steps at the line, e.g., painting and subsequent annealing. The idea is that the ParallelProcs model the time it takes for the last piece of any steel cage to proceed through the subsequent steps. As the line is entirely coupled, throughput is determining the overall takt, in turn determined by loading speed. The ParallelProcs have unlimited capacity. By this, I have managed to keep program run times really low and realistically represent the process.
However, the failures are now a little problem. So far, I have written methods that stop the upstream processes in a line whenever a failure occurs. As such, downstream processes are still processed. The 'loading'-SingleProc is not failing, but pausing. The problem is now however that the failure time of the line should relate to the processing time of the ParallelProcs. This is however not correct since they only measure the travel time of the last piece of a steel cage and thus underestimate the actual processing time.
The idea is now to consume processing time whenever there is a part on the either of ParallelProcs. This is trivial, by just choosing failure mode relates to processing time. However, the failure interval should also be consumed if the SingleProc contains an MU.
Is there a way to manage this?
Solved! Go to Solution.
You can fail an object by SimTalk: ParallelProc.Failed:=true. That way you can make the failure behavior totally dependent on another process.
I was thinking, couldn't you use the LockoutZone object? Then you do not exactly fail, but rather stop objects when one of them fails. The LockoutZone is in the Resources folder.
Thanks for your answer. The problem is that several ParallelProcs are interconnected. If one fails, only those upstream of it fail. This also means that the failure time of the SingleProc, which starts this chain of interdependence, can't be used directly to control the failure of downstream ParallelProcs but rather the other way round. This is also what I do.
Now the problem is that I don't want to consume failure interval's of ParallelProcs when there is no MU on any of them OR on the SingleProc at the beginning.
I think the object you spoke about does not exist in the version 8.2
Anyway, I guess you can help me with the question how the active/inactive impacts failures. I am currently writing methods that activate the failures off all ParallelProcs in chain as soon as the SingleProc is allocated a MU (as then, the line is running). Furthermore do I write an exit control for the very last ParallelProc in the chain that checks whether there is any MU left on previous ParallelProcs or the initial SingleProc. If not, it deactivates the failures.
Will this result in the behaviour that I want, i.e., only consuming failure intervals whenever there is a part on one of any of the ParallelProcs or the SingleProc at the beginning? Or does this always reset something?
Would be great if you could help me with that.
Personally, I am cautious of playing around with activation/deactivation of Failure profiles.
But in your case I can imagine something like the following. I assume that each ParallelProc/SingleProc has an active Failure-profile. You give each ParallelProc in your "line" a Failure control (object dialog>Tools>Edit Controls). In the method, you can Pause the immediate predecessor (SimTalk: pred, Pause). If you also have a Pause control in place, you can also keep Pausing predecessors until there is no predecessor left in the chain. As soon as you/the model sets Failed to false, you also set Pause to false again. The line starts running again. Alternatively, you can put the objects in a list/table and loop back from your failed object.
PS: V8.2 is a very old, no longer supported version of Plant Simulation!
Thanks again for the answer.
Just to quickly clarify: I am currently using failure controls to fail upstream objects whenever a downstream objects fails. Another control observes whether all downstream objects are available again and the removes the failure from a specific object.
What I am trying to achieve is that whenever there is one MU on the "line", all failure profiles should consume failure intervals. Whenever there is no MU on the "line", there should be no failure profile consuming failure intervals. Typically I would do this by simply setting "failure time refers to processing time". However, this is not possible (due to my "logic" described earlier) and so I was thinking to write controls that activate all the failure profiles whenever there is a part loaded onto the "line" and deactive all failure profiles whenever the exit control of the last process identifies there is no more part left on the "line".
But I think you refered to this idea when you said to be cautious about activating and deactivating failure profiles. I assume that everytime I activate the failure profile, everything starts anew. Ideally, the previous failure event would just be delayed when deactivated and then resumed when activated again. I saw a post earlier that implied this. But probably that is not true?
Thanks again for the answer
I am not sure whether I get the issue here.
First of all, as I understand it, there is a "source" of a failure, i.e. at some point in time an object in the line fails. The failure only happens when there is an MU located on it, so that would be failure mode "ProcessingTime". (I inferred that it is not likely that another object fails at exactly the same time) This failure iniates a kind of protective circuit for the upstream processes. By using Pause instead of Failed, you make sure that no MU will be located on the object during the failure time. It is kind of similar to Failed true/false. And you have a means of measuring how much time an object is stopped due to failures elsewhere.
the problem is indeed a bit different.
I am simulating a line process consisting of manual loading and automatic line processing stages. Parts processed on the line arrive in steel cages and are loaded manually to the line by an operator. Lets assume the stages are washing, painting, and annealing. Each of the three process stages has availability of 95% and MTTR 3600 seconds. Loading is done 1 second per piece by an operator. Loading speed determines cycle time for the line (as it can't produce faster than it is fed with parts and it can't be fed faster with parts then it processes).
This, I am modelling using SingleProc for the operator loading the line, and using ParallelProcs for washing, painting, and annealing. Thus, the single proc represents the time neecssary to load the content of a full steel cage to the line. The parallel procs however represent how long it takes for the last part of a steel cage to travel the specific process stage on the line (e.g., 5 meter washing at speed of 0.1m/s).
If I now just choose failure time refers to processing time, it doesnt make sense, since the parallel procs may be empty in my model even though the line is running, e.g., if it is currently loaded and the "steel-cage-MU" is in the SingleProc. The problem is that there are in reality already parts on the downstream stages but not in the model.
I am not having a problem with failing or non-failing the processes as required. My problem is with regards to the failure interval consumption as I can't use the standard options of Plant Simulation.
My problem is therefore to adjust the failure interval consumption of the ParallelProcs so that it matches the situation that whenever the SingleProc contains an MU (steel cage with custom attribute Qty), OR any of the parallelprocs making up the line contains an MU (steel cage that is processed for a fixed time representing the travel time of the last part of that steel cage), I need to consume failure intervals for all ParallelProcs.
So, I am currently just setting failure time refers to simulation time and activate/deactivate the failure profiles of the parallel procs as soon as there is one part on the line/no part on the line.
The question is therefore: If I deactivate the failure profile when I don't want to consume failure intervals and activate it again when I want to consume failure intervals: does that make sense?
Or, do you have another solution to this?
Ok, I think I get the problem. Version 8.2 is too hold for me to check if anything strange happens to the next failure event when (de)activate the failure profiles, but I am quite sure that pausing will do no harm to it!
I think it is wise to disinguish between "failures" and "stoppages". So, a "failure" is when an object failed independently because of its failure profile. This kind of failure should only happen when there is an MU located on it. Then, a "stoppage" occurs when another object has a "failure", it is dependent on another object.
But still I think the solution is the same in principle. A Fail-control will trigger when the Failed-state of an object changes. In the code you can query if the object in question just started to fail, or just recovered. The dependent objects can then be paused/unpaused. To me this looks like the safest way to handle the postponement of failure events: an object that is paused cannot go into a failure if it depends on the processing time.
A last thought: you may be over-simplifying you system a bit. You could use a DismantleStation for the unloading and a Line object for the processing part. It will be more precise regarding the timing aspect and it will be more understandable, although it takes some more CPU time.
Thanks for the answer, again
Tow short questions:
(1) Is there a possibility to exclude specific days from failure interval consumption without using pause state (reason see below).
(2) When I manually set an object into failed state, will it then consume failure interval of its own failure profile? Assuming the mode is "simulation time" or "operating time".
Generally, I must correct myself: I am actually pausing upstream in case of failure at a certain stage. However, I didn't do this initially because of the failure interval consumption consideration but just for 'reasons'. Thus, you made a very good point. I guess that this rules out using "relates to processing time", since then, failure intervals would be only consumed when downstream processes are not failed. As the idea is that the failures occur independently, the failure intervals need to be consumed independently of downstream failures. If I understood you correctly, pausing an upstream object prevents it from consuming its failure interval -- which would be not the desired code of action.
Thanks for this thought as I haven't event considered that problem yet. My initial idea of using "relates to processing time" in combination with some technique to include the processing time of another object will give wrong results.
My initial concern with my model was that while an MU is getting "dismantled" in the SingleProc, the "line segments" should be consuming failure intervals (which they don't when set to "relates to processing time" as the MU is only located on the SingleProc despite the fact that something has been [logically] loaded already from the MU to the line). The reason is that in reality, loading requires an operating line and we agreed (we, as in, the SMEs I model for) that the very rough failure estimation should relate to the running time of the line.
1: You can use a Formula for the Interval field of the Failure-profile and then use a ShiftCalendar to calculate the exact point in time for the next failure event.
2: I don't know. But you could try it out yourself.
BTW, you can also implement the correct MTBF, depending on whatever you like, and use a Formula for the Duration field. When a failure event occurs you can decide at that precise moment how long the failure should take, depending on all kinds of conditions. The Formula should refer to a method in your case and it should return the duration of that failure epoch.
Altogether I still get a sense that you make things complicated in an undesirable way. You mention a "very rough failure estimation" and use ParallelProcs to represent complete production lines. That may seem simple at first, but when you need all the trickery you describe the model has become far from simple, nor transparent.