Technology readiness level
Technology Readiness Levels (TRL) are a method of estimating technology maturity of Critical Technology Elements (CTE) of a program during the acquisition process. They are determined during a Technology Readiness Assessment (TRA) that examines program concepts, technology requirements, and demonstrated technology capabilities. TRL are based on a scale from 1 to 9 with 9 being the most mature technology. The use of TRLs enables consistent, uniform, discussions of technical maturity across different types of technology. A comprehensive approach and discussion about TRLs has been published by the EARTO.[1]
Contents
Definitions
Different definitions are used. Although they are conceptually similar, significant differences exist in terms of maturity at a given technology readiness level.
U.S. Department of Defense (DoD) definitions
| Technology readiness level | Description | Supporting information |
|---|---|---|
| 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 outline the application being considered and that provide analysis to support the concept. |
| 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 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 system goals. |
| 5. Component and/or breadboard validation in 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? |
| 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 prototype system that is near the desired configuration 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? |
| 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 aircraft, in a vehicle, or in space). | Results from testing a prototype system in an 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? |
| 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 determine 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 (operational test and evaluation) reports. |
Related DoD definitions
The DoD uses similar definitions for the following specialized areas:
- Software Technology Readiness Levels[3]
- Biomedical Technology Readiness Levels
- Manufacturing Readiness Level
NASA definitions
| Technology readiness level | Description |
|---|---|
| 1. Basic principles observed and reported | This is the lowest "level" of technology maturation. At this level, scientific research begins to be translated into applied research and development. |
| 2. Technology concept and/or application formulated | Once basic physical principles are observed, then at the next level of maturation, practical applications of those characteristics can be 'invented' or identified. At this level, the application is still speculative: there is not experimental proof or detailed analysis to support the conjecture. |
| 3. Analytical and experimental critical function and/or characteristic proof of concept | At this step in the maturation process, active research and development (R&D) is initiated. This must include both analytical studies to set the technology into an appropriate context and laboratory-based studies to physically validate that the analytical predictions are correct. These studies and experiments should constitute "proof-of-concept" validation of the applications/concepts formulated at TRL 2. |
| 4. Component and/or breadboard validation in laboratory environment | Following successful "proof-of-concept" work, basic technological elements must be integrated to establish that the "pieces" will work together to achieve concept-enabling levels of performance for a component and/or breadboard. This validation must be devised to support the concept that was formulated earlier, and should also be consistent with the requirements of potential system applications. The validation is "low-fidelity" compared to the eventual system: it could be composed of ad hoc discrete components in a laboratory. |
| 5. Component and/or breadboard validation in relevant environment | At this level, the fidelity of the component and/or breadboard being tested has to increase significantly. The basic technological elements must be integrated with reasonably realistic supporting elements so that the total applications (component-level, sub-system level, or system-level) can be tested in a 'simulated' or somewhat realistic environment. |
| 6. System/subsystem model or prototype demonstration in a relevant environment (ground or space) | A major step in the level of fidelity of the technology demonstration follows the completion of TRL 5. At TRL 6, a representative model or prototype system or system - which would go well beyond ad hoc, 'patch-cord' or discrete component level breadboarding - would be tested in a relevant environment. At this level, if the only 'relevant environment' is the environment of space, then the model/prototype must be demonstrated in space. |
| 7. System prototype demonstration in a space environment | TRL 7 is a significant step beyond TRL 6, requiring an actual system prototype demonstration in a space environment. The prototype should be near or at the scale of the planned operational system and the demonstration must take place in space. |
| 8. Actual system completed and 'flight qualified' through test and demonstration (ground or space) | In almost all cases, this level is the end of true 'system development' for most technology elements. This might include integration of new technology into an existing system. |
| 9. Actual system 'flight proven' through successful mission operations | In almost all cases, the end of last 'bug fixing' aspects of true 'system development'. This might include integration of new technology into an existing system. This TRL does not include planned product improvement of ongoing or reusable systems. |
ESA definition
Instruments and spacecraft sub-systems are classified according to a "Technology Readiness level" (TRL) on a scale of 1 to 9. Levels 1 to 4 relate to creative and innovative technologies before or during the mission assessment phase. Levels 5 to 9 relate to existing technologies and to missions in definition phase.
| Technology Readiness Level | Description |
|---|---|
| TRL 1. | Basic principles observed and reported |
| TRL 2. | Technology concept and/or application formulated |
| TRL 3. | Analytical & experimental critical function and/or characteristic proof-of-concept |
| TRL 4. | Component and/or breadboard validation in laboratory environment |
| TRL 5. | Component and/or breadboard validation in relevant environment |
| TRL 6. | System/subsystem model or prototype demonstration in a relevant environment (ground or space) |
| TRL 7. | System prototype demonstration in a space environment |
| TRL 8. | Actual system completed and "Flight qualified" through test and demonstration (ground or space) |
| TRL 9. | Actual system "Flight proven" through successful mission operations |
If the TRL is too low, then a mission risks being jeopardized by delays or cost over-runs. It is a responsibility of the Advanced Studies and Technology Preparation Division to promote the technology readiness at a very early stage in order to make new missions feasible.
European Commission definition
| Technology Readiness Level | Description |
|---|---|
| TRL 1. | basic principles observed |
| TRL 2. | technology concept formulated |
| TRL 3. | experimental proof of concept |
| TRL 4. | technology validated in lab |
| TRL 5. | technology validated in relevant environment (industrially relevant environment in the case of key enabling technologies) |
| TRL 6. | technology demonstrated in relevant environment (industrially relevant environment in the case of key enabling technologies) |
| TRL 7. | system prototype demonstration in operational environment |
| TRL 8. | system complete and qualified |
| TRL 9. | actual system proven in operational environment (competitive manufacturing in the case of key enabling technologies; or in space) |
Oil & Gas Industry (API 17N)
The following definition is based on API recommended practice and is used in the oil and gas industry.[citation needed]
| Technology Readiness Level | Description |
|---|---|
| TRL 0 | Unproven idea/proposal Paper concept. No analysis or testing has been performed |
| TRL 1 | Concept demonstrated. Basic functionality demonstrated by analysis, reference to features shared with existing technology or through testing on individual subcomponents/subsystems. Shall show that the technology is likely to meet specified objectives with additional testing |
| TRL 2 | Concept validated. Concept design or novel features of design validated through model or small scale testing in laboratory environment. Shall show that the technology can meet specified acceptance criteria with additional testing |
| TRL 3 | New technology tested Prototype built and functionality demonstrated through testing over a limited range of operating conditions. These tests can be done on a scaled version if scalable |
| TRL 4 | Technology qualified for first use Full-scale prototype built and technology qualified through testing in intended environment, simulated or actual. The new hardware is now ready for first use |
| TRL 5 | Technology integration tested Full-scale prototype built and integrated into intended operating system with full interface and functionality tests |
| TRL 6 | Technology installed Full-scale prototype built and integrated into intended operating system with full interface and functionality test program in intended environment. The technology has shown acceptable performance and reliability over a period of time |
| TRL 7 | Proven technology Technology integrated into intended operating system. The technology has successfully operated with acceptable performance and reliability within the predefined criteria |
Other definitions and uses
The Canadian Innovation and Commercialization Program administered by Public Works and Government Services Canada provides assistance by awarding contracts to entrepreneurs with pre-commercial innovations, provided the innovation has a TRL between 7 and 9.[7]
The Federal Aviation Administration (FAA) references Technology Readiness Levels in some of their documents, and seems to rely on the NASA definitions.[8]
The United States Department of Energy (DOE) uses the following guidelines throughout the department in conducting Technology Readiness Assessments (TRAs) and developing Technology Maturation Plans (TMPs).
| Technology Readiness Level | Description |
|---|---|
| TRL 1. | Scientific research begins translation to applied R&D - Lowest level of technology readiness. Scientific research begins to be translated into applied research and development. Examples might include paper studies of a technology’s basic properties. |
| TRL 2. | 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. |
| TRL 3. | Active R&D is initiated - Active research and development is initiated. This includes analytical studies and laboratory studies to physically validate analytical predictions of separate elements of the technology. Examples include components that are not yet integrated or representative. |
| TRL 4. | Basic technological components are integrated - Basic technological components are integrated to establish that the pieces will work together. |
| TRL 5. | Fidelity of breadboard technology improves significantly - The basic technological components are integrated with reasonably realistic supporting elements so it can be tested in a simulated environment. Examples include “high fidelity” laboratory integration of components. |
| TRL 6. | Model/prototype is tested in 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 simulated operational environment. |
| TRL 7. | Prototype near or at planned operational system - Represents a major step up from TRL 6, requiring demonstration of an actual system prototype in an operational environment. |
| TRL 8. | Technology is proven to work - Actual technology completed and qualified through test and demonstration. |
| TRL 9. | Actual application of technology is in its final form - Technology proven through successful operations. |
Brief history of Technology Readiness Levels
Technology Readiness Levels were originally developed by NASA in the 1980s. The original definitions only included seven levels, which were later expanded to nine.[when?]
Original NASA TRL Definitions (1989)[10]
- Level 1 – Basic Principles Observed and Reported
- Level 2 – Potential Application Validated
- Level 3 – Proof-of-Concept Demonstrated, Analytically and/or Experimentally
- Level 4 – Component and/or Breadboard Laboratory Validated
- Level 5 – Component and/or Breadboard Validated in Simulated or Realspace Environment
- Level 6 – System Adequacy Validated in Simulated Environment
- Level 7 – System Adequacy Validated in Space
The TRL methodology was originated by Stan Sadin at NASA Headquarters in 1974.[11] At that time, Ray Chase was the JPL Propulsion Division representative on the Jupiter Orbiter design team. At the suggestion of Stan Sadin, Mr Chase used this methodology to assess the technology readiness of the proposed JPL Jupiter Orbiter spacecraft design.[citation needed] Later Mr Chase spent a year at NASA Headquarters helping Mr Sadin institutionalize the TRL methodology. Mr Chase joined ANSER in 1978, where he used the TRL methodology to evaluate the technology readiness of proposed Air Force development programs. He published several articles during the 1980s and 90s on reusable launch vehicles utilizing the TRL methodology.[12] These documented an expanded version of the methodology that included design tools, test facilities, and manufacturing readiness on the Air Force Have Not program.[citation needed] The Have Not program manager, Greg Jenkins, and Ray Chase published the expanded version of the TRL methodology, which included design and manufacturing.[citation needed] Leon McKinney and Mr Chase used the expanded version to assess the technology readiness of the ANSER team's Highly Reusable Space Transportation ("HRST") concept.[13] ANSER also created an adapted version of the TRL methodology for proposed Homeland Security Agency programs.[14]
The United States Air Force adopted the use of Technology Readiness Levels in the 1990s.[citation needed]
In 1995, John C. Mankins, NASA, wrote a paper[4] that discussed NASA’s use of TRLs and proposed expanded descriptions for each TRL. In 1999, the United States General Accounting Office produced an influential report[15] that examined the differences in technology transition between the DOD and private industry. It concluded that the DOD takes greater risks and attempts to transition emerging technologies at lesser degrees of maturity than does private industry. The GAO concluded that use of immature technology increased overall program risk. The GAO recommended that the DOD adopt the use of NASA's Technology Readiness Levels as a means of assessing technology maturity prior to transition. In 2001, the Deputy Under Secretary of Defense for Science and Technology issued a memorandum that endorsed use of TRLs in new major programs. Guidance for assessing technology maturity was incorporated into the Defense Acquisition Guidebook. Subsequently, the DOD developed detailed guidance for using TRLs in the 2003 DOD Technology Readiness Assessment Deskbook.
TRL assessment tools
A Technology Readiness Level Calculator was developed by the United States Air Force.[16] This tool is a standard set of questions implemented in Microsoft Excel that produces a graphical display of the TRLs achieved. This tool is intended to provide a snapshot of technology maturity at a given point in time.[17]
The Technology Program Management Model was developed by the United States Army.[18] The TPMM is a TRL-gated high-fidelity activity model that provides a flexible management tool to assist Technology Managers in planning, managing, and assessing their technologies for successful technology transition. The model provides a core set of activities including systems engineering and program management tasks that are tailored to the technology development and management goals. This approach is comprehensive, yet it consolidates the complex activities that are relevant to the development and transition of a specific technology program into one integrated model.[19]
Uses of technology readiness levels
The primary purpose of using Technology Readiness Levels is to help management in making decisions concerning the development and transitioning of technology. It should be viewed as one of several tools that are needed to manage the progress of research and development activity within an organization.[20]
Among the advantages of TRLs:[21]
- Provides a common understanding of technology status
- Risk management
- Used to make decisions concerning technology funding
- Used to make decisions concerning transition of technology
Some of the characteristics of TRLs that limit their utility:[21]
- Readiness does not necessarily fit with appropriateness or technology maturity
- A mature product may possess a greater or lesser degree of readiness for use in a particular system context than one of lower maturity
- Numerous factors must be considered, including the relevance of the products’ operational environment to the system at hand, as well as the product-system architectural mismatch
Current TRL models tend to disregard negative and obsolescence factors. There have been suggestions made for incorporating such factors into assessments.[22]
See also
References
- ↑ The TRL scale as a Research & Innovation Policy Tool
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ 4.0 4.1 Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ 21.0 21.1 Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
Online
- Presentation to the S&T Conference on the Transition of Technology to Acquisition, GAO, (26 October 1999)
- Joint Strike Fighter Acquisition – Mature Critical Technologies Needed to Reduce Risk, GAO-02-39 (October 2001)
External links
- DNV Recommended_Practices (Look for DNV-RP-A203)
- UK MoD Acquisition Operating Framework guide to TRL (requires registration)
