Attachment_L-6_TMSA_-_8_Dec_2016.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.

Relevant Environment Operational Environment Description A relevant environment is a testing environment that simulates both the most important & most stressing aspects of the operational environment. The operational environment includes all weather conditions, day & night-time operations in all USN TMS aircraft. The user must function in this environment with both LEP, Personnel Protective Equipment and helmet mounted displays and devices. Elements of a relevant environment also include the following:

. Curved surface . High humidity . High and Low temperature . Temperature shock . Salt fog environment . Solar radiation

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?