Reverse Engineering

Availability - Achieving
Reliable and
Supportable Designs

August 2007

“Transforming Strategy into Capability”

 Experience
• Defence Background - Air Force
• Operations and Maintenance Delivery
• Ground Equipment
• Aircraft
• Requirements Specification
• Operational performance based specification
• JORN Project – Reliability Engineering
• Whole project – electronics, infrastructure
• Other Applications Environments
• IT (Telstra & others), Facilities Infrastructure (ANZ),
Plant and Equipment, Unattended Facilities, Radars

“Transforming Strategy into Capability”

 Overview
• Outline some simple Systems concepts
• Share some experiences with RAM
Requirements
• Outline an approach to determining required
Reliability from support considerations
• Discuss availability concepts in context –
supporting practical applications specification
and design
• Outline some keys to success

“Transforming Strategy into Capability”

 Availability
Availability is normally measured as the ratio of an “Uptime”, meaning
the system is working satisfactorily versus some total time, of
which the system could be expected to work.

Uptime
Availabili ty 
Total _ Time
There are two flavours of availability:
• Inherent Availability (Ai), and
• Operational Availability (Ao)

This ratio is usually discussed as a probability – 2 event states

“Transforming Strategy into Capability”

 Reliability
By definition Reliability has three distinct components:

• Specified Functions / Requirements / uses

• Specified environments (conditions under which it is
used), and
• Specified time (how long to run, how long can run
degraded)

Reliability is expressed as a “probability” that these three

conditions will be simultaneous achieved

“Transforming Strategy into Capability”

 Three Domains (Spaces)

Physical
(As – Designed)
Solution
Architectecture
Physical characteristics

Operations
(Customer / Business
Environment)

Support

(Providing the services

to keep the Physical
solution meeting the
Users needs)

“Transforming Strategy into Capability”

 System Variation
• All outcomes result from a system of
interconnected processes
• Variation exists in all processes
• Understanding and reducing variation are keys
to success (Adapted from ASQ 1995)

These concepts apply to all levels of a system - from machine level to facility
level and includes both man and machine and their impact on “outcomes.”

“Transforming Strategy into Capability”

 Outcome Evaluation
User / Customers Requirements

Delivery Processes

Evaluation of Outcomes

This is where KPIs are

Process Outputs normally measured

Delivered Outcomes

“Transforming Strategy into Capability”

 Requirement 1
• What’s wrong with this interpretation:

• 0.9999 Availability = < 5 minutes downtime / month

(discussion with PM in IT design)
• What’s the reliability – is there going to be DT every month?
• Time base – power on time, use time ?
• Can you really have 5 minutes downtime
• What is considered “DOWN”?

• Believe it or not, this seems to be very common

thinking
“Transforming Strategy into Capability”
 Requirement 2
• This WIDGET will have demonstrated reliability
statistics of greater than ninety (90) percent
(extract from recent VIC Government Tender)
• Which reliability statistics do they mean ?
• How is it demonstrated and would this be relevant
• Service delivery contract (availability based) – is the
WIDGET Reliability actually relevant ?

“Transforming Strategy into Capability”

 Requirement 3

• The [WIDGET] is broken again, why can’t you

[maintainers] keep it working?
• What was it doing at the time?
• Is it capable of this:
• Function
• Performance over time

“Transforming Strategy into Capability”

 The Best Requirement Ever
• The “WIDGET” will have a 90% probability of
mission success whilst continuously operating in
an area [a fair way away from the start] for 18
hrs a day, for 30 continuous days. [request for
OTS solution]
• WIDGET has known endurance of 4 hours
• WIDGET has operational maintenance requirements
• WIDGET designed as stand alone capability
• Is this reasonable for an “off-the-shelf” solution
that was not designed to be operated this way?

“Transforming Strategy into Capability”

 Concentrate on Ao

• The End User experience –

synergy between all three
domains

• Early consideration
• Cost of design changes gets
increasingly more expensive to
implement
“Transforming Strategy into Capability”
 Design Influence on Outcome
1.2

1
Concept
0.8
De monstra tion &
0.6 Va lida tion

Full S c a le
0.4 De ve lopme nt

P roduction &
0.2 Operation
Dis pos al
0
S cope Remaining for Decis ions to Influence LCC
Decis Strategy
“Transforming ions already
intomade having
Capability” an irrevers ible influence on LCC
 Distribution of Total Costs

“Transforming Strategy into Capability”

 Concentrate on Downtime Reduction

• The failure rate of the system is:

• Built into the physical implementation and
operational use
• The consequence of unexpected failures
• Is determined by the (business) application
• And the physical design
• The management of the failure consequences
and rectification is a factor of:
• Physical Design
• Support System Design

“Transforming Strategy into Capability”

 What is Major DT Contributor?
Reliability?
Reliability? Personnel
Personnel
Availability?
Availability?

Travel
Travel
Testability?
Testability? to
to Personnel
Personnel
Site?
Site? Skill
Skill??

What is the major contributor to Operational Downtime?

Time
Time
to Waiting
Waiting
to Maintainability?
Maintainability?
Repair? for
for
Repair? Spares
Spares??

“Transforming Strategy into Capability”

 Ac c umulate d Do wntime (ho urs )
Downtime Distribution
S ys te m Do wntime pe r S quadro n o f 4 Fas t
Patro l Bo at Clas s e s (40 bo ats ) in 1985

2000

1800

1600

1400
Re pa ir, wa tc h,
1200 a dmin.
Othe r prioritie s
1000

800 S e a Conditions

600
Wa iting for s pa re s
400

200

0
FP B FP B FP B FP B
Cla s s Cla s s Cla s s Cla s s
1 2 3 4

“Transforming Strategy into Capability”

 The Availability Trade-Off

Ao = 99.999

1,200
MTBF (x 1000 hrs)

1,000
800
600
400
200
0
0 2 4 6 8 10 12
MDT (hours)

“Transforming Strategy into Capability”

 Designing for High Availability /
Reliability
• Architecture – appropriate redundancy
• All things fail
• Functional failures and consequences
• Physical failures and repair cycle
• Support is Event and Consequence based
• Consequences can only be changed by changing the
design or operation (assuming optimum maintenance
policy)
• If support requirements are understood then acceptable
Ao can be achieved by improving support processes in
terms of timely delivery (to the limit of the Ai/Ao gap)

“Transforming Strategy into Capability”

 Keys to Success – Requirements
Phase
Apply Systems Engineering
Understand Requirements
Use cases – Operational and Support

Derive Supportability / Performance Requirements

Analyse interactions (3 bubble model)

“Transforming Strategy into Capability”

 Keys to Success – Design 1
Perform Modelling
• RBD Based
• Allocations
• Predictions
• Evaluate design alternatives and monitor progress
• Simulation
Perform FMECA / RCM
• Functional / Interfaces
• Consequence Analysis
• Understand FM distribution & detection, rectification
• Focus on elimination of undesirable operational and support FM
consequences

• Influence the Architecture of the whole Solution

“Transforming Strategy into Capability”
 Keys to Success – Acquisition /
Design 2
Apply Statistical Thinking to Design Operations
and Support
• Map Processes – understand drivers and process
factors
• Identify /Analyse sources Variation within the
Downtime process
• Address the Management of Variation

“Transforming Strategy into Capability”

 Keys to Success – Support
Determination
Create Support Resource Baseline early in design
– provide feedback on support cost drivers

Understand and acquire the resources (people,

material and processes) to respond to Support
”Events”
Planned
Unplanned

“Transforming Strategy into Capability”

 Keys to Success – Operations and
Support
Capture all Support Events
Perform Root Cause Analysis
Continuous validate and review RCM baseline
Monitor operations to ensure that they are with in
design capability
Educate management

Apply Statistical Thinking to support system

“Transforming Strategy into Capability”

 Summary
“Start with the End in Sight”
The systematic application of Systems Engineering
and the implementation of Reliability
Engineering Techniques produces systems:
• Capable of the achieving performance through
time
• Have understood behaviours Consequence /
Rectification
• Sustainable over the long term through on going
review and adaptation to the evolving
Operational and Support needs
“Transforming Strategy into Capability”