Effective Date: February 05, 2008
Expiration Date: February 05, 2018
|| TOC | ChangeHistory | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | AppendixK | AppendixL | ALL ||
TRL descriptions are in NPR 7123.1, NASA Systems Engineering Processes and Requirements.
Proof of Concept:
Analytical and experimental demonstration of hardware/software concepts that may or may not be incorporated into subsequent development and/or operational units.
A low fidelity unit that demonstrates function only, without respect to form or fit in the case of hardware, or platform in the case of software. It often uses commercial and/or ad hoc components and is not intended to provide definitive information regarding operational performance.
A medium fidelity functional unit that typically tries to make use of as much operational hardware/software as possible and begins to address scaling issues associated with the operational system. It does not have the engineering pedigree in all aspects, but is structured to be able to operate in simulated operational environments in order to assess performance of critical functions.
The proto-type unit demonstrates form, fit, and function at a scale deemed to be representative of the final product operating in its operational environment. A subscale test article provides fidelity sufficient to permit validation of analytical models capable of predicting the behavior of full-scale systems in an operational environment
A high fidelity unit that demonstrates critical aspects of the engineering processes involved in the development of the operational unit. Engineering test units are intended to closely resemble the final product (hardware/software) to the maximum extent possible and are built and tested so as to establish confidence that the design will function in the expected environments. In some cases, the engineering unit will become the final product, assuming proper traceability has been exercised over the components and hardware handling.
The final architecture/system design of the product that will be used in the operational environment. If the product is a subsystem/component, then it is embedded in the actual system in the actual configuration used in operation.
Not all systems, subsystems, and/or components need to be operated in the operational environment in order to satisfactorily address performance margin requirements. Consequently, the relevant environment is the specific subset of the operational environment that is required to demonstrate critical "at risk" aspects of the final product performance in an operational environment. It is an environment that focuses specifically on "stressing" the technology advance in question.
The environment in which the final product will be operated. In the case of space flight hardware/software, it is space. In the case of ground-based or airborne systems that are not directed toward space flight, it will be the environments defined by the scope of operations. For software, the environment will be defined by the operational platform.
An environment that does not address in any manner the environment to be encountered by the system, subsystem, or component (hardware or software) during its intended operation tests in a laboratory environment are soley for the purpose of demonstrating the underlying principles of technical performance (functions) without respect to the impact of environment.
| TOC | ChangeHistory | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | AppendixK | AppendixL | ALL |
|| NODIS Library | Program Formulation(7000s) | Search ||