RAMP Simulation Software for Modelling Reliability, Availability and Maintainability


RAMP Simulation Software for Modelling Reliability, Availability and Maintainability is a computer software application developed by WS Atkins specifically for the assessment of the reliability, availability, maintainability and productivity characteristics of complex systems that would otherwise prove too difficult, cost too much or take too long to study analytically. The name RAMP is an acronym standing for Reliability, Availability and Maintainability of Process systems.
RAMP models reliability using failure probability distributions for system elements, as well as accounting for common mode failures. RAMP models availability using logistic repair delays caused by shortages of spare parts or manpower, and their associated resource conditions defined for system elements. RAMP models maintainability using repair probability distributions for system elements, as well as preventive maintenance data and fixed logistic delays between failure detection and repair commencement.
RAMP consists of two parts:
  1. RAMP Model Builder. A front-end interactive graphical user interface.
  2. RAMP Model Processor. A back-end discrete-event simulation that employs the Monte Carlo method.

    RAMP Model Builder

The RAMP Model Builder enables the user to create a block diagram describing the dependency of the process being modelled on the state of individual elements in the system.

Elements

Elements are the basic building blocks of a system modelled in RAMP and can have user-specified failure and repair characteristics in the form probability distributions, typically of Mean Time Between Failure and Mean Time To Repair values respectively, chosen from the following:
  1. Weibull: Defined by scale and shape parameters.
  2. Negative exponential: Defined by mean average.
  3. Lognormal: Defined by median average and dispersion.
  4. Fixed : Defined by a maximum time to failure or repair.
  5. Empirical : Defined by a multiplier.
Elements can represent any part of a system from a specific failure mode of a minor component to major subsystems depending on the level and detail of the analysis required.

Deterministic elements

RAMP allows the user to define deterministic elements which are failure free and/or are unrepairable. These elements may be used to represent parameters of the process or where necessary in the modelling logic.

Q values

Each element of the model has a user-defined process 'q value' representing a parameter of interest. Each element is considered to be either operating or not operating and has associated performance values q = Q or q = 0 respectively. The interpretation of each 'q value' in the model depends on the parameter of interest being modelled, which is typically chosen during the system analysis stage of model design.

Groups

Elements with interacting functionality can be organised into groups. Groups can be further combined to produce a Process Dependency Diagram of the system, which is similar to a normal reliability block diagram commonly used in reliability engineering, but also allows complex logical relationships between groups and elements to permit a more accurate representation of the process being modelled. The PDD should not be confused with a flow diagram since it describes dependency, not flow. For example, an element may appear in more than one position in the PDD if this is required to represent the true dependency of the process on that element. Groups may also be shown in full or may be compressed to allow the screen to show other areas to greater resolution.

Group types

Each group can be one of eleven group types, each with its own rule for combining 'q values' of elements and/or other groups within it to produce a 'q value' output. Groups thus define how the behaviour of each element affects the reliability, availability, maintainability and productivity of the system. The eleven group types are divided into two classes:
Five 'Flow' group types:
  1. Minimum : qM = min
  2. Active Redundant : qA = min unless qA < Cut-off, then qA = 0
  3. Standby Redundant : qS = as for Active Redundant, but where the first component is always assumed to be duty equipment.
  4. Time : qT = 0 if component with 'q value' q1 is in a "down" state when time through mission t < t0, otherwise qT = q1 +... + qm if component with 'q value' q1 is in an "up" state when time t ≥ t0 + x Time Delay, where m = 1 to n.
  5. Buffer : if the buffer is not empty qB = q2 else qB = min, where the buffer empties as output if component with 'q value' q2 is in an "up" state with level at time 0 = Initial Level, otherwise level at time t = level at time -, and the buffer fills as input if component with 'q value' q2 is in a "down" state with level at time 0 = Initial Level, otherwise level at time t = Capacity if level at time + q1 > C, otherwise level at time t = level at time +. Buffer input and output may also be limited by buffer constraints.
Six 'Logic' group types:
  1. Product : qP = q1 x q2 x... x qn
  2. Quotient : pQ = q1 / q2
  3. Conditionally Greater Than : if q1 > q2 then qG = q1 else qG = 0
  4. Conditionally Less Than : if q1 < q2 then qG = q1 else qG = 0
  5. Difference : max
  6. Equality : q1 if q1 lies outside the range PA to PB, q2 if q1 lies inside the range PA to PB
Three group types are displayed in parallel configurations. All others are displayed in series configurations.
Six group types contain exactly two components with 'q values' q1 and q2. All others contain two or more components with 'q values' q1, q2 to qn.

Element states

An element may be in one of five possible states and its 'q value' is determined by its state:
  1. Undergoing preventive maintenance.
  2. Being repaired following failure, including queueing for repair.
  3. Failed but undetected, dormant failure.
  4. Up but passive, available but not being used.
  5. Up and active, being used.
Occurrence of a state transition for an element is determined largely by the user-defined parameters for that element.

Element resource and repair conditions

There is often a time delay between an element failing and the commencement of repair of the element. This may be caused by a lack of spare parts, the unavailability of manpower or the element cannot be repaired due to dependencies on other elements. In all of these cases, the element must be queued for repair. RAMP allows the user to define multiple resource conditions per element, all of which must be satisfied to allow a repair to be commenced. Each resource condition is one of five types:
  1. Repair Trade: a specified number of a repair trade must be available.
  2. Spare: a specified number of a spare part must be available.
  3. Group Q Value: a specified group must satisfy a condition regarding its 'q value'.
  4. Buffer Level: a specified buffer must satisfy a condition regarding its level.
  5. Element State: a specified element must satisfy a condition regarding its state.

    Repair trades repair condition

Repair trades can be specified for the repair of any element, and they represent manpower in the form of a set of skilled maintenance workers with a particular trade. A repair trade can be used for the duration of an element repair. On completion of the repair, the Repair Trade becomes available to repair another element. the number of repairs which can be performed simultaneously for elements requiring a particular repair trade depends on the number of repair trade resources allocated and the number of that repair trade specified as a requirement for the repair.

Spares repair condition

If a spare part is required for an element repair, then the spare part is withdrawn from stock at the instant the repair commences. The maximum number of spare parts of each type that may be held in stock is user-defined. The stock may either be replenished periodically at a user-defined time interval, or when the stock falls below a user-defined level, in which case RAMP allows a user-defined a time delay that must occur between reordering and the actual replenishment of the stock.

Group Q value repair condition

RAMP allows the user to specify that an element cannot be repaired until the 'q value' of a nominated group satisfies one of six conditions relative to a user-defined non-negative real number repair constraint. These conditions may be used to model certain rules in a system.

Buffer level repair condition

Specifying a buffer level constraint means that preventive maintenance of an element can be restricted until the buffer level of a nominated buffer group satisfies one of six conditions relative to a user-defined non-negative real number repair constraint. These conditions may be used to model certain rules in a system.

Element state repair condition

RAMP allows the user to specify that an element cannot be repaired until the state of another nominated element satisfies one of six conditions relative to a user-defined non-negative real number repair constraint.

Repair policy

Each element has user-defined parameters that can affect how it is repaired:
  1. Logistic repair delay: A time period that must elapse before a repair can start on an element. It is a fixed time that is added to the repair time sampled from the user-defined repair probability distribution for the element. Typically, it represents a combination of the time taken for the repair team to reach the site of failure, time to isolate the failed item, and time taken to obtain the required spare part from store.
  2. Repair 'good-as-new' or 'bad-as-old': Refers to the failure rate of an element rather than its 'q-value'. By default an element is restored to 'good-as-new' following repair, but there is an option to toggle a 'bad-as-old' state that simulates a quick-fix equivalent to restoring the element to the beginning of the wear-out phase of a Weibull bathtub curve, should a Weibull probability distribution with shape greater than one be used for repairs.
  3. Repair priority: Used only if element resource and repair conditions are specified. The purpose of this field is to help determine the sequence in which elements are drawn from the repair queue as resources become available for element repair. Elements are repaired according to their repair priority, where 1 is highest priority, 2 is next highest, and so on. Elements with the same priority are repaired on a 'first come first served' basis.
In addition, each element in a Standby Redundant group has more parameters that can affect how it is repaired:
  1. Passive failure rate factor: Factor by which the element failure rate is multiplied when operating in the passive state as opposed to the active state. By default this factor will be one and typically between zero and one, indicating a lower passive failure rate than active failure rate.
  2. Probability of switching failure: Percentage probability that the element will fail when switched from the passive state into the active state. If such a switching failure occurs, the element must be repaired in the normal way before it can be used again.
  3. Startup delay: Startup of the element going from a passive state to an active state is delayed by a specified time.