MEL - GeoXO Lightning Mapper-1.pdf

A H A A u

New Technology or Engineering Change Options

NT

EC

Identical

Heritage Level Options F P N

NA

Unit Type Definitions for MEL Additional definitions to support the Unit Type Definitions NPR 7120.8, Appendix J Definitions

Cold (Backup) Units

Cold Units and Hot Units are both flown, and the sum of units is the total Flight Units in Column F.

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.

Hot (Primary) Units

Cold Units and Hot Units are both flown, and the sum of units is the total Flight Units in Column F.

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.

Flight Units A Flight Unit is the actual model that will be launched. It either undergoes protoflight testing if a qualification model has not been tested, or it undergoes flight acceptance testing if a qualification model has been successfully tested. This total should include Engineering Test Units (ETU's), which will be fully flight qualified. This column includes everything planned for flight - the primary & backup flight units or ETU's. This includes flight units that must fly to provide redundancy (ie. hot or cold spares).

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.

Flight Spares A Flight Spare is a duplicate of either a component, subsystem, or the entire Flight Unit. Flight Spares are preassembled, tested and ready to swap with the corresponding Flight Unit, or they are spare flight-qualified parts ready for assembly and subsequent acceptance level testing when a need arises. Flight units that must fly to provide redundancy are NOT included in the flight spares column. The flight spares column includes hardware on the ground that is intended to replace a non-functioning flight item.

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 Test Unit (ETU) / Qual Unit

Engineering Test Units (ETUs) are flight-like qualification units that are tested to flight environmental levels. If your ETU should not be costed as like full flight spare, then discuss it in additional information or put it in the EM / EDU / Prototype column.

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.

Engineering Model (EM) / Engineering Demonstration (EDU) / Prototype Unit

Engineering Model (EM) and Engineering Demonstration Unit (EDU) are generally different names for the same model. These engineering units are flight-like in terms of fit, form, and functionality. They are used to reduce risk, or perform life-testing on parts that can degrade over time and/or with use, provided flight-like parts are used for life test unit.

A prototype is generally a non-flight like model that is used to demonstrate functionality early in the project. It is not used for environmental testing or flight qualification. Also known as “breadboard”.

Prototypes are included in the Engineering Model column

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.

N R C

P D

R D

N P R C

R O O C

R u y gy d v

D

O

W

V

V

R PR

Q N

N D

V V D O

V V W

U D O

O H D H

O P NC ND R R N O

Heritage Summary

Full Heritage Partial Heritage No Heritage Design Identical Minimal modifications Major modifications

Manufacture Identical Limited update of parts and processes necessary

Many updates of parts or processes necessary

Software Identical Identical functionality with limited update of f

Major modifications (>=50%)

Provider Identical provider and development team

Different however with substantial involvement of original team

Different and minimal or no involvement of original team

Use Identical Same interfaces and similar use within a novel overal context

Significantly different from original

Operating Environment

Identical Within margins of original

Significantly different from original

Referenced Prior UIn operation Built and successfully ground tested

Not yet successfully ground tested

1. The flight elements and components entered on each row should be traceable to block diagrams and heritage claims provided in other parts of the proposal. For each major component, current best estimates (CBE) and contingency for mass and power, number of flight units required, and some description of the heritage basis must be provided. Power values should represent nominal steady-state operational power requirements. Information to be provided includes identification of planned spares, indentification of engineering models and prototypes with their fidelities, required delieveries for simulatiors and testing, contingency allocations for individual components, and other component description/characteristics. Certain items should include additional details, sufficient to assess functionality and/or cost, to identify and separate individual elements.

2. List each electronic board separately, identify the functionality of each board (either in the MEL or in the proposal), and provide the operational speed of the board. If proposing Field-Programmable Gate Arrays (FPGAs) or Application Specific Integrated Circuits (ASICs), or Radio Frequency Integrated Circuits (RFICs), list the design size (in the appropriate sizing parameter such as number of logic cells or logic elements), the board that will include the chip(s), and how what amount of heritage will be used in the design.

MEL Supplemental Instructions:

Provide the following data for Software elements: (1) the number of logical lines of code by Computer Software Configuration Item (CSCI); (2) description of the functionality for each CSCI; (3) code counts categorized as either New, Modified, Full Reuse, or Auto-generated; (4) development method (spiral, waterfall, agile, etc.), and (5) development language

Instructions for software (can be included under the heading for HERITAGE JUSTIFICATION and ADDITIONAL INFORMATION)