1. OmegaPS Users’ Group Meeting OUGM19

2. HMS Kellington
Not on my watch!
Operators need their equipment to be ready anytime they want it.
When the equipment is in use it must keep working until the job is done.
Available and Reliable…….

3. Availability Analysis with OmegaPS Analyzer Training Workshop
Graham Brum
9 May 2019

4. Analyzer Workshop This workshop:
demonstrates new functionality in Analyzer for the allocation and assessment of system availability.
describes the process to achieve availability goals.
explains the relationship between algorithms and simulation in the new OmegaPS Analyzer Availability Modelling tools.
A high-level review of the calculations will give users insight to the value of these new functions.
Demonstrations will display the application within the core Analyzer product.

5. New Availability Functions in Analyzer
System availability is usually a design target required for new capabilities and needs to be properly described as a system requirement. Availability requirements are based on targets to be achieved that are allocated to sub-systems and the equipment being acquired. Through analysis techniques to allocate goals, design support solutions, assess designs and simulate design choices in multiple mission scenarios, optimal support solutions are designed, developed, delivered and deployed. Operational systems use performance analysis to determine the reality of achieving design goals and determines changes needed to improve system availability and cost of ownership.

6. Supportability Tools BCS DATM – Design Availability Target Model
Maturing BCS through updates supplied from supportability analysis. Used to assess the proposed support solution in the CAF environment, consider alternatives, and set the support solution baseline.
DATM – Design Availability Target Model
This model is used to allocate a required availability target, usually at the system, or system of systems level, to the Prime Equipment and sub-systems. Then it measures and tracks the ability to achieve that availability through the design process.
TLAS – Through Life Availability Simulation
A simulation of the described ship’s supportability design within defined mission scenarios over a life cycle. TLAS provides outputs of the supportability and mission simulation results.

7. DATM – Design Availability Target Model
DMGOR converted the B Price DoD concept

8. DATM Functionality
Allocate CSC Availability system targets to Prime Equipment and systems Determine realistic availability targets to be required from ship designs Assess the Availability achievable from proposed ship designs at key design milestones (e.g. PDR, CDR, FDR, Production) Estimate supportability costs from optimized support solutions

9. DATM - Allocate
A required availability is specified for the system. The required operational system availability is allocated to each PE in the system
taking into account the mission, PE design concepts (e.g. redundancy), and support concepts (e.g. PM, supply chain).
The system target is allocated to the constituent PE, based on a weighting method using average LRU reliability and cost.
Allocated targets are the “design to” targets for an optimized support solution. DATM uses the basic structures defined in Analyzer and presents a report indicating how the PE should apply the design target availability. These are the preferred design targets.
Early in the design process DND needs to specify the required availability of the system (or sometimes system of systems, like a ship) that is being acquired or modernized. The desired availability for the overall operational system then needs to be allocated to the Prime Equipment (PE) that provide the operational capability, taking into account things like the importance of the PE in the mission, design concepts (e.g. redundancy), and support concepts (e.g. preventive maintenance and supply chain). DATM is the Analyzer module that provides this functionality through an allocation technique first developed by US DoD and modified by DND DMGOR defence scientists.
The system target is allocated to the constituent PE, based on a weighting method using average LRU reliability and cost. These allocated targets then become the “design to” targets for an optimized support solution. DATM uses the basic structures defined in Analyzer and presents a report indicating how the PE should apply the design target availability. These are the preferred design targets.
The US Department of Defense, US Army CECOM, developed a model known as ASOAR. This is documented in CECOM-TR-92-8 and CECOM-TR-92-6.
DND DMGOR reviewed the CECOM model guide and developed a prototype based on ASOAR, known as the Achievable Platform Availability Utility (APAU) model (Ref: DRDC CORA TM ).
The prototype has been expanded at the request of PMO CSC to improve the APAU algorithms and integrate them into Analyzer. The integrated version of APAU is the DATM module.

10. Systems and End Items Systems are a collection of End Items
System = EI1 + EI Ein
End Items are usually different acquisition contracts
For Example:
Halifax Combat System includes 3D Radar, 2D Radar, FCS, Navigation Radar, IFF, etc.

11. RAM DATA End Items have RAM Data requirements for
Reliability (MTBF)
Maintainability (MTTR)
These combine to determine System level values:
(1/MTBFsys) = (1/MTBF1) + (1/MTBF2) (1/MTBFn)
MTTRsys = (MTBFsys/MTBF1)*MTTR (MTBFsys/MTBFn)*MTTRn
Note: equations taken from AD-A ASOAR Model Methodology

12. AVAILABILITY
Operational Availability (Ao) is the measure of a system’s “Uptime” with respect to “Downtime” Ao = UPTIME UPTIME + DOWNTIME Or AoSys = MTBFsys MTBFsys + MTTRsys + MLDTsys

13. MLDT
Mean Logistics Delay Time – waiting for a spare to be provided to restore the equipment The system MLDT is a weighted average of the End Item’s failure frequency multiplied by the EI MLDT

14. TARGET SYSTEM MLDT
Because Ao, MTBF and MTTR are specified the System MLDT target can be determined from:
AoSys = MTBFsys
MTBFsys + MTTRsys + MLDTsys
Therefore, Target MLDT
MLDTtarget = ((1-Ao) * MTBFsys) – (Ao * MTTRsys)
AoSys

15. COST – FAILURE RATE RATIO
Sparing to Availability works with the largest Ao gain per unit cost. Also, Ao increased by optimal location of spares leads to largest reduction in MLDT for least spares cost. The Cost to Failure Rate ratio of an LRU is a key parameter which can aid in selecting spares

16. SYSTEM TARGETS
When the LRU structure is not known in the End Item the Cost/FR ratio can be estimated. Use average LRU Cost and average LRU failure rate. Adjust for high cost low FR items to prevent skew. MLDT is calculated as the cost effective End Item target value.

17. Ao ESTIMATES
With the target End Item MLDT calculated it can be used to estimate the End Item Ao The estimated System Ao is the product of all End Item Ao estimates Compare estimated System Ao with required value Iterate until estimate equals target

18. ADJUSTMENTS
DATM can make computational adjustments for various cases in the system
Equipment Configurations (e.g. Common EI and redundancy)
Periodic Maintenance (Scheduled and PM)
Maintenance Plans

19. DATM - Assess Ability to Achieve Availability Design Reviews
The second process in DATM is the assessment of design data and that design’s ability to achieve the design targets.
Design Reviews
As data is provided at significant mile stones (e.g. PDR, CDR, etc.), and the support solution matures, then the DATM assessment can be made, providing insight to the design’s ability to provide the system at a required level of availability.
Compared with maturing baseline system
Report displays comparison between ‘Allocated’ values and current design values.
The second process in DATM is the assessment of design data and that design’s ability to achieve the design targets. As data is provided at significant mile stones (e.g. PDR, CDR, etc.), and the support solution matures, then the DATM assessment can be made, providing insight to the design’s ability to provide the system at a required level of availability.

20. TLAS – Through Life Availability Simulation
Based on a bespoke spreadsheet for MHLH, which was converted to ADES by DMGOR.
PMO CSC named it TLAS for their program and have invested to produce a functional discrete event simulation (DES) for the ship program.
What is DES?
A simulation-based form of modelling in which patterns of events in the problem are recreated so that the timing and resource implications can be examined.
The events generated usually include the arrival and departure of entities from the system or one of its sub processes.
Timing and quantities in the model are typically generated by implementing appropriate stochastic distributions.
Note that TLAS is build on the ADES simulator. ADES is the Availability Discrete Event Simulator, developed by DMGOR.
A discrete-event simulation (DES) models the operation of a system as a discrete sequence of events in time. Each event occurs at a particular instant in time and marks a change of state in the system. Between consecutive events, no change in the system is assumed to occur; thus the simulation can directly jump in time from one event to the next.
A common exercise in learning how to build discrete-event simulations is to model a queue, such as customers arriving at a bank to be served by a teller. In this example, the system entities are Customer-queue and Tellers. The system events are Customer-Arrival and Customer-Departure. (The event of Teller-Begins-Service can be part of the logic of the arrival and departure events.) The system states, which are changed by these events, are Number-of-Customers-in-the-Queue (an integer from 0 to n) and Teller-Status (busy or idle). The random variables that need to be characterized to model this system stochastically are Customer-Interarrival-Time and Teller-Service-Time. An agent-based framework for performance modeling of an optimistic parallel discrete event simulator is another example for a discrete event simulation.

21. Discrete Event Simulation
In addition to the logic of what happens when system events occur, discrete event simulations include the following:
System State
Clock
Events List
Random Number Generator
Statistics
Ending Condition
Components of DES
In addition to the logic of what happens when system events occur, discrete event simulations include the following:
State
A system state is a set of variables that captures the salient properties of the system to be studied. The state trajectory over time S(t) can be mathematically represented by a step function whose value can change whenever an event occurs.
Clock
The simulation must keep track of the current simulation time, in whatever measurement units are suitable for the system being modeled. In discrete-event simulations, as opposed to continuous simulations, time 'hops' because events are instantaneous – the clock skips to the next event start time as the simulation proceeds.
Events list
The simulation maintains at least one list of simulation events. This is sometimes called the pending event set because it lists events that are pending as a result of previously simulated event but have yet to be simulated themselves. An event is described by the time at which it occurs and a type, indicating the code that will be used to simulate that event. It is common for the event code to be parametrized, in which case, the event description also contains parameters to the event code.
When events are instantaneous, activities that extend over time are modeled as sequences of events. Some simulation frameworks allow the time of an event to be specified as an interval, giving the start time and the end time of each event.
Single-threaded simulation engines based on instantaneous events have just one current event. In contrast, multi-threaded simulation engines and simulation engines supporting an interval-based event model may have multiple current events. In both cases, there are significant problems with synchronization between current events.
The pending event set is typically organized as a priority queue, sorted by event time.[4] That is, regardless of the order in which events are added to the event set, they are removed in strictly chronological order. Various priority queue implementations have been studied in the context of discrete event simulation; alternatives studied have included splay trees, skip lists, calendar queues, and ladder queues.
Typically, events are scheduled dynamically as the simulation proceeds. For example, in the bank example noted above, the event CUSTOMER-ARRIVAL at time t would, if the CUSTOMER_QUEUE was empty and TELLER was idle, include the creation of the subsequent event CUSTOMER-DEPARTURE to occur at time t+s, where s is a number generated from the SERVICE-TIME distribution.
Random-number generators
The simulation needs to generate random variables of various kinds, depending on the system model. This is accomplished by one or more Pseudorandom number generators. The use of pseudo-random numbers as opposed to true random numbers is a benefit should a simulation need a rerun with exactly the same behavior.
One of the problems with the random number distributions used in discrete-event simulation is that the steady-state distributions of event times may not be known in advance. As a result, the initial set of events placed into the pending event set will not have arrival times representative of the steady-state distribution. This problem is typically solved by bootstrapping the simulation model. Only a limited effort is made to assign realistic times to the initial set of pending events. These events, however, schedule additional events, and with time, the distribution of event times approaches its steady state. This is called bootstrapping the simulation model. In gathering statistics from the running model, it is important to either disregard events that occur before the steady state is reached or to run the simulation for long enough that the bootstrapping behavior is overwhelmed by steady-state behavior. (This use of the term bootstrapping can be contrasted with its use in both statistics and computing).
Statistics
The simulation typically keeps track of the system's statistics, which quantify the aspects of interest. In the bank example, it is of interest to track the mean waiting times. In a simulation model, performance metrics are not analytically derived from probability distributions, but rather as averages over replications, that is different runs of the model. Confidence intervals are usually constructed to help assess the quality of the output.
Ending condition
Because events are bootstrapped, theoretically a discrete-event simulation could run forever. So, the simulation designer must decide when the simulation will end. Typical choices are "at time t" or "after processing n number of events" or, more generally, "when statistical measure X reaches the value x".

22. TLAS Functionality
Assess System Availability over a Defined Life Generate Missions to simulate the life of a fleet of Assets. Integrate sparing solution into Stock Management. Log life events simulated by model. Evaluate support solution effectiveness.
The core model in Analyzer is engineering based and uses defined equations and optimisation techniques to determine the optimal design for the support solution. This is necessary to run decision processes that select optimal solutions, however, it is also useful to run a simulation to assess those selected options to evaluate the probability that the systems will achieve the required availability and that the support solution will respond correctly. This is done in the TLAS module.
Mission simulation is an important element of availability simulation. Therefore, TLAS is driven by a comprehensive mission generator that creates user defined missions, and is capable of including standard DND mission types, especially the managed readiness programme for RCN ships. As the simulation progresses ships are assigned to fulfil the missions, observing system failures causing downtime and the ability to repair those failures, using spares and other resources. On completion of the TLAS run a summary report is generated, along with a detailed log of events during the simulation ‘life’. Both these outputs are used to estimate system operational availability, mission losses, part reliability, maintainability, spares availability and consumption, loading on maintenance facilities, and various other support system perspectives.

23. Basic TLAS Model Stock Management 6. If LRU not discarded send to LOM2
5. Is LRU Repaired at LOM1
4. Uses LRU Stock Item
3. LRU Replaced – restores PE
2. Prime Equipment waits in queue for LRU R/R
1. Prime Equipment has LRU failure. PE goes ‘down’

24. Mission Generation
Generator Type (e.g. International; Domestic; Training) Random or Scheduled mission generation. Multiple Missions defined for each generator type. Phases defined within missions (e.g. Prep, Execute, Recovery) Asset Readiness Levels used (e.g. High, Normal, Restricted) Mission required or critical equipment allocation.

25. System of Systems Prime Equipment (PE) are defined:
e.g. PE1 - Navigation Radar, PE2 - 2D Radar, PE3 - 3D Radar
PE work together as a system:
e.g. System X = PE1 (fwd) & PE1 (aft)
Redundancy between PE provides
improved system availability (PE2)
Missions
systems and PE are required or critical
for each mission phase.
PE are made up of LRUs
R/R LRU to return PE to service

26. Maintenance Facilities (MF)
A hierarchy of maintenance and support shops
Multiple lines, e.g. ships, FMF, depot, contractor
Uses Analyzer support organizations
Predefined models are reusable in TLAS
Each MF is defined for operating times
When maintenance techs are available for work
Queues jobs as they arrive
Operating Sites are LOM1 MF
LOM1 (e.g. ships) operate equipment and do first line work
Failure Diagnostics determine repair location.

27. Stock Management
Applies the principle that stock might not be available when repair commences:
Not held at this location (optimal sparing design) – order stock
Stock-out at this location – replenish
Stock out at highest MF – procure
Initial inventory taken as PDS in Analyzer
LRU becomes Shop Item after removal from PE.
Repair process returns LRU to stock.

28. Output Options TLAS uses xml format data files.
TLAS Results provides basic outcomes:
Missions Generated; PE assigned; mission times; mission successes
Ship operational times; downtimes
Stock repairs; replenish; procured; stock-out
LOG File provides detailed step by step process log
Filter and process log file for analysis of results
Display processed results and detailed breakdown for ‘dashboard’ type display.

29. Provide a detailed demonstration of:
Allocating Availability targets (DATM)
Designing support solutions through LSA/PSA
Simulating support solution designs (TLAS)
Mission generation and simulation scenarios (TLAS)
Assessing availability targets in proposed designs (DATM)
Costing support solution options for Business Case Analysis (LCC BCA)

30. Allocating Availability targets (DATM)

31. Designing support solutions through LSA/PSA

32. Simulating Support Solution Designs in TLAS
3 year TLAS profile (Sep 2019 – Sep 2022)
Typical missions:
Standard Operations (1 Jan - 1 Mar; 30 Apr - 31 Aug; 1 Nov - 31 Dec)
User Training Courses (6 weeks; every Sept and March)
Emergency SAR (Random)
Readiness levels: Maint; Normal; High.

33. TLAS Missions
 Mission generation and simulation scenarios

34. Availability Assessment
 Assessing availability targets in proposed designs (DATM)

35. Support Solution Options
Costing support solution options for Business Case Analysis (LCC BCA)

36. New User Requirements
Discuss users’ requirements to apply these models to develop future Analyzer enhancements.
How would you apply these new functions?
What do you need when designing support solutions?
How could Analyzer improve in future releases?