Penta Chart: the Penta Chart format is a one page summary of a technology proposal. NASA needs to review many concepts and technologies. Having a standard summary page which emphasizes the technical context of an idea is useful and helps NASA to review of many ideas quickly and efficiently. The Penta Chart format asks that a technology be described in terms of the problem/need it addresses and asks for a summary of the status quo in how the problem is addressed today. In the introduction and description of the idea, the Penta Chart asks for a description of the insight achieved which make this idea attractive. The proposer is asked to provide a description of the concept along with a summary of the benefits of its approach. If a development program is pursued, the Penta Chart format asks for the goals that would be achieved.

Quad Chart: the Quad Chart format is a traditional one page summary of a project. A Quad Chart asks for a brief description of the project, a statement about the potential benefit from the project, and description of the management approach of the project, and a summary of the cost and schedule for the project.

Suborbital Rocket: a vehicle, rocket-propelled in whole or in part, intended for flight on a suborbital trajectory, and the thrust of which is greater than its lift for the majority of the rocket-powered portion of its ascent.

Suborbital Trajectory: the intentional flight path of a launch vehicle, reentry vehicle, or any portion thereof, whose vacuum instantaneous impact point does not leave the surface of the Earth.

Key Decision Point (KDP): the event at which the Decision Authority determines the readiness of a program/project to progress to the next phase of the life cycle (or to the next KDP).

Guided technology: technology that meet high value strategic goals and critical needs

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.

Breadboard: 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.

Brassboard: 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.

Proto-type Unit: 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

Engineering Unit: 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.

Mission Configuration: 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.

Laboratory Environment: 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 solely for the purpose of demonstrating the underlying principles of technical performance (functions), without respect to the impact of environment.

Relevant Environment: 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.

Operational Environment: 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.

Web Accessibility and Privacy Notices Curator: Alexander van Dijk Responsible NASA Official: Stephan Ord Last Update: July 30, 2015