arrow_back_ios

Main Menu

See All Software See All Instruments See All Transducers See All Vibration Testing Equipment See All Electroacoustics See All Acoustic End-of-Line Test Systems See All Academy See All Resource Center See All Applications See All Industries See All Services See All Support See All Our Business See All Our History See All Global Presence
arrow_back_ios

Main Menu

See All nCode - Durability and Fatigue Analysis See All ReliaSoft - Reliability Analysis and Management See All Test Data Management See All DAQ Software See All Drivers & API See All Utility See All Vibration Control See All High Precision and Calibration Systems See All DAQ Systems See All S&V Hand-held Devices See All Industrial Electronics See All Power Analyzer See All S&V Signal Conditioner See All Acoustic Transducers See All Current and Voltage Sensors See All Displacement Sensors See All Force Sensors See All Load Cells See All Multi Component Sensors See All Pressure Sensors See All Strain Sensors See All Strain Gauges See All Temperature Sensors See All Tilt Sensors See All Torque Sensors See All Vibration See All Accessories for Vibration Testing Equipment See All Vibration Controllers See All Measurement Exciters See All Modal Exciters See All Power Amplifiers See All LDS Shaker Systems See All Test Solutions See All Actuators See All Combustion Engines See All Durability See All eDrive See All Production Testing Sensors See All Transmission & Gearboxes See All Turbo Charger See All Training Courses See All Acoustics See All Asset & Process Monitoring See All Custom Sensors See All Data Acquisition & Analysis See All Durability & Fatigue See All Electric Power Testing See All NVH See All Reliability See All Vibration See All Weighing See All Automotive & Ground Transportation See All Calibration See All Installation, Maintenance & Repair See All Support Brüel & Kjær See All Release Notes See All Compliance
arrow_back_ios

Main Menu

See All API See All Experimental Testing See All Electroacoustics See All Noise Source Identification See All Environmental Noise See All Sound Power and Sound Pressure See All Noise Certification See All Industrial Process Control See All Structural Health Monitoring See All Electrical Devices Testing See All Electrical Systems Testing See All Grid Testing See All High-Voltage Testing See All Vibration Testing with Electrodynamic Shakers See All Structural Dynamics See All Machine Analysis and Diagnostics See All Dynamic Weighing See All Vehicle Electrification See All Calibration Services for Transducers See All Calibration Services for Handheld Instruments See All Calibration Services for Instruments & DAQ See All On-Site Calibration See All Resources See All Software License Management

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 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 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?