Skip to content

A walkthrough of a typical failure event

As promised, today’s post is a guide to typical stages of a failure event. Of course, this definition may differ from what you are used to but my aim is to cover the main aspects of a failure event.

In Maros and Taro, events comprise of any outcomes within a system’s life which impact the behaviour of the system. A system can incur a wide range of events from the routine (planned) inspection and overhaul etc., to the abnormal (undesirable) episodes, such as failure and repair of equipment etc.

There are six important parameters which fully define an event:

  • Time To Failure, which describes when an event occurs;
  • Time To Repair, which describes the overall duration of the event;
  • Capacity Loss at Failure, which describes the immediate consequences of the event upon loss of functionality of the system;
  • Capacity Loss at Repair, which describes the consequences of the event during the ‘repair’ stage of the event;
  • Delay in commencing the repair stage of the event, i.e. time to diagnose what has happened and decide upon an action to rectify the situation if necessary;
  • Actual Repair Time, which describes the duration of the repair stage

Plant - A walkthrough of a typical failure event - event-schematic

Event schematic

The sketch above illustrates the most common event profile in which there are two distinct stages to the event.

  • Once a failure occurs, the maintenance logistics takes place and it is responsible for determining the “repair delay” portion of the sequence. This is achieved by defining the location, quantity and constraints of the various resources involved in the repair process, then allowing the simulation to determine each repair delay depending upon the foregoing and the instantaneous workload at the time of the failure. It is not simply a case of specifying a repair delay per task.
  • After the “repair delay” where all the maintenance resources are worked out, the process to rectify the fault can initiate. This repair might cause further degradation to the system. Consider a valve that fails to close; from a productivity point of view, there is no bottleneck to the system, the flow keeps running through the system. However, when you start the repair, most likely, you will have to stop production.

There are, however, numerous permutations of the schematic. There may be:

  • No delay;
  • No consequences;
  • One event can initiate another event thus extending the profile.

Events can be formally classified depending on their mechanism of initiation. Maros and Taro incorporates three classes of events; Unscheduled Events, Scheduled Events and Conditional Events. This gives us the ability to model basically every production loss occurrence.

Author: Victor Borges

11/14/2014 4:12:48 PM

Contact us

How can we help you?

Contact us

Read more blog posts

Back to blog overview