Attachment_L-6 _TMSA_TWBS.xlsx

TRA TWBS

(1) Fill in the TRA Phase, program ACAT, & program name.

(2) Fill in the program background info, provide a picture of your top level system/subsystem, & provide your program level risk cube.

(3) Provide a description of what constitutes a relevant environment (lab) & operational environment (field) for your system /subsystem, a picture/chart of your overall system /subsystem architecture, & associated technology-related risk cube.

(4) Refer to the sample aircraft system decomposition, & complete the 1st 4 columns for each Technology Element (TE) of your system /subsystem based on your system /subsystem architecture.

(5) Provide a description of each TE by filling in the 5 white boxes identifying the Technology, its Function in the system /subsystem, its Location in the platform, system, or subsystem, the Requirement Reference for this TE, & if this TE can be traced to a KPP. (6) Decide, utilizing the 2 definitions provided in the TWBS Guidance tab at the bottom, if this TE is or is not a CTE. If a CTE, then complete the green section & place a "Y" in the cell for a novel, new, or new application of a technology & also the recommended to be a CTE cell. In the white box, explain why it is novel, new, or a new application. Explain if it's being repackaged such that a new relevant or operational environmental is applicable, & describe the differences between the original & new environments. If it has been modified from prior successful use, explain the extent of the mods & the technological challenges resulting from the mods. If it is expected to operate in an environment and/or achieve a performance beyond its original design intention or demo'd capability, explain & describe the new technological challenges. (7) If not a CTE, then identify if its COTS, modified COTS, repackaged technology, or an extension of, or next generation of an internal developmental effort. Under change description, provide the production part # for unmodified COTS in the pink box, or describe the extent of the mods or repackaging effort in the white box.

(8) Under the CTE/Non-CTE Justification Narrative, regardless of the category chosen for a TE, substantiate the developmental maturity of the TE by providing its heritage/pedigree, quantitative TE demonstration evidence from the prototype or end-item integrated system/subsystem testing in a low or high fidelity lab relevant environment, or simulated or real operational environment, as appropriate (include dates, quantities, lab hrs., platforms, & flight hrs.), & a concluding statement in the adjacent white boxes.

AND

(2) this TE or its application is new or novel in an area that poses major technological risk during detailed design or demostration.

Note to Offeror - By definition, if you assign a TRL to a Technology Element (TWBS Item) you are identifying it as a CTE, i.e. an immature technology. If a Technology Element is not a CTE, then it does not get assigned a TRL.

• Curved surface

• High humidity

• High and Low temperature

• Temperature shock

• Salt fog environment

• Solar radiation

• Laser saturation

1.1.1 Fuselage

1.1.2 Wings

1.1.3 Empannage

1.1.4 Nacelle

1.1.5 Flight Controls

1.1.6 Landing Gear

1.1.7 Environmental

1.1.8 Ice Protection

1.1.9 Stores Suspension

1.1.10 Hydraulics

1.1.11 Pneumatics 1.2 Propulsion System

1.2.1 Engines

1.2.2 Monitor & Control

1.2.3 Fuel

1.2.4 Compressed Air

1.2.5 Inlet

1.2.6 Exhaust

1.2.7 Lubrication

1.2.8 Electrical Power 1.3 Crew System

1.3.1 Aircrew

1.3.2 Crew Station

1.3.3 In-flight Protection 1.4 Avionics System

1.4.1 Sensor Systems

1.4.2 Controls & Displays

1.4.3 Vehicle Management

1.4.4 Stores Management

1.4.5 Common Processing

1.4.6 Navigation Systems

1.4.7 Communication Systems

1.4.8 Antenna Systems 1.5 Stores System

1.5.1 Air-to-Air

1.5.2 Air-to-Surface

1.5.3 Expendables

1.5.4 Pods 2.0 TRAINING SYSTEM

2.1 Aircrew Training Devices

2.2 Parts Task Trainers

2.3 Embedded

2.4 Desktop Trainers

2.5 Maintenance Training Devices

2.6 Air Combat Training Systems

2.7 Targets & Scores 3.0 SUPPORT SYSTEM

3.1 Mission Planning System

3.2 Surface Control Systems

3.3 Cround Handling & Support Systems

3.4 Portable Maintenance Aids

3.5 Surface Test & Maintenance Systems

3.6 Launch & Recovery Systems

ELEMENT (TE)

MAPPING SPACE for ADDITIONAL NARRATIVE if REQUIRED

CRITICAL TECHNOLOGY ELEMENT (CTE) TECHNOLOGY MATURATION PLANS (TMPs) Once the TRA IRP has identified & scored CTEs above, an associated Technology Maturation Plan (TMP) is required here for each CTE. Update the TWBS CTE TMP whenever progress is achieved.

GUIDANCE for WRITING a TMP:

1) The chinning bar for technological maturity is for each IRP-identified CTE to achieve a TRL 6 by MS-B, a TRL 7 by MS-C, & a TRL 8 by the end of EMD.

2) The TMP should begin by listing the IRP-identified CTE & the reason(s) it was identified as a CTE.

3) Since understanding the importance of a TRL 6 is essential, the TMP should include the OSD definition of TRL 6. (See TRL Definitions tab)

4) The TMP should include subsequent definitions of all the key words identified in the TRL 6 definition.

5) The TMP should focus the rationale provided in the TMP towards addressing the finer points of the subsequent definitions.

6) The TMP should concentrate on a clear & complete definition of what constitutes a "system or subsystem" for the CTE.

7) The TMP should clearly & completely define (for a TRL 6) what constitutes a system/subsystem "relevant environment", with focus on rationale for compliance with a "high-fidelity lab environment".

8) Once these are established, the TMP should include all the steps included in the planned tests & demos with a description of what will be accomplished upon completion of each. 9) The TMP should include all tests & demos leading up to attainment of subsequent TRLs, along with anticipated time frames for each.

10) The TMP shall provide detailed insight into the objective, scope, method, & success criteria for each demonstration event, along with a definitized quantity.

11) The TMP should include "mature" fallback options in case the primary immature approach fails to mature as planned.

12) Evidence should be provided that documents why each alternative is an acceptable solution for technology maturity, performance, cost, & schedule.

13) The TMP should include a definitive time frame off-ramp for each mature fallback option to be exercised without impact to the overall program schedule.

14) The TMP should also identify any External Dependencies, i.e. dependency upon another program or investment to achieve the enabling technology maturity.

15) Once the TMP is established & underway, the CTE maturation progress should be routinely updated in the TWBS in the space provided here at the bottom as per DD Form 1423-1.

16) A CTE's TRL can only advance to the next level once the recorded progress has received concurrence from the TRA IRP.

17) If new CTEs are identified throughout the life of the program, then accordingly a TMP should be generated for each CTE.

ELEMENT (TE)

DO NOT REFORMAT &"Arial,Bold Italic"&11For Official Use Only DO NOT REFORMAT

TWBS Guidance

► See NAVAIRINST 3910.1 TRA Process.

TRA

Definition & Authority ► A TRA is a formal, systematic, metrics-based process that assesses the maturity of, and the risks associated with, critical technologies (defined as Critical Technology Elements (CTEs)) to be used in Major Defense Acquisition Systems (MDAPs). CTEs can be hardware (HW) or software (SW). It is conducted for the Program Manager by the NAVAIR TRA Chairman within the NAVAIR ITRO via an Independent Review Panel (IRP) of subject matter experts (SMEs).

► TRA Authority: DoDI 5000.02 establishes a regulatory requirement for TRAs. All Department of Defense (DoD) MDAPs must prepare a TRA at Milestone B of the Defense Acquisition System. Per SECNAVINST 5000.2E, TRAs are required for MS B and MS C. A TRA is only conducted on the actual proposed threshold compliant final design(s).

► Title 10 United States Code (U.S.C.) Section 2366b requires, in part, that the Milestone Decision Authority (MDA) certify that the technology in Major Defense Acquisition Programs (MDAPs) has been demonstrated in a relevant environment (TRL 6) before Milestone B approval.

► DoDI 5000.02 requires Request for Proposal (RFP) language that prevents the award of an EMD contract if it includes technologies that have not been demonstrated to be mature. As such, a generic TRA not based on the planned technical solution is not acceptable. The TRA must be based on the technologies in the system. This means that TRAs must be performed on all the competitors’ proposals in a source selection.

CTE Definition ► CTE DEFINITION: A technology element (TE) is defined as “critical” if the system being acquired depends on that TE to meet its capability development document (CDD) & capability production document (CPD) requirements and if its application is either new or novel in an area that poses major technological risk during detailed design or demonstration.

► NOT A CTE DEFINITION: This TE is NOT “critical” because the system being acquired does depend on this TE to meet operational rqmts with acceptable development cost & schedule, & with acceptable production & operation costs BUT this TE or its application IS NOT considered either new, novel, or in an area that poses a major risk in completing technology maturation development.

► CTE lists of varying origin exist during the TRA. “Candidate” CTEs are can be self-assessed by the program manager (PM), by the Integrated Product Team (IPT), or from the pre-Materiel Solution Analysis (MSA) early evaluations of technology maturity. A final “candidate” CTE list is identified by the IRP & represents the IRP product for CNR concurrence. The term “CTE” is reserved for the final list concurred with by the Chief of Naval Research (CNR). The final list is coordinated with the Director, Research & Development (DRD).

► As an activity separate from the formal TRA, an early evaluation of technology maturity conducted shortly before Milestone A should be used to support the planning of these risk reduction efforts.

► There is no such thing as an informal TRA. While many assessments of technology maturity will be conducted in the science & technology (S&T) environment & in the context of an acquisition program, the term “Technology Readiness Assessment” applies only to this regulatory requirement.

► The DRD has primary responsibility for reviewing & evaluating the TRA for the Office of the Secretary of Defense (OSD) for ACAT ID & IAM programs.

► The Component S&T Executive (for Navy CNR) evaluates the TRA for ACAT ICs. The Component S&T Executive can delegate to the appropriate MDAs for ACAT II and below. ► The DRD monitors the TRA process and reports to the DDR&E.

► The IRP of SMEs is responsible for conducting the TRA itself via the NAVAIR TRA Chairman.

Basis of Technology Maturity Assessments Throughout Acquisition ► The disciplined identification of CTEs is important to a program’s success. If a CTE is overlooked & not brought to the requisite maturity level for exploitation at the start of Engineering & Manufacturing Development (EMD), the system performance, program schedule, & overall cost could be jeopardized. On the other hand, if an overly conservative approach is taken & a plethora of technologies are categorized as critical, energy & resources are likely to be diverted from the few technologies that deserve an intense maturation effort. If a disciplined process with due diligence does lead to an inordinate number of CTEs, this process should indicate that the proposed development is reaching too far for its goals.

► The functional architecture establishes what the system accomplishes in descriptive & quantitative terms. It provides the well-defined framework around which the physical architecture is conceived & designed & the basis against which the system & its various subelements are tested.

► The physical architecture includes a representation of the SW & HW “products” necessary to realize the concept. The physical architecture forms the basis for design definition documentation (e.g., specs, baselines, the system & SW architectures, & the technical work breakdown structure (TWBS) as distinguished from a programmatic or contractual WBS)).

► The technical WBS (TWBS) has several beneficial attributes for identifying CTEs: (1) It is readily available when system-engineering practices are used, (2) It evolves with the system concept & design, (3) It is composed of all products that constitute a system &, thus, is an apt means to identify all the technologies used by a system, (4) It relates to the functional architecture &, therefore, to the environment in which the system is intended to be employed, (5) It reflects the system design/architecture & the environment & performance envelope for each product in the system, (6) It increases in specificity during development, thereby allowing old CTEs to be updated & new CTEs to be identified.

► The length of the TWBS should be as long as necessary & represent an exhaustive listing of the decomposed existing or conceptual threshold compliant baseline HW & SW design configuration elements (i.e., systems, subsystems, components & devices).

► The TWBS should decompose the design to the lowest level of indenture necessary to conclusively show that the system/subsystem is or is not a CTE by itself (as an integrated product) & that there is or is not a lower level technology component of the system/subsystem that dictates the system is a CTE .

► Do not separate the TWBS into separate HW & SW sections. Instead, embed the SW in its associated system/subsystem items.

► Include a row for anti-tamper (AT), if applicable. If it needs to be addressed in a separate forum, identify it as such. Likewise, for any other potentially classified items state that a separate forum is required.

► It is assumed that what is listed in the TWBS spreadsheet constitutes a threshold compliant design & it is part of the program of record (POR).

Operational Environment Description ► Describe here the CONOPS & what constitutes a relevant environment for your system, & the operational environmental boundaries for your system.

► Operational performance requirements highlighting KPPs in general, & those operational requirements that will be directly influenced by the potential CTEs to be assessed.

► Generally, the requirement statement for your system will provide some description of the environment in which the system is expected/required to operate. This environment can be called the external or imposed environment. It may be natural or man-made, friendly or hostile (e.g., weather, terrain, friendly & hostile jamming, enemy fire, & so forth). Another environment — the one generally more important for identifying & evaluating CTEs — can be called the internal or realized environment. It is derived from the performance required of each design item (product, subsystem, component, TWBS element). Your design analysis should include the required or expected performance envelope & conditions for each TWBS (or system architecture & SW architecture) element.

► Overall system architecture highlighting the CTE system / subsystem elements that will be assessed.

► Include a picture of the overall System / Subsysten Architecture.

► Include a chart on the associated technology-related risks.

ELEMENT (TE)

► If more dollars, human resources, or schedule could be applied all within the Program of Record constraints to solve a technology limitation it is most likely not a CTE.

(2) this TE or its application is either new or novel in an area that poses major technological risk during detailed design or demonstration.]

Some example questions to ask when trying to identify the CTEs for aircraft development are as follows:

► Aerodynamic Configuration. Does the design incorporate a configuration that has not been used in flight? How similar is the configuration to that of A/C that are successful? Does the configuration impose limitations on control authority, stability, structural rigidity, or strength? Is stability acceptable at high angles of attack? Are stability & control acceptable during configuration changes in flight?

► Flight Performance. Is the lift-to-drag (L/D) ratio being used in range calculations consistent with that being achieved by operating aircraft? Has this L/D ratio been confirmed by wind tunnel tests corrected to full-scale, trimmed conditions? Are takeoff & landing distances based on achievable lift coefficients & installed thrust? ► Control. How is the A/C controlled & how does it interact with the operator? How much autonomy is it required to have? Can it operate without human intervention? Are there safety concerns in autonomous modes?

► Airframe Structure & Weight. Is the structural weight fraction consistent with operating A/C of the same type? Are lower fractions justified by use of more efficient materials or structural designs? Do the materials & structures have stiffness & fatigue properties suitable to the application & has this capability been demonstrated with full-scale sections & representative loads?

► Propulsion. Do the engine hot sections rely on new materials? Have these materials been tested to the temperatures, loads, & dynamic environment of expected flight? Are the results for thrust & specific fuel consumption (SFC) from ground tests consistent with the estimates? Have the inlets been tested at flight flow rates?

► Rotors & Hubs. Has the rotor type been used before in a similar application? Has testing been limited to static conditions? Has a similar type of rotor been tested at a relevant scale? What is the test basis for the durability estimates for the rotor & hub? Do the cyclic & collective control mechanisms differ from common practice? How have they been tested?

► Mission Equipment. The appropriate questions differ greatly for the different roles aircraft play. Advanced technology might be incorporated in weapon carriage & employment, in cargo handling, in surveillance, in communications, & elsewhere.

General questions include the following: What limits the operational effectiveness of this design? How is advanced technology contributing to more effective performance of the aircraft mission? Are any of these technologies unproven in this application? What requirements for the aircraft program depend on mission payloads? Are the requirements for the payload consistent with those of the aircraft platform?

Missiles & Guided Weapons System The development program for a missile or other guided weapon is quite different from that of a “platform” vehicle, & the program for a solid propellant rocket is different from that of a liquid propellant rocket. Most military missiles have structure, propulsion, guidance, flight control, & payload. Each of these systems comprises numerous elements that must function together to meet the objectives of the system, & any of these elements can depend upon CTEs. To assess the maturity of these critical technologies, issues that should be considered in performance demonstrations include how the test environments compare with the real environments & how the performance exposes what is req'd.

Missile structural integrity & flight control are highly interdependent. Structural bending modes, placement of accelerometers, control system time constants, aerodynamic loads & control moments, & reaction controls must work together to achieve stable, controlled flight. Structural rigidity & inertial properties can 1st be computed during computer-aided design (CAD) & confirmed by ground tests. Aerodynamics can be determined by analysis & wind tunnel tests. High-fidelity, 6 degree of freedom (DOF) simulations can represent the complete missile in its intended flight environment.

Components that are tested in HW-in-the-loop (HWIL) simulations can reasonably be considered to be TRL 4. If we assume that flight accelerations & vibrations are important to the functioning of a component, testing that component while it is carried on a surrogate missile could achieve TRL 5. After the components have been integrated into a dynamically correct prototype missile and are flown, perhaps on a flight with preprogrammed maneuvers, the components can be considered TRL 6 if the environment is relevant for those components.

Missile guidance systems can include a variety of sensor types. Several types of test environments are useful for particular types of sensors. These include anechoic chambers for radars & other radio frequency (RF) systems, terrain tables for visual & infrared (IR) detectors, towers overlooking tactical targets, captive carry on A/C & missiles, & free-flight. The maturity associated with these sensors depends on the fidelity of the relevant features of the environment & the fidelity of the test article when compared with the final product. If a tower can provide the correct viewpoint & range to a target & if motion is not important, perhaps a tower test of a prototype sensor can be adequate to assess TRL 5. However, if motion is important, a captive carry test might be necessary to achieve TRL 5. Since motion is almost always important to missile guidance systems, captive carry for TRL 5 & demo on a prototype or surrogate missile for TRL 6 are suggested as the norms.

For liquid fuel rockets, different items are important. Movement & metering of fuel & oxidizer are considerations, & throttling or multiple starts & cooling of the nozzle with fuel might be factors. Relevant conditions can include very low ambient pressures & longitudinal & lateral accelerations that can be achieved only in flight.

Air-breathing rockets have the add'l needs to establish inlet performance & flammability limits over a wide range of Mach #s & ambient pressures. Demos can include connected tests (inlet connected to an air source) to merit TRL 4 & free-flow tests including inlet, captive-carry, & free-flight tests to merit TRLs of 5, 5, & 6, respectively, if the test articles of the free-flight tests are functionally representative prototypes.

Some example questions to ask when trying to identify the CTEs for missile development are as follows:

► Guidance & Control. Has the type of guidance under consideration been used before? If so, was it successful in the similar application? Do the field of view (FOV), field of regard (FOR), scan rate, slew rate, sensitivity, acuity, or any other performance parameters exceed what has been achieved in affordable guidance systems? Has the guidance system been tested in prototype form? Has it been tested from a tower, in captive carry, or in flight? Has it been tested against realistic targets in realistic environments? Are the sensor range & the missile control time constant compatible with the dynamics of the end game?

► Propulsion & Structure. Is there a propellant that can meet the specific impulse requirement & have acceptable safety characteristics, burn rates, physical characteristics, & cost? What size batches of this propellant have been made? What size test motors have been fired? Has the combo of case, insulation, grain support, & grain configuration ever been used in a rocket motor? Does the design have any special features (e.g., multiple burn, throttling, air-burning, case-consuming, throatlessness)?

► General Questions (particularly for COTS products). Does this CTE claim to implement standards that provide critical functionality? How was the compliance to these standards verified? Is there familiarity with the element from other projects? How is the commercial use of this CTE different from the DoD use? Will this CTE work in large-scale environments such as the DoD GIG? What aspects of the system design are dependent on unique features or particular versions of the CTE? Will these unique features be sustained in future versions of the CTE? Will this CTE be modified, tailored, extended, or enhanced from its original state? Who will perform these modifications? How complex are these mods? What version of this CTE has been tested? Is this the same version that will enter production? Does this CTE depend on other systems? Does the CTE conform with the required size, weight, & power (SWAP) requirements?

► Terminal Hardware. Terminal HW consists of video displays, audio/ sound systems, keyboards, touch-screen terminals, personal digital assistants (PDAs) & so forth.

Are there extenuating physical environment considerations for size, weight, visibility in daylight, or usability? ► Processing Hardware. Processing HW consists of processors, memory, servers, supercomputers, mainframes, blade servers (self-contained, all-inclusive computer servers with a design optimized to minimize physical space), & so forth. Are needed SW development environments supported? Have any significant changes been made to the operating system & other systems SW? Are processors able to handle average & peak processing loads? How does needed processing power scale with the number of users?

► Storage Hardware. Storage HW consists of disk drives, magnetic tapes, redundant array of inexpensive disks (RAID), controllers, & so forth. Is the storage media new? How is storage being connected to the processing hHW? Is storage balanced with processing capacity? How will storage scale with increasing processing capacity?

► Networking Hardware. Networking HW consists of routers, switches, access points, network interface cards (NICs), local area network/wide area network (LAN/WAN) components, storage area network (SAN) components, & so forth. Do requirements for bandwidth, delay, jitter, loss, & availability imply that new or modified HW is required? Is wireless performance acceptable in the expected electromagnetic environment? Is the network able to grow in physical size & bandwidth while still satisfying key performance requirements?

Networked Communications & Data Management Systems Some example questions to ask when trying to identify the CTEs for networked communications & data management systems are as follows:

► Do the requirements for throughput, data latency, jitter, loss, security, or reliability imply that a new or novel technology is required? Have the network routers been used before within the required performance envelope? Are new or novel media access control, coding, or routing algorithms needed? Is the multiplexing schema new? Is the topology (logical & HW) new? Do the peak & average data rates require new HW or algorithms in the system?

► If the network includes wireless technology, have the wireless devices been used previously in the anticipated electromagnetic environment? Does the way in which data sources or uses interface to the network imply a need for a new interface (logical or HW)? Does the ICD identify any interfaces that are new or novel? ► If the network includes commercially available elements, such as Asynchronous Transfer Mode (ATM) & optical components, have these elements been demonstrated for their intended use? Do they support the data rates, switching schema, routing, & any other needed performance?

► Do the DoD information assurance (IA) requirements create a new or novel security environment? Is the CTE relying on other systems to provide security functions? Do DoD IA requirements & regulations place requirements on this CTE because of its interfaces with other systems?

► Do requirements for scalability & the capability to upgrade imply the need for new algorithms? Does the scale of the system imply a new environment for the network?

Mission Planning Systems Mission Planning Systems often include a combination of COTS/GOTS SW & developmental SW to integrate SW systems. Usually for these systems, the components are mature in their original environment. What needs to be determined is how the newly integrated environment differs.

Some example questions to ask when trying to identify the CTEs for mission planning systems are as follows: ► Are there new logical or data relationships for each component? Are the algorithms used to create interfaces new or novel? Are new HW components needed to enable interoperability?

► Do the information exchange requirements (IERs) require many more interfaces than previously achieved? Does this imply a new logical or security environment?

► Will the components run on a new HW system? On a new network?

► Will the need to upgrade the components introduce new algorithms or technologies?

Embedded IT in Tactical Systems The Embedded IT or SW in Tactical Systems is often inextricably linked to the requirements & performance of the developmental HW. However, the developmental responsibility for HW & SW may be separate.

Some example questions to ask when trying to identify the CTEs for embedded IT in tactical systems are as follows:

► How does the performance of the HW rely on the IT, & vice versa?

► Can the requirements be clearly mapped to those met with HW & those met with SW?

► Have the algorithms been proven to work in a simulated environment? How is that environment different from the operational environment? ► Do the data dissemination requirements imply a new or novel technology or environment?

► Does timeliness imply new or novel algorithms or HW? Does the quality of the data (e.g., engagement quality) imply special processing that has not been done previously?

► Does the tactical system have an interface with non-tactical systems that have significantly different performance requirements?

► Are the number of SW systems or lines of code unprecedented? Do the IERs imply a new or novel technology?

► Does the IT provide a degree of autonomy? Is the decision tree well characterized? Should other approaches to autonomy be considered?

or GOTS ► If a technology is COTS (commercial off-the-shelf) or GOTS (gov't off-the-shelf) it may or may not be a CTE.

► A COTS product is one that is used unmodified "as-is" off-the-shelf & if so, then it should have a production part # that is required to substantiate maturity. COTS products are designed to be easily installed & to interoperate with existing system components. For example, almost all SW bought by the average computer user fits into the COTS category (operating systems, office product suites, word processing, & e-mail programs). One of the major advantages of COTS SW, which is mass-produced, is its relatively low cost.

► A GOTS product is typically developed by the technical staff of the gov't agency for which it is created. It is sometimes developed by an external entity, but with funding & spec from the agency. Because agencies can directly control all aspects of GOTS products, these are generally preferred for gov't purposes.

► The "environment" in which the technology will be used is important & key to determining if the "COTS or GOTS" is a CTE. ► The question to consider is was the identified COTS or GOTS designed to perform in the extreme conditions associated with a Naval aviation environment & this program's intended relevant (lab) & operational (field) environment?

► Identify whether or not the intended relevant & operational environment the COTS or GOTS product will be required to perform in is within the scope of the COTS or GOTS original design?

► Provide evidence that this COTS item has been previously installed on the intended platform…