How to Perform Reliability, Maintainability, and Availability Analysis with Innoslate

Published by on August 19, 2015 at 10:33 am.

How to Use Innoslate for Advanced Users

A system is reliable when it gives the same result each time you use it. This reliability gives users confidence that the system will be there to support them when needed; hence the users are more likely to want to use such a product and the product increases in value.  All human-built systems fail at some point.  The trick is to design the system so that reliability is enhanced.

The same can be said of maintainability. Everything we build breaks down, so the ability to maintain a system easily and at low cost is an important consideration. Many people don’t want to buy iPhones because when the battery no longer can hold a charge the phone is worthless.

And of course, if a system isn’t available then it’s useless to meet the user’s need.

All three of these parameters are critical “ilities” that are often ignored as part of the systems engineering process. One of the reasons why it’s overlooked is that RAM analysis requires details to estimate uncertainties in estimated values and requirements, which takes time and money. As such, it often is not addressed at all until the detailed design phase. So what happens is someone arbitrarily assigns the number of “9’s” needed (e.g., 99.999% reliable). However, RAM should be part of the overall scenario analysis at the very beginning of the concept development phase.

To avoid that problem, we use the overlay to the Middle-Out process below. The red text highlights key places in the process where RAM considerations can be included.

RAM blog pic 1

Note that we want to consider RAM in the context diagram and scenario development at the very beginning.

A good example of RAM analysis is provided in the Applied Space Systems Engineering (ASSE) book (see p. 113). They define the RAM requirements as:

  • Reliability: “The FireSAT spacecraft shall have an on-orbit lifetime of at least five years”
  • Availability: “The FireSAT spacecraft shall have an operational availability of 98%, excluding outages due to weather, with a maximum continuous outage of no more than 72 hours”
  • Maintainability: “The FireSAT spacecraft shall require the removal (or opening) of no more than ten fasteners (panels) to replace any Line Replaceable Unit (LRU) … during pre-launch ground operations”

But where did these requirements come from? Were they the result of analyses or are they just best guesses (“engineering judgement”)?

The Lifecycle Modeling Language (LML) was designed to capture and create models to support all aspects of systems engineering across the lifecycle, including RAM considerations. LML provides:

  • Asset/Resource entities, Asset Diagrams, and Characteristics/Measures entities to capture physical information about the system
  • Action entities, Action Diagrams, and Input/Output to capture and model processes
  • Action Diagrams can be simulated to include Resource use

As such, LML can support the analyses needed to derive key RAM metrics, such as Mean Time between Failures (MTBF).

Innoslate® implements LML and has been used to create in-depth models that reflect RAM concerns early in the lifecycle.


One way we enhance system reliability is to use redundant components. For example, a spacecraft which is subject to a high radiation environment may have multiple computers to perform navigational calculations. The computers then “vote” so that if one or two of the computers have a “glitch” (the technical term is single event upset) the navigation system will accept the majority report. The figure below shows an Asset Diagram that provides a physical picture of a navigational system, which includes the sensors, computers and controls.

RAM blog pic 2

The equivalent functional model is shown as an Innoslate Action diagram below.

RAM blog pic 3

Innoslate allows timing to be provided for each computer as a random distribution. Random distributions for possible failure modes can also be used. A failure mode hierarchy for the FireSAT example from the ASSE book is shown below.

RAM blog pic 4

This hierarchy comes (automatically) from the Action Diagrams that model the failure processes (see below).

RAM blog pic 5

The below graphics are a result from using Innoslate®’s Monte Carlo simulator (currently available in the Enterprise edition).

RAM blog pic 6

Obviously any preliminary numbers developed using these models will need to be refined as component RAM information becomes available, but this analysis done in the beginning of the program can be used to bound what the acceptable component performance must be to have a successful mission.