Major Capability Acquisition (MCA)

Reference Source: DAG CH 3-4.3.1 Accessibility (Section 508 Compliance)

All Electronic and Information Technology (E&IT) systems comply with Section 508 of the Rehabilitation Act (i.e., 29 U.S.C. 794d), unless exempt under FAR (Subpart 39.204, para (b)) as a military system or National Security System. Compliance with Section 508 provides access by Federal employees with disabilities and the public to information and data that able-bodied persons can access through E&IT systems. Section 508 should be considered as a design requirement, addressed at each technical review and clearly stated in the Acquisition Strategy and Systems Engineering Plan.

Program Managers (PMs) should ensure Section 508 compliance, unless exempt, while Systems Engineers are responsible for implementation through use of standards and compliant tools and products.

Resources to aid programs in complying are in Table 43. Additional information on accessibility is found in DAG Chapter 5 Manpower Planning & Human Systems Integration; and Chapter 6 Acquiring Information Technology and Business Systems.

Table 43: Links to Section 508 Government Resources

Description of Link	Active Link
Section 508 technical standards	http://www.access-board.gov/508.htm
Federal rules for Section 508 implementation hosted by GSA has: Roles and responsibilities of procurement officials and engineers 508 best practices Products and techniques	https://www.section508.gov/
The “Buy Accessible System” GSA site has free tools and guides for conduct of Section 508-compliant acquisitions as well as on-line training and help desk	https://www.section508.gov/buy/
Department of Health and Human Services has: Check lists Code library Test tools	http://www.hhs.gov/ found by searching on “section 508”
Department of Justice home page for ADA has federal laws and pending legislation	https://www.ada.gov/
Department of Veteran Affairs reports on Section 508 products and tools and tracks user comments	http://www.section508.va.gov/

Reference Source: DAG CH 3-4.3.2 Affordability – Systems Engineering Trade-Off Analyses

Affordability is the degree to which the capability benefits are worth the system’s total life-cycle cost and support DoD strategic goals. Systems engineering (SE) trade-off analyses for affordability, a special application of the Decision Analysis process (see CH 3–4.1.2.) should:

• Support the establishment of realistic affordability caps as documented in the program’s Acquisition Program Baseline (APB).
• Serve as inputs for the will-cost estimate and should-cost targets, including related should-cost initiatives.
• Enable continuous monitoring of program life-cycle costs with respect to affordability caps across the system life cycle.

The Milestone Decision Authority (MDA) establishes tentative cost and inventory goals at Materiel Development Decision (MDD) and affordability goals at Milestone A to inform early requirements and design trade-offs. Affordability caps are set at the Development RFP Release Decision, Milestone B, and beyond for unit procurement and sustainment costs. Affordability caps are established as fixed-cost requirements equivalent to Key Performance Parameters (KPP).

The affordability goal forms the basis for the SE trade-off and sensitivity analyses conducted to ensure that requirements are affordable and technically feasible, and to inform the validation of the Capability Development Document (or equivalent requirements document) from an affordability standpoint. SE trade-off analyses also support the establishment of affordability caps at the Development RFP Release Decision, Milestone B, and subsequent reviews. The affordability goal is nominally the average unit acquisition cost and average annual operations and support cost per unit. For indefinite quantity of production units, the affordability goal may be the total acquisition cost (see CH 1–4.2.15. for more information regarding the affordability goal/cap).

The independently generated will-cost estimate is used to defend the program budget but does not account for potential efficiencies. The should-cost target is based on the efficient use of resources and effective implementation of processes identified as should-cost initiatives, and is the focus of SE activities and program management decisions across the life cycle. Should-cost management is implemented in all acquisition programs (all ACATs) regardless of the life-cycle phase.

The SE trade-offs are conducted among cost, schedule and performance objectives to ensure the program is affordable. The Program Manager (PM) should identify the design performance points that are the focus of trade-off analyses to establish cost and schedule trade space. The PM presents the results of the trade-off analyses at program milestone/technical reviews, showing how the system’s life-cycle cost varies as a function of system requirements, major design parameters and schedule. The results are used to identify cost and affordability drivers and to demonstrate how the cost-effective design point is established for the system.

The PM and Systems Engineer use the results of SE trade-off analyses for affordability to inform system requirements and ensure that, when taken collectively, the requirements are compelling, affordable and achievable within the time frame available to the program.

The SE trade-off analyses are executed by a resourced team that consists of a decision maker with full responsibility, authority and accountability for the trade at hand; a trade-off analyst with a suite of reasoning tools; subject matter experts with performance models; and a representative set of end users and other stakeholders.

Throughout the system life cycle, the Systems Engineer continuously monitors affordability drivers, identifies opportunities to reduce life-cycle costs (should-cost initiatives), and conducts SE trade-off analyses as needed to meet program cost, schedule and performance requirements.

Reference Source: DAG CH 3-4.3.3 Anti-Counterfeiting

An increasing threat of counterfeit (and fraudulent) parts in the global marketplace affects every component of the program from commercial-off-the-shelf (COTS) assemblies to military-unique systems. Preventing counterfeit parts from entering the supply chain reduces cost and negative impacts to program schedule and system performance. DoDI 4140.67 “DoD Counterfeit Prevention Policy”provides direction for anti-counterfeit measures for DoD weapon and information systems acquisition and sustainment to prevent the introduction of counterfeit materiel.

Counterfeit parts are becoming pervasive in various supply chains and therefore have become a significant threat to the Defense supply chain. Counterfeiters’ motives are primarily greed (profit) and/or malicious intent. Counterfeits may appear at all phases of the life cycle, making it necessary for the Program Manager (PM), Systems Engineer, and Product Support Manager to plan for prevention, detection, remediation, reporting and restitution activities from the beginning of the life cycle to disposal and demilitarization.

In order to properly assess the risks of counterfeit products, the PM needs to be aware that anti-counterfeit activities have relationships, as described in Table 44, with many of the other design considerations outlined in CH 3–4.3. Design Considerations, such as:

Table 44: Anti-Counterfeit Design Considerations Relationships

Design Consideration	Relationship
Commercial-Off-the-Shelf (COTS)	The Government and its industry agents have little to no visibility into the supply chains that create COTS products. Implications of this lack of visibility into the supply chain include counterfeit vulnerabilities and counterfeit parts being more readily available.
Corrosion Prevention and Control (CPC)	Counterfeits, by their nature, may have been falsely certified. In addition, if the counterfeit is a compound/material or component (e.g., gaskets, ground wires) intended to prevent or reduce corrosion, then effects of wear may appear sooner than predicted and the impacts to the system may be worse than expected or catastrophic.
Critical Safety Items (CSI)	From an anti-counterfeiting risk-based approach, CSIs should be more carefully scrutinized to ensure no counterfeits infiltrate the supply chain.
Demilitarization and Disposal	An excellent source for counterfeiters to obtain parts that can be turned into “used sold as new” parts (fraudulently certified as new).
Diminishing Manufacturing Sources and Material Shortages (DMSMS)	As systems age and the trustworthy sources for the piece parts dry up, counterfeiters increasingly take advantage of the situation by offering a source for hard-to-find parts.
Environment, Safety and Occupational Health (ESOH)	Several examples of counterfeit materials that can increase ESOH risks include: false R-134, a refrigerant which produces explosive by-products; fire extinguishers compressed with air; and faulty smoke detectors. Furthermore, Restriction of Hazardous Substances (RoHS) (2002/95/EC) has led to increased numbers of counterfeits, where a lead-free (Pb-free) microcircuit is sold as having tin-lead (SnPb) leads.
Item Unique Identification (IUID)	Successful implementation of IUID could reduce the ability of counterfeiters to introduce parts into supply. Conversely, IUID may provide a false sense of security if it can be duplicated by counterfeiters.
Modular Open Systems Approach (MOSA)	MOSA could provide a means to quickly certify a newer, more available part for use in weapon systems, thus reducing the impact of DMSMS. Conversely, it could also result in more part numbers (equivalents) being introduced into supply, thus increasing the likelihood of counterfeit intrusion.
Producibility, Quality and Manufacturing (PQM)	PQM can be severely degraded if supply is contaminated with counterfeits.
Reliability and Maintainability Engineering	Counterfeits that somehow get past receipt inspection and test can have radically different reliability and failure modes than the “honest” part.
Supportability	Increased failure rates due to counterfeits can have a negative impact on supportability and might drive the wrong problem-resolution behaviors and increase sustainment costs.
System Security Engineering (SSE)	SSE implements anti-counterfeit protection measures as part of a comprehensive plan to protect CPI and mission-critical functions and components (See DAG Chapter 9).

During development of the Systems Engineering Plan (SEP) and Program Protection Plan (PPP), the PM, Systems Engineer and Product Support Manager should consider these relationships and develop plans to address the threat.

Reference Source: DAG CH 3-4.2.3 Commercial-Off-the-Shelf

The use of commercial-off-the-shelf (COTS) items, including Non-Developmental Items, can provide significant opportunities for efficiencies during system development but also can introduce certain issues that should be considered and mitigated if the program is to realize the expected benefits.

The primary benefits of using COTS components in system design are to:

• Reduce development time.
• Allow faster insertion of new technology.
• Lower life-cycle costs by taking advantage of the more readily available and up-to-date commercial industrial base.

However, regardless of the extent to which a system is made up of commercial items, the Program Manager (PM) and Systems Engineer still develop, integrate, test, evaluate, deliver, sustain and manage the overall system.

Among concerns with using COTS products are:

• Subtle differences in product use can significantly affect system effectiveness; Environment, Safety and Occupational Health (ESOH); reliability; and durability.
• If integration requires a “modified COTS product,” meaning that a COTS product may not be designed for many military environments (which, by definition, is not a COTS product under 41 USC 104, but is allowed under 41 USC 1907), then the program may lose the ability to use the vendor’s subsequent product upgrades or to find a suitable replacement for the product from other commercial sources.
• The vendors can embed proprietary functions into COTS products, limiting supply sources.
• Vendors do not have to provide design information and often restrict purchasers from reverse engineering their intellectual property.
• Licensing agreements vary and can be very restrictive while limiting the vendor’s liability for merchantability for intended purposes.
• Supply chain risk management of COTS items is limited by the vendor, who is under no obligation to the purchaser to provide such information.
• Incorporating COTS products places constraints on the rest of the design and reduces trade space; functionality, interfaces and reliability and maintainability characteristics are embedded in the choice of a COTS system element.
• Difficulty in finding suitable replacements and/or alternate items if the COTS vendor stops manufacturing the product or changes the configuration drastically, requiring the need to maintain different configurations of a single product.
• The program needs to understand the “pedigree” of the qualified vendors for the COTS product.
• The graphical user interface (GUI) design may not completely support user tasks, which can cause inefficient workarounds and improper use of the system by the user.

The marketplace drives COTS product definition, application and evolution. COTS products presume a flexible architecture and often depend on product releases that are designed to be used “as is” to meet general business needs and not a specific organization’s needs. The commercial product life cycle is usually much shorter than the equivalent military product life cycle. Programs should consider the potential availability of suitable replacement and/or alternative items throughout the longer, military life cycle, and should monitor the commercial marketplace through market research activities and ongoing alignment of business and technical processes. This necessary activity imposes additional cost, schedule, and performance risks for which the acquisition community should plan. COTS products should be evaluated to meet all performance and reliability requirements during all environmental conditions and service life requirements specified by the intended application requirements documents.

P.L. 103-355 (SEC 8104) and P.L. 104-106 (SEC 357), both endorse the use of COTS products by the Federal Government but have slightly different definitions, with the latter allowing for modifications to COTS products.

The Systems Engineer should ensure open system design, identification and mitigation of ESOH and security risks, survivable technology insertion, or refresh throughout the projected system life cycle.

The PM and Systems Engineer should consider the following when evaluating use of COTS products:

• The intended product-use environment and the extent to which this environment differs from (or is similar to) the commercial-use environment
• Integration, documentation, security, Human System Integration, ESOH, hardware/software integrity, reliability risk, program protection and corrosion susceptibility/risk
• Planning for life-cycle activities (including sustainment, supply chain risks, obsolescence, and disposal)
• Developing relationships with vendors, Foreign Ownership Control, and Influence (FOCI) (see Defense Security Service for the latest policy regarding COTS products from FOCI sources)
• Supportability, if product modifications are made or if vendor or marketplace changes occur
• Test and evaluation of COTS items (including early identification of screening, functionality testing and usability assessments) (See CH 8–2.1.)
• Protecting intellectual property rights by being aware of pertinent intellectual property rights issues associated with commercial items acquisitions, especially with the acquisition of commercial software products. When acquiring Intellectual Property (IP) license rights, the acquisition community should consider the core principles described in the DoD guide: “Intellectual Property: Navigating through Commercial Waters.”
• Ability to modify or interface COTS software with other software even if Government-generated or owned
• Ability to have insight into configuration management, and the features and functions of upgrades and changes

• Ability to instrument and/or test aspects of COTS products

Reference Source: DODI 5000.88 Section 3.7.c.

 

The LSE will:

• Working for the PM and in conjunction with the product support manager, evaluate corrosion considerations throughout the acquisition and sustainment phases that reduce, control, or mitigate corrosion in sustainment.
• Perform corrosion prevention and control planning and include corrosion control management and design considerations for corrosion prevention and control in the SEP and life-cycle sustainment plan.
• Ensure that corrosion control requirements are included in the design and verified as part of test and acceptance programs established pursuant to DoDI 5000.67.

Reference Source: DAG CH 3-4.3.5 Corrosion Prevention and Control

The corrosion of military equipment and facilities costs the DoD over $20 billion annually. In addition, corrosion degrades system availability; safety; and Environment, Safety and Occupational Health (ESOH) factors. Therefore, acquisition officials should fully consider corrosion prevention and mitigation as early as possible in the acquisition life cycle (even prior to Milestone A), and implement appropriate strategies to minimize the life-cycle impact.

Sound Corrosion Prevention and Control (CPC) planning reduces life-cycle costs, improves maintainability and availability and enhances ESOH compliance. The DoD Corrosion Prevention and Control Planning Guidebook for Military Systems and Equipment (MS&E) (i.e. CPC Planning Guidebook) helps Program Managers (PMs), Systems Engineers, Product Support Managers and other program staff develop and execute a comprehensive CPC approach.

DoDI 5000.67 and DoDD 4151.18 require CPC planning and execution for all acquisition programs across the life cycle. The PM is responsible for identifying and evaluating corrosion considerations throughout the acquisition and sustainment phases to reduce, control or mitigate corrosion. The PM and Systems Engineer should conduct CPC planning, ensure corrosion control requirements are included in the system design and verified as part of test and acceptance programs and include CPC management and design considerations in the Systems Engineering Plan (SEP) and Life-Cycle Sustainment Plan (LCSP). CPC planning is integrated into sustainment. Product support planning should mitigate the appropriate CPC risks inherent in the system design to meet sustainment requirements.

Good CPC planning and execution includes, but is not limited to, the following elements:

• Engaging corrosion expertise relevant to the system and its operating environment throughout the life cycle.
• Examining legacy systems for possible corrosion-design improvements.
• Documenting alternative material and process assessments that offer increased corrosion protection.
• Including CPC as a consideration in trade studies involving cost, useful service life and effectiveness.
• Incorporating CPC requirements, plans, specification, standards and criteria into relevant contractual documentation for all equipment and facilities.
• Including CPC in integrated product support element (IPSE) development and evaluation, to include facilities (see DAG Chapter 4).
• Identifying planning, resourcing and acquisition of corrosion-related features for longevity, lowest total ownership cost (TOC) and sustained system effectiveness.
• Retaining access to CPC resources throughout the life cycle.

All designated Acquisition Category (ACAT) programs are required to conduct CPC planning across their life cycle. The extent of CPC planning and the breadth of documentation should consider the type of system and correlate the system’s corrosion risk to mission criticality and the harshness of the operational environment. Refer to the DoD Corrosion Prevention and Control Planning Guidebook for MS&E for more information.

In addition to the SEP and LCSP, CPC planning and execution for all ACAT programs should be reflected in other program documents, including, but not limited to:

• Acquisition Strategy (AS)
• Test and Evaluation Master Plan (TEMP)
• Request for Proposal (RFP) and contract
• Program schedule — Integrated Master Plan/Integrated Master Schedule (IMP/IMS)
• Funding/budget
• Programmatic ESOH Evaluation (i.e., DFARS (Subpart 223.73, Minimizing the Use of Hexavalent Chromium))
• System finish/process specification (add to the Statement of Work (SOW) and as a Data Item Description (DID) to the Contract Data Requirements List (CDRL))
• Contractor Corrosion Prevention and Control Plan (add to the SOW/Statement of Objectives (SOO)/ Performance Work Statement (PWS) and as a DID to the CDRL)
• System performance specifications

In the contract and RFP, CPC planning and execution should be addressed in the management and technical content of each contract/RFP section and subsection, including, but not limited to, the SOW, IMP/IMS, CDRL, DID, and system performance specifications (see CH 3–2.7 Systems Engineering Role in Contracting and the DoD Corrosion Prevention and Control Planning Guidebook for MS&E).

Reference Source: CH 3-4.3.6 Critical Safety Item

A Critical Safety Item (CSI) is a part, assembly or support equipment whose failure could cause loss of life, permanent disability or major injury, loss of a system or significant equipment damage. Special attention should be placed on CSIs to prevent the potential catastrophic or critical consequences of failure. Significant problems occurred when DoD purchased CSIs from suppliers with limited knowledge of the item’s design intent, application, failure modes, failure effects or failure implications.

The purpose of CSI analysis is to ensure that Program Managers (PMs) for DoD acquisition programs who enter into contracts involving CSIs do so only with resources approved by the Design Control Activity (DCA). The DCA is defined by law as the systems command of a military department. The DCA is responsible for the airworthiness or seaworthiness certification of the system in which a CSI is used.

The intent of CSI laws, policies, regulations and guidance is to reduce the likelihood and consequence of failure by mitigating receipt of defective, suspect, improperly documented, unapproved and fraudulent parts having catastrophic potential. These statutory requirements are contained in P.L. 108-136 (SEC 802), enacted to address aviation CSIs, and P.L. 109-364 (SEC 130), enacted to address ship CSIs, embedded in 10 USC 2319. The statute addresses three specific areas:

• Establish that the DCA is responsible for processes concerning the management and identification of CSIs used in procurement, modification repair, and overhaul of aviation and ship systems.
• Require that DoD work only with sources approved by the DCA for contracts involving CSIs.
• Require that CSI deliveries and services performed meet all technical and quality requirements established by the DCA.

CSI policies and guidance ensure that items of supply that are most critical to operational safety are rigorously managed and controlled in terms of:

• Supplier capability
• Conformance to technical requirements
• Controls on changes or deviations
• Inspection, installation, maintenance and repair requirements

DoDM 4140.01, Volume 11 establishes top-level procedures for the management of aviation CSIs. The Joint Aeronautical Commanders Group issued the Aviation Critical Safety Items (CSIs) Management Handbook. This guidance establishes standard user-level operating practices for aviation CSIs across the Services, the Defense Logistics Agency (DLA), the Defense Contract Management Agency (DCMA), and other Federal agencies. Appendix I of the Aviation CSI Management Handbook is a joint Military Service/Defense Agency instruction on “Management of Aviation Critical Safety Items” issued on January 25, 2006. This instruction (SECNAVINST 4140.2, AFI 20-106, DA Pam 95-9, DLAI 3200.4, and DCMA INST CSI (AV)) addresses requirements for identifying, acquiring, ensuring quality of, managing and disposing of aviation CSIs. Similar policies and guidance are being developed and/or revised to address ship CSIs as defined by public law.

The Defense Federal Acquisition Regulation Supplement (DFARS) was amended to implement the contractual aspects regarding aviation CSIs. Comparable DFARS amendments are being developed to address ship CSIs. DFARS (Subpart 209.270) states that the DCA is responsible for:

• Identifying items that meet aviation CSI criteria.
• Approving qualification requirements.
• Qualifying suppliers.

This supplement states that the contracting activity contracts for aviation CSIs only with suppliers approved by the DCA. PMs should coordinate with the contracting activity to ensure that they contract for aviation CSIs only with suppliers approved by the DCA and that nonconforming aviation CSIs are to be accepted only with the DCA’s approval, as required by DFARS (Subpart 246.407). DFARS (Subpart 246.407) was amended to state that DCA authority can be delegated for minor nonconformance. DFARS (Subpart 246.504) requires DCA concurrence before certificates of conformance are issued to accept aviation CSIs.

Because the developer may uncover problems with products after items are delivered, DFARS (Subpart 246.371) and DFARS (Subpart 252.246-7003) require the developer to notify the procuring and contracting officers within 72 hours after discovering or obtaining credible information that a delivered CSI may have discrepancies that affect safety. PMs should coordinate with the contracting authority to be kept aware of materiel recalls and shortfalls that may impact production rates and sustainment.

The CSI list evolves as the design, production processes and supportability analyses mature. PMs identify and document CSIs during design and development to influence critical downstream processes, such as initial provisioning, supply support and manufacturing planning to ensure adequate management of CSIs throughout a system’s Operations and Support (O&S) phase. The PM should ensure that the allocated baseline established at the Preliminary Design Review (PDR) includes an initial list of proposed CSIs and a proposed process for selecting and approving CSIs, and that it addresses the critical characteristics of those items. Prior to the Critical Design Review (CDR), the program office, with support from the DCA and developer/OEM contractors, should ensure there is a clear understanding of CSI processes, terms and criteria. The initial product baseline, established at CDR, should have 100% of drawings completed for the CSIs. Throughout Low-Rate Initial Production (LRIP) (if applicable), conduct of the Physical Configuration Audit (PCA) and establishment of the product baseline, the program should update the CSI list and review it to ensure the list reflects the delivered system. Before the Full-Rate Production/Full Deployment Decision Review (FRP/FD DR), a final CSI list should be documented and approved by the DCA.

Reference Source: CH 3-4.3.7 Demilitarization and Disposal

The incorporation of demilitarization (DEMIL) and disposal requirements into the initial system design is critical to ensure compliance with:

• All DoD DEMIL and disposal policies
• All legal and regulatory requirements and policies relating to safety (including explosive safety), security, and the environment

Program Managers (PMs) and Product Support Managers should ensure, as an essential part of systems engineering, that DEMIL and disposal requirements are incorporated in system design to minimize DoD’s liabilities, reduce costs and protect critical program information and technology. This includes integrating DEMIL and disposal into the allocated baseline approved at the Preliminary Design Review (PDR) and refining DEMIL and disposal requirements in the initial product baseline at the Critical Design Review (CDR). DEMIL and disposal requirements are included in the program’s Systems Engineering Plan (SEP), Life-Cycle Sustainment Plan (LCSP) and contract(s). For munitions programs, DEMIL and disposal documentation need to be in place before the start of Developmental Test and Evaluation.

DEMIL eliminates functional capabilities and inherent military design features from both serviceable and unserviceable DoD materiel. It is the act of destroying the military offensive or defensive advantages inherent in certain types of equipment or material. DEMIL may include mutilation, scrapping, melting, burning or alteration designed to prevent the further use of this equipment and material for its originally intended military or lethal purpose. Systems Engineers integrate DEMIL considerations into system design to recover critical materials and protect assets, information and technologies from uncontrolled or unwanted release and disruption or reverse engineering. PMs should ensure the DEMIL of materiel is accomplished in accordance with DoDI 4160.28, DoD Demilitarization Program.

Disposal is the process of reusing, transferring, donating, selling or destroying excess surplus and foreign excess property. Disposal first ensures adequate screening is accomplished to satisfy all valid DoD and other U.S. Government agency needs. After assurances that Government needs for surplus DoD property are met, the materiel disposition process:

• Permits authorized transfer or donation to Government or non-Government entities.
• Obligates DoD to obtain the best-available monetary return to the Government for property sold.

PMs ensure disposal is accomplished in accordance with DoDM 4140.01, Volume 6 and DoDM 4160.21-M, Volume 1, Defense Materiel Disposition: Disposal Guidance and Procedures.

The program’s plan for DEMIL and disposal of DoD excess and surplus property protects the environment and personnel and minimizes the need for abandonment or destruction. During system design, the Systems Engineer supports the PM’s plans for the system’s demilitarization and disposal, through the identification and documentation of hazards and hazardous materials related to the system, using MIL-STD-882 (System Safety). Early, balanced analyses of Environment, Safety and Occupational Health (ESOH) hazards relative to the system’s design enable the PM to make informed decisions based on alternatives and provide a clear understanding of trade-offs and consequences, both near term and over the system’s life cycle.

Reference Source: DAG CH 3-4.3.8 Diminishing Manufacturing Sources and Material Shortages

Diminishing Manufacturing Sources and Material Shortages (DMSMS) is the loss, or impending loss, of manufacturers or suppliers of items, raw materials or software. DMSMS-generated shortages in the ongoing production capability or life-cycle support of a weapon system or shortages in any training, support or test equipment already in the field can endanger mission effectiveness. While DMSMS issues can be caused by many factors, their occurrence is inevitable.

The Program Manager (PM) should incorporate a technology management strategy into design activities as a best practice to reduce DMSMS cost and readiness impacts throughout the life cycle. The PM and Systems Engineer should develop a technology management strategy for maintaining insight into technology trends and internal product changes by the manufacturer, and testing the effects of those changes on the system when necessary. This insight into technology trends could potentially:

• Result in seamless upgrade paths for technologies and system elements.
• Provide a timetable for replacing system elements even if they are not obsolete.

The Systems Engineer should be aware of and consider DMSMS management during system design. Following are several practices that the program should consider to minimize DMSMS risk throughout the life cycle of the system:

• Avoid selecting technology and components that are near the end of their functional life.
• During the design process, proactively assess the risk of parts obsolescence while selecting parts.
• When feasible, use a Modular Open Systems Approach (MOSA) to enable technology insertion/refreshment more easily than with design-specific approaches.
• Proactively monitor supplier bases to prevent designing in obsolescence; participate in cooperative reporting forums, such as the Government-Industry Data Exchange Program (GIDEP), to reduce or eliminate expenditures of resources by sharing technical information essential during research, design, development, production and operational phases of the life cycle of systems, facilities and equipment.
• Proactively monitor potential availability problems to resolve them before they cause an impact in performance readiness or spending.

In addition, by using MIL-STD-3018 (Parts Management), the program can enhance the reliability of the system and mitigate part obsolescence due to DMSMS.

A useful resource for additional guidance is SD-22 (Diminishing Manufacturing Sources and Material Shortages (DMSMS) Guidebook).

Reference Source: DAG CH 3-4.3.9 ESOH

Environment, Safety and Occupational Health (ESOH) analyses are an integral, ongoing part of the systems engineering (SE) process throughout the life cycle. The benefits of early integration of ESOH considerations include:

• Mitigation of program cost and schedule risks from actions that cause damage to people, equipment or the environment.
• Reduction of Operations and Support and disposal costs to achieve system affordability.
• Provision of a safe, suitable, supportable and sustainable capability able to operate world-wide, including opportunities for Foreign Military Sales.

Throughout each acquisition phase, programs conduct their ESOH analyses to:

• Identify and mitigate potential risks to the system and its associated personnel.
• Manage ESOH design considerations from the beginning of the SE effort.
• Plan for compliance with 42 USC 4321, National Environmental Policy Act (NEPA), and Executive Order (EO) 12114, Environmental Effects Abroad of Major Federal Actions.
• Ensure compliance with statutory ESOH requirements.

ESOH in Systems Engineering

Programs are required to use the system safety methodology in MIL-STD-882 to manage their ESOH considerations as an integral part of the program’s overall SE process. This starts with including ESOH management planning in the Milestone A SEP to cover Technology Maturation and Risk Reduction (TMRR) activities and continues throughout the system’s life cycle.

DoD defines ESOH in MIL-STD-882 (System Safety) as “the combination of disciplines that encompass the processes and approaches for addressing laws, regulations, EOs, DoD policies, environmental compliance, and hazards associated with environmental impacts, system safety (e.g., platforms, systems, system-of-systems, weapons, explosives, software, ordnance, combat systems), occupational safety and health, hazardous materials management, and pollution prevention.”

The PM uses the system safety methodology for the identification, documentation and management of ESOH hazards and their associated risks during the system’s development and sustainment. The Program Manager, with support from the Systems Engineer, eliminates hazards where possible, and manages ESOH risks where hazards cannot be eliminated. MIL-STD-882 provides a matrix and defines probability and severity criteria to categorize ESOH risks.

MIL-STD-882 provides a structured, yet flexible, framework for hazard analysis and risk assessment for a specific system application (including system hardware and software). As an example for software, Subject Matter Experts (SMEs) use the MIL-STD 882 process for assessing the software contribution to system risk, which considers the potential risk severity and degree of control the software exercises over the hardware, and dictates the analysis level of rigor needed to reduce the risk level. The Joint Services Software Safety Authorities’ “Software System Safety Implementation Process and Tasks Supporting MIL-STD-882” is a concise “Implementation Guide” to assist in the implementation of the software system safety requirements and guidance contained in MIL-STD-882 and the Joint Software System Safety Engineering Handbook (JSSSEH) process descriptions complement MIL-STD-882 for these analyses.

The PM and Systems Engineer should also identify and integrate ESOH requirements into the SE process. Examples of this include, but are not limited to, the following:

• Complying with NEPA, EO 12114, and applicable environmental quality requirements, which will require assessing the system’s operation and maintenance pollutant emissions.
• Obtaining required design certifications, such as Airworthiness for air systems.
• Prohibiting or strictly controlling the use of banned or restricted hazardous materials, such as hexavalent chrome and ozone-depleting substances.

The PM and the Systems Engineer ensure ESOH is addressed during the Technology Maturation and Risk Reduction (TMRR) phase by including their ESOH plans in the Milestone A SEP. This is critical because the program conducts most of their developmental testing and finalizes a significant portion of the system design during TMRR. During TMRR, the ESOH SME can provide the most cost-effective ESOH support to the program by identifying and then eliminating or mitigating ESOH hazards and ensuring ESOH compliance during system testing and design development.

At Milestone B, the Systems Engineer and their ESOH SMEs document the results of their TMRR ESOH activities in the Programmatic ESOH Evaluation (PESHE) and their NEPA/EO 12114 Compliance Schedule. The PESHE consists of the ESOH hazard data, hazardous materials management data and any additional ESOH compliance information required to support analyses at test, training, fielding and disposal sites.

Finally, properly integrating ESOH in SE requires addressing the following key areas:

• Programs should integrate ESOH and system safety activities by incorporating various functional disciplines such as system safety engineers, fire protection engineers, occupational health professionals and environmental engineers to identify hazards and mitigate risks through the SE process.
• Programs should document ESOH management planning in the SEP, not the PESHE. The PESHE should document data generated by ESOH analyses conducted in support of program execution.
• Programs should continue to conduct assessment of the system and its hazards throughout the system life cycle to address system changes for any potential to alter existing risk levels (even for accepted ESOH risks) or to add hazards.

ESOH System Design Requirements

The Systems Engineer identifies the ESOH requirements applicable to the system throughout its life cycle from statutes, regulations, policies, design standards and capability documents. From these requirements, the Systems Engineer should derive ESOH design requirements and include them in capability documents, technical specifications, solicitations and contracts.

ESOH in Program Documents

Together the Systems Engineer and their ESOH SMEs use the SEP to document the program’s plan to integrate ESOH into the SE process, incorporating ESOH as a mandatory design, test, sustainment and disposal consideration. They use the Programmatic ESOH Evaluation (PESHE) and the NEPA/EO 12114 Compliance Schedule to document the results of the program’s implementation of their ESOH planning. This approach segments required ESOH information across the SEP, PESHE and NEPA/EO 12114 Compliance Schedule to avoid duplication and enhance ESOH integration.

The SEP should include the ESOH management planning information listed in Table 45.

Table 45: ESOH Information in SEP

Column Heading in SEP Table 4.6-1	Expected Information (provided or attached)
Cognizant PMO Organization	Organizational structure for integrating ESOH and the Program Office ESOH point of contact
Certification	Required ESOH approvals, endorsements, releases, and the designated high and serious risk acceptance user representative(s)
Documentation	PESHE and NEPA/EO 12114 Compliance Schedule
Contractual Requirements (CDRL#)	ESOH contractual language, ESOH Contract Data Requirements List (CDRL) items, and ESOH DFARS clauses
Description / Comments	Description of how design minimizes ESOH risks by summarizing how the program has integrated ESOH considerations into SE processes including the method for tracking hazards and ESOH risks and mitigation plans throughout the life cycle of system

 

The Systems Engineer and ESOH SMEs also provide input to other program documentation such as the: Acquisition Strategy (AS), Test and Evaluation Master Plan (TEMP), Life-Cycle Sustainment Plan (LCSP), system performance specifications, solicitations, contracts and capability documents.

As the repository for ESOH data and information, the PESHE includes, but is not limited to:

• ESOH Risk Matrices (for hardware and software) used by the program with definitions for severity categories, probability levels, risk levels and risk acceptance and user representative concurrence authorities. (NOTE: If a program is using risk matrices other than those required by MIL-STD-882, the program documents the formal Component approval for those alternative matrices in the PESHE.)
• The following data for each hazard: Hazard Tracking System (HTS) identification number; identified hazards (to include descriptions); associated mishaps (potential mishaps resulting from the hazard); risk assessments (to include the initial, target, and event(s) Risk Assessment Codes (RACs) and risk levels); identified risk mitigation measures; selected (and funded) mitigation measures; hazard status (current RAC and risk level based on any mitigation actions that have been implemented, verified and validated); verification of risk reductions (i.e., status of assessments of mitigation effectiveness); and risk acceptances (records of each risk acceptance decision to include the names of the risk acceptance authority and user representative(s); and dates of risk acceptance and user concurrence(s)). (NOTE: providing an electronic copy of the current data from the HTS would satisfy this requirement.)
• In addition to the applicable hazard and risk data, include the following data for each hazardous material, hazardous waste and pollutant associated with the system: the specific uses, locations, quantities and plans for their minimization and/or safe disposal. (NOTE: providing an electronic copy of the current data from either the HTS (if it includes this information) or the hazardous materials management data would satisfy this requirement.)
• Environmental impact information not included in the HTS or hazardous materials tracking system needed to support NEPA/EO 12114 compliance activities.

NOTE: Programs should use the results of the sustainability analysis (see CH 3–2.4.3. Sustainability Analysis) to inform the hazard analysis.

Each program maintains a NEPA/EO 12114 compliance schedule. This schedule includes, but is not limited to:

• Each proposed action (e.g., testing or fielding)
• Proponent for each action (i.e., the organization that exercises primary management responsibility for a proposed action or activity)
• Anticipated start date for each action at each specific location
• Anticipated NEPA/EO 12114 document type
• Anticipated start and completion dates for each document
• The document approval authority

The PM should incorporate the NEPA / EO 12114 Compliance Schedule into the Program Office’s Integrated Master Schedule (IMS) and Integrated Master Plan (IMP).

Because actions occurring during the TMRR phase may require NEPA/EO 12114 compliance, the program should identify these compliance requirements in the Milestone A SEP. Programs support other organizations’ NEPA/EO 12114 analyses involving their systems.

ESOH Activities by Phase

Table 46 aligns typical ESOH activities by phase.

Table 46: ESOH Activities by Phase

Acquisition Phase	Typical ESOH Activities
Materiel Solution Analysis (MSA)	Participate in Analysis of Alternatives (AoA) Provide inputs to the SEP, draft Capability Development Document (CDD), Corrosion Prevention and Control (CPC) Planning, AS, Life-Cycle Sustainment Plan (LCSP) and draft Request for Proposal (RFP)
Technology Maturation and Risk Reduction (TMRR)	Participate in prototyping and design development through the Integrated Product Team (IPT) structure to identify and mitigate ESOH risks in the product to be developed in the next phase Prepare initial PESHE and NEPA/EO 12114 Compliance Schedule Ensure NEPA/EO 12114 compliance, ESOH risk acceptance, Preliminary Design Review (PDR) risk reporting, and safety releases Inputs to SEP, CPC Planning, final CDD, Test and Evaluation Master Plan (TEMP), LCSP, and draft RFP
Engineering and Manufacturing Development (EMD)	Participate in trades and design development activities through the IPT structure Evaluate Test and Evaluation (T&E) results, to include assessment of ESOH risk mitigations Update NEPA/EO 12114 Compliance Schedule and PESHE; support NEPA/EO 12114 compliance activities, ESOH risk acceptance Obtain required ESOH approvals, endorsements and releases; provide inputs to the SEP, CPC Planning, LCSP, Capability Production Document (CPD) and draft RFP
Production and Deployment (P&D)	Participate in initial Configuration Control Board (CCB) process Evaluate T&E results, to include assessment of ESOH risk mitigations Analyze deficiency reports Review Physical Configuration Audit (PCA) Update NEPA/EO 12114 Compliance Schedule and PESHE Support NEPA/EO 12114 compliance activities and ESOH risk mitigations Obtain required ESOH approvals, endorsements and releases Support Initial Operational Capability (IOC) and Full Operational Capability (FOC) Provide inputs to the LCSP, CPC Planning, and product support package
Operations and Support (O&S)	Participate in mishap investigations and the CCB process Analyze system use data such as deficiency reports, hazard reports, regulatory violations, etc. Keep the PESHE data current; support NEPA/EO 12114 compliance activities and ESOH risk acceptance Provide inputs to draft Joint Capabilities Integration and Development System (JCIDS) documents and CPC Planning

ESOH Risk Management

The PM is also responsible for ensuring the appropriate management level accepts ESOH risks prior to exposing people, equipment or the environment to those risks.

• High ESOH risks require Component Acquisition Executive (CAE) acceptance
• Serious ESOH risks require Program Executive Officer (PEO)-level acceptance
• Medium and Low ESOH risks require PM acceptance

Any time a risk level increases the PM should ensure the appropriate management level accepts the new risk level prior to exposing people, equipment or the environment to the new risk level. This means a given ESOH risk may require multiple risk acceptances as the risk level changes across the life of a system. For example:

• During development, the risk level will change as the program funds and implements identified mitigations.
• During testing, the risk level may change due to test configurations, which differ from the eventual system design.
• During sustainment of a fielded system, the risk level may change as the system ages and as more information about a given risk becomes available.

The Systems Engineer, in support of the PM, uses the MIL-STD-882 methodology to manage ESOH risks. Before accepting a risk, the appropriate acceptance authority requires user representative concurrence from the DoD Component(s) responsible for the personnel, equipment or environment exposed to the risk.

For joint programs, the ESOH risk acceptance authorities reside within the lead DoD Component (unless the Milestone Decision Authority (MDA) approves an alternative) and each participating DoD Component provides an appropriate user representative. Joint programs should identify the specific risk acceptance authority and user representative offices in the PESHE. If a joint program uses a memorandum of agreement (MOA) to document risk acceptance authority and user representative offices, they should attach the MOA to the PESHE.

The program documents formal risk acceptances as part of the program record (e.g., Hazard Tracking System). If a risk level increases for a hazard, a new risk acceptance is required prior to exposing people, equipment or the environment to the increased risk. The program also participates in system-related mishap investigations to assess contributing hazards, risks and mitigations.

Programs report the status of current high and serious ESOH risks at program reviews and fielding decisions and the status of all ESOH risks at technical reviews. The purpose of this reporting is to inform the MDA, PEO, PM and end user about trades being made and ESOH risks that need to be accepted. Each ESOH risk report includes the following:

• The hazard, potential mishap, initial RAC and risk level
• Mitigation measure(s) and funding status
• Target RAC and risk level
• Current RAC and risk level
• Risk acceptance/user representative concurrence status

In accordance with MIL-STD-882, a risk is never closed nor is the term “residual” risk used. This enables programs to ensure, as their system changes occur over time; they assess those changes for any potential to alter existing risk levels or to add hazards. This also enables a program to determine the potential for eliminating hazards or reducing their risk levels as the program implements system design or operating and maintenance procedure changes.

Hazardous Materials Management

When Hazardous Materials (HAZMAT) and chemicals/materials of evolving regulatory concern are designed into the system or used for system operation and maintenance, the Program Manager and Systems Engineer assess and document the ESOH risks for each combination of HAZMAT and application. (NOTE: The use of certain HAZMATs in system design can increase life-cycle cost and create barriers to Foreign Military Sales.) The Systems Engineer can use the optional Task 108, Hazardous Materials Management Plan, in MIL-STD-882 and/or the Aerospace Industries Association (AIA) National Aerospace Standard (NAS) 411, Hazardous Materials Management Program, as the basis for a program’s HAZMAT management. Both Task 108 and NAS 411 require a contractual listing of the HAZMAT, which the program intends to manage. The contractual listing categorizes each listed HAZMAT as Prohibited, Restricted or Tracked. NAS 411-1, Hazardous Material Target List, provides a DoD-AIA agreed-upon baseline listing of HAZMAT for each category to use as the starting point in defining the program’s list of HAZMAT. When using either Task 108 or NAS 411, the Program Manager and Systems Engineer should document the following data elements for each listed HAZMAT:

• HAZMAT item or substance name (with Chemical Abstract Services (CAS) Number if available)
• HAZMAT Category (Prohibited, Restricted or Tracked)
• Special Material Content Code (SMCC) as designated in Federal Logistics Information System (FLIS) Technical Procedures Volume 10
• The locations, quantities, and usage of each HAZMAT embedded in the system or used during operations and support of the system, with traceability, as applicable, to version specific hardware designs
• ESOH requirements for demilitarization and disposal
• Energetic qualification information, as applicable
• Reasonably anticipated quantities of hazardous waste generated during normal operation and maintenance
• Reasonably anticipated HAZMAT (whether categorized or not) generated during the system’s life cycle (e.g., installation, Government test and evaluation, normal use and maintenance or repair of the system)
• Hazardous emissions/discharges, including those reasonably anticipated in emergency situations
• Special control, training, handling, Personal Protective Equipment (PPE) and storage requirements, to include provision of required Safety Data Sheets (SDSs), previously called Material Safety Data Sheets (MSDSs)

The Systems Engineer manages hexavalent chromium usage in systems to balance the requirements for corrosion prevention and control and the procedures in DFARS (Subpart 223.73 – Minimizing the Use of Hexavalent Chromium). For more information on chemicals/materials of evolving regulatory concern, refer to the DENIX website.

Safety Release for Testing

The PM, in concert with the user and the T&E community, provides safety releases (to include formal ESOH risk acceptance), to the developmental and operational testers before any test exposing personnel to ESOH hazards. The safety release addresses each system hazard present during the test and includes formal risk acceptance for each hazard. The program’s safety release is in addition to any test range safety release requirements, but it should support test range analyses required for a range-generated test release. Safety releases should be documented as part of the Program Record.

The PM should provide a transmittal letter to the involved test organization with a detailed listing of the system hazards germane to the test that includes the current risk level and documented risk acceptance along with information on all implemented mitigations.

Sustainable Procurement Program

In an effort to enhance and sustain mission readiness over the system life cycle, reduce reliance on resources and reduce the DoD footprint, programs should follow the policy and procedures identified in the DoD Sustainable Procurement Program (SPP). SPP benefits include:

• Improving mission performance by decreasing life cycle costs and reducing liabilities.
• Reducing impacts to human health and the environment.
• Ensuring availability of chemicals and materials.
• Enhancing installation and national security by reducing dependence on foreign energy sources.
• Contributing to regulatory compliance.
• Increasing potential for Foreign Military Sales.

PMs should implement the applicable SPP procedures in FAR (Subparts 23.2, 23.4, 23.7 and 23.8) to select materials and products that are energy-efficient, water conserving and environmentally preferable. More information on SPP is available on the DENIX website.

Climate Change

In an effort to continuously adapt current and future DoD operations to address the impacts of climate change, and to maintain an effective and efficient U.S. military, DoDD 4715.21 (para 1.2, 2.1, and 2.4) requires programs to integrate climate change considerations, including life-cycle analyses, into acquisitions.

Key Resources

• Acquisition Community Connection/ESOH
• Defense Acquisition University Continuous Learning Modules “CLE 009 — ESOH in Systems Engineering” and “CLR 030 – ESOH in JCIDS”
• Joint Software System Safety Engineering Handbook, August 27, 2010
• MIL-STD-882 with 25 optional Tasks

Reference Source: DAG CH3-4.3.10 Human Systems Integration

Systems engineering (SE) addresses the three major elements of each system: hardware, software and human. SE integrates human capability considerations with the other specialty engineering disciplines to achieve total system performance requirements by factoring into the system design the capabilities and limitations of the human operators, maintainers and users.

Throughout the acquisition life cycle, the Systems Engineer should apply Human Systems Integration (HSI) design criteria, principles and practices described in MIL-STD-1472 (Human Engineering) and MIL-STD-46855 (Human Engineering Requirements for Military Systems, Equipment and Facilities).

The HSI effort assists the Systems Engineer to minimize ownership costs and ensure the system is built to accommodate the human performance characteristics of users who operate, maintain and support the total system. The total system includes not only the mission equipment but also the users, training and training devices and operational and support infrastructure.

The Program Manager (PM) has overall responsibility for integrating the HSI effort into the program. These responsibilities are described in DAG Chapter 5 Manpower Planning & Human Systems Integration.

The Systems Engineer supports the PM by leading HSI efforts. The Systems Engineer should work with the manpower, personnel, training, safety, health, habitability, personnel survivability and Human Factors Engineering (HFE) stakeholders to develop the HSI effort. The Systems Engineer translates and integrates those human capability considerations, as contained in the capabilities documents, into quantifiable system requirements. Requirements for conducting HSI efforts should be specified for inclusion in the Statement of Work and contract. HSI should also be addressed in the Systems Engineering Plan (SEP), specifications, Test and Evaluation Master Plan (TEMP), Software Development Plan (SDP), Life-Cycle Sustainment Plan (LCSP) and other appropriate program documentation. The SEP Outline requires that HSI be addressed as a design consideration.

Elements of an effective HSI effort, described in DAG Chapter 5 Manpower Planning & Human Systems Integration, should:

• Provide a better operational solution to the warfighters.
• Lead to the development or improvement of all human interfaces.
• Achieve required effectiveness of human performance during system testing, operation, maintenance, support, transport, demilitarization and disposal.
• Ensure the demands upon personnel resources, skills, training and costs are planned and accounted for at every stage in the system life cycle.

• Ensure that overall human performance is within the knowledge, skills and abilities of the designated operators, maintainers and users to support mission tasking.

Reference Source: DAG CH3-4.3.11 Insensitive Munitions

The term “Insensitive Munitions” (IM) implies that unanticipated stimuli will not produce an explosive yield, in accordance with MIL-STD-2105 (Hazard Assessment Tests for Non-Nuclear Munitions). IM minimizes the probability of inadvertent initiation and the severity of subsequent collateral damage to weapon platforms, logistic systems and personnel when munitions are subjected to unanticipated stimuli during manufacture, handling, storage, transport, deployment or disposal, or due to accidents or action by an adversary.

IM is a component of explosives ordnance safety described in 10 USC 2389, which specifies that it is the responsibility of DoD to ensure IM under development or procurement are safe, to the extent practicable, throughout development and fielding when subjected to unplanned stimuli, (e.g., electro-magnetic interference, vibration or shock). In accordance with DoDD 5000.01, Enc. 1), the Program Manager (PM) and Systems Engineer for munitions programs and other energetic devices (such as ordnance, warheads, bombs and rocket motors) and munitions handling, storage and transport programs have an overriding responsibility to address safety aspects of their programs in trade studies, design reviews, milestone reviews and in JCIDS documents.

The PM and Systems Engineer for munitions programs, regardless of ACAT level, should have safety as a top consideration when performing trade studies or making program decisions. The PM and cognizant technical staff should coordinate harmonized IM/Hazard Classification (HC) test plans with the Service IM/HC testing review organizations. The Service organizations should coordinate the IM/HC with the Joint Services Insensitive Munitions Technical Panel (JSIMTP), Joint Service Hazard classifiers and the DoD Explosives Safety Board (DDESB), which is chartered by DoDD 6055.09E, Explosives Safety Management. Aspects of IM also apply to nuclear weapons but are not addressed here.

The primary document to address IM is the Insensitive Munitions Strategic Plan (IMSP), as required by USD(AT&L) memorandum, “Insensitive Munitions Strategic Plans,” July 21, 2004, which establishes DoD policy for the annual submission of IMSPs to the Joint Requirements Oversight Council (JROC) and Office of the Under Secretary of Defense (Acquisition, Technology, and Logistics) (OUSD(AT&L)), by the Program Executive Officer (PEO) for munitions programs. USD(AT&L) memorandum, “Joint Insensitive Munitions Test Standards and Compliance Assessment.” February 10, 2010, establishes policy for oversight and compliance assessment. The DoD Standard Operating Procedure (SOP) for IMSP and the Plan of Action and Milestones (POA&M), defined by Joint Business Rules, March 2011, define the content of the IMSP, which spans the Future Years Defense Plan (FYDP) and includes currently funded as well as unfunded requirements. The DoD Acquisition Manager’s Handbook for Insensitive Munitions contains the above-referenced documents and appendices for each Service’s policy and review board process.

The IMSP is the primary program output required by USD(AT&L) and the Joint Staff to provide evidence that the program is in compliance with all applicable laws and regulations. Both the Component-level and DoD-level IM review organizations can provide additional guidance and can assess the adequacy of the IMSP. In addition to the IMSP, the Analysis of Alternatives, Acquisition Strategy, Systems Engineering Plan, Test and Evaluation Master Plan, Risk Management Plan and other JCIDS documents called for in CJCSI 3170.01 and the JCIDS Manual (requires Common Access Card (CAC) to access website), address aspects of explosives ordnance safety, including IM.

Reference Source: DAG CH 3-4.3.12 Intelligence (Life-Cycle Mission Data Plan)

In collaboration with the intelligence community and the operational sponsor(s), the Program Manager (PM), with support from the Systems Engineer and Chief Developmental Tester, is responsible for planning, identifying, documenting, communicating and programming for life-cycle intelligence mission data support (see Figure 42 and DoDD 5250.01.)

Modern weapon systems are inherently dependent on a variety of scientific and technical intelligence products throughout every stage of their life cycle. Hence, planning for intelligence Mission Data (IMD) support, which informs design and development trade-offs, risk assessments and decisions is essential to satisfying system requirements. Similarly, communicating IMD requirements to the DoD intelligence community that supplies the necessary intelligence data is critical to achieving system capabilities.

Modern weapon systems are often intended to operate in threat and target environments throughout the world in multiple domains. System design decisions, development trade-offs and advanced technology insertion may be optimized, thereby creating sensitivities to changes in adversary capabilities in the threat and target environments. Critical intelligence parameters (CIP) represent key performance thresholds of foreign threat systems, which, if exceeded, could compromise the mission effectiveness of the system in development. Therefore, these CIPs (for example, radar cross-section, armor type or thickness or acoustic characteristics) should be identified and communicated to the intelligence community for tracking and immediate notification if breached. See DAG CH 7–4.1.4. for more information on CIPs.

Intelligence life-cycle mission data planning is necessary to effectively:

• Derive functional baseline requirements and life-cycle IMD requirements necessary to identify, define, and refine sensors, algorithms and intelligence data needs and trade-offs.
• Design, develop, test and evaluate IMD-dependent sensors, algorithms, systems, processes and interfaces.
• Conduct effectiveness analyses and risk assessments.
• Identify and acquire threat and target parameters that support digital modeling and simulation (see CH 3–2.4.2. Modeling and Simulation).
• Develop technical performance measures to inform test and evaluation.
• Inform decision making and science and technology investments for identifying IMD production and collection requirements.
• Assess system capability and limitations.
• Ensure system flexibility and agility in response to a dynamic threat and target environment.

Figure 42: Intelligence Mission Data (IMD) Life Cycle Timeline

The initial Life-Cycle Mission Data Plan (LMDP) is due at Milestone A, with a draft update due at the Development RFP Release Decision Point and approval at Milestone B by the DoD Component. Additional updates to the LMDP are due at Milestone C and the Full Rate Production/Full Deployment Decision.

DAG CH 7–4.1.3. provides key linkages to the system performance specification (sometimes called the System Requirements Document (SRD)), Systems Engineering Plan (SEP) and Test and Evaluation Master Plan (TEMP). These three products are directly affected by IMD requirements.

Reference Source: DAG CH 3-4.3.13 Interoperability and Dependencies

Almost all DoD systems operate in a system of systems (SoS) context relying upon other systems to provide desired user capabilities — making it vital that interoperability needs and external dependencies are identified early and incorporated into system requirements. When identifying system requirements, it is critical to consider the operational and SoS context (see CH 3–3.1.2. Systems of Systems). These include, but are not limited to, physical requirements (e.g., size, power limits, etc.), electronic requirements (e.g., signature, interference, etc.) and information exchange/management (e.g., network, bandwidth, information needs, etc.). These system requirements also include interdependencies with other systems. For efficiency, systems often rely on either services provided by other systems during operations or reuse of system elements developed by other programs.

Interoperability is the requirement that the program’s system interact with other systems through transport of information, energy or matter. For example, an air-launched missile is required to be interoperable with its delivery platform(s). Information is exchanged. A mechanical interface secures the missile until launch and so on. Usually, interoperability involves external interfaces (see CH 3–4.1.8.Interface Management Process) and is essential for the creation of systems of systems (SoS). Every system is required to be certified interoperable before it is fielded. The Joint Interoperability Test Command (JITC) is responsible for this certification.

Dependencies are relationships between different programs that cause one program to rely on another program’s actions or products to successfully meet its requirements. As examples, a ship development program may require prototypes of mission modules being developed by another program in the course of developmental testing, or a weapon may depend on new sensor capabilities provided by another system. The program depends on the mission module or sensor program to enable it to meet its testing schedule. A schedule issue could occur if the needed prototypes are not available in time for the tests. A performance issue could occur if the designs of the two systems do not support the needed end-to-end capability.

The common element linking interoperability and dependencies (I&D) is the need for cooperation and/or coordination between separate programs. Two common ways to meet this need are memoranda of agreements (MOAs) and invited attendance at program technical reviews and other technical meetings. MOAs are agreements between programs that specify expectations as to performance, resources, management and schedules. Interchange between engineers and managers at technical meetings opens lines of communication, which permits risk identification and early mitigation.

The Program Manager (PM) is responsible for ensuring that the operational and SoS context for the system are well understood. The PM is also responsible for establishing required MOAs and managing relationships with other programs.

The Systems Engineer has the responsibility for ensuring all interoperability and dependency impacts are analyzed and collaborated with the appropriate internal/external stakeholders and translated into system requirements and design considerations.

Analysis conducted for the SoS contexts for the system — where the system is dependent on other systems and where the system needs to interact with other systems — enables translation of interoperability and dependencies (I&D) into system requirements. I&D requirements call for collaborative implementation approaches with external organizations, including identification, management and control of key interfaces. Areas of dependency and interoperability should be reviewed for risks to the program and plans made to manage and mitigate those risks. This review includes system interdependencies (e.g., a weapon may depend on new sensor capabilities provided by another system) and information exchanges with other systems required to support mission capabilities. For efficiency, systems may rely on system elements developed by others for key functionality, either through services (e.g., weather information) provided by other systems or through reuse of system elements (e.g., engines, radios) developed by other programs. These contexts are analyzed to identify system requirements and risks, including actions needed by external parties (e.g., other systems or infrastructure) for the system to meet user requirements.

Additional DoD policy and guidance regarding I&D, summarized below, are directed at ensuring that systems work effectively with other systems:

• Interoperability of information technology and National Security System (NSS) acquisition programs are required to comply with DoDI 8330.01, CJCSI 3170.01, the JCIDS Manual (requires Common Access Card (CAC) to access website), and 44 USC 3506.
• DoDD 5000.01, Enc. 1:
  • Ability of acquired systems to exchange information and services with other systems and to interoperate with other United States forces and coalition partners, and, as appropriate, with other United States Government departments and agencies.
  • Providing systems and systems of systems that are interoperable and able to communicate across a universal infrastructure that includes organizational interactions, other systems, networks and information-exchange capabilities.

• DoDI 2010.06: Pursuing opportunities throughout the acquisition life cycle that enhance international cooperation and improve interoperability.

Reference Source: DODI 5000.88 Section 3.7.d

 

The PM will plan for and implement item unique identification to identify and track applicable major end items, configuration-controlled items, and U.S. Government-furnished property to enhance life-cycle management of assets in systems acquisition and sustainment, and to provide more accurate asset valuation and property accountability. Item unique identification planning and implementation will be documented in an item unique identification implementation plan linked to the program’s SEP. DoDI 8320.04 provides the standards for unique item identifiers.

Reference Source: DAG CH 3-4.3.14 Item Unique Identification

Item Unique Identification (IUID) is a systematic process to globally and unambiguously distinguish one item from all the other items that DoD buys or owns. IUID-enabled Serialized Item Management (SIM) provides a capability that allows DoD to locate, control, value and manage its assets throughout the life cycle. A robust SIM program provides tools and processes to assist informed decision making to achieve both better weapon system reliability and readiness at reduced total ownership cost. IUID-enabled SIM provides DoD with a standard methodology to:

• Consistently capture the value of all individual items it buys/owns.
• Trace these items during their use.
• Combat counterfeiting of parts.
• Associate valuable business intelligence to an item throughout its life cycle via automatic identification technology and connections to automated information systems.

Program Managers (PMs) and Product Support Managers should budget, plan for and implement IUID-enabled SIM as an integral activity within MIL-STD-130 (Identification Marking of U.S. Military Property)requisite item identification processes to identify and track applicable major end items and configuration-controlled items. IUID implemented in accordance with DoDI 8320.04 and IUID Implementation Plans are required for all milestone decisions. IUID-specific design considerations are required in the Systems Engineering Plan (SEP) and SIM planning and implementation required by DoDI 4151.19 are addressed in the Life-Cycle Sustainment Plan (LCSP).

The Systems Engineer considers what to mark and how to incorporate the IUID mark within MIL-STD-130 item-marking requirements when formulating design decisions. In addition, the Systems Engineer considers where product and maintenance information reside and how the life-cycle data are used within the configuration management and product support systems — including new and legacy information systems.

The DoD Guide to Uniquely Identifying Items provides guidance on implementing IUID intended for use by Department of Defense (DoD) contractors and their suppliers, who put unique item identifier (UII) marks on new items during production, as directed in the contract.

Reference Source: DAG CH 3-4.3.15 Modular Design

Modular design allows for modifications to systems, recombination of existing capabilities and upgrade of system elements, to enable competition, innovation, rapidly responding to a changing environment, etc. Designing for modularity is a key technical principle for implementing a modular open systems approach (MOSA) and is a complementary piece to the open system practices in contracting. The major tenet of a modular design strategy is to develop loosely coupled systems, where modules can be decoupled, separated or even re-arranged. When designing for modularity, the system should be appropriately partitioned into discrete, scalable, self-contained functional elements by decomposing and decoupling the functions of a system. This functional partitioning results in elements that can now be composed into modules that can be reconfigured or even replaced.

Acquisition programs implementing a modular design provide flexible system designs, which allow for the replacement or recombination of subsystems and components. It is important for the program management to understand the expected benefit from modular design as part of implementing a MOSA strategy. This understanding provides guidance to the system realization, on which enabling elements (e.g., standards, contract clauses, engineering tools, etc.) to use. MOSA benefits are usually categorized into five individually useful areas, which often overlap: cost savings/cost avoidance; increased competition; enhanced interoperability; application of innovative elements; and ability to realize technology upgrade opportunities easily.

Program Managers (PMs) should understand both the positive and negative outcomes from implementing a modular design and determine if the realization of a particular benefit outweighs the potential negative consequence. When scoping where the system should implement modular design, the PM and Systems Engineer should consider multiple factors, such as anticipated obsolescence, technical innovation, preplanned product improvements to meet performance, etc. These circumstances will vary across systems. System engineers should conduct design trades to support the PM in deciding where to implement modularity into the system design, including how to organize system components, where to put interfaces and which interface specifications and standards to select. (For additional details see CH 3–2.4.1. Modular Open Systems Approach.)

Reference Source: DAG CH 3-4.3.16 Operational Energy

Emerging threats to the logistic resupply of operational forces, the trend toward ever greater energy demand in the operational forces and increasing costs to operate and resupply energy-intensive systems have all put increasing focus on lowering system and unit energy demand. Reducing the force’s dependence on energy logistics can improve the force’s mobility and resilience and increase its control over the timing and conditions of the fight. Focusing on energy as an explicit design consideration and systems engineering (SE) category is a significant change in practice and thinking that will help manage emerging operational challenges.

The Program Manager (PM) and Systems Engineer can help lower operational energy by addressing issues associated with the system’s energy logistics support and power resupply frequency.

This approach should generate informed choices based on the threshold and objective values of the Energy Key Performance Parameter (KPP) for the system. For liquid energy-consuming systems, the top-level units of measure for the Energy KPP might be gallons of fuel demanded (consumed) over a defined set of duty cycles or for accomplishing a specified mission goal such as a sortie. These measures may be further decomposed into weight, range, electric power demand and other relevant measures to inform the necessary SE trade-off analysis. The intended result is a comprehensive set of trade-space choices for industry to consider to deliver solutions that are not only energy efficient but also mission-effective and affordable. See the Joint Capabilities Integration and Development System (JCIDS) Manual linked at the end of this section for more information on the Operational Energy KPP.

Energy’s relationship to performance arises from the operational context in which the system is used. Accordingly, the scenarios that illustrate how the system is used, as part of a unit of maneuver, are essential to understanding the energy supply and demand constraints to be managed. This is essentially the same approach as balancing survivability goals against lethality goals in the engineering trade space. Operational energy issues include:

• How the system and combat unit refuel/recharge in the battlespace scenarios, and how often.
• How this refueling/recharging requirement might constrain our forces (limit their freedom of action, on-station time, signature, etc.)
• How the adversary depicted in the defining scenarios might delay, disrupt and/or defeat our forces by interdicting this system’s refueling/recharging logistics.
• How much force protection could be diverted from combat missions to protecting these refueling/recharging events when and where required.

Systems Engineers should consider incorporating energy demand in design, technology, materials, and related issues into the system trade space along with other performance issues, so that oppressive energy resupply needs are not inadvertently introduced in the attempt to achieve other performance goals (e.g., survivability, lethality). In practice, this means requirements managers should factor into the system design the necessity of refueling/recharging using the same scenarios used to illustrate other performance requirements, and allowing the adversary a realistic chance to interdict the refueling/recharging effort. Systems Engineers may find it necessary to have a continuing dialogue with the warfighter (the user and requirements manager) to help grasp the operational impact of these issues and depict them in trade-space decisions.

Energy-related engineering analysis should begin early enough to support initial Analysis of Alternatives (AoA) planning following the Materiel Development Decision, and should also be routinely updated to inform any AoA performed later in the life cycle (i.e., in support of block upgrades and modifications).

The following documents provide the PM and Systems Engineer with additional insight into the issue of Operational Energy in the acquisition life cycle:

• JCIDS Manual (for the Energy KPP; requires Common Access Card (CAC) to access website)
• Operational Energy Strategy
• Defense Science Board Task Force report on Operational Energy, February 2008
• Defense Science Board Task Force report on Operational Energy, May 2001

NOTE: The results of the sustainability analysis (see CH 3–2.4.3. Sustainability Analysis) can be used to inform energy analyses.

Reference Source: DAG CH 3-4.3.17 Packaging, Handling, Storage and Transportation

The program team employs Packaging, Handling, Storage and Transportation (PHS&T) principles/methods to ensure the necessary equipment reaches the warfighter while minimizing risk of damage to the equipment during handling, storage and transportation — frequently in highly challenging and corrosive operational environments.

Thorough PHS&T requirements promote supportability and sustainability of major end items, reparable system elements and supporting test equipment. PHS&T focuses on transportation, handling and storage (short- and long-term) constraints on performance resulting from driving size, weight, parts robustness and shelf life.

Program Managers (PMs) and Systems Engineers should ensure PHS&T is addressed during the requirements analysis process, and validated throughout each phase of the systems engineering (SE) development of the weapon system. All PHS&T requirements should be verified before entering the Production and Deployment phase, as this phase will require the implementation of PHS&T for a weapon system delivery to the warfighter during low rate initial production. DoDI 4540.07 identifies specifics regarding PHS&T as related to systems engineering of weapon systems acquisitions. In addition, the following documents address PHS&T:

• MIL-STD-2073-1 (Standard Practice for Military Packaging)
• MIL-STD-129 (Military Marking for Shipment and Storage)
• ASTM-D3951, Standard Practice for Commercial Packaging
• DoDM 4140.27, Volume 1
• DTR 4500.9-R, Defense Transportation Regulation
• 49 CFR Parts 171-180, Transportation

Reference Source: DAG CH 3-4.3.18 Producibility, Quality and Manufacturing Readiness

Producibility

Producibility is a design accomplishment for the relative ease of manufacturing. Like manufacturing and other key system design functions, producibility is integral to delivering capability to the warfighter effectively and efficiently. Producible designs are lower risk, more cost-effective and repeatable, which enhances product reliability and supportability. Producibility should be assessed at both a product and enterprise (i.e., organizational, prime contractor facility) level. The Program Manager (PM) should implement producibility engineering and planning efforts early and should continuously assess the integrated processes and resources needed to successfully achieve producibility.

To assess producibility on a product level, both the product and its manufacturing processes should be measured. Manufacturing processes should be monitored and controlled, through measurement, to ensure that they can repeatedly produce accurate, high-quality products, which helps the program meet objectives for limiting process variability to a tolerable range.

To assess producibility within a manufacturing enterprise level, the organization should evaluate producibility performance on a product-specific basis. This evaluation allows the organization to understand the strengths and weaknesses of its producibility approach better, so enhancements can be identified and measures of processes, products, and the producibility system (integrated processes and resources needed for achieving producibility) can be tailored to strive for continuous improvement.

The PM should ensure that the producibility program focuses on the following five elements to build and maintain a successful producibility system:

1. Establish a producibility infrastructure:

• Organize for producibility
• Integrate producibility into the program’s risk management program
• Incorporate producibility into the new product strategy
• Employ producibility design guidelines

2. Determine Process Capability:

• Determine Process Capability (Cpk)
• Understand and document company and supplier processes
• Plan for future process capabilities

3. Address producibility during initial design efforts:

• Identify design objectives
• Identify key characteristics of the design
• Perform trade studies on alternative product and process designs
• Develop a manufacturing plan
• Perform complexity analysis

4. Address producibility during detailed design:

• Address producibility measurements at Preliminary Design Review (PDR), Critical Design Review (CDR), Production Readiness Review (PRR) and Full-Rate Production Design Review (FRP DR)
• Optimize manufacturing plans as the design matures

5. Measure producibility processes, products and systems.

Producibility should be a Technical Performance Measure (TPM) for the program, and the program’s strategy for producibility should be contained in paragraph 3.6 of the program’s Systems Engineering Plan (SEP). Planned producibility engineering activities for previous and subsequent phases also should be summarized in the SEP. As a key design accomplishment, producibility should be included in the SEP, mapping key design considerations into the Request for Proposal (RFP) and subsequently into the contract.

Quality in Design

Design engineering focuses on concurrent development of the total system, using capable manufacturing processes leading to a producible, testable, sustainable and affordable product that meets defined requirements. The design phase is critical because product life-cycle costs are committed at this point. The objectives of quality design efforts are to:

• Achieve effective and efficient manufacturing with necessary process controls to meet system requirements.
• Transition to production with no significant manufacturing process and reliability risks that could breach production thresholds for cost and performance.

To ensure consistency in applying quality planning and process control, the program should establish a Quality Management System (QMS) early, ideally at Milestone A (See CH 1–4.2.19. for more information on Quality Management.)The QMS should be defined and documented in the Acquisition Strategy (AS). The process should be integrated into these documents as a systems engineering (SE) practice that supports the successful transition of capability development to full-rate production and delivery of systems to support warfighter missions.

The primary focus of the QMS should be to ensure efficiency in processes, and should be integrated with Statistical Process Control (SPC) to eliminate defects and control variation in production. The QMS should aid the transition from system development to production by controlling life-cycle cost and reducing complexities that are often found when quality is not integrated as a function of the design. Therefore, to achieve high-quality (product characteristics meet specification requirements), an end product should be designed so that:

• Processes to produce the end product are in statistical control (uniformity in manufacturing and production).
• Design specifications are aligned with manufacturing process capabilities.
• Functional design integrates producibility requirements (measure of relative ease of manufacturing) with no significant compromises to quality and performance.

The PM and Systems Engineer should take into consideration that process capability goes beyond machine capability. The process should include the effects of change in workers, materials, fabrication methods, tooling and equipment, setup and other conditions. Process capability data should be collected throughout process and product development. Data collection efforts should be continuously refined, using test articles, through production.

In addition to QMS and SPC, understanding and improving processes may require common and/or new tools and techniques to eliminate defects and variation in processes.

Another quality management tool available to the PM is parts management. MIL-STD-3018 (Parts Management) provides requirements for the implementation of an effective Parts Management Program (PMP) on DoD acquisitions.

Quality should be a TPM for the program, and the program’s strategy for managing quality should be included in the SEP. Planned quality engineering and management activities for previous and subsequent phases also should be summarized in the SEP. As a key design accomplishment, quality should be included in the SEP mapping key design considerations into contracts.

Two valuable tools to assist in creating quality in design are Six Sigma and Quality Function Deployment (QFD). Six Sigma techniques identify and reduce all sources of product variation — machines, materials, methods, measurement system, the environment and the people in the process. QFD is a structured approach to understanding customer requirements and translating them into products that satisfy those needs.

Assessing Manufacturing Readiness and Risk

PMs of programs with a manufacturing component should ensure contractors have a robust manufacturing management system. Planned manufacturing management activities for previous and subsequent phases also should be summarized in the SEP. As a key design accomplishment, efficient and cost-effective manufacturing should be included in the SEP, mapping key design considerations into contracts. The SAE AS6500, Manufacturing Management Program, contains best practices for a manufacturing management system, has been adopted for use by DoD and may be placed on contract with tailoring appropriate to the program’s needs.

Manufacturing feasibility, processes and risk should be assessed early in the Materiel Solution Analysis (MSA) phase, and continuously through the Production and Deployment (P&D) phase in all acquisition programs. To ensure integration of manufacturing readiness and risk as part of design activities, the focus should be on system risk reduction, manufacturing process reliability and producibility.

PMs should use existing manufacturing processes whenever practical to support low-risk manufacturing. When the design requires new manufacturing capability, the PM may need to consider new manufacturing technologies or process flexibility (e.g., rate and configuration insensitivity), which introduces risk. See DFARS (Subpart 207.105 – Contents of Written Acquisition Plans) for specific guidance on manufacturing actions planned by the PM to execute the approach established in the AS and to guide contractual implementation. These include:

• Consideration of requirements for efficient manufacture during the design and production of the system
• The availability of raw materials, special alloys, composite materials, components, tooling and production test equipment
• The use of advanced manufacturing technology, processes and systems
• The use of contract solicitations that encourage competing offerors to acquire modern technology, production equipment and production systems (including hardware and software)
• Methods to encourage investment in advanced manufacturing technology, production equipment and processes
• During source selection, increased emphasis on the efficiency of production.
• Expanded use of commercial manufacturing processes rather than processes specified by DoD

Low-risk manufacturing readiness includes early planning and investments in producibility requirements, manufacturing process capabilities and quality management to ensure effective and efficient manufacturing and transition to production. It also includes assessments of the industrial base. Manufacturing risk is evaluated through manufacturing readiness assessments, which are integrated with existing program assessments throughout the acquisition life cycle. The PM should assess manufacturing readiness in the program’s earliest phase, and the assessment should be continuous. The PM should report on the program’s manufacturing readiness progress/status during each technical review, Program Support Assessment, or its equivalent, and before each milestone decision.

Successful manufacturing has many dimensions. Industry and Government have identified best practices in the following nine manufacturing risk categories. PMs should use the best practices to assess their programs early and should report on these areas during technical reviews and before acquisition milestones. Implementation of these best practices should be tailored according to product domains, complexity and maturity of critical technologies, manufacturing processes and specific risks that have been identified throughout the assessment process. These categories should help frame the risk assessment and focus mitigation strategies:

• Technology and the Industrial Base: assess the capability of the national technology and industrial base to support the design, development, production, operation, uninterrupted maintenance support and eventual disposal (environmental impacts) of the system.
• Design: assess the maturity and stability of the evolving system design and evaluate any related impact on manufacturing readiness.
• Cost and Funding: examine the risk associated with reaching manufacturing cost targets.
• Materials: assess the risks associated with materials (including basic/raw materials, components, semi-finished parts and subassemblies).
• Process Capability and Control: assess the risks that the manufacturing processes are able to reflect the design intent (repeatability and affordability) of key characteristics.
• Quality Management: assess the risks and management efforts to control quality and foster continuous improvement.
• Manufacturing Workforce (Engineering and Production): assess the required skills, certification requirements, availability and required number of personnel to support the manufacturing effort.
• Facilities: assess the capabilities and capacity of key manufacturing facilities (prime, subcontractor, supplier, vendor and maintenance/repair)
• Manufacturing Management: assess the orchestration of all elements needed to translate the design into an integrated and fielded system (meeting program goals for affordability and availability).

As part of the manufacturing strategy development effort, the PM needs to understand the contractor/vendor business strategy and the impacts to Government risk identification and mitigation efforts, such as the Make/Buy decisions and supply chain risks assessments. Additional guidance on assessing manufacturing risks can be found in the Manufacturing Readiness Guide.

Assessment and mitigation of manufacturing risk should begin as early as possible in a program’s acquisition life cycle — including conducting a manufacturing feasibility assessment as part of the AoA.

The PM and Systems Engineer should consider the manufacturing readiness and manufacturing-readiness processes of potential contractors and subcontractors as a part of the source selection for major defense acquisition programs, see DFARS (Subpart 215.304).

The PM and Systems Engineer should assess manufacturing readiness during the acquisition life cycle, as described in Table 47.

Table 47: Manufacturing Readiness Assessment Points During the Acquisition Life Cycle

Manufacturing Readiness Assessment Points	Considerations
1. Post-AoA assessment during the Materiel Solution Analysis Phase. As part of the AoA, manufacturing risks should have been assessed for each of the competing alternatives (see the MRL Implementation Guide for one source of specific assessment factors). Risks for the preferred system concept should be assessed and identified at this point. The overall assessment should consider whether:	Program critical technologies are ready for the Technology Maturation and Risk Reduction phase Required investments in manufacturing technology development have been identified Processes to ensure manufacturability, producibility and quality are in place and are sufficient to produce prototypes. Manufacturing risks and mitigation plans are in place for building prototypes Cost objectives have been established and manufacturing cost drivers have been identified; draft Key Performance Parameters have been identified as well as any special tooling, facilities, material handling and skills required Producibility assessment of the preferred system concept has been completed, and the industrial base capabilities, current state of critical manufacturing processes and potential supply chain sources have all been surveyed
2. Technology Maturation and Risk Reduction, Development RFP Release Decision. As the program approaches the Development RFP Release Decision and the Milestone B decision, critical technologies should have matured sufficiently for 2366b certification and demonstrated in a relevant environment and should consider:	The program should be nearing acceptance of a preliminary system design An initial manufacturing approach has been developed Manufacturing processes have been defined and characterized, but there are still significant engineering and/or design changes in the system itself; manufacturing processes that have not been defined or that may change as the design matures should be identified Preliminary design, producibility assessments, and trade studies of key technologies and components should have been completed Prototype manufacturing processes and technologies, materials, tooling and test equipment, as well as personnel skills have been demonstrated on systems and/or subsystems in a production-relevant environment Cost, yield and rate analyses have been performed to assess how prototype data compare with target objectives, and the program has in place appropriate risk reduction to achieve cost requirements or establish a new baseline, which should include design trades Producibility considerations should have shaped system development plans, and the Industrial Base Capabilities assessment (in the AS for Milestone B) has confirmed the viability of the supplier base
3. Production Readiness Review. A production readiness review identifies the risks of transitioning from development to production. Manufacturing is a function of production; in order to transition to production without significant risk it is important that key processes have been considered and evaluated during the PRR, such as ensuring:	The detailed system design is complete and stable to support low-rate initial production (LRIP) Technologies are mature and proven in a production environment, and manufacturing and quality processes are capable, in control and ready for low-rate production All materials, manpower, tooling, test equipment, and facilities have been proven on pilot lines and are available to meet the planned low-rate production schedule Cost and yield and rate analyses are updated with pilot line results Known producibility risks pose no significant challenges for low-rate production Supplier qualification testing and first article inspections have been completed Industrial base capabilities assessment for Milestone C has been completed and shows that the supply chain is adequate to support LRIP
4. Full Rate Production (FRP) Decision Review. To support FRP, there should be no significant manufacturing process and reliability risks remaining. Manufacturing and production readiness results should be presented that provide objective evidence of manufacturing readiness. The results should include recommendations for mitigating any remaining low (acceptable) risk, based on assessment of manufacturing readiness for FRP which should include (but not be limited to):	LRIP learning curves that include tested and applied continuous improvements Meeting all systems engineering and design requirements Evidence of a stable system design demonstrated through successful test and evaluation Evidence that materials, parts, manpower, tooling, test equipment and facilities are available to meet planned production rates Evidence that manufacturing processes are capable, in control, and have achieved planned FRP objectives Plans are in place for mitigating and monitoring production risks LRIP cost targets data have been met; learning curves have been analyzed and used to develop the FRP cost model

Reference Source: DAG CH 3-4.3.19 Reliability and Maintainability Engineering

The purpose of Reliability and Maintainability (R&M) engineering (Maintainability includes Built-In-Test (BIT)) is to influence system design in order to increase mission capability and availability and decrease logistics burden and cost over a system’s life cycle. Properly planned, R&M engineering reduces cost and schedule risks by preventing or identifying R&M deficiencies early in development. This early action results in increased acquisition efficiency and higher success rates during operational testing, and can even occur in the development process as early as the Engineering and Manufacturing Development (EMD) phase.

Program Managers (PMs) implement a comprehensive R&M engineering program as an integral part of the systems engineering (SE) process. The Systems Engineer should understand that R&M parameters have an impact on the system’s performance, availability, logistics supportability, and total ownership cost. To ensure a successful R&M engineering program, the Systems Engineer should as a minimum integrate the following activities across the program’s engineering organization and processes:

• Providing adequate R&M staffing.
• Ensuring R&M engineering is fully integrated into SE activities, Integrated Product Teams and other stakeholder organizations (i.e., Logistics, Test & Evaluation (T&E), and System Safety).
• Ensuring specifications contain realistic quantitative R&M requirements traceable to the Initial Capabilities Document (ICD), Capability Development Document (CDD) and Capability Production Document (CPD).
• Ensuring that R&M engineering activities and deliverables in the Request for Proposal (RFP) are appropriate for the program phase and product type.
• Ensuring that R&M Data Item Descriptions (DIDs) that will be placed on contract are appropriately tailored (see the Guidance for Tailoring R&M Engineering Data on the DASD(SE) website).
• Integrating R&M engineering activities and reliability growth planning curve(s) in the Systems Engineering Plan (SEP) at Milestones A and B and at the Development RFP Release Decision Point.
• Planning verification methods for each R&M requirement.
• Ensuring the verification methods for each R&M requirement are described in the Test and Evaluation Master Plan (TEMP), along with a reliability growth planning curve beginning at Milestone B.
• Planning for system and system element reliability growth (i.e. Highly Accelerated Life Test, Accelerated Life Test or conventional reliability growth tests for newly developed equipment).
• Ensuring data from R&M analyses, demonstrations and tests are properly used to influence life-cycle product support planning, availability assessments, cost estimating and other related program analyses.
• Identifying and tracking R&M risks and Technical Performance Measures.
• Assessing R&M status during program technical reviews.
• Including consideration of R&M in all configuration changes and trade-off analyses.

As part of the SE process, the R&M engineer should be responsible for the R&M activities by the acquisition phase outlined in Table 48.

Table 48: R&M Activities by Acquisition Phase

Acquisition Phase	R&M Activities
Materiel Solution Analysis (MSA) Phase. During the MSA Phase, the R&M engineer, as part of the program SE team, should:	Analyze conceptual design approaches and estimate the feasibility with respect to R&M ICD performance capabilities Perform AoA trade-off studies among R&M, availability and other system performance parameters to arrive at a preferred system alternative. The studies should be performed in conjunction with product support, cost and design personnel, using the DoD RAM-C Rationale Report Manual Conduct a Reliability, Availability, Maintainability and Cost (RAM-C) analysis. For Major Defense Acquisition Programs (MDAP), prepare a preliminary RAM-C Rationale Report and attach the report to the SEP for Milestone A Translate ICD performance capabilities and draft CDD thresholds to R&M specification requirements based on the Concept of Operations/Operational Mode Summary/Mission Profile (CONOPS/OMS/MP), failure definitions and utilization rates Develop a system reliability growth planning curve and include it in the SEP. Reliability growth curves should be stated in a series of intermediate goals and tracked through fully integrated, system-level test and evaluation events until the reliability threshold is achieved. If a single curve is not adequate to describe overall system reliability, curves for critical subsystems, with rationale for their selection, should be provided Use data from the RAM-C Rationale Report to provide the following for logistics design support: a. The initial failure mode assessment, including effects of failure on system performance and the probable manner in which each failure mode would be detected to provide guidance to planning and the conceptual design of the diagnostics concept and maturation process b. Failure rate and removal rate estimates, for both corrective and preventive maintenance, to provide a realistic basis for equipment and replaceable unit spares provisioning planning Define contractor R&M engineering activities in the RFP and contract Statement of Work for the TMRR phase, which should include: a. Allocations b. Block diagrams and modeling c. Predictions d. Failure Mode, Effects and Criticality Analysis (FMECA) e. Subsystem and system-level reliability growth planning activities f. R&M tests and demonstrations g. Failure Reporting, Analysis and Corrective Action System (FRACAS)
Technology Maturation and Risk Reduction (TMRR) Phase.During the TMRR phase, the R&M engineer, as part of the program SE team, should:	Participate in trade studies during requirements analysis and architecture design Review results of R&M engineering analyses, verification tests, design approach, availability assessments and maintenance concept optimization to verify conformance to requirements, and to identify potential R&M problem areas Contribute to integrated test planning to avoid duplication and afford a more complete utilization of all test data for R&M assessment. Comprehensive test planning should include subsystem reliability growth and maintainability and BIT demonstrations as appropriate Understand schedule and resource constraints, and adjust the reliability growth planning curve based on more mature knowledge points. Include updated reliability growth planning curve in the SEP at the Development RFP Release Decision Point and at Milestone B, and in the TEMP at Milestone B Integrate R&M engineering analyses with logistics design support in the following areas: requirements and functional analysis; test planning; Reliability Centered Maintenance (RCM) and Condition Based Maintenance Plus (CBM+); and refinement of the maintenance concept, including the Level of Repair Analysis (LORA) and maintenance task analysis Verify that plans have been established for the selection and application criteria of parts, materials and processes to limit reliability risks Define contractor R&M engineering activities in the RFP and contract Statement of Work (SOW) for the EMD phase, during which R&M quantitative requirements and verification methods are incorporated Update the RAM-C analysis to support the Development RFP Release Decision Point ensuring the JCIDS Sustainment Thresholds in the CDD are valid and feasible. For MDAPs, attach the updated RAM-C Rationale Report to the SEP for Milestone B
Engineering and Manufacturing Development (EMD) Phase. During the EMD phase, the R&M engineer, as part of the program SE team, should:	Perform evaluations to assess R&M status and problems Update the RAM-C analysis, ensuring the JCIDS Sustainment Thresholds in the CPD are valid. For MDAPs, attach the updated RAM-C Rationale Report to the SEP for Milestone C. Ensure that the product baseline design and required testing can meet the R&M requirements Ensure the final FMECA identifies failure modes, and their detection methods, that could result in personnel injury and/or mission loss, and ensure they are mitigated in the design Ensure that the detailed R&M prediction to assess system potential to meet design requirements is complete Verify through appropriate subsystem/equipment-level tests the readiness to enter system-level testing at or above the initial reliability established in the reliability growth planning curve in both the SEP and the TEMP Verify system conformance to specified R&M requirements through appropriate demonstration and test Implement a FRACAS to ensure feedback of failure data during test and to apply and track corrective actions Coordinate with the Chief Developmental Tester (T&E Lead) and Operational Test Agencies (OTA) to ensure that the program office and OTA data collection agree on R&M monitoring and failure definitions, and that R&M and BIT scoring processes are consistent in verification of requirements through all levels of testing Define contractor R&M engineering activities in the RFP and contract SOW for the P&D phase to ensure adequate R&M engineering activities take place during P&D and the RFP and contract SOW provide adequate consideration of R&M in re-procurements, spares and repair parts Verify that parts, materials and processes meet system requirements through the use of a management plan detailing reliability risk considerations and evaluation strategies for the intended service life. Include flow of requirements to subcontractors and suppliers. See MIL-STD-1546 (Parts, Materials, and Processes Control Program for Space and Launch Vehicles) and MIL-STD-1547 (Electronic Parts, Materials, and Processes for Space and Launch Vehicles)and MIL-STD-11991 (General Standard for Parts, Materials, and Processes)
Production and Deployment (P&D) Phase. During the P&D phase, the R&M engineer, as part of the programs SE team should:	Verify initial production control of R&M degradation factors by test and inspection, production data analysis, and supplemental tests Verify R&M characteristics, maintenance concept, repair policies, Government technical evaluation and maintenance procedures by T&E Identify R&M and production-related BIT improvement opportunities via FRACAS and field data assessment Review Engineering Change Proposals (ECP), operational mission/deployment changes and variations for impact on R&M Update R&M predictions and FMECAs based on production tests, demonstration tests, operational evaluation and field results and apply them to the models previously developed to assess impacts on maintenance procedures, spares, manpower, packaging design, test equipment, missions and availability Verify that parts, materials and processes management requirements for limiting reliability risk and “lessons learned” are utilized during all design change efforts including change proposals, variations, substitutions, product improvement efforts or any other hardware change effort
Operations and Support (O&S) Phase. During the O&S phase, the R&M engineer, as part of the program SE team should:	Assess operational data to determine the adequacy of R&M and BIT characteristics performance; maintenance planning, features and procedures; provisioning plans, test equipment design; and maintenance training Identify problem areas for correction through ongoing closed-loop FRACAS and field data assessment Monitor availability rates and respond to negative trends and data anomalies

Reference Source: DODI 5000.88 Section 3.7.b

 

The PM will:

• Ensure compliance with U.S. and host nation electromagnetic spectrum regulations in accordance with Section 305 of Title 47, U.S.C., and Sections 901 through 904 and Section 104 of Public Law 102-538.
• Submit written determinations to the DoD Component chief information officer or equivalent that the electromagnetic spectrum necessary to support the operation of the system during its expected life-cycle is or will be available in accordance with DoDI 4650.01. These determinations will be the basis for recommendations provided to the MDA by the DoD Component chief information officer, or equivalent.

Reference Source: DAG CH 3-4.3.20 Spectrum Management

Warfighters use spectrum-dependent systems for communications, sensors (i.e., radar), navigation beacons, jammers, homing devices, anti-Improvised Explosive Devices (IED) and other purposes. Often emitters are in close physical proximity to each other and to civilian devices that should not be disrupted by military signals. Spectrum-dependent developers should be aware of the enemy electronic order of battle and countermeasures, and plan accordingly. Devices (including commercial items) that do not account for countermeasures may have vulnerabilities in hostile environments.

Spectrum management requirements are needed for all spectrum-dependent systems. Any system that uses an antenna or a platform that mounts such systems is a spectrum-dependent system. If a platform obtains a spectrum-dependent system as Government-furnished equipment (GFE), the platform Program Manager (PM) is responsible for ensuring that the GFE PM has obtained the needed permissions. Both programs are required to submit a Spectrum Supportability Risk Assessment (SSRA). The platform SSRA can reference the GFE SSRA, but may have to expand upon it regarding host-nation features or other information not contained in the GFE-level SSRA. The Systems Engineer should be aware of the worldwide rules for spectrum management and the need to obtain host-nation permission for each transmitter and frequency assignment.

PMs need to ensure that spectrum access is adequate and that it is granted in the Continental United States (CONUS) and wherever else the equipment is deployed. The Pre-Milestone A Analysis of Alternatives (AoA) should address spectrum needs as part of concept formulation. Both the SSRA and DD-1494 are required for each milestone (see DoDI 4650.01). The SSRA is used within the DoD as the basis for assessing the feasibility of building and fielding equipment that operate within assigned frequency bands and identifying potential de-confliction situations. The DD-1494, Application for Equipment Frequency Allocation, has four stages, which reflect the increasing maturity of available spectrum information during development. The DD-1494 form is submitted to National Telecommunications and Information Administration (NTIA) for approval of spectrum allocation, without which emitters cannot operate within CONUS, and to the International Telecommunications Union (ITU) for satellites. The NTIA Manual of Regulations and Procedures for Federal Radio Frequency Management (Redbook) chapter 3 addresses international treaty aspects of the spectrum, and chapter 4 addresses frequency allocations.

The Systems Engineer has a lead role in defining spectrum needs, throughput and power requirements and other attributes of the signals in space (outside the antenna — not in the transmission device) and the antenna characteristics and platform mounting details, as well as the safety aspects of emitters with regard to the Hazards of Electromagnetic Radiation to Ordnance (HERO), Personnel (HERP) and Fuel (HERF). The Systems Engineer should be aware that portions of the spectrum previously assigned to DoD or other Federal users are being sold for commercial use. Thus, previously approved DD-1494 can be revoked, requiring modifications to designs and even to fielded equipment. Similarly, host nations can alter prior agreements, as commercial applications encroach upon previously available spectrum.

Each nation reserves the right to control emitters operating within its territory; thus, host- nation agreements are essential in support of deployment. PMs and Systems Engineers of platforms that mount multiple emitters and receivers need to obtain spectrum access for each emitter and ensure that those emitters and receivers do not produce mutual interference or interact with ordnance (see DoDI3222.03, MIL-STD-461 (Requirements for the Control of Electromagnetic Interference Characteristics of Subsystems and Equipment), MIL-STD-464 (Electromagnetic Environmental Effects Requirements for Systems), MIL-HDBK-235-1 (Military Operational Electromagnetic Environment Profiles Part 1C General Guidance), MIL-HDBK-237 (Electromagnetic Environmental Effects and Spectrum Supportability Guidance for the Acquisition Process), MIL-HDBK-240 (Hazards of Electromagnetic Radiation to Ordnance Test Guide), and “Joint Services Guide for Development of a Spectrum Supportability Risk Assessment”). The Defense Information Systems Agency (DISA), Defense Spectrum Organization provides spectrum support and planning for DoD. See Figure 43 for spectrum activities by acquisition phase. This figure summarizes the requirements of DoDI 4650.01.

Figure 43: Spectrum-Related Activities by Life-Cycle Phase

Reference Source: DODI 5000.88 Section 3.7.f

 

The PM will plan for the identification and implementation of specifications and standards that support interoperable, reliable, technologically superior, and affordable capabilities pursuant to DoDI 4120.24.

 

Reference Source: DAG CH 3-4.3.21 Standardization

Standardization supports the achievement of commonality and interoperability of parts and processes with United States forces and our allies, promotes safety, provides for life-cycle sustainment and allows for rapid, cost-effective technology insertion through use of standard interfaces and open systems. Standardization is an enabling tool to provide the warfighter with systems and equipment that are interoperable, reliable, sustainable and affordable. Standardization plays a key role in defining systems engineering (SE) best practices and processes.

The Program Manager (PM) balances the decision to use standardized agreements, practices, products, parts, processes, interfaces and methods with required capabilities, operational environment, technology feasibility and growth and cost-effectiveness.

DoDM 4120.24, Enclosure 4, Standardization in the Acquisition Process, provides policies on standardization considerations, how to document standardization decisions, and a discussion of the tailoring of standardization documents. It also provides references to key resources for the standardization process.

Parts management is a standardization design strategy available to PMs. Benefits of parts standardization include:

• Reducing the number of unique or specialized parts used in a system (or across systems).
• Reducing the logistics footprint.
• Lowering life-cycle costs.

In addition, parts management can enhance the reliability of the system and mitigate part obsolescence due to Diminishing Manufacturing Sources and Material Shortages (DMSMS). MIL-STD-3018 (Parts Management) dictates that program offices should apply standardization processes to:

• Improve parts commonality.
• Reduce total ownership costs.
• Reduce proliferation of parts.
• Promote the use of parts with acceptable performance, quality, and reliability.

The Systems Engineer is responsible for:

• Implementing parts management contractual requirements.
• Approving contractor submitted plans.
• Ensuring parts management objectives are met.

Additional guidance on parts management may be found in SD-19 (Parts Management Guide).

Reference Source: DODI 5000.88 Section 3.7.e

 

The PM, in conjunction with the product support manager, will include supportability analyses (e.g., failure modes, effects and criticality analysis; level of repair, source of repair; maintenance task, provisioning) as an integral part of the systems engineering process at acquisition pathway initiation and continuing throughout the program life-cycle.

• The supportability analysis results should be reflected in the evolution of the digital authoritative source of truth.
• The LSE, working for the PM, will ensure that engineering analyses conducted by the specialty engineering disciplines inform the supportability analyses and sustainment risk mitigation strategies.

 

Reference Source: DAG CH 3-4.3.22 Supportability

A system with a balanced survivability and susceptibility approach ensures operational crew and personnel safety while satisfying mission effectiveness and operational readiness requirements.

Survivability is the capability of a system and its crew to avoid or withstand a hostile environment without suffering an abortive impairment of its ability to accomplish its designated mission. Susceptibility is the degree to which a device, piece of equipment or weapon system is open to effective attack as a result of one or more inherent weaknesses. Manmade and natural environmental conditions described in MIL-STD-810 (Environmental Engineering Considerations and Laboratory Tests) (e.g., sand, vibration, shock, immersion, fog, etc.), electromagnetic environment described in MIL-STD-461 (Requirements for the Control of Electromagnetic Interference Characteristics of Subsystems and Equipment) and MIL-STD-464 (Electromagnetic Environmental Effects Requirements for Systems), and cyber environment should also be considered in system design.

Susceptibility is a function of operational tactics, countermeasures, probability of an enemy threat, etc. Susceptibility is considered a subset of survivability. Vulnerability is the characteristics of a system that cause it to suffer a definite degradation (loss or reduction of capability to perform the designated mission) as a result of having been subjected to a certain (defined) level of effects in an unnatural (manmade) or natural (e.g., lightning, solar storms) hostile environment. Vulnerability is also considered a subset of survivability.

Design and testing ensure that the system and crew can withstand manmade hostile environments without the crew suffering acute chronic illness, disability or death. The Program Manager (PM), supported by the Systems Engineer, should fully assess system and crew survivability against all anticipated threats, at all levels of conflict, throughout the system life cycle. The goal of survivability and susceptibility is to:

• Provide mission assurance while maximizing warfighter safety (or minimizing their exposure to threats).
• Incorporate balanced survivability, with consideration to the use of signature reduction with countermeasures.
• Incorporate susceptibility reduction features that prevent or reduce engagement of threat weapons.
• Provide mission planning and dynamic situational awareness features.

The mandatory System Survivability Key Performance Parameter (KPP) is applicable to all Capability Development Documents (CDD) and Capability Production Documents (CPD). The System Survivability KPP may include:

• Reducing a system’s likelihood of being engaged by hostile fire, through attributes such as speed, maneuverability, detectability and countermeasures.
• Reducing the system’s vulnerability if hit by hostile fire, through attributes such as armor and redundancy of critical components.
• Enabling operation in degraded electromagnetic (EM), space or cyber environments.
• Allowing the system to survive and continue to operate in, or after exposure to, a chemical, biological, radiological and nuclear (CBRN) environment, if required.

If the system or program has been designated by the Director, Operational Test and Evaluation (DOT&E), for live-fire test and evaluation (LFT&E) oversight, the PM should integrate test and evaluation (T&E) to address crew survivability issues into the LFT&E program supporting the Secretary of Defense LFT&E Report to Congress.

If the system or program has been designated a CBRN mission-critical system, the PM should address CBRN survivability, in accordance with DoDI 3150.09, The Chemical, Biological, Radiological and Nuclear (CBRN) Survivability Policy. The PM should ensure that progress toward CBRN survivability requirements is documented in the applicable Service CBRN mission-critical report. More information on CBRN can be found on the CBRN Survivability DoDTechipedia page [CAC-enabled].

Unless waived by the Milestone Decision Authority (MDA), mission-critical systems, including crew, regardless of acquisition category, should be survivable to the threat levels anticipated in their projected operating environment as portrayed in their platform-specific Validated On-line Life-cycle Threat (VOLT) Report (see CH 7-4.1.2.).

The Systems Engineer should describe in the Systems Engineering Plan:

• How the design incorporates susceptibility and vulnerability reduction and CBRN survivability requirements.
• How progress toward these are tracked over the acquisition life cycle.

Additional techniques include rapid reconstruction (reparability) to maximize wartime availability and sortie rates and incorporating damage tolerance in the system design.

Reference Source: DAG CH 3-4.3.23 System Security Engineering

System Security Engineering (SSE) activities allow for identification and incorporation of security design and process requirements into risk identification and management in the requirements trade space.

SSE is an element of system engineering (SE) that applies scientific and engineering principles to identify security vulnerabilities and minimize or contain risks associated with these vulnerabilities. Program Protection is the Department’s integrating process for mitigating and managing risks to advanced technology and mission-critical system functionality from foreign collection, design vulnerability or supply chain exploit/insertion, battlefield loss and unauthorized or inadvertent disclosure throughout the acquisition life cycle. The Program Protection processes capture SSE analysis in the system requirements and design documents and SSE verification in the test plans, procedures and results documents. The Program Protection Plan (PPP) (see CH 9–2.3.) documents the comprehensive approach to system security engineering analysis and the associated results.

SSE analysis results should be captured in the PPP, provided at each technical review and audit (see CH 9–3.4.) and incorporated into the technical review assessment criteria as well as the functional, allocated and product baselines. The PPP is approved by the Milestone Decision Authority (MDA) at each milestone decision review and at the Full-Rate Production/Full-Deployment (FRP/FD) decision, with a draft PPP due at the Development Request for Proposals (RFP) Release Decision Point. The analysis should be used to update the technical baselines prior to each technical review and key knowledge point throughout the life cycle. It should also inform the development and release of each RFP (see CH 9–4.1.) by incorporating SSE process requirements and the system security requirements into the appropriate solicitation documentation.

The Program Manager (PM) is responsible for employing SSE practices and preparing a PPP to guide the program’s efforts and the actions of others. The Systems Engineer and/or System Security Engineer is responsible for ensuring a balanced set of security requirements, designs, testing and risk management are incorporated and addressed in the their respective trade spaces. The Systems Engineer and/or System Security Engineer is responsible for leading and facilitating cross-discipline teams to conduct the SSE analysis necessary for development of the PPP. The cross-discipline interactions reach beyond the SSE community to the test and logistics communities. CH 9–2.5. further details the program protection roles and responsibilities.

To address SSE as a design consideration, the Systems Engineering and Systems Security Engineer should ensure the system architecture and design addresses how the system:

• Manages access to, and use of, the system and system resources.
• Is configured to minimize exposure of vulnerabilities that could impact the mission through techniques such as design choice, component choice, security technical implementation guides and patch management in the development environment (including integration and T&E), in production and throughout sustainment.
• Is structured to protect and preserve system functions or resources, e.g., through segmentation, separation, isolation or partitioning.
• Monitors, detects and responds to security anomalies.
• Maintains priority system functions under adverse conditions.
• Interfaces with DoD Information Network or other external security services.

The early and frequent consideration of SSE principles reduces re-work and expense resulting from late-to-need security requirements (e.g., anti-tamper, exportability features, supply chain risk management, secure design, defense-in-depth and cybersecurity implementation.)