Opportunity maintenance in BlockSim

ReliaSoft BlockSim offers corrective maintenance and also on-condition, preventive and inspection scheduled tasks. Corrective maintenance can be implemented as a direct task when an item fails, or it can be triggered by inspections. Inspections themselves can be regularly scheduled, or they can be triggered by other system events. Accordingly, redundancy or other non-customer affecting failures can be left un-repaired until an inspection is triggered by another failure or some other (defined) maintenance action.

In today’s world of increasing availability of system diagnostics through online connectivity, operations managers can be aware of component failures within redundant systems, well ahead of any customer being aware of system degradation. However, repair of such component failures would likely be undertaken only when it is cost-effective to do so. Sending out a repair technician just for a redundancy failure may involve significant travel cost – the alternative, of waiting for system failure, may increase customer and other secondary costs.

Of course, if a system-outage results from some other component failure, the redundancy failure would usually be repaired concurrently.

However, a good operations manager might keep a list of redundancy failures and direct a technician to repair the affected system if he were driving close-by – this would avoid travel costs.

But what approach would be best for a particular system and operations scenario?

Immediate repair of redundant elements
Delayed repair of redundant elements, concurrent with other maintenance (such as for system outage or during regular scheduled inspections)
Drive-by repair

The first 2 options are easily modeled using corrective and scheduled inspections. The 3^rd requires a trigger that is essentially outside the system being modeled, namely the likelihood of a drive-by. Unfortunately, BlockSim does not allow triggers from outside the system being modeled. A “Drive-by” trigger, therefore, must be modeled within the affected system.

Example

Electronic billboards are managed by advertising companies with maybe several hundred units on inventory. Maintenance management is a key factor supporting profit generation – billboard downtime equates to lost advertising revenue.

Good billboard design will include some elements of redundancy but optimizing when and how to implement maintenance support is a complex task based on component reliability properties. This is a classic scenario to explore in BlockSim.

For simplicity, the block diagram below is used to represent a billboard. It has a serial element to represent the serial elements (“Rest of System”) and a redundancy element (“Parallel Block”). The potential for a drive-by repair is modeled with “Passing Technician” block, together with a parallel “dummy” block to prevent our modeling affecting the system availability.

Figure 1: System Block Diagram

Figure 2: Parallel Block Properties

The reliability and details of the parallel block is inconsequential to the discussion. Corrective maintenance is undertaken only when found during inspection – a technician is not sent out simply because a redundant failure has occurred. Inspections occur due to either of 2 reasons:

Whenever the system is down – “Rest of System” or the “Parallel block” in this case
Whenever a defined event from a maintenance group occurs – defined as being the group associated with the “Passing technician”

Initiating corrective action as a result of the overall system being down is perhaps easily understood. For the case of the “Passing technician” maintenance group, some explanation of the “Passing technician” block is required.

Conceptually, a dedicated dispatch of a technician will take longer due to travel time, whereas a “passing technician” will only incur the costs associated with the direct inspection time. The times and costs associated with these differences should be coded into the inspections, rather than the corrective maintenance. Corrective maintenance costs are, therefore, only those associated with direct activity.

Figure 3: Parallel block inspection task -- initiated by Passing Technician

Figure 4: Passing Technician Block Properties

Passing Technician Block

The block has a reliability model, used to model how long it might be, on average, for a technician to drive by whilst on other tasks. In this case, an exponential model is used, to indicate that there is a constant daily probability of a technician passing by. Failure of this block indicates that a technician is available to repair a redundant block. Corrective repair of the block is inconsequential to the discussion but must be carried out in order to allow its continued role.

The block is assigned the maintenance group “Passing technician” that is used by the “Parallel block”.

Thus, when the block “fails” (a technician arrives), the inspection within the “Parallel block” is triggered.

However, we do not wish to trigger a passing technician unless a “Parallel block” unit has failed. Accordingly, the “Passing technician” block is de-activated by default – it is activated by failure of any block in “Parallel block”, and is de-activated again by repair of a “Parallel block” and by its own repair (just to be sure).

Parallel block failures are observed. These are not repaired immediately, but rather await a passing technician. The probability of a passing technician is modeled, in this case, by constant rate (exponential distribution). Different durations have been assigned to the different inspection periods and corrective maintenance times, with a “passing technician” inspection being shorter than a dedicated inspection.

Summary

We thus have 2 additional blocks in the billboard system – one does nothing and one only takes up BlockSim simulation resources after a “Parallel block” item failure. Accordingly, the simulation remains efficient and does not slow down BlockSim performance.

We are now able to model a form of opportunity maintenance that may become increasingly relevant with the growth of the “internet of things” and more visible system performance.

Figure 5: Example System Block Output

Ready to take your reliability program further?

Get a free demo

Request a quote

Find training options

Main Menu

Main Menu

Main Menu

Main Menu

Opportunity maintenance in BlockSim

Example

Figure 1: System Block Diagram

Figure 2: Parallel Block Properties

Figure 3: Parallel block inspection task -- initiated by Passing Technician

Figure 4: Passing Technician Block Properties

Passing Technician Block

Summary

Figure 5: Example System Block Output

Ready to take your reliability program further?

We have moved ${referer} to www.hbkworld.com

We have moved ${referer} to www.hbkworld.com

We have moved ${referer} to www.hbkworld.com

We have moved ${referer} to www.hbkworld.com

We have moved ${referer} to www.hbkworld.com