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.