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 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 regularly scheduled inspections)
- Drive-by repair
The first 2 options are easily modeled using corrective and scheduled inspections. The 3rd 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 optimising 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 in 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.
|
|
The reliability and details of the parallel block are 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 a direct activity.
Passing Technician Block
The details of the “Passing technician” block are shown in figure 4.
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 a 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).
An example simulation result is shown below. Parallel block failures are observed. These are not repaired immediately, but rather await for 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.
This blog was originally posted on HBK Prescia, by Les Warrington (Les Warrington Consulting). The article can be found here.
