The purpose of this phase is to reduce technology risks (including required sustainment technologies to achieve the needed materiel availability) and determine the technologies to be integrated into the system. The focus is on developing the preliminary design (down to the subsystem/equipment level), reducing integration and manufacturing risk, and, from a sustainment perspective:

Designing-in the critical supportability aspects to reduce sustainment technology risks and ensuring features (including CBM+ technologies) are incorporated into the system specifications and test plans.
Developing the initial product support package framework, options, and requirements for the long-term performance-based support concept.

This phase is the most critical for optimizing system sustainment through designed-in criteria to help ensure sustainability. Particular attentions should be paid to reducing the logistics footprint, implementing human systems integration, and designing for support to help ensure life-cycle affordability. Also, during this phase detailed plans for organizing to manage the implementation of the product support package should begin.

The support concept should be defined going into this phase. The phase should be used to define the design-to requirements and to design the product support package. Technology demonstrations and prototyping should be conducted to help determine mature, affordable technologies to be included in the system and support system designs. The demonstrations results coupled with analysis should be used to refine requirements and the LCC estimate, narrow the ranges of all program metrics, and increase confidence the values can be met at an affordable cost.

5.4.2.2. Activities/Processes

This phase is important because cost/schedule/performance/sustainability trade-off analyses linked to demonstrated technologies increase the confidence performance, cost, and schedule thresholds can be achieved. During this phase, the logistics emphasis is on maturing the technologies that enable achievement of supportability objectives, on performing requirements refinement and trade-offs to evaluate the achievable performance given the demonstrated technologies, on refining the supportability objectives in both range and depth, and on identifying any constraints that will limit the system or its supply chain to achieve the operational readiness or mission effectiveness.

Cost/Schedule/Performance/Sustainment Trade-Offs. In all life-cycle phases, cost, schedule, performance, and sustainability may be traded within the trade space between the objective and the threshold without obtaining Milestone Decision Authority approval. Consequently, it is critical the trade space be established early and be acceptable to the user and acquisition communities. As a result, the operational user and sponsor should be involved with the determination of the trade space and involved in trade-off decisions during this phase. The following are the key steps for establishing the trade space and determining the specific developmental requirements:

Include sustainment requirements and/or considerations in Advanced Concept Technology Demonstrations, Advanced Technology Demonstrations, and other technology oriented demonstrations and prototyping. The demonstrations should be used to help assess the maturity of available and planned technology required for:
- The preferred operating and support concepts.
- Achieving the best balance between mission effectiveness, life-cycle cost, logistics footprint, and risk.
- The sustainment performance driver parameters that best represent user needs in achieving operational readiness.
Forecast the physical and operational environment of the proposed system along with corresponding notional operating and support concepts. The forecast should include consideration of future projections of domestic and foreign facilitation and logistics infrastructure. Specific consideration should be given to the performance-based requirements to achieve the objectives / thresholds for each of the alternatives considered and determining gaps based on technology availability. The gap analysis needs to take into account the complexity and the obstacles to, as well as, the required enablers for effective sustainment likely to be available when the system is deployed considering the current state of the art and likely funding. These gaps should then be used to eliminate alternatives or to determine specific technologies to be developed. It should also form the foundation for a corresponding technology development and verification strategy.
Perform a market analysis (both public and private) for the needed system and product support capabilities to fill the gaps. The analysis should address the extent and scope of opportunities for using commercial items and processes. It should consider and assess the:
- Elements of support currently provided (for any legacy systems to be replaced).
- Current measures used to evaluate support effectiveness.
- Current effectiveness of required support.
- Existing support data across the logistics support elements.
- Existing technologies and associated support that impact the new system.
Develop the functional characteristics and performance specification of the system and its support system based on the best balance between mission performance, life-cycle cost, logistics infrastructure and footprint, and risk. An analysis should be conducted to identify key performance and related support parameters for inclusion in the CDD. The analysis should form the basis of design requirements for subsequent phases and will affect the KPPs/KSAs and the overall capability of the system to perform and endure in the required mission environment. ROM LCC estimates should be developed and included in the analysis results based on the following key elements:
- Preliminary manpower and personnel requirements estimates. This should also include an assessment of any constraints in both quantity and skill levels and the use of contractor support.
- Operational effectiveness, reliability, maintainability, supportability and interoperability drivers. This should include embedded and external diagnostics, prognostics, and other maintenance enabler technologies that will be required based on suitably mature new design technology. In identifying the drivers and their threshold and objective values, performance histories of similar systems should be examined to determine the feasibility/risks of achieving the required levels and develop a risk mitigation plan. If one has to be developed, the corresponding benefits and resource requirements for each of the drivers should be identified.
- Logistics footprint metric estimates, deployment requirements, and other factors affecting the in-theater operational concept. This should include the elements the program will be responsible for and the supply chain performance requirements upon which the program will require to meet operational effectiveness objectives.

Depot Maintenance: During this phase, the following actions are required:

Finalization in the determination of the organic source of repair to be assigned primary responsibility for maintenance and repair of each system and each sub-system having a core capability requirement.
Estimate the ROM for the depot-level maintenance workload to be performed at organic facilities for the system and each subsystem.
Determine the technical data, facility and equipment requirements to ensure the capability to support these workloads.
Program the resources for the technical data, facilitation, and equipment requirements.
Summarize the results of these actions in the Acquisition Strategy submitted for Milestone B approval.

5.4.2.2.1. Initial Life-Cycle Sustainment Plan

During this phase, and in preparing for MS-B, the program focuses on finalizing the sustainment metrics, sustainment requirements integration into the design, expanding on the sustainment strategy and maintenance concept and an execution plan describing the design, acquisition, fielding, and competition of sustainment activities to deliver the product support package. The LCSP documents the maintenance & support concepts based on the results of any technology demonstrations and analyses performed to date. It should describe the envisioned sustainment capabilities as viewed by the user and major support providers (e.g., the maintainer, supplier and transportation providers). Taking into account the real world constraints and limitations (including "core" requirements, statutory requirements, etc.), it should include the:

Sustainment metrics (including their threshold and objective values) as well as the supporting design characteristics included in the contract along with the corresponding test methods incorporated in the TEMP.
Envisioned Product Support Arrangements, including the level that will be covered by performance-based incentives tied to metrics.
Approach for developing and fielding the product support package describing who is doing what, where, and when with the associated budgets.
Analytical process for determining affordable “design to” metrics goals and thresholds at the subsystem level and for the supply chain are established including how they will be kept aligned/balanced as the design and the supply chain evolve.

5.4.2.2.2. Maintenance & Sustainment Strategy Development

The maintenance & sustainment strategy should be refined from the projected system's reliability and the preliminary sustainment concept of operations to meet the operational requirement in the planned environment. They are then used to determine the supply chain performance requirements, along with the key enabling features needed to implement the strategy. These enablers can range from system design features (e.g. condition based maintenance) to supply chain features (e.g., rapid distribution of tailored support packages, just in time training / distance support, total asset visibility anywhere in the support chain, dedicated rapid response support teams analyzing real time data). The details should be described in sufficient detail to provide assurance that risks are understood and the gaps can be filled.

Core logistics and repair sources are critical elements in establishing appropriate repair and support capability. New and emerging systems may lack mature data at this stage, but by using data from similar current systems and subsystems, planning for a sustainment strategy can evolve. Key activities should include establishing the baseline for trade studies by identifying notional maintenance levels and activities for major subsystems, taking into account system/subsystems with a core capability.

The gaps between the current state of the art and current sustainment/maintenance capabilities versus what is required (along with the risk) should be used to identify technologies needing to be developed and demonstrated in subsequent phases. They should also be used in developing the implementation plan for proceeding with the best value alternative and summarized in the LCSP. The following are key considerations in developing the performance/cost/schedule/ sustainment and risk tradeoff analysis:

The relative cost vs. benefits of different support strategies.
The methods and rationale used to quantify benefits and costs.
Data required to support and justify the best value support strategy.
Sensitivity of the data to change.
Analysis and classification of risks.

Core Capability Planning and Analysis. The requirement for determining core requirements and applying this methodology extends to all weapon systems and equipment operated by each DoD Component, regardless of where depot-level maintenance is actually performed (DoDI 4151.20, "Depot Maintenance Core Capabilities Determination Process"). The following depot maintenance core capability requirements determination methodology is used to determine essential DoD depot maintenance capability requirements for each DoD Component, and the workloads needed to sustain those capabilities.

Programs requiring a core capability/DSOR decision shall be identified by the managing Service Acquisition Program Manager (PM) (or Joint Program Office (JPO) in the case of Joint Service acquisitions) to the Service organization(s) responsible for depot-level maintenance management (hereafter referred to as MMOs). Joint programs, and those having depot-level maintenance inter-servicing potential, shall be identified by each DoD Component MMO in conjunction with the PM/JPO.
The identification of the need for a core determination will occur at least 180 days prior to the Acquisition Milestone B decision need date. For systems entering the acquisition process after Milestone B, identification will occur immediately following the acquisition approval.
It is the responsibility of the Acquisition Program Manager (PM) (or Joint Program Office (JPO)) in conjunction with the DoD component that owns the depot-level maintenance assets to ascertain the potential need for establishing an organic core capability requirement by addressing, at a minimum, the following questions. Other considerations may be applied, as appropriate.
Is the system replacing a system having a core capability requirement at either the system or the subsystem level? If the answer is "Yes" then it can be assumed that this system and its subsystems will require the same core capability requirements as the system being replaced, adjusted for known inventory and workload differences.
- If not, will the system be used or is it planned to be used in support of a JCS contingency scenario? If the answer is "Yes" then Section 2464 of Title 10, United States Code requirements for the establishment of organic core capability apply.
- If the answer to either question is 'yes', an initial core capability requirement determination analysis must be conducted and candidate Depot Source of Repair (DSOR) depot-level maintenance facilities identified by the DoD Component(s).
After core requirements have been determined, the PM/JPO shall take appropriate steps to assure that the requirements for the establishment of organic capability are included in all product support acquisition requirements (e.g. need for tech data, peculiar support equipment, facilities and/or Public Private Partnership).
While not part of the core determination process it is at this stage that any requirements to assign a portion of the proposed workload to an organic depot to provide reasonable assurance of future compliance with the 50/50 requirements be identified and provided by the DoD Component(s) MMOs to the PM/JPO along with justification and documentation for use in designing the product support strategy.

5.4.2.2.3. Technical Reviews in Technology Development

Many of the actions and subsequent results in this phase are reviewed during technical reviews. The actions and results discussed in this section should be accomplished even if the specific referenced reviews do not occur. The actions and results are tied to the reviews to reflect the relative timeframe in which they should be accomplished.

5.4.2.2.3.1. Sustainment Considerations in the System Requirements Review (SRR)

The SRR is conducted to ascertain the results of the prototyping and demonstrations relative to the system technical requirements. It determines the direction and progress of the systems engineering effort and the degree of convergence upon a balanced and complete system baseline. (See section 4.2.10 for additional information.) The purpose is to ensure all system requirements (performance requirements and sustainment requirements) derived from the Initial Capabilities Document (ICD) or draft CDD are defined, consistent and achievable within cost, schedule and any other constraints. Generally the SRR assesses the prototyping results with respect to the system requirements captured in the system specification and support strategy to ensure they are consistent with the system and support solution as well as available technologies.

The SRR is important in understanding the performance requirements, cost, and scheduling impacts on the system and its support concept. During the SRR, the systems requirements are evaluated to determine whether they are fully defined and consistent with a demonstrated mature technology solution. A successful review is predicated on determining the system and support element requirements are based on available technology, a sustainable support concept, and program resources (e.g., funding, staffing, processes and schedule). Logistics and product support subject matter experts should participate to ensure the critical sustainment system and support elements enabler technologies required to implement the support strategy and achieve the needed materiel availability are included in the planning and performance specifications. Understanding and accepting the program risk inherent in the system specification, Systems Engineering Plan and Life-Cycle Sustainment Plan is key to a successful review. The SRR should provide:

An approved system performance specification with achievable system, supportability, human systems integration, and sustainment enabler requirements which satisfy and are traceable to the ICD or draft CDD and support concept.
A preliminary allocation of system requirements to hardware, human, and software subsystems. The system sustainment requirements should be sufficiently detailed and understood to enable system functional definition and functional decomposition.
Demonstration that critical sustainment system and support element enabler technologies required to implement the support strategy and achieve the needed materiel availability are sufficiently mature to enable low risk entry into development.
Approved support and sustainment concepts with the corresponding metrics.
A preliminary Cost Analysis Requirements Description consistent with the approved system performance specification and sustainment concept.

5.4.2.2.3.2. Sustainment Considerations in the System Functional Review (SFR)

The SFR ensures the system functional baseline has a reasonable expectation of satisfying the CDD requirements within the allocated budget and schedule. A critical SFR aspect is the development of representative operational and product support use cases for the system. System performance and the anticipated functional requirements for operations, maintenance and sustainment are assigned to sub-systems and support systems hardware and support systems hardware & software after analysis of the operational and support environments. The SFR determines whether the system's functional definition is fully decomposed to its lowest level forming the functional baseline, and that IPTs are prepared to start preliminary design. Additional information for this review can be found in section 4.2.11.

Product support IPT members as well as independent supportability and sustainment subject matter experts should participate in the review to ensure the system functionality is consistent with the supportability requirements and the support strategy contained in the evolving Life-Cycle Sustainment Plan (LCSP). This involves:

Addressing the supportability requirements to support the CDD and the supportability functionality as defined in the functional baseline ensuring adequate processes for achieving the sustainment metrics are in place.
Defining the detailed support concept functionality requirements for system and subsystem elements to ensure system functional requirements are sufficiently detailed and understood to enable system design supportability analyses to proceed.
Ensuring program sustainment development efforts (including system and software critical path drivers), with corresponding schedules, are included in LCSP updates.
Ensuring the updated Cost Analysis Requirements Description (CARD) (or a CARD-like document) based on the system functional baseline, captures the key program sustainment cost drivers, development costs, production costs, and operation & support costs for all aspects of sustainment and human system integration.

5.4.2.2.3.3. Sustainment Considerations in the Preliminary Design Review (PDR)

The PDR helps ensure the system's allocated baseline and its associated support system have a reasonable expectation of satisfying the CDD requirements within the allocated budget, staffing, and schedule and have an acceptable risk level. Details can be found in section 4.2.12 but in summary the PDR assesses the preliminary design captured in the preliminary subsystem product specifications for each configuration item (hardware and software) and ensures each function, in the functional baseline, has been allocated to one or more system configuration items. The PDR evaluates the subsystem requirements to determine whether they correctly implement all system requirements allocated to the subsystem. The Integrated Product Team (IPT) should review the results of peer reviews of requirements, preliminary design documentation (including Interface Control Documents) along with the plans for development and testing for both system performance and supportability aspects to ensure the system is ready to proceed into detailed design and test procedure development.

Product support IPT members, as well as independent supportability and sustainment subject matter experts, should participate in the review to ensure the supportability requirements and the support strategy contained in the Life-Cycle Sustainment Plan (LCSP) are consistent with the evolving design. This involves:

Addressing the supportability requirements to support the CDD and ensuring the supportability functionality are allocated to each system or subsystem and they can be achieved within the budgets and schedule. This includes ensuring the Failure Mode Effects and Criticality Analysis, Maintainability Analysis, and Reliability Centered Maintenance Analysis results have been factored into the allocated requirements, preliminary design, and risk assessment. In addition to ensuring adequate processes for achieving the sustainment metrics are in place, this includes ensuring the HSI design factors have been reviewed and included in the overall system design.
Setting the allocated baseline for any system and/or major subsystem product support package elements. This includes defining the detailed support concept functionality requirements for subsystem product support package elements to ensure system functional requirements are sufficiently detailed and understood to enable more detailed supportability analyses to proceed.
Defining the test success criteria for development testing and operational testing (for both operationally effective and suitable) requirements and the general test approach for key sustainment enablers or drivers.
Ensuring program sustainment development efforts (including system and software critical path drivers with corresponding schedules) are included in LCSP updates.
Ensuring the updated Cost Analysis Requirements Description (CARD) (or a CARD-like document) based on the system allocated baseline, captures the key program sustainment cost drivers, development costs, production costs, and operation & support costs for all aspects of sustainment and Human Systems Integration (HSI.)

5.4.2.2.3.4. Sustainment Considerations in the Technology Readiness Assessment (TRA)

The TRA is a metrics based process that assesses the maturity of critical technology elements, including sustainment drivers, conducted concurrently with technical reviews. From a sustainment perspective, the process should be used for assessing risk and the adequacy of technology maturation planning when the support concept or sustainment drivers depend on specific new or novel technologies to meet system threshold requirements in development, production, or operation. If a key enabler or sustainment driver (e.g., reliability, turn around time) does not meet required performance levels or significant performance advances is required over what is currently achieved with existing technology, then a plan for maturing the critical technology should be developed, explaining in detail how the performance level will be reached within the program’s schedule and resources. See section 10.5.2 for additional information.

5.4.2.2.3.5. Sustainment Considerations in the Integrated Baseline Reviews (IBR)

IBRs are used throughout the program whenever earned value management is used. IBRs establish a mutual understanding of the project performance measurement baseline. While they have a business focus, IBRs can also be useful in ensuring sustainment is considered in the acquisition process when the efforts required to achieve the Sustainment KPP, KSAs and any other key sustainment enabler metrics are included in the reviews. These reviews and resultant understanding also provide for a plan of action to evaluate the risks inherent in the program measurement baseline and the management processes during project execution. Additional information can be found in section 11.3.1.3.

5.4.2.3. Technology Development Phase Results/Exit Criteria

The focus of this phase is on reducing risk and defining achievable performance and sustainment requirements. This begins with the analysis of alternatives that include examining alternative operating and system support concepts, with specific consideration of performance-based requirements. Success is demonstrated by identifying key performance and related sustainment metrics (with their basis) as design requirements that affect the overall capability of the system to perform and endure in the required mission environment. (In addition to the Sustainment KPP/KSAs, the metrics can include other supportability, maintainability, interoperability, manpower or footprint measures.) Implementing the process contained in figure 5.4.2.2.F1 produces the refined supportability objectives and, in some cases, anticipated constraints based on the technology assessments. The conclusion of this phase results in the contractual documents required to continue (including the related sustainment requirements and actions) and updated system baseline support & maintenance concepts, LCC, and manpower estimates.

Table 5.4.2.3.T1 identifies the most critical documents that should incorporate or address sustainment/logistics considerations. The key sustainment elements to be addressed in the next phase should be included in the Acquisition Strategy and the materiel availability enabler requirements should be included in the Engineering and Manufacturing System Development RFP as well as the Source Selection Plan. The exit documents from this phase should focus on the materiel availability driver metrics (including drivers for the enablers) and the baseline support strategy. They should also contain the following sustainment related information:

Table 5.4.2.3.T1. Sustainment Considerations in Technology Development

Entry Documents:

Analysis of Alternatives

Technology Development Strategy – Draft Capability Development Document (including sustainment technology issues)

Test and Evaluation Strategy

Life-Cycle Sustainment Plan

Exit Documents:

Analysis of Alternatives (including Market Research results)

System Performance Specification

Capability Development Document

Preliminary Design Review Results

Test and Evaluation Master Plan (TEMP)

Information Support Plan

Acquisition Strategy

Cooperative Opportunities

Technical Data Rights Strategy

Core Logistics Analysis/Source of Repair Analysis

Industrial Capabilities

Life-Cycle Sustainment Plan

Life-Cycle Cost Estimate and Manpower Estimate

Preliminary Maintenance Plans

Acquisition Program Baseline (APB)

Affordability Assessment (including DoD Component Cost Analysis & ICE)

AoA - the sustainment driver metrics and product support strategies for each alternative considered along with any gaps and major assumptions
System Performance Specification - objectives and thresholds for the sustainment driver metrics including the corresponding enabler drivers
CDD - the information necessary to deliver an affordable and supportable capability using mature technology. The following sustainment drivers information should be included:
- System maintenance/support profiles and use case scenarios
- The corresponding support and maintenance effectiveness measures
- Description of the specific capabilities required to achieve the support concept and/or to reduce risks in achieving the values required to meet the operational requirements. It should include metrics for each of the key enabling technologies (e.g., reliability/ maintenance rates, diagnostics/prognostics effectiveness measures)
Preliminary Design Review Results – the description and status of the sustainment driver design features
Technology Readiness Assessment - approach for achieving the required enabling sustainment technologies (including design criteria for each of the drivers in the preliminary system design specification) (see section 10.5.2)
Test and Evaluation Master Plan (TEMP) – identification of the metrics and enabling/driver technologies to be evaluated in subsequent phases, the approach for evaluating them, and test points (see section 9.5.5)
Data Management Strategy – the long term strategy integrating data requirements across all functional disciplines.
Information Support Plan – plan for acquiring and managing the data required to execute the support concept in the operational environment (see section 7.3.6)
Acquisition Strategy – containing the LCSP executive summary
Life-Cycle Sustainment Plan (LCSP) – summary of the maintenance & sustainment concepts including the support locations and duration. It should focus on the support strategy including the contracting strategy to acquire the major elements of the support concept and the specific incentives being used to help achieve the sustainment drivers and enablers
Life-Cycle Cost Estimate and Manpower Estimate – the major assumptions and values being used for the sustainment drivers and enablers (see Chapters 3 and 6) It should also include the confidence level of the values being achieved
Acquisition Program Baseline (APB) – description of the sustainment metrics, criteria, and logistics funding requirements (see section 10.9)
Affordability Assessment – an assessment based on the likelihood of the key sustainment metrics being achieved (also see section 3.2.2)

5.4.2.4. Sustainment Considerations in the Technology Development Phase

During this phase, the focus should be on refining the threshold and objective range value estimate for each sustainment metric based on more detailed analysis identifying the technical capabilities, risks, and limitations of the alternative concepts and design options. Analysis should also be performed to identify the impacts the sustainment metrics will have on mission success and materiel availability. The key enabling requirements to achieve the sustainment metrics should be allocated to the major system level and included in the system specification. Even this early it is important to establish the reliability requirements and assess the extent to which the system will likely meet the requirements. Consequently, the reliability of the technology or system should be included in the technology readiness assessments.

Detailed plans for monitoring, collecting and validating key metrics should be established to provide empirical data to evaluate technical performance, system maturity, and the projected logistics burden. Detailed test criteria should be developed for each metric (including any key dependent enabling technologies) to provide information about risk and risk mitigation as the development and testing continue. The test strategy/requirements to provide data and analysis support to the decision process should be documented in the TEMP.

5.4.2.5. Best Practices during the Technology Development Phase

M&S combined with LCC analysis are important best practices to help assess the success in reducing program risk. In addition, both should be used in the Engineering & Manufacturing Development Phase source selection process and to define the sustainment objectives and thresholds to be placed on contract. The data used for the assessments and analysis (including the projected sustainment demand) should be complied and saved for analyses in subsequent phases.

5.4.2.5.1. Supportability Analysis

During this phase, supportability analysis focuses on the technology trade-offs. As indicated in figure 5.4.2.5.1.F1, the analysis process is iterative. They are re-run as required as the design is refined. Trade-off impacts are identified and evaluated to ensure the selection of a system concept that not only delivers system performance, but also achieves supportability, interoperability and system affordability objectives. The supportability analysis goal within this phase is to establish affordable and obtainable thresholds and objectives to achieve the user requirements in the projected environment within the Concept of Operations.

The analyses are iterative, evolving and expanding as more specific design and other technical information on the actual equipment is identified. While the focus is high level for the system at the beginning of this phase, it should also consider requirements for key enablers in terms of "what is required" vice "how it is accomplished". As the phase progresses, the analysis should determine the relative cost vs. benefits of different support strategies (including potential source of support decisions). The impact and value of performance/cost/schedule/sustainment trade-offs based on the preliminary design should continue expanding to the lowest level of the work break down structure as the design evolves across this and subsequent life-cycle phases.

A complete supportability analysis should be performed for any parts of the system for which the government is going to provide the product support package vice using a contracted approach with materiel availability as the performance measure. Figure 5.4.2.5.1.F1 shows the key system reliability, maintainability and supportability system engineering processes. The affordable system operationally effectiveness analysis process coupled, with available tools and opportunities - such as modeling and simulation, performance testing, supportability testing/demonstration, technical data validation, and maintenance assessments - should be proactively applied and integrated with the systems engineering process. For example, system requirements can be used to develop a system reliability/availability block diagram as a basis for modeling and analysis. This approach can identify opportunities for targeted system redundancy, ease of reconfiguration, and derating, etc., and can thereby enhance system level reliability and availability. In addition, reliability, maintainability (BIT/prognostics), and supportability/ logistics demonstrations can provide the data to assess achievement of RAM requirements.

The level of detail performed by the government team will vary by the extent to which performance-based product support contract is used but that will not impact the general process, including the program major events. As a result, the supportability analysis process should take advantage and be an integral part of the major engineering events and processes, including but not limited to the System Requirements Review (SRR) and Preliminary Design Review (PDR).

As illustrated in Figure 5.4.2.5.1.F1, a FMECA helps identify the ways in which systems can fail, performance consequences, and serve as basis in the identification of Critical Safety Items as well as potential areas for preventative maintenance for the system. When conducted in a timely fashion, the FMECA can be used to support trade-offs between performance and life-cycle costs to drive design improvements. A Fault Tree Analysis (FTA) assesses the safety-critical functions within the system's architecture and design. A Maintainability Analysis and Prediction (MAP) assesses the maintenance aspects of the system's architecture, including maintenance times and resources. This analysis identifies strategic opportunities for focused diagnostics, prognostics, and performance monitoring/fault localization, leading to reduced system maintenance times and cost drivers. A level of repair analysis optimally allocates maintenance functions for maximum affordability and materiel availability.

Once FMECA, FTA, and MAP are completed and system design has been established, RCM analysis develops a focused, cost-effective system preventive maintenance program. RCM uses a system based methodical approach to determine causes of failure, failure consequences, and a logic tree analysis to identify the most applicable and effective maintenance task(s) to prevent failure, if possible. RCM also provides rules for determining evidence of need for condition based maintenance to perform maintenance only upon evidence of need. (DoDI 4151.22, Enclosure 3)

Figure 5.4.2.5.1.F1. Supportability Analysis During Design

A maintenance task analysis identifies detailed logistics and support resource requirements to sustain system readiness. Appropriate use of proactive maintenance technologies embodied in diagnostics and prognostics pays system dividends. Integrating on-board and off-board monitoring, testing, data collection, and analysis capabilities can significantly enhance system maintainability and overall supportability. Typically, practices here include enhanced prognosis/diagnosis techniques, failure trend analysis, electronic portable or point-of-maintenance aids, corrosion mitigation, serial item management, automatic identification technology, and data driven interactive maintenance training. Ultimately, these practices can increase materiel availability and readiness at a reduced cost throughout the life cycle.

The activities shown in figure 5.4.2.5.1.F1 are not necessarily carried out in a linear progression. Design increments and the continuous assessment of test results and in-service system performance will identify needs for system improvements to enhance reliability, maintainability, overcome obsolescence, corrosion, or other sustainment needs.

Risk Assessments. Risk assessments should be performed to identify and develop design trade-off that mitigates risk. Technology risk considerations should receive intensive consideration as the system concept is developed. Maximum use of low-to-medium risk technology, as indicated in Table 5.4.2.5.1.F2, provides the greatest opportunity to hold to program cost, schedule and performance requirements. Medium-to-high risk technologies should be thoroughly justified and risk mitigation efforts resourced. Use of high-risk technologies should be avoided and be a critical factor in choosing an incremental acquisition strategy.

Once the preferred system, system support concepts and enabling technologies are selected, case scenarios reflecting system support, maintenance, and logistics are refined. These scenarios identify significant system support, maintenance, and logistic requirements and objectives. These are compared to the Sustainment KPP/KSA threshold and objective and expanded in depth as the hardware design matures and the process is iterated until an affordable systems operational effective solution is achieved.

Table 5.4.2.5.1.T1. Technology Risk Considerations

Technology Maturity	Technology Description
Low Risk	Existing Mature Technologies
Medium Risk	Maturing Technologies; New Applications of Mature Technologies
High Risk	Immature Technologies; New Combinations of Maturing Technologies

5.4.2.5.2. Modeling and Simulation

M&S should be used to refine sustainment objectives (this includes the Sustainment KPP and KSAs as well as any other LCC or readiness driver metrics) and identify any constraints based on technology assessments. The technology demonstration results should be modeled to project likely capabilities and the associated confidence levels that enabling technologies will be achievable in the operational environment. It should also be used to develop initial/notional system level product sustainment strategy and maintenance concepts for major sub systems. All of these elements will be used to project the mature Sustainment KPP/KSA values and their associated confidence levels they will be met within the CONOPS.

As the design evolves, modeling and simulation can be used to help keep the product support elements in balance between and within system hardware elements. This is done by allocating the sustainment, LCC or readiness driver metrics to specific subsystems and equipments. These requirements are then used to develop the specific system level support strategies and maintenance plans along with their design-to requirements for both the system and its logistic support system. Modeling at this level of detail provides more creditability especially relative to the following efforts important in this phase:

Analyzing the impact of proposed budget alternatives on the Sustainment KPP/KSAs (as well as mission effectiveness).
Assessing the alternatives affecting the design and deployment of both the end item and its support system to ensure all metrics and their drivers are considered in parallel and not at the expense of the others.
Anticipating and resolving potential problems by taking use data and user feedback for similar equipments and/or sustainment strategies.

Top of page

Previous and Next Page arrows