ACHIEVING A SYSTEM OPERATIONAL AVAILABILITY REQUIREMENT (ASOAR) MODEL INTEGRATING RELIABILITY, AVAILABILITY, MAINTAINABILITY (RAM) AND SUPPORTABILITY IN REQUIREMENTS ACHIEVING A SYSTEM OPERATIONAL AVAILABILITY REQUIREMENT (ASOAR) MODEL This topic is about developing requirements that help to design in readiness. It will cover a generic model used to integrate Reliability, Availability, Maintainability (RAM) and Supportability in determining requirements. The name of this tool is the Achieving a System Operational Availability Requirement Model. Its acronym is ASOAR. The Communications-Electronics Life Cycle Management Command (C-E LCMC) Systems Analysis Division developed the ASOAR model. Unfortunately, when the Personal Computer operating systems progressed to Windows 2000 and Windows NT, the FORTRAN based ASOAR model will not work with these operating systems. If needed by any Government requestor, the C-E LCMC Systems Analysis Division can run the ASOAR model for you on an off-line computer with a Windows 98 operating system. The C-E LCMC Engineering, Logistics & Acquisition (ELA) Division is presently reworking the ASOAR model in a completely different computer language in an attempt to make the ASOAR model available again for others to use on their PCs. Bernard Price Certified Professional Logistician

ASOAR Equipment Levels of Indenture FLEET OF SYSTEMS Multiple Similar Systems Used in Mission Total Weapon System System with its GFE SYSTEM END ITEMS Primary Items Being Developed/Acquired System Without GFE or GFE Items This equipment levels of indenture diagram helps to explain the equipment levels analyzed with the ASOAR model. A FLEET OF SYSTEMS applies when multiple similar systems are used for a mission. The SYSTEM is the total weapon system or system with its Government Furnished Equipment (GFE). The system is the level where readiness rates are measured. The END ITEMS are the primary items being developed or acquired. End items are often the system without its GFE or the GFE items. ASSEMBLIES are modeled like end items in the ASOAR model. Assemblies are often modeled as a grouping of Line Replaceable Units (LRUs) within the end item or they may be common items within different end items modeled as an assembly. LRUs are the secondary items removed and replaced forward to restore the end item or assembly after it fails. LRUs are the items impacting equipment maintainability. ASSEMBLIES Grouping of Line Replaceable Units Common Items in Different End Items LRUs Secondary Items Replaced Forward Items Impacting Maintainability

ASOAR Version 6 Allocates Optimum Ao to End Items Being Acquired from System Readiness Rate Determines Ao Inputs to Use in Supportability Optimization Models Integrated Analysis of RAM and Supportability Used Early-On to Help Generate Requirements Determines the Fleet Ao and Mission Reliability When Using Multiple Similar Systems in a Mission ASOAR Version 6 is the latest version of the model. The Achieving a System Operational Availability Requirement (ASOAR) model optimally allocates a system Ao or operational readiness rate requirement to determine Ao goals for its end items being acquired. The end item Ao outputs of ASOAR can also be used later in supportability optimization models as the end item’s Ao objective function input. ASOAR Version 6 also provides a generic, integrated analysis of reliability, availability and maintainability (RAM) and supportability. Since an ASOAR analysis does not require Line Replaceable Unit (LRU) level inputs, the model can be used early-on in the development cycle to help generate RAM requirements. By integrating RAM and supportability, ASOAR permits concurrent analyses of the Mission Reliability, Ao and Maintenance Ratio requirements for the system. The ASOAR model can also determine the fleet aggregate Ao and mission reliability associated with using multiple similar systems in a mission.

ASOAR System Level Inputs System Ao/Readiness Requirement System Operating Tempo per Year, Mission Duration & Percent of System Failures Not Mission Critical Reliability Configuration Block Diagram of Mission Critical End Items Quantity of Each End Item in System Serial Configuration End Items Redundant Configuration End Items Hot or Cold Standby Redundancy Full or Degradational Redundancy This chart covers the ASOAR system level inputs. First, a system Ao or readiness rate requirement is needed. Other system inputs may include the system operating hours per year for Ao computation, mission hours used for determining the mission reliability and percent of total system failures that are not mission critical used in corrective maintenance ratio computations. The reliability configuration block diagram of mission critical end items and assemblies is also a system level input. The quantity of each end item in the system and designating whether they are serially or redundantly configured are necessary. If a redundant configuration of end items exists, this configuration will have to be identified as using a hot or cold standby redundancy. If degradational redundancy exists, partial mission capability states apply. Full redundancy implies that only the states of being fully up or fully down are considered.

ASOAR End Item Inputs RELIABILITY (Choose One ) MTBF, Operating Hours/Year & Mission Use Hours MMBF, Miles/Year, Average Miles/Hour, Mission Miles MRBF, Rounds/Year, Average Rounds /Hour, Mission Rounds MTBF, Op Hours/Year, Non Op Hour Failure Rate & Mission Use Hours Failures per Year or Mean Calendar Time Between Failure (MCTBF) MAINTAINABILITY (Choose One ) Mean Time to Repair (MTTR) MTTR & Restoral Delay Time with Spares Forward Mean Time to Restore (MTR) COST (Choose One ) Cost of Each End Item & Cost of Expensive, Very Low Failure Rate Items Relative Cost of End Items to Each Other (May Use Ratios) This chart covers ASOAR end item inputs. Each end item requires a reliability, maintainability and cost input. For mission reliability analysis, inputs must be either in terms of Mean Time Between Failure (MTBF), Mean Miles Between Failure (MMBF) or Mean Rounds Between Failure (MRBF). The model will internally compute the failures per year or Mean Calendar Time Between Failure (MCTBF) used in the Operational Availability (Ao) analysis portion. For a maintenance ratio analysis, maintainability inputs must be in terms of Mean Time to Repair (MTTR). The Mean Time to Restore (MTR) when spares are located at the forward support level, which includes a restoral delay time added to the MTTR, is used in the Ao analysis portion. If the cost of each end item is inputted, then the cost of any expensive, very low failure rate module should be deducted from the end item cost to keep ASOAR model LRU sparing outcomes close to “Sparing to Availability” model results. The ratios of the relative cost of end items to each other can be used in lieu of estimated costs.

ASOAR Logistics Inputs Forward Support Level Mean Time to Obtain LRUs - or- Determine With Following Inputs: Supply Support Levels Applicable Maintenance Support Levels Applicable Repair Percentage at Each Repair Level Average Order and Ship Times to Lower Support Levels Stock Availabilities at Higher Support Levels Average Repair Cycle Time at Each Repair Level Average Back Order Duration Time at Depot Level This chart covers the ASOAR logistics inputs. Basically, all that is needed is the forward support level mean time to obtain LRUs. If this value is not directly inputted, it will be computed based on the typical maintenance and supply concept used for each end item. The maintenance and supply inputs needed to calculate the Mean Time To Obtain LRU spares at the forward level of support are listed. These inputs cover the number of supply support levels and maintenance support levels applicable and the LRU repair percentages at the applicable maintenance support levels. Key input drivers to obtain spares are the average order and ship times to the lower support levels and stock availabilities at the higher support levels. When the LRU spare is not available in supply, other logistics response time inputs become important. These inputs are the average repair cycle time where LRUs are repaired or the average back order duration time at the wholesale supply level.

No Special Cases DEFAULT SCENARIO: There is One Each of All End Items Each End Item is Serially Configured in the System Systems are Restored with LRUs Potentially Spared at the ORG Level When no special cases are used in an ASOAR run, it says that the default scenario applies. In this scenario, there is one each of all the inputted end items, each end item is serially configured in the system, and systems are restored with LRUs potentially spared at the Unit or Organizational (ORG) level.

Sparing Optimization Heuristic Cost to Failure Rate to Down Time Ratios Without LRU Spares are Compared (COST X MCTBF / MLRT) End Items with the Lowest Ratios Will be Spared First More LRU Sparing Lowers MLRT to Increase Ratio The LRU Sparing Increase Stops When the Product of End Item Availabilities Equal the System Ao Target End Items with a Ratio Higher Than the Final Ratio Meeting the Ao Target Will Have No LRU Sparing The sparing optimization heuristic in ASOAR is based on the cost to failure rate to downtime ratios of each end item relative to each other. The Cost times the Mean Calendar Time Between Failure (MCTBF) divided by the Mean Logistics Restoral Time (MLRT) are the values used to compute this ratio. After comparing, the end items with the lowest cost to failure rate to down time ratios will be spared first. More LRU sparing lowers the MLRT to increase the end item’s ratio. The LRU sparing increase stops when the product of end item availabilities equal the system Ao target. End items that happen to have a ratio higher than the final ratio meeting the Ao target will have no LRU sparing at the forward support level.

Special Cases Cause Adjustments Scheduled Maintenance or Periodic Startup/Servicing Causing System Downtime Causes Ao Adjustments   Cold Standby Redundancies or End Item Spares with System Causes Reliability & Ao Adjustments Systems Restored with End Item LRUs Stocked Forward at DS Level Causes Restoral Time Adjustments Systems Restored with End Item Floats at DS Level Causes Reliability & Restoral Time Adjustments Common End Item Use (whether Serial or Hot Standby Redundancy) Causes Reliability Adjustment When Special Cases apply, the applicable Special Case causes internal equivalency adjustments to be made prior to the model using its sparing optimization heuristic. Depending on the special case cited, computational adjustments may be made to the system operational availability (Ao) target, the end item’s reliability or its mean restoral delay time. These adjustments influence the LRU sparing results needed for corrective maintenance. Scheduled maintenance, set up and teardown, software maintenance, pre-flight and post-flight maintenance, and other periodic servicing that causes system downtime adjusts the Ao target used for corrective maintenance sparing. Cold standby redundancies or end item spares with the system causes both a reliability adjustment and a slight Ao target adjustment to cover the switchover time to another end item. Systems restored with end item LRUs stocked forward at the Direct Support (DS) level causes restoral delay time adjustments. Systems restored with end item floats at DS level will cause both reliability and restoral delay time adjustments. Common end item use, whether serially configured or in hot standby redundancy, causes a reliability adjustment.

GROUP 1 Special Cases CAUSES Ao TARGET ADJUSTMENT:   CASE 1.1: SYSTEM SCHEDULED MAINTENANCE OR PERIODIC STARTUP CAUSING SYSTEM DOWNTIME CASE 1.2: END ITEM SCHEDULED MAINTENANCE OR PERIODIC STARTUP CAUSING SYSTEM DOWNTIME CASE 1.3: COLD STANDBY REDUNDANCY OR END ITEM SPARES WITH SYSTEM (also causes reliability adjustment) CASE 1.4: COLD STANDBY DEGRADATIONAL REDUNDANCY (also causes reliability adjustment) When a special case applies, its Case number is identified in the ASOAR model runs. Group 1 special cases minimally cause Ao target adjustments. Case 1.1 and 1.2 applies to additional system downtime and maintenance hours due to preventive maintenance, set up or tear down, pre-flight and post-flight maintenance, software maintenance, movement when the system cannot operate on the move or periodic servicing of the equipment. Case 1.1 applies to system downtime from non-corrective maintenance actions, non-hardware maintenance actions or periodic system movement. Case 1.2 identifies the non-corrective or non-hardware maintenance actions applied to specific serially configured end items in the system. Case 1.3 and 1.4 applies to cold standby redundancies or end item spares located with the equipment. They adjust the Ao target due to the system downtime to switch over from a failed end item to another end item. These cases also adjusts the end item reliability to be the effective reliability of the cold standby redundant configuration. Case 1.3 permits only fully up or fully down states and Case 1.4 permits some partial capability states associated with degradational redundancy.

ASOAR Conditional Inputs PERIODIC/SCHEDULED SYSTEM DOWN TIMES Mean Calendar Time Between Similar Actions Average Down Time Duration & Maintenance Hours for the Action Repeat Inputs for Each Dissimilar Action REDUNDANCY Number of End Items in System Number of Operating End Items (If Cold Redundancy) Number of End Items Needed to be Mission Capable DEGRADATIONAL REDUNDANCY Minimum Number of End Items Needed to be Fully Up Maximum Number of End Items Needed to be Fully Down Percentage of Capability Associated with Each Partially Mission Capable State Some ASOAR conditional inputs associated with these special cases are listed on this chart. For periodic or scheduled system down times, the mean calendar time between the similar actions, the average system down time duration and the maintenance man-hours for that action are inputted. These inputs are repeated for each dissimilar periodic or scheduled action causing system downtime. For redundancy, the number of end items per system and the number of end items needed to be mission capable are inputted. For a cold redundancy, the number of operating end items is also inputted. For degradational redundancy, the minimum number of end items needed to be fully up, maximum number of end items needed to be fully down are inputted. For each partially mission capable state in between the minimum and maximum inputs, a percentage of capability associated with each state is also inputted.

GROUP 2 Special Cases FORWARD LRU STOCKAGE IS NOT AT ORG LEVEL:   CASE 2.1: SYSTEM RESTORED WITH END ITEM LRUs STOCKED FORWARD AT DS LEVEL CASE 2.2: SYSTEM RESTORED WITH END ITEM FLOATS AND LRUs STOCKED FORWARD AT DS LEVEL CASE 2.3: SYSTEM RESTORED WITH END ITEM FLOATS AT DS AND LRUs STOCKED FORWARD AT GS LEVEL CASE 2.4: SYSTEM RESTORED WITH END ITEM FLOATS AT DS AND LRUs STOCKED FORWARD AT DEPOT/CONT Group 2 special cases apply when forward LRU stockage is not at the Unit or Organizational (ORG) level. This causes an end item restoral time adjustment. Case 2.1 is used when the system and end item are restored using LRUs stocked forward at the Direct Support (DS) level. A restoral delay time occurs by having the LRU spares delivered forward to restore the end item, having a contact maintenance team come out to restore the equipment, or having the equipment evacuated so that it can be restored. Cases 2.2 through 2.4 apply only when the system is restored with end item spares in lieu of restoring the system with LRU spares. End item floats are considered end item spares stocked at the DS level. In ASOAR, using floats will also cause an internal reliability adjustment to the end item. Case 2.2 is applied when the failed end items are repaired by LRUs at the DS level. Case 2.3 applies when the end item is repaired at the General Support (GS) level and Case 2.4 is used when the end item is repaired at the depot level or contractor. End item restoral delay times also apply to Cases 2.3 and 2.4 because forward LRU stock is not at the end item repair level.

ASOAR Conditional Inputs Restoral Delay Time When LRU Forward Support Level is Not at ORG Level Order & Ship Time of Floats from DS to ORG When End Item Floats are Used to Restore System ASOAR conditional inputs associated with Group 2 special cases are listed on this chart to cover the additional end item down time associated with getting the appropriate spare to the equipment. When the LRU forward sparing is not to be co-located at the same level where the end item is repaired, a restoral delay time input is required. When end item floats are used as spares to restore the system, the average Order and Ship Time of a float from the Direct Support (DS) level to the Unit or Organizational Level (ORG) is inputted.

GROUP 3 Special Cases CAUSES RELIABILITY ADJUSTMENTS:   CASE 3.1: SERIALLY CONFIGURED COMMON END ITEMS CASE 3.2: HOT STANDBY REDUNDANT END ITEMS CASE 3.3: HOT STANDBY DEGRADATIONAL REDUNDANCY OR CAPACITY AVAILABILITY CASE 3.4: HOT STANDBY REDUNDANT END ITEMS AND SYSTEM RESTORED WITH END ITEM FLOATS CASE 3.5: HOT STANDBY DEG REDUNDANCY AND SYSTEM RESTORED WITH END ITEM FLOATS Group 3 special cases involves operating with common end items in the system. Commonality causes an end item reliability adjustment. These common end items are either serially configured or configured as a hot standby redundancy. When commonality applies to an end item, one of the Group 3 special cases, Case 1.3 or Case 1.4 needs to be selected. Case 3.1 applies to serially configured common end items where the failure of any one of the similar end items causes a mission critical failure. Cases 3.2 through 3.5 apply to different types of hot standby redundancy configurations. Hot redundant end items are operating and accrue failures in the standby mode. Cold redundancy end items are not operating and do not accrue failures in the standby mode. Therefore, the reliability adjustment computations applied to a hot redundancy configuration is different from computations used for a cold redundancy. Case 3.2 and 3.4 applies to hot standby, fully redundant end items while Case 3.3 and 3.5 permits some partial capability states. Case 3.4 and 3.5 are only applied when both hot standby redundancy exists and end item spares are also available with the system to restore the system. Cases 3.4 and 3.5 are needed keep the internal computational order correct when applying both hot and cold redundancy to an end item.

GROUP 4 Special Cases MISSION USES MULTIPLE SIMILAR SYSTEMS: CASE 4.1: ALL SYSTEMS NEEDED TO BE FULLY MISSION CAPABILITY – NO PARTIAL CAPABILITY STATES EXIST   CASE 4.2: NOT ALL SYSTEMS NEEDED TO BE FULLY MISSION CAPABILITY – NO PARTIAL CAPABILITY STATES CASE 4.3: PARTIAL MISSION CAPABILITY APPLIES & ALL SYSTEMS ARE NEEDED TO BE FULLY MISSION CAPABLE CASE 4.4: PARTIAL MISSION CAPABILITY APPLIES & ALL SYSTEMS NOT NEEDED TO BE FULLY MISSION CAPABLE If the mission is based on using a fleet of multiple similar systems, one of the Group 4 special cases will apply. Cases 4.1 and 4.2 permit only full mission capability and no mission capability states. Case 4.1 is used when all the systems must be up to be mission capable. This represents a series configuration where all the systems must be operating to successfully perform the mission. Case 4.2 is used when all the systems do not have to be up to be fully mission capable and no partial capability states apply. This represents a hot redundancy configuration of systems allowing some of the systems to fail in fully accomplishing the mission. In Cases 4.3 and 4.4, partial mission capability states do apply. In Case 4.3, all the systems must be up to be fully mission capable. This represents a hot degradational redundancy configuration where all systems must be up to be fully mission capable and the failure of one systems will create a partial mission capability state. Case 4.4 represents both a hot redundancy and degradational redundancy configuration where all of the systems do not have to be up to be fully mission capable.

When Mission Use Requires Multiple Similar Systems Mission Capability Inputs Total Number of Systems in Fleet to Draw From for Mission Total Number of Systems to be Used for Mission Minimum Number of Systems Up to be Fully Capable Maximum Number of Systems Up to be Non-Capable Degree of Upness When Partially Capable Outputs for Mission Use of Multiple Systems Probabilities for Number of Systems Available Mission Reliabilities for Number of Systems Available Fleet Mission Success Probability of Being Available for Mission and Lasting the Mission Duration When mission use requires drawing from a fleet of multiple similar systems, the population of similar systems to draw from for the mission and the total number of systems to be used for the mission must be inputted. Depending on the special case chosen, other mission capability inputs may be needed. Cases 4.2 and 4.4 include the minimum number of systems needed to be up to be fully mission capable. Case 4.3 and 4.4 include the maximum number of systems up to be considered non-mission capable and a percent of upness or degree of capability input for each partially mission capability state between the fully up and fully down inputs. ASOAR outputs for missions using multiple similar systems will cover all the probabilities that so many systems in the fleet are available and the effective mission reliabilities associated with the number of systems available. The outputted fleet mission success probability of being available for the mission and lasting the mission duration is based on the binomial probability of multiple systems being available times the mission reliability associated with the number of systems available times the percentage capability also associated with the number of systems available.

Key ASOAR RAM & Log. Outputs FLEET OF SYSTEMS Ao, Reliability & Capability Probability States Probability Of Fleet Mission Success Mission Reliability & Maintenance Ratios Effective System Reliability & Maintainability SYSTEM END ITEMS Each Ao & ALDT Optimally Allocated from System Ao Common EI Configuration Ao & Reliability This chart lists some of key ASOAR reliability, availability, maintainability (RAM) and logistics outputs for each equipment level of indenture. When a fleet of similar systems is used to accomplish a mission, the availability, reliability and capability probabilities associated with each state over the quantity of systems are displayed. Also, the aggregate probability of fleet mission success is outputted. The system’s mission reliability and maintenance ratios are outputted when applied. The effective system reliability and maintainability are always outputted. Their results are determined from the reliability block diagram configuration of the end items within the system. At the end item level, each Ao and ALDT output are optimally allocated from the system Ao requirement. Also, when common end items are used within the system, the Ao and reliability for both the common configuration and the individual end item are outputted. Regarding the LRU level with each end item, each LRU order fill rate output is based on the optimal allocation from the system Ao requirement. Although there are no LRU inputs, the LRU order fill rate output represents the percentage of time that appropriate LRUs are needed to be stocked forward to restore the system or the end item to achieve its Ao. The forward level Mean Time To Obtain LRUs are determined from the maintenance and supply support inputs. End Item LRUs Each LRU Order Fill Rate Based on Allocation Forward Level Mean Time to Obtain LRUs

ASOAR Computational Notes Reliability, Availability & Supportability Analyses Effective Reliabilities, Ao, ALDT & LRU Fill Rates are Based on Calendar Time Failure Rates (Internally Uses MCTBF) Mission Reliability is Based on Operating Failure Rates to Determine Probability of Lasting System Mission Duration System Maintenance Ratio Built Up in terms of Labor Hours per System Operating Hour MReff Uses MTTR & Computed System MTBF for Failures Causing System Restoral Corrective Maintenance MRp of Periodic or Servicing Actions Uses Action Frequency & Labor Time for Non-Hardware or Non-Corrective Maintenance MRneff Uses MTTR, % of Total Failures Non-Critical & Corrective Maintenance on Redundant End Items Not Causing System Failure As computational notes, the effective reliabilities, Ao, Administrative & Logistics Down Time (ALDT) and LRU order fill rate outputs are based on calendar time failure rates. The ASOAR model internally computes and uses MCTBF to determine their values. On the other hand, mission reliability is based on operating time failure rates. Mission reliability determines the probability of lasting the system’s mission duration without having a mission critical failure. The system’s Maintenance Ratio (MR) is built up in terms of labor hours per system operating hour. The MR for essential function failures uses the MTTR and computed system MTBF to cover failures causing system restoral corrective maintenance. The MR for preventive maintenance plus other periodic, scheduled or servicing actions uses the action’s frequency of occurrence and the action’s maintenance labor time to cover non-hardware maintenance or non-corrective maintenance to hardware. The MR for non-essential function failures uses the MTTR and the percent of total system failures that are not mission critical. It also accounts for the corrective maintenance actions on redundant end items failures that do not cause a system failure.

Maintenance Ratio Yields Fleet Maintenance Personnel Requirement MR = MRp + MReff + MRneff System Maintenance Man Hours Year Operating Hours Year = MR x The number of maintenance personnel needed forward is an important logistics footprint factor. The Maintenance Ratio (MR) requirement helps to estimate the forward maintenance personnel requirements for a fleet of similar systems. The system’s MR is the sum of the MR for preventive or periodic maintenance, the MR for essential function failures and the MR for non-essential function failures. The system maintenance man-hours per year is equal to the MR labor hours per operating hour times the number of operating hours per year per system. The number of maintenance personnel forward with the fleet is approximately equal to the average system maintenance man-hours per year times the number of systems in the fleet divided by the average maintenance person’s productive man-hours per year at the forward location. No. Maint Personnel Fleet System Maint Man Hours Year = x No. Systems Fleet Productive Man Hours Year /

ASOAR Model Usefulness Early-On RAM Requirements Analysis of a System Helps to Determine Mission Reliability, Maintenance Ratio & Ao ORD Requirements Assesses Whether System Ao is Achievable & Optimally Allocates the System Ao Requirement to its End Items Early-On System Reliability & Supportability Analysis Assesses Degree of Logistics Support Affordability High LRU Order Fill Rate Output is More Expensive Low LRU Order Fill Rate Output Reduces Log Footprint Permits Sensitivity Analysis of Ao or Support Concepts Determines System Reliability & Permits Sensitivity Analysis of System Design Reliability Configuration As a recap, the ASOAR model is useful for analyzing the early-on RAM requirements of a system. It can help to determine mission reliability, maintenance ratio and/or Ao requirements or goals. An ASOAR analysis also assesses whether the system Ao input is achievable and optimally allocates the system Ao requirement to its end items when achievable. For early-on system reliability and supportability analysis, ASOAR can help to assess a degree of logistics support needed with regard to affordability. Since there are typically many Organizational Level sites or Direct Support locations forward, the LRU order fill rate outputs become a logistics footprint indicator to assess the extent of sparing support needed forward to meet Ao requirements. A high LRU order fill rate output at the forward support level can be expensive to achieve. On the other hand, a low LRU order fill rate output needs less spares to attain the requirement. Multiple ASOAR model runs permits sensitivity analysis of Ao or support concepts. Since ASOAR also outputs the system reliability, sensitivity analysis of the system design reliability configuration is also possible.

ASOAR Model Usefulness Help Requirements Community to Perform RAM Rationale Effectively Provides Integrated RAM Computations – No Longer an Off-Line Analysis Determines Cost Effective ALDT as Output – Not an Estimated Input Makes Availability a Part of R&M Requirements Analysis Relates RAM Requirements to User Outcomes Forward Level Maintenance Personnel Requirements Based on Maintenance Ratio & Operating Tempo Determines Mission Success Rate for System or Fleet Based on Availability to do Mission & Mission Reliability The ASOAR model should also be used to help the requirements community to perform Reliability, Availability and Maintainability (RAM) requirements analysis effectively. ASOAR automates integrated RAM and supportability computations, which reduces the need for off-line analyses. The ASOAR model also determines the cost effective Administration & Logistics Down Time (ALDT) as an output. Therefore, ALDT no longer needs to be a guessed at input. ASOAR makes Operational Availability an integral part of the Reliability and Maintainability requirements analysis. The latest capabilities of ASOAR help it to relate RAM requirements to user community outcomes. ASOAR will compute the system’s maintenance ratio. Together with the number of systems fielded and the operating hours per year, this maintenance ratio will estimate the number of forward level maintenance personnel needed. Additionally, ASOAR can be use to determine the mission success rate for a fleet of systems used to accomplish missions. The probability of mission success is due to binomial probabilities that so many systems in the fleet are available to accomplish missions and the mission reliabilities associated with so many systems in the fleet being available.

System Supportability Optimization Modeling to Operational Availability SYSTEM Ao/ READINESS RATE REQUIREMENT OPTIMAL ALLOCATION OF OPERATIONAL AVAILABILITY (Ao) ASOAR END ITEM Ao GOAL MAINTENANCE OPTIMIZATION This is a picture showing how the Achieving a System Operational Availability Requirement (ASOAR) model helps to permit system supportability optimization modeling. The ASOAR model allocates a system Ao or readiness rate requirement to cost effective end item Ao goals or requirements. The allocated end item Ao outputs yield supportability optimization model Ao input goals for those end items being developed or separately acquired that goes into the system. This allocation is also possible when some end items are not known and the system reliability requirement or goal is specified. A maintenance optimization model will provide the least cost maintenance concepts for the Line Replaceable Units (LRUs) and Shop Replaceable Units (SRUs) within the end item. A supply optimization model, will provide the least cost sparing mix for the critical LRUs within the end item. SUPPLY OPTIMIZATION LEAST COST MAINTENANCE CONCEPT FOR LRUs & SRUs LEAST COST SPARING MIX FOR LRUs & SRUs

System Effectiveness Probability System Performs Appropriately In Mission Product Effectiveness Probability System Lasts Mission Without Failing Mission Reliability System Effectiveness Probability System is Available to Accomplish Mission Support Effectiveness This diagram repeats the macro-level view of the influence of reliability, maintainability, supportability and Ao or readiness on system effectiveness. Product effectiveness is impacted by both the system’s success in performing appropriately to accomplish the mission and the mission reliability over the mission duration. The probability the system performs appropriately in a mission is not solved by the ASOAR model, but can be represented by using a percent capability input. The mission reliability of the system over its mission duration is an ASOAR model output. The probability the system is available to accomplish missions is based on the system availability input value used in the ASOAR model. By assuming that the product will perform appropriately, both the mission reliability and support effectiveness values determine the conditional probability of mission success computed by the ASOAR model. However, the full system effectiveness mission success rate will need some percentage capability values associated with performing the mission to be established. This may possibly come from performance modeling, testing or expert judgment. Therefore, ASOAR model usage in conjunction with performance modeling could theoretically help to determine the effectiveness of the system or a fleet of systems. e.g. Operational Availability Readiness Rate Sortie Rate

System of Systems Modeling Tailored System of Systems Mission Reliability & Availability Analysis Spreadsheets Used Perform Separate ASOAR Analysis of Each Different System to Determine Their (Fleet) Mission Success Rate System Mission Success Rates for each Different System are Multiplied to Estimate System of System Mission Success Rate System of Systems mission reliability and Operational Availability (Ao) analysis modeling may directly apply the ASOAR model if one system is applied on multiple different systems and the one system is being analyzed. However, since Readiness Rates are captured at the system level, the top down heuristic to optimally allocate Ao from the System of Systems is not needed. Therefore, when the System of Systems mission reliability and Ao can be computed using a much simpler bottoms up methodology that may even apply a tailored spreadsheet tool. To determine the System of Systems mission success rate, a separate ASOAR analysis may be performed on each different non-similar system to determine their mission success rate or their fleet’s mission success rate. The system mission success rates for each different system may then be multiplied to estimate the System of Systems mission success rate when the multiple different systems are used for the mission.