(694b) Use of Technology Readiness Levels as a Development Tool

Technology Readiness Levels (TRLs) are a means to categorize the relative technical maturity of components, sub-systems, or systems. Technological or technical maturity is a measure of performance, reliability, durability, and operating experience, and more technologically mature components (better performing, more reliable, more durable, greater operating experience) are rated higher than experimental or prototype components or systems. In this definition, an understanding of the supporting terms is important, and those are also defined. Performance is the component's or system's ability to perform the task for which is intended. Reliability is a measure of how well the component or system is able to achieve the desired performance upon repeated use. Durability is the ability of the component to withstand stresses and wear without a degradation or failure in performance. Increased operating experience is correlated with higher technical maturity because it provides more data to support more accurate assessments of performance, reliability, and durability.

Various government agencies and research programs are now using TRLs to assess the technological maturity of components and systems in order to drive the technology development process. The National Aeronautics and Space Administration (NASA) and the U.S. Department of Defense (DoD) employ an integer rating system that spans from 1 to 9, with the lowest number corresponding to ?basic principles observed? and the highest number corresponding to ?mission proven.? The Next Generation Nuclear Plant (NGNP) Project is adopting the NASA and DoD systems to govern its work, while the DOE Nuclear Hydrogen Initiative (NHI) and the DOE Hydrogen Program, which is managed by the DOE Office of Energy Efficiency and Renewable Energy (EERE), are exploring systems that span 0 to 6 and 1 to 8, respectively.

By themselves, TRLs are abstractions that help facilitate the communication of complex ideas between developers and project stakeholders; that is, between scientists and engineers, who tend to be highly technical, and program managers and sponsors, who tend to be less technical. For example, instead of a developer discussing with a program sponsor whether the latest design of Device X is operating at 23% efficiency with a mean time between failures of 650 hours, a developer can instead reference a TRL in the discussion. Since a common understanding of what that TRL means in terms of performance, reliability, durability, and operating experience will have been previously established, less confusion would result. If there is only one component or system under development by the program, then the facilitation is moot, but it becomes much easier to use TRLs in such discussions rather than direct technical data when the number of components or systems under development is greater than just a few, and each component or system under development is designed for a different purpose.

Additional value is drawn from TRLs by virtue of the programmatic infrastructure needed to support the TRL assessment system. Assigning a TRL requires the establishment of an objective entry and assessment process, identification of expected component or system performance at each stage of development, and application of quality assurance processes to technical data and other supporting records. As a natural extension, such processes also almost automatically lead to the identification and generation of information that can be used to support intellectual property claims.

The use of TRLs is a risk reduction strategy. A component's or system's TRL is loosely correlated with the capital and operating cost required to perform a test in order to verify that a particular component or system is at a particular TLR. For example, it is usually cheaper to perform a test of a small prototype component in the laboratory in order to prove proof-of-principle than it is to perform long duration testing of a full-sized component an operational or plant environment. TRLs are also indicative of risk, and lower TRLs, due to lack of data or inherent design problems, are correlated with a higher probability of failure. In a development process, only successful tests lead to higher technical maturity, while failed tests either lead to lost investment or higher investment if tests must be repeated. Therefore, greater programmatic efficiencies (lower overall costs) may be realized if the capital and operating investment made into testing a component or system is scaled appropriately to the current and target TRLs.

Successful use of TRLs by a development program requires the sustained support of program management, and active management of the supporting processes.

In this presentation, existing TRL systems are discussed. The mechanics of managing and using a TRL system are described. Further details about how components, sub-systems, or systems may be initially assessed (the entry process) and promoted are provided. The importance of building development case files and maintaining records is highlighted. Also, a more thorough discussion of communications and risk is undertaken in order to highlight the advantages of using TRLs as a tool to help manage large technology development projects.