The Applications of OPUS-RDM During an Acquisition Program

Conducting Product Support Analysis (PSA) is the gold standard for the logistics arm of an acquisition program. Recently, we’ve seen a shift in PSA program requirements to adapt to modern technology and demonstrate capturing real value (i.e., demonstrate cost of ownership reduction across the life of a system). To achieve this, acquisition programs are more frequently requiring the use of specific logistics software that provide the opportunity to better streamline and integrate PSA efforts and data throughout the program, and present PSA results in a comprehensive, easy-to-interpret, standardized, and visual manner for improved stakeholder buy-in.

One of these specific logistics software programs is Systecon Group’s OPUS Suite. The OPUS Suite is a commercially-available software developed by Systecon Group AB. The US Navy and Air Force has required the use of OPUS on several major programs that ALE has been involved with, including the Medium Unmanned Undersea Vehicle (MUUV), F/A-18 Super Hornet, F-35 Joint Strike Fighter, Survivable Airbourne Operations Center (SAOC), and the SPY-6 family of radars. Additionally, the OPUS Suite meets all US Navy Readiness Based Sparing (RBS) requirements and is part of the “Digital Twin” concepts being employed by the DoD.

A major challenge for most companies concerning the OPUS Suite is its significant license cost and skillset/training needed for proficiency. However, being able to provide data that is usable in the OPUS Suite and also able to interpret OPUS Suite outputs will become a baseline necessity to conducting and/or supporting DoD PSA programs. The remainder of this article provides a simplified introduction to the OPUS Suite and its applications.

The OPUS Suite consists of three main modules:

  1. OPUS 10: optimizes logistics support concepts (including maintenance and supply/spare parts),
  2. SIMLOX: provides system operation and maintenance simulations to identify downtime drivers and evaluate alternatives to prevent and minimize them
  3. CATLOC: estimates system life cycle cost and supports cost reduction analysis, budgeting and planning, and financial risk assessments

The modules utilize a common set of input data for consistency between modules and analysis outputs. The modules can be used together to yield sparing models, fleet optimization, economic Level of Repair (LORA results), and availability analyses, among many other insights. The user interface is both graphic and table-based. Product Tree, Support Organization, Input Tables, Report Tables, and Output Graphs make results easy to interpret across a variety of formats.

The OPUS Suite is also exceptionally flexible in being able to provide insights with limited or preliminary input data. For example, a system can be effectively modeled with a single operating location (“station”) and a limited number of line replaceable units (LRUs). Alternatively, systems can collectively be modeled across dozens of stations in an advanced organizational structure and maintenance concept, down to the piece-part level (if desired). To determine the level of model complexity necessary for an application, the desired outputs (and level of insights) should be identified.

In the early phases of a program when only a small amount of data is available, OPUS can provide meaningful initial insights, such as major maintenance cost drivers and predicted logistics delay time-critical paths. But where OPUS truly shines is how the initial rudimentary models can grow in detail as data becomes available throughout a program to ultimately reflect any level of data maturity.

The OPUS modeling environment consists of the following characteristic features:

  • Variant Configuration Management. Items (from LRUs in a simple model to piece-parts in a more complex model) are input into an Item Library, and utilizing these items, Products and Product Variants can be “built” to model different end item configurations, hulls, tail numbers, etc.
  • System Operation Environment Scenarios. For simple analyses, average predicted annual operation values can be used. For more in-depth analyses, entire bottom-up or top-down operational profiles can be modeled for the system, variants, and/or individual units. Mission types, locations, and resource needs can also be specified by system, variants, and/or units.
  • Complex Support Organization Structure Modeling. OPUS allows flexibility to define multi-echelon operating, maintenance, and support locations, and to assign item/product quantities to locations, resources, and mission types. Stations are assigned “types” depending on their capabilities: for example, whether items are repaired but not stocked (Workshop), both repaired and stocked (Depot – not to be confused with the traditional DoD definition of a depot), stocked but not repaired (Store), or neither stocked nor repaired (Operational).
  • Cost-Optimization.  OPUS performs Cost-Optimization to meet Operational Availability (Ao) requirements at the least cost. OPUS recommends depth and range of supply needs for each supply location to meet the desired Ao.

Some applications for the OPUS Suite include:

  • Determining cost-effective solutions for meeting Ao requirements and cost constraints
  • Identifying recommended range and depth of spares and repair parts (at each maintenance supply level) utilizing RBS concepts
  • Evaluating Alternative Maintenance/Support Concepts (performing LORA)
  • Estimating key contributors to Life Cycle Cost (LCC)

Defining the best maintenance concept for a system requires effective supportability and LCC modeling. The OPUS Suite is a powerful tool that can be tailored to support an extensive amount of modeling needs relative to the other commercial or custom software tools commonly used by industry. It has enormous potential for maintenance planning and cost-reduction applications. Whether or not you’ll be working directly in OPUS, you will likely need to provide data to a customer to feed an OPUS model and/or interpret results of an OPUS model. With OPUS being a requirement in increasingly more programs, we hope that this introduction to its features and capabilities has provided context for its use and data needs and has encouraged you to learn more about it.

Article Authored By Steve Rogers and Elizabeth Schwartz