Technology Readiness Assessment (TRA)

Slides:



Advertisements
Similar presentations
Willie J. Fitzpatrick, PhD Chief, Aviation Division
Advertisements

Technology Module: Technology Readiness Levels (TRLs) Space Systems Engineering, version 1.0 SOURCE INFORMATION: The material contained in this lecture.
Technology readiness levels in a nutshell
What Is A Technical Readiness Level and How Is It Used?
Technology Readiness (TR)
Technology Readiness Level Calculator NDIA Systems Engineering Conference October 20, 2003 William L. Nolte, P.E., CQE Sensors Directorate Air Force Research.
Jack Taylor Office of the Deputy Assistant Secretary of
Measuring Technology Maturity Actual system “flight proven” through successful mission operations Actual system completed and “flight qualified” through.
“Common Process for Developing Briefings for Major Decision Points” INSTRUCTIONS Provide Feedback via to: Lois Harper PEO C4I and Space
About Us Vision: A national center for new imaging detectors. Mission: To design, develop, and implement new advanced sensor technologies in collaboration.
What are MRLs ? Alfred W. Clark Dawnbreaker, Inc.
EMIS 7307 T&E Part 2 1 Documents in flux. MNS - Mission need statement –Non system specific, a needed capability. Being replaced by Initial Capabilities.
Technology Input Formats and Background Appendix B.
Why is BCL Needed? BCL addresses long-standing challenges that have impacted the delivery of business capabilities The DepSecDef directed increasing the.
Liviu LAZAR IS - Staff Officer NIAG Guyonne Le Fournis
* Backup materials can be found at
Andrew Faulkner1 Technology Readiness Levels 4 th SKADS Workshop, Lisbon Technology Readiness Levels TRLs Andrew Faulkner.
New 5000 Documents 14 May 2001 New 5000 Documents 14 May 2001 Defense Systems Management College Acquisition Policy Department.
Ocean Observatories Initiative OOI Cyberinfrastructure Architecture Overview Michael Meisinger September 29, 2009.
The Center for Space Research Programs CSRP Technology Readiness Level.
Page 1 of 11 Progress developing an evaluation methodology for fusion R&D ARIES Project Meeting March 4, 2008 M. S. Tillack.
1 MRL Assist Tool Website Access the MRL Assist Tool at
Verification and Validation — An OSD Perspective — Fred Myers Deputy Director, Test Infrastructure Test Resource Management Center November 4, 2009.
Lecture 2.1b: DoD Acquisition Process (SEF Ch 2)
Cross fertilisation Technology readiness level From Space and Aeronautic to ITS ? 11/06/2014Topos proposal done by JPhM1.
045-05/rs PERSISTENT SURVEILLANCE FOR PIPELINE PROTECTION AND THREAT INTERDICTION Technical Readiness Level For Control of Plasma Power Flux Distribution.
MB6025-MB7226 TECHNOLOGY COMMERCIALIZATION
Assessment of Fusion Development Path: Initial Results of the ARIES “Pathways” Program Farrokh Najmabadi UC San Diego ANS 18 th Topical Meeting on the.
 CMMI  REQUIREMENT DEVELOPMENT  SPECIFIC AND GENERIC GOALS  SG1: Develop CUSTOMER Requirement  SG2: Develop Product Requirement  SG3: Analyze.
SAS_08_Legacy_Safety_Hill Assurance and Recertification of Safety Critical Software In Legacy Systems Janie Hill NASA Kennedy Space Center, Florida
Horizon 2020 – 2016 Transport Call
Cross-Domain Semantic Interoperability ~ Via Common Upper Ontologies ~ Presentation to: Expedition Workshop #53 15 Aug 2006 James Schoening
GAO’s Cost and Schedule Assessment Guides U.S. Government Accountability Office Applied Research and Methods Cost Engineering Sciences Jason T Lee, Assistant.
EIAScreening6(Gajaseni, 2007)1 II. Scoping. EIAScreening6(Gajaseni, 2007)2 Scoping Definition: is a process of interaction between the interested public,
Dr. Thomas D. Fiorino November 2002
Lesson Objectives Determine the major requirements management activities during the acquisition process from Milestone A to Milestone B Explain the purpose.
DoD Template for Application of TLCSM and PBL
Lesson Objectives Determine the major requirements management activities during the acquisition process from Milestone A to Milestone B Explain the purpose.
DT&E Strategy and the Developmental Evaluation Framework (DEF) Concept & Program Implementation 5 June 2014.
MNS - Mission need statement
Competitive Prototyping – the New Reality
Lesson Objectives Assess the major requirements management activities during the acquisition process from Milestone B to Initial Operational Capability.
National Defense Industrial Association
ISA 201 Intermediate Information Systems Acquisition
Fundamentals of a Vocational Assessment
Milestone A to Milestone B Requirements Management Activities
Milestone A to Milestone B Requirements Management Activities
Milestone A to Milestone B Requirements Management Activities
Milestone A to Milestone B Requirements Management Activities
Cumulative IOT&E Results Through FY 2008
ISA 201 Intermediate Information Systems Acquisition
ISA 201 Intermediate Information Systems Acquisition
Flooding Walkdown Guidance
Concept Idea Title Summary of the effort to include:
Milestone A to Milestone B Requirements Management Activities
The Open Group Architecture Framework (TOGAF)
MRL 6 Artifacts (at End of TMRR) Page 1 of 6
EMIS 7307 Chapter 6.
About Us Vision: A national center for new imaging detectors.
BASIC IRRS TRAINING Lecture 6
USNRC IRRS TRAINING Lecture 12
US/Japan Workshop on Fusion Power Plant Studies
Principal Investigator ESTCP Selection Meeting
MECH 3550 : Simulation & Visualization
Building Valid, Credible, and Appropriately Detailed Simulation Models
TRL tables: power conversion and lifetime
What Is A Technical Readiness Level and How Is It Used?
G. Technology Readiness Levels (TRL*)
Principal Investigator ESTCP Selection Meeting
Presentation transcript:

Technology Readiness Assessment (TRA) DoD Requires all Major Defense Acquisition Programs to conduct a TRA prior to Engineering and Manufacturing Development (Milestone B) for review by ASD(R&E) DoD uses the TRA as the basis for certification to Congress MDAs for all programs are required to ensure that technology risk has been reduced to acceptable levels prior to entering engineering development ACAT II-IV programs should conduct TRAs by tailoring the TRA Guidance TRA Definition: Systematic, metrics-based process and accompanying report Assesses the maturity of critical technologies used in systems Uses Technology Readiness Level (TRL) as the metric Adequate maturity at MS B (TRL 6 or greater) is largely based on experience with prototypes or previous usage in a relevant environment Report includes how the critical technologies are identified, why critical technologies are important to the program, and an independent (from the program) assessment of their maturity Definition: Systematic, metrics-based process and accompanying report Assesses the maturity of Critical Technology Elements (CTEs) used in systems Uses Technology Readiness Levels (TRLs) as the metric Adequate maturity at MS B (TRL 6 or greater) is largely based on experience with prototypes or previous usage in a relevant environment Report includes how the CTEs are identified, why CTEs are important to the program, and an independent (from the program) assessment of their maturity Purpose: To surface data, assess information relevant to maturity of CTEs in acquisition programs Assessment does not predict future TRA is not a risk assessment or a design review Does not address system integration or imply that the technology is right for job 11 May USD AT&L memo “Improving Technology Readiness Assessment Effectiveness”

Technology Readiness Assessment (TRA) TRA assesses the maturity of critical technologies Uses Technology Readiness Level (TRL) as the metric Adequate maturity at MS B (TRL 6 or greater) is largely based on experience with prototypes or previous usage in a relevant environment New TRA guidance (April 2011 and May 2011) – Docs are on student CD-ROM (in “Technical Reviews” folder) TRAs are now conducted & reported by the PM, using SMEs as appropriate MDAPs must conduct a TRA prior to MS B, for review by ASD(R&E) All programs - must insure that technology risk has been reduced to acceptable levels prior to entering EMD ACAT II-IV programs should conduct TRAs by tailoring the TRA Guidance TRA Report includes: how the critical technologies are identified, why critical technologies are important to the program, and an independent (from the program) assessment of their maturity TRAs used to be conducted & reported by the science & technology community (SMEs). TRAs used to be required for all programs (all ACAT levels), with critical technology elements. TRA Definition: Systematic, metrics-based process and accompanying report Assesses the maturity of Critical Technology Elements (CTEs) used in systems Uses Technology Readiness Levels (TRLs) as the metric Adequate maturity at MS B (TRL 6 or greater) is largely based on experience with prototypes or previous usage in a relevant environment Report includes how the CTEs are identified, why CTEs are important to the program, and an independent (from the program) assessment of their maturity Purpose: To surface data, assess information relevant to maturity of CTEs in acquisition programs Assessment does not predict future TRA is not a risk assessment or a design review Does not address system integration or imply that the technology is right for job

TRA Execution Program identifies the critical technologies in the context of the program’s systems engineering process, based on a comprehensive review of the most current system performance and technical requirements and design and the program’s established technical work breakdown structure. Data concerning the performance of the critical technologies are collected and presented to reviewers independent from the program and expert in the technologies Independent reviewers assess maturity of critical technologies against established TRL metrics PM prepares report and sends through PEO to the Component Acquisition Executive or Agency Head, who then transmits it to ASD(R&E) ASD(R&E) reviews TRA plan and recommends any changes then provides the MDA an independent assessment and review concerning whether the technology in the program has been demonstrated in a relevant environment A waiver by the MDA is possible, but this waiver must be based on acceptable means of risk mitigation, such as inclusion of an alternative more mature technology ASD(R&E) TRA Guidance, April 2011 Self Explanatory

Technology Readiness Assessment (Template) 1.0 Purpose of Document 2.0 Executive Summary 3.0 Program Overview 3.1 Program Objective 3.2 Program Description 3.3 System Description 4.0 Technology Risks Summary and Readiness Assessment 4.1 Process Description 4.2 Identification of Technologies Assessed 4.3 Assessment of Risks and Demonstration in a Relevant Environment 4.3.1 First Technology 4.3.2 Next Technology 5.0 Summary NOTE: Outline taken from TRA Desk Book ASD(R&E) TRA Guidance, April 2011

From Technology Readiness Assessment Guidance, ASD (R&E), 13 May 2011 TRL Definitions TRL Definition Description Supporting Info. 1 Basic principles observed and reported. Lowest level of technology readiness. Scientific research begins to be translated into applied research and development (R&D). Examples might include paper studies of a technology’s basic properties. Published research that identifies the principles that underlie this technology. References to who, where, when. 2 Technology concept and/or application formulated. Invention begins. Once basic principles are observed, practical applications can be invented. Applications are speculative, and there may be no proof or detailed analysis to support the assumptions. Examples are limited to analytic studies. Publications or other references that out-line the application being considered and that provide analysis to support the concept. From Technology Readiness Assessment Guidance, ASD (R&E), 13 May 2011

TRL Definitions TRL Definition Description Supporting Info. 3 Analytical and experimental critical function and/or characteristic proof of concept. Active R&D is initiated. This includes analytical studies and laboratory studies to physically validate the analytical predictions of separate elements of the technology. Examples include components that are not yet integrated or representative. Results of laboratory tests performed to measure parameters of interest and comparison to analytical predictions for critical subsystems. References to who, where, and when these tests and comparisons were performed. 4 Component and/or breadboard validation in a laboratory environment. Basic technological components are integrated to establish that they will work together. This is relatively “low fidelity” compared with the eventual system. Examples include integration of “ad hoc” hardware in the laboratory. System concepts that have been considered and results from testing laboratory-scale breadboard(s). References to who did this work and when. Provide an estimate of how breadboard hardware and test results differ from the expected sys-tem goals.

TRL Definitions TRL Definition Description Supporting Info. 5 Component and/or breadboard validation in a relevant environment. . Fidelity of breadboard technology increases significantly. The basic technological components are integrated with reasonably realistic supporting elements so they can be tested in a simulated environment. Examples include “high-fidelity” laboratory integration of components. Results from testing laboratory breadboard system are integrated with other supporting elements in a simulated operational environment. How does the “relevant environment” differ from the expected operational environment? How do the test results compare with expectations? What problems, if any, were encountered? Was the breadboard system refined to more nearly match the expected system goals?

TRL Definitions TRL Definition Description Supporting Info. 6 System/subsystem model or prototype demonstration in a relevant environment. Representative model or prototype system, which is well beyond that of TRL 5, is tested in a relevant environment. Represents a major step up in a technology’s demonstrated readiness. Examples include testing a prototype in a high-fidelity laboratory environment or in a simulated operational environment. Results from laboratory testing of a proto-type system that is near the desired con-figuration in terms of performance, weight, and volume. How did the test environment differ from the operational environment? Who performed the tests? How did the test compare with expectations? What problems, if any, were encountered? What are/were the plans, options, or actions to resolve problems before moving to the next level? From Technology Readiness Assessment Guidance, ASD(R&E), 13 May 2011 Complete list at end of lesson

TRL Definitions TRL Definition Description Supporting Info. 6 System/subsystem model or prototype demonstration in a relevant environment. Representative model or prototype system, which is well beyond that of TRL 5, is tested in a relevant environment. Represents a major step up in a technology’s demonstrated readiness. Examples include testing a prototype in a high-fidelity laboratory environment or in a simulated operational environment. Results from laboratory testing of a proto-type system that is near the desired con-figuration in terms of performance, weight, and volume. How did the test environment differ from the operational environment? Who performed the tests? How did the test compare with expectations? What problems, if any, were encountered? What are/were the plans, options, or actions to resolve problems before moving to the next level?

TRL Definitions TRL Definition Description Supporting Info. 7 System prototype demonstration in an operational environment. Prototype near or at planned operational system. Represents a major step up from TRL 6 by requiring demonstration of an actual system prototype in an operational environment (e.g., in an air-craft, in a vehicle, or in space). Results from testing a prototype system in an operational environment. Who per-formed the tests? How did the test com-pare with expectations? What problems, if any, were encountered? What are/were the plans, options, or actions to resolve problems before moving to the next level?

TRL Definitions TRL Definition Description Supporting Info. 8 Actual system completed and qualified through test and demonstration. Technology has been proven to work in its final form and under expected conditions. In almost all cases, this TRL represents the end of true system development. Examples include developmental test and evaluation (DT&E) of the system in its intended weapon system to deter-mine if it meets design specifications. Results of testing the system in its final configuration under the expected range of environmental conditions in which it will be expected to operate. Assessment of whether it will meet its operational requirements. What problems, if any, were encountered? What are/were the plans, options, or actions to resolve problems before finalizing the design? 9 Actual system proven through successful mission operations. Actual application of the technology in its final form and under mission conditions, such as those encountered in operational test and evaluation (OT&E). Examples include using the system under operational mission conditions. OT&E reports.