NASA

Reference
Publication
1370

January 1997

Training Manual for Elements of Interface

Definition and Control

Vincent R. Lalli, Robert E. Kastner, and Henry N. Hartt

National Aeronautics and

Space Administration
Lewis Research Center
Cleveland, Ohio 44135
 NASA
Reference
Publication
1370

1997

Training Manual for Elements of Interface

Definition and Control

Vincent R. Lalli
Lewis Research Center
Cleveland, Ohio

Robert E. Kastner
Vitro Corporation
Rockville, Maryland

Henry N. Hartt
Vitro Corporation
Washington, DC

National Aeronautics and

Space Administration
Office of Management
Scientific and Technical
Information Program
 Preface
This technical manual was developed under the Office of Safety and Mission Assurance continuous
training initiative. The structured information contained in this manual will enable the reader to efficiently and
effectively identify and control the technical detail needed to ensure that flight system elements mate properly
during assembly operations (both on the ground and in space).
Techniques used throughout the Federal Government to define and control technical interfaces for both
hardware and software were investigated. The proportion of technical information actually needed to
effectively define and control the essential dimensions and tolerances of system interfaces rarely exceeded 50
percent of any interface control document. Also, the current Government process for interface control is very
paper intensive. Streamlining this process can improve communication, provide significant cost savings, and
improve overall mission safety and assurance.
The primary thrust of this manual is to ensure that the format, information, and control of interfaces
between equipment are clear and understandable, containing only the information needed to guarantee
interface compatibility. The emphasis is on controlling the engineering design of the interface and not on the
functional performance requirements of the system or the internal workings of the interfacing equipment.
Interface control should take place, with rare exception, at the interfacing elements and no further.
There are two essential sections of the manual. The first, Principles of Interface Control, discusses how
interfaces are defined. It describes the types of interface to be considered and recommends a format for the
documentation necessary for adequate interface control. The second, The Process: Through the Design Phases,
provides tailored guidance for interface definition and control.
This manual can be used to improve planned or existing interface control processes during system design
and development. It can also be used to refresh and update the corporate knowledge base. The information
presented herein will reduce the amount of paper and data required in interface definition and control processes
by as much as 50 percent and will shorten the time required to prepare an interface control document. It also
highlights the essential technical parameters that ensure that flight subsystems will indeed fit together and
function as intended after assembly and checkout.

NASA RP–1370 iii

This Page Intentionally Left Blank
This Page Intentionally Left Blank
 Contents
Chapter
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Principles of Interface Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Purpose of Interface Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Identifying Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Categorizing (Partitioning) and Defining Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.1 Electrical/Functional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.2 Mechanical/Physical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.4 Supplied Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Documenting Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Identifying Steady-State and Non-Steady-State Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6 Selecting a Custodian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.7 Analyzing for Interface Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.8 Verifying Design Compliance With Interface Control Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.9 Verifying Contract-Deliverable Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.10 Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3. The Process: Through the Design Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Program Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Concept Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2 Requirements Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.3 Systems Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Preparing and Administering Interface Control Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 Selecting Types of Interface Control Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2 Tracking and Resolving Missing Interface Design Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Initial Issuance of ICD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Document Review and Comment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.1 Resolving Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.2 Interface Control Working Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.3 Approval/Signoff Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.4 Technical Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.5 Baselining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5 Change Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.1 Initiating Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.2 Requesting Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5.3 Proposed Change Notice Review and Comment Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5.4 Processing Approved Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5.5 Distributing Approved Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5.6 Configuration Control Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5.7 Closing the Loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6 Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

NASA RP–1370 vi
 Appendixes:
A: Electrical/Functional Interface Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
B: Mechanical/Physical Interface Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
C: Software Interface Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
D: Supplied Services Interface Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
E: Compatibility Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
F: Bracket System for Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
G: ICD Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
H: Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Training Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

NASA RP–1370 vii

NASA RP–1370 viii
Chapter 1
Introduction
This technical manual resulted from an investigation of Establishing a system that ensures that all interface param-
techniques used throughout NASA and other Federal Govern- eters are identified and controlled from the initial design
ment agencies to define and control technical interfaces for activities of a program is essential. It is not necessary that the
both hardware and software. The processes described herein fine details of these parameters be known at that time, but it is
distill the requirements for interface definition and control into very important that the parameters themselves are identified,
a concise set of parameters that control the design of only the that everything known about them at that time is recorded and
interface-related elements rather than providing extraneous controlled, and that voids1 are identified and scheduled for
design detail that must subsequently be configuration elimination. The latter requirement is of primary importance to
managed. the proper design of any interface. Initial bounding of a void and
The purpose of this manual is to provide guidelines for scheduled tightening of those bounds until the precise dimen-
establishing and conducting the interface control process so sions or conditions are identified act as a catalyst to efficient
that items produced by different design agencies satisfactorily design and development. An enforced schedule for eliminating
mate and operate in a way that meets mission requirements. voids is one of the strongest controls on schedule that can be
These guidelines were drawn from the methodologies of a applied (ref. 3).
number of highly successful programs and therefore represent The process of identifying, categorizing, defining, and docu-
a compilation of “lessons learned.” menting interfaces is discussed in the following chapter. Guid-
The principles and processes of interface definition and ance for the analysis of interface compatibility is also provided.
control presented in this document apply to all projects and
programs but may be tailored for program complexity. For
example, the interface control process may be less formal for a
project or program that requires only one or two end items and
has few participants; however, the formal interface control
document is still necessary. For a project or program that Verification Mission needs
requires a number of end items and where several participants and validation definition
are involved, a carefully followed interface control process is
imperative, with comments, decisions, agreements, and com-
Risk and
mitments fully documented and tracked. Individual managers Technical systems
should provide the implementation criteria for their interface oversight analysis
control processes early in the project or program (ref. 1).
This manual covers the basic principles of interface defini-
tion and control: how to begin an interface control program
during the development of a new project or program, how to Configuration Concept
develop and produce interface documentation, how to manage management definition
the interface control process, and how to transfer interface
control requirements to hardware and software design. Systems
Interface definition and control is an integral part of system Requirements
integration
engineering. It should enter the system engineering cycle at the definiton
end of the concept development phase. Depending on whether Figure 1.1—System engineering cycle. (The
the system under development is designed for one-time or requirements definition phase must include
continuous use, the process may continue for the full life cycle the requirements for the interfaces as well as
of the system. Interface definition and control should not be those which will eventually be reflected in the
equated to configuration management or configuration control. interface control document.)
Rather it is a technical management tool that ensures that all
equipment will mate properly the first time and will continue to
operate together as changes are made during the life cycle of the
system. Figure 1.1 depicts the elements of the system engineer- 1A “void” is a specific lack of information needed for control of an interface
ing cycle and is used in chapter 3 to describe the application of feature. Control and elimination of voids is fundamental to a strong interface
the interface discipline at different parts of the life cycle (ref. 2). definition and control program.

NASA RP–1370 1
1.1 Training2
1. The processes explained in this manual for interface C. Mission needs definition, risk and systems analysis,
definition and control are concept and requirements definitions, system integra-
A. A concise set of parameters that control the design of the tion, configuration management, technical oversight,
interface-related elements and verification and validation
B. A set of design details needed for configuration manage-
ment 4a. What is a void?
A. Bracketed data
2. The process is very important for projects that require B. Wrong data
A. A number of end items C. Lack of information needed
B. Involvement of several participants
C. Comments, decisions, agreements, and commitments 4b.How should voids be handled?
that must be fully documented and tracked A. Voids should be identified and their elimination
D. All of the above scheduled.
B. Data should be analyzed.
3. What elements does the system engineering cycle contain? C. Supplier should be guided.
A. Mission needs, requirements, and integration
B. Technical oversight, core design, and system configura- 4c. Name a strong control needed for voids.
tion A. Precise dimensions
B. Enforced schedule
C. Identified catalysts

2Answers are given at the end of this manual.

2 NASA RP–1370
Chapter 2
Principles of Interface Control
mance requirements. These performance requirements are trans-
2.1 Purpose of Interface Control lated into design requirements as the result of parametric
studies, tradeoff studies, and design analyses. The design
An interface is that design feature of a piece of equipment3 requirements are the basis for developing the system specifica-
that affects the design feature of another piece of equipment. tions. The boundaries between the functional areas as defined
The purpose of interface control is to define interface require- in the system specifications become the interfaces. Early inter-
ments so as to ensure compatibility between interrelated pieces face discussions often contribute to final subsystem specifica-
of equipment and to provide an authoritative means of control- tions. Interface characteristics, however, can extend beyond the
ling the design of interfaces. Interface design is controlled by an interface boundary, or interface plane, where the functional
interface control document (ICD). areas actually come together. The interface could be affected
These documents by, and therefore needs to be compatible with, areas that
contribute to its function but may not physically attach. For
1. Control the interface design of the equipment to prevent example, it may be necessary to define the path of a piece of
any changes to characteristics that would affect compat- equipment as it traverses through another piece of equipment
ibility with other equipment and rotates and articulates to carry out its function. Electrical
2. Define and illustrate physical and functional characteris- characteristics of a transmitter and receiver separated by an
tics of a piece of equipment in sufficient detail to ensure interface plane may have to be defined for each to properly
compatibility of the interface, so that this compatibility function. Similarly, the acoustic energy produced by one com-
can be determined from the information in the ICD alone ponent and transmitted through the structure or onto another
3. Identify missing interface data and control the submis- component may need a corresponding definition.
sion of these data Identifying interfaces early in a program is essential to
4. Communicate coordinated design decisions and design successful and timely development. Functional analyses are
changes to program participants used for analyzing performance requirements and decompos-
5. Identify the source of the interface component ing them into discrete tasks or activities (i.e., decomposing the
primary system functions into subfunctions at ever increasing
ICD’s by nature are requirements documents: they define levels of detail). Functional block diagrams are used to define
design requirements and allow integration. They can cause data flow throughout the system and interfaces within the
designs to be the way they are. They record the agreed-to design system. Once the segments and elements within a system have
solution to interface requirements and provide a control mecha- been defined, a top-level functional block diagram is prepared.
nism to ensure that the agreed-to designs are not changed by one The block diagrams are then used in conjunction with N-
participant without negotiated agreement of the other participant. squared diagrams to develop interface data flows. The N-
To be effective, ICD’s should track a schedule path compat- squared diagram is a technique used extensively to develop data
ible with design maturation of a project (i.e., initial ICD’s interfaces but can also be refined for use in defining hardware
should be at the 80% level of detail at preliminary design interfaces. However, use of this tool in this manual will be
review, should mature as the design matures, and should reach restricted to interface categorization. Additional description is
the 99% mark near the critical design review). provided in section 3.1.1.
In summary, identifying where interfaces are going to occur
begins the systems integration component of systems engineer-
ing and must start early in design planning. The interface
2.2 Identifying Interfaces boundaries or planes vary from program to program depending
on how design and development responsibilities are assigned.
Identifying where interfaces are going to occur is a part of
Interface control can occur within a functional area of other
systems engineering that translates a mission need into a
design and development agents. Therefore, interfaces can be
configured system (a grouping of functional areas) to meet that
identified at many levels, for example,
need. Each functional area grouping is assigned certain perfor-

3For purposes of this manual, a piece of equipment is a functional area assigned 1. Center to center
to a specific source. Thus, a piece of equipment can be an element of the space 2. Discipline to discipline (e.g., propulsion to guidance,
station, a system of a spacecraft, a work package assigned to a contractor, or a sensor to structure, or power to users)
subsystem. 3. Contractor to contractor

NASA RP–1370 3
 4. Center to contractor to discipline 3. Shielding and grounding
5. Program to program (e.g., shuttle to National Launch 4. Signal characteristics
System) 5. Cable characteristics
6. Data definition
Once interface boundaries or planes are established, the 7. Data transmission format, coding, timing, and updating
interfaces must be categorized and defined. 8. Transfer characteristics
9. Circuit logic characteristics
10. Electromagnetic interference requirements
2.3 Categorizing (Partitioning) and 11. Data transmission losses
12. Circuit protective devices
Defining Interfaces
Other data types may be needed. For example, an analog
Categorizing, or partitioning, interfaces separates the inter-
signal interface document would contain function name and
face features by technical discipline and allows each category,
symbol, cable characteristics, transfer characteristics, circuit
in most cases, to proceed through the definition process
protective devices, shielding, and grounding; whereas a digital
independently.
data interface would contain function name and symbol, data
The following basic interface categories (defined by the
format, coding, timing and updating, and data definition.
types of feature and data they encompass) are recommended for
Additional data types under the electrical/functional heading
use in most programs:
are
1. Electrical/functional
2. Mechanical/physical 1. Transmission and receipt of an electrical/electromag-
3. Software netic signal
4. Supplied services 2. Use of an electrically conductive or electromagnetic
medium
During the early phases of systems engineering, interfaces
may be assigned only the high-level designation of these Appendix A shows recommended formats for electrical and
categories. As the system becomes better defined, the details of functional interface control drawings.
the physical and functional interface characteristics become
better defined and are documented. 2.3.2 Mechanical/Physical
An interface can be assigned to one of these categories by a
number of processes of elimination. The one recommended for Mechanical/physical interfaces are used to define and con-
use is the N-squared diagram (ref. 4), which is currently being trol the mechanical features, characteristics, dimensions, and
used by some NASA centers. tolerances of one equipment design that affect the design of
another subsystem. They also define force transmission re-
2.3.1 Electrical/Functional quirements where a static or dynamic force exists. The features
of the equipment that influence or control force transmission
Electrical/functional interfaces are used to define and con- are also defined in this ICD. Mechanical interfaces include
trol the interdependence of two or more pieces of equipment those material properties of the equipment that can affect the
when the interdependence arises from the transmission of an functioning of mating equipment, such as thermal and galvanic
electrical signal from one piece of equipment to another. All characteristics. Specific types of data defined are
electrical and functional characteristics, parameters, and toler-
ances of one equipment design that affect another design are 1. Optical characteristics
controlled by the electrical/functional ICD. The functional 2. Parallelism and straightness
mechanizations of the source and receiver of the interface 3. Orientation requirements
electrical signal are defined, as well as the transmission 4. Space or provisions required to obtain access for perform-
medium. ing maintenance and removing or replacing items,
The interface definition includes the data and/or control including space for the person performing the function
functions and the way in which these functions are represented 5. Size, shape, mass, mass distribution, and center of gravity
by electrical signals. Specific types of data to be defined are 6. Service ports
listed here: 7. Indexing provisions
8. Concentricity
1. Function name and symbol 9. Surface finish
2. Impedance characteristics 10. Hard points for handling

4 NASA RP–1370
 11. Sealing, pressurization, attachment, and locking multiple components, such as data-processing interactions
provisions between components, timing, priority interrupts, and watchdog
12. Location and alignment requirements with respect to timers. Controversy generally arises in determining whether
other equipment these relationships are best documented in an electrical/func-
13. Thermal conductivity and expansion characteristics tional ICD, a software ICD, or a performance requirements
14. Mechanical characteristics (spring rate, elastic proper- document. Generally, software interface definitions include
ties, creep, set, etc.)
15. Load-carrying capability 1. Interface communication protocol
16. Galvanic and corrosive properties of interfacing 2. Digital signal characteristics
materials 3. Data transmission format, coding, timing, and updating
requirements
Other data types may be needed. For example, an ICD 4. Data and data element definition
controlling a form-and-fit interface would generally contain 5. Message structure and flow
such characteristics as size and shape of the item, location of 6. Operational sequence of events
attachment features, location of indexing provisions, and weight 7. Error detection and recovery procedures
and center of gravity of the item. However, an ICD controlling
a structural load interface would contain weight and center of Other data types may be needed. Appendix C provides an
gravity, load-carrying capability, and elastic properties of the example of a software interface signal.
material if applicable to the loading conditions. Not all ICD’s
controlling a form-and-fit interface would have to contain all 2.3.4 Supplied Services
types of data given in this example, but some form-and-fit
interface definitions contain more than the 16 types of data Supplied services are those support requirements that a piece
listed. Indexing definitions may require angularity, waviness, of equipment needs to function. Supplied services are provided
and contour definitions and tolerances. by an external separate source. This category of interface can be
Additional data types under the mechanical/physical head- subdivided further into electrical power, communication, fluid,
ing would be and environmental requirements. The types of data defined for
these subcategories are
1. Dimensional relationships between mating equipment
2. Force transmission across an interface 1. Electrical power interface:
3. Use of mechanically conductive media a. Phase
4. Placing, retaining, positioning, or physically transporting b. Frequency
a component by another component c. Voltage
5. Shock mitigation to protect another component d. Continuity
e. Interrupt time
Appendix B (from ref. 5) shows a mechanical/physical draw- f. Load current
ing. g. Demand factors for significant variations during
This extensive variety of possibilities and combinations operations
prevents assigning a standard set of data types or level of detail h. Power factor
to a form-and-fit interface. Each interface must be analyzed and i. Regulation
the necessary controlling data identified before the proper level j. Ripple
of interface definition and control can be achieved. This holds h. Harmonics
true for all examples given in this chapter. l. Spikes or transients
m. Ground isolation
2.3.3 Software n. Switching, standby, and casualty provisions
2. Communication interface:
A software interface defines the actions required when a. Types of communication required between equip-
interfacing components that result from an interchange of ment
information. A software interface may exist where there is no b. Number of communication stations per communica-
direct electrical interface or mechanical interface between two tion circuit
elements. For example, whereas an electrical ICD might define c. Location of communication stations
the characteristics of a digital data bus and the protocols used 3. Fluid interface:
to transmit data, a software interface would define the actions a. Type of fluid required
taken to process the data and return the results of the process. i. Gaseous
Software interfaces include operational sequences that involve ii. Liquid

NASA RP–1370 5
 b. Fluid properties (ref. 8), for general guidance of a drawing format. The specifi-
i. Pressure cation format should use MIL–STD–490 (ref. 6) for paragraph
ii. Temperature numbering and general content.
iii. Flow rate Some large programs require large, detailed ICD’s. Main-
iv. Purity taining a large, overly detailed document among multiple
v. Duty cycle parties may be more difficult than maintaining a number of
vi. Thermal control required (e.g., fluid heat lost or smaller, more focused documents. Grouping small documents
gained) by major category of interface and common participants is one
4. Environmental characteristic interface: of the most effective and efficient strategies. It minimizes the
a. Ambient temperature number of parties involved and focuses the technical disci-
b. Atmospheric pressure plines, greatly streamlining the decision process and permitting
c. Humidity much shorter preparation time. However, interfaces can be
d. Gaseous composition required multidisciplinary and separate documents can result in mis-
e. Allowable foreign particle contents communications.

Other data types may be needed. Appendix D shows an ex-

ample of a supplied services interface for air-conditioning and 2.5 Identifying Steady-State and
cooling water. Non-Steady-State Interfaces
Interfaces can vary from a single set that remains constant for
2.4 Documenting Interfaces the life of a program to a multiple set of documents that
reconfigures during specific events in the life of a system. The
Once an interface has been categorized and its initial con- first category would be used for an interplanetary probe. The
tents defined, that interface definition must be recorded in a interfaces of its instruments with the basic spacecraft structure
document that is technically approved by the parties (designer would remain the same from assembly for launch throughout
and manager) and the owners of both sides of the interface. The the life of the experiment. However, a continually evolving
document then is approved by the next higher level in the platform, such as a lunar base, would perhaps be controlled in
project management structure and becomes the official control a series of interface documents based on the assembly sequence
for interface design. of the base. An initial base would be established and later made
The program manager must ensure that compliance with the more complex with additional structures and equipment deliv-
approved interface control document is mandatory. Each level ered by subsequent lunar flights. Pressurized elements, logistic
of program management must ensure that the appropriate elements, power-generating sources, habitats, laboratories, and
contractors and Government agencies comply with the docu- mining and manufacturing facilities might be added and
mentation. Therefore, technical approval of the interface con- reconfigured over time. Each configuration would require a set
trol document indicates that the designated approving of interface control documents to ensure compatibility at the
organization is ready to invoke the interface control document construction site as well as with the transportation medium
contractually on the approving organization’s contractor or from Earth to Moon. Interfaces that remained constant during
supporting organization. this process might be termed steady state and require no further
The interface categories can be grouped together in one consideration once the interface was verified and delivered;
document, or each category can be presented in a separate whereas interfaces that would evolve from the initial
document (i.e., electrical ICD’s, mechanical ICD’s, etc). The configuration through multiple iterations would require multi-
format for interface control documents is flexible. In most cases coordination of interface parameters and schedules. The selec-
a drawing format is the easiest to understand and is adaptable tion of interface categories should identify the steady-state or
to the full range of interface data. non-steady-state nature of interfaces as well as their initial
The specification format (ref. 6) can also be used. The use of designations (ref. 9).
this type of format enables simple changes through the removal
and insertion of pages; however, the format is often difficult to
use when presenting complex interface definitions that require 2.6 Selecting a Custodian
drawings, and normally requires many more pages to convey
the same level of information. Selecting an ICD custodian can depend on several factors
In either case there must be agreement on a standard for data (e.g., percentage of interface ownership, relative mission im-
presentation and interpretation. ANSI standard Y14.5 (ref. 7) portance of interface sides, and relative investment of interface
can be used for dimensions, along with DOD–STD–100 sides). However, it is generally most effective if the custodian

6 NASA RP–1370
selected has an objective point of view. An example of this 2.7 Analyzing for Interface
would be someone who is independent of either side of the
interface (i.e., without any “vested interest” in the interface
Compatibility
hardware or software). Objectivity permits unbiased control of
the interface, involvement of the custodian as an objective The interface definitions to be documented on the ICD’s
mediator, and documentation of the interface on a noninterfer- must be analyzed for compatibility before the ICD is authenti-
ence basis with program/project internal design. Selecting an cated. Appendix E provides guidance on how compatibility
independent interface custodian should be the first step in analyses may be performed. They vary in their complexity from
establishing an interface control organization. A set of criteria a simple inspection of the interface definitions to complex
should be used to select the custodian by weighting the content mathematical analyses where many variables are involved.
and interests of the interface with the needs of interface control. Regardless of complexity, the compatibility analysis should
One set of criteria is as follows: be documented and maintained as backup information for the
ICD. It can be used to expedite any changes to the interface
1. Integration center: Is one center accountable for integrat- definition by providing a ready means for evaluating the
ing the interfaces controlled by this ICD? This criterion is compatibility of the proposed change. The compatibility analy-
considered the most important because the integration center sis also can be used to document how the interface definition
will have the final responsibility for certifying flight readiness was arrived at and why the definition is presented as it is on
of the interfaces controlled in the ICD. an ICD.
2. U.S. center: Is the participant a U.S. center? This crite-
rion is considered the next most important because of agency
experience and projected responsibility. 2.8 Verifying Design Compliance With
3. Flight hardware or software: Is the interfacing article Interface Control Requirement
flight hardware or software (as opposed to support hardware or
software)? Flight hardware or software takes precedence. The ICD can only fulfill its purpose if the contractors’
4. Flight sequence: Does one side of the interfacing equip- detailed design drawings and construction practices adhere to
ment fly on an earlier manifest than the other? An earlier flight the limits imposed by the ICD. Verifying compliance of the
sequence takes precedence over follow-on interfacing design as well as of the construction process is an integral part
hardware. of interface control.
5. Host or user: Is the interfacing article a facility (as Each contractor should be assigned the responsibility of
opposed to the user of the facility)? Procedure in this criterion denoting on their manufacturing and inspection drawings or
is guided by the relative priority of the interfacing articles. documents those features and characteristics that, if altered,
6. Complexity: How complex is the interfacing equipment would affect interfaces controlled by the ICD’s. To ensure that
(relative to each side)? The more complex side of the interface all ICD requirements are covered, the contractor should select,
normally takes precedence. at the highest assembly level at which the equipment is in-
7. Behavior: How active is the interfacing equipment? The spected, the features and characteristics to be denoted. Any
active side normally takes precedence over the passive side. design change affecting an ICD-controlled feature or charac-
8. Partitions: How are the partitions (categories) used by the teristic would be clearly identified even at the assembly level
interfacing equipment? The relative importance of the parti- (ref. 10).
tions to the interface is acknowledged, and selection of the Entries identified as “to be resolved” (TBR) can be bracketed
custodian is sensitive to the most important partition or shaded to indicate preliminary interface information or an
developers. interface problem. This information is subject to further review
and discussion and is an interim value for use in evaluating
Scores are assigned to each piece of interfacing equipment effects. Entries identified as “to be supplied” (TBS) represent
for each criterion. These scores can be determined by many data or requirements to be furnished. Appendix F shows a
different methods. Discrete values can be assigned to the first typical bracket system.
four criteria. A score of 1.0 is assigned if the interfacing piece
of equipment is unique in meeting the criterion, the other piece
of equipment then receives a score of 0.0. Scores of 0.5 are
assigned to both sides if both (or neither) of them meet the 2.9 Verifying Contract-Deliverable Item
criterion. There is no definitive way of assigning scores to the
last four criteria; however, verbal consensus or an unbiased Each contract-deliverable item that is a mating side to an ICD
survey can be used to assign scores. Also, the partition criteria interface should also be tested or measured to verify that the
can be scored by partition evaluation analysis (ref. 4). item complies with the requirement as specified in the ICD. The

NASA RP–1370 7
responsibility for administering and reporting on this verifica- 4b. Who approves the interface control document?
tion program could be assigned to the design agent, the contrac- A. Designer or manager
tor, or an independent third party. If feasible, an independent B. Owners of both sides
third party should be selected for objectivity. C. Both of the above
The verification methods should include analysis, measure-
ment and inspection, demonstration, and functional testing. 4c. Who ensures compliance with the approved ICD?
The specific methods employed at each interface will depend A. Designer or manager
on the type of feature and the production sequence. Compliance B. Owners of both sides
should be verified at the highest practical assembly level. To C. Project manager
preclude fabrication beyond the point where verification can be
performed, an integrated inspection, measurement, and dem- 5a. What is a steady-state interface?
onstration test outline of both hardware and software should be A. A single set that remains constant for the life of the
developed. This verification test outline will provide a sched- project
ule, tied to production, that allows all interface requirements to B. A multiple-set suite that reconfigures during specific
be verified. The resultant data and inspection sheets should events in the life of the system
become part of the verification data in the history jacket
retained by the contractor for NASA. 5b. Give an example of a steady-state interface.
A. An interplanetary probe
B. A lunar base
2.10 Training2
5c. What features make this a good example of a steady-state
1. What is the purpose of interface control? interface?
A. To define interfaces A. The basic structure of the spacecraft would remain the
B. To ensure compatibility between interrelated equip- same from assembly for launch throughout the life of
ment the experiment.
C. To provide an authority to control interface design B. An initial base would be established and subsequently
D. All of the above made more complex with additional structures and
equipment delivered by subsequent lunar flights.
2. How is an interface identified?
A. By boundaries between functional areas 6a. How should an ICD custodian be selected?
B. By functional analyses of performance requirements A. Percentage of ownership of the interface
C. By design features of a component that can affect the B. Relative investment of interface sides
design features of another component C. An objective point of view

3a. How can interfaces be categorized? 6b. What criteria should be used to select a custodian?
A. Mechanical, electrical, software, and services A. Integration or U.S. center, flight hardware or software,
B. Electrical/functional, mechanical/physical, software, flight sequence, host or user, complexity, behavior,
and supplied services and partitions
C. Electrical, physical, software, and supplies B. Integration hardware, sequence user, and partitions

3b. What is one method of assigning an interface to one of the 6c. What scoring system can be used for these criteria?
four basic categories? A. Zero to 1.0, verbal consensus, unbiased survey, and
A. Functional flow block diagram partition evaluation analysis
B. Timeline analysis B. One to 100, priority ranking, and voting
C. N-squared diagram
7a. What is the purpose of an ICD compatibility analysis?
4a. How can an interface be documented? A. Demonstrates definitions and provides mathematical
A. By drawing format analysis
B. By specification format B. Demonstrates completeness of an interface definition
C. By both of the above and provides a record that the interface has been
examined and found to be compatible

2Answers are given at the end of this manual.

8 NASA RP–1370
7b. What are the four categories that require interface 8b. What interface deficiency rating does a bracket discrep-
analysis? ancy have?
A. Electrical/functional, mechanical/physical, supplied/ A. S & MA impact A > 1 or understanding of risk B > 2
services, and hydraulic/pneumatic B. S & MA impact A < 1 or understanding of risk B < 2
B. Electrical/functional, mechanical/physical, software,
and supplied services 9a. How are mating sides of an ICD interface verified?
A. Testing or measurement to meet requirements
7c. The hardware for mounting the satellite vehicle (SV) B. Analysis, measurement or inspection, demonstration,
adapter to the Titan IV Centaur is shown in figures 2.1 and functional testing
to 2.3.
A. Is there sufficient data to perform a compatibility 9b. What does the verification test outline provide?
analysis? A. Schedule, tied to production, that allows interface
i. Yes ii. No requirements to be verified
B. Can the Jet Propulsion Laboratory specify the SV B. Process controls, tied to manufacturing, for meeting
adapter ring? schedules
i. Yes ii. No
C. What items need to be bracketed? 9c. Where is the resultant test and inspection data stored?
i. Shear pin material and SV attachment view A. Contractor files for use by an independent third party
ii. SV panel and view C–C B. History jackets for use by NASA

8a. What does a bracket on an ICD represent?

A. Verification of design compliance
B. An interface problem

NASA RP–1370 9
10
Figure 2.1.—Titan IV and satellite vehicle physical/envelope interfaces.

NASA RP–1370
NASA RP–1370
Figure 2.2.—Titan IV and satellite vehicle orientation.

11
12
Figure 2.3.—Titan IV and satellite vehicle adapter ring.

NASA RP–1370
Chapter 3
The Process: Through the Design Phases
Interface control should be started when a program begins. ticipants responsible for the interface control documentation,
This process eventually will define all interface design and the approval or signoff loop for documentation, and the degree
documentation responsibilities throughout the life cycle of the to which all participants have to adhere to interface control
program. Each program phase from concept development to parameters and establishing a missing design data matrix,
project construction is directly related to the maturity level of change procedures, etc. (See section 3.2.)
interface control. Early development of the interface process, products, and
participants provides a firm foundation for the design engineer
to use the correct information in designing his or her portion of
3.1 Program Phases an interface. It minimizes the amount of paper to be reviewed,
shortens the schedule, and concentrates the efforts of the
3.1.1 Concept Definition designer on his or her area of responsibility.
Initial selection of interfaces generally begins with listing of
During the system engineering concept definition phase all pieces of equipment in a system and then identifying the
(from fig. 1.1), basic functional areas of responsibility are extent of interrelation among them. One tool used to help in this
assigned for the various pieces of equipment that will be process is the N-squared diagram. Details of this process can be
employed by the project (electrical power, environment con- found in reference 4. The N-squared diagram was initially used
trol, propulsion, etc.); see figure 3.1. At this point the design for software data interfacing; however, some centers are using
responsibilities of the responsible organization and related it for hardware interfaces. If the diagram is not polarized
contractor (if chosen) should be defined to establish a set of initially (input/output characteristics not labeled), it is a conve-
tiered, traceable requirements. From these requirements the nient format for identifying equipment interfaces and for cat-
interfaces to be designed are identified by category (electrical/ egorizing them. An example of this form is shown in figure 3.2.
functional, mechanical/physical, software, and supplied ser- This diagram can be further stratified to identify the interfaces
vices) and by type of data that must be defined. This categori- for each of the categories; however, detailed stratification is
zation will include a detailed review of each requirement to best applied to electrical/functional, software, and supplied
determine which requirements or features will be controlled by services interfaces. Using the N-squared diagram permits an
the interface control process. (What is important for this item to orderly identification and categorization of interfaces that can
fulfill its intended function? On what interfacing equipment is be easily shown graphically and managed by computer.
this function dependent?) Once the interfaces to be controlled By the end of this phase the basic responsibilities and
are selected, the formal procedures for interface control need to management scheme, the framework for the interface control
be established. These procedures include identifying the par- documentation, and the process for tracking missing interface
design data (see section 3.2.2) should be established and
disseminated.

3.1.2 Requirements Definition

During the requirements definition phase (fig. 3.3; from

fig. 1.1), the definitions of the mission objectives are completed
Concept so that each subsystem design can progress to development.
definition Here, the technology to be used in the project will be defined to
limit the risk associated with the use of new, potentially
• Assign basic functional areas of responsibility. unproven technologies. Defining requirements and baselining
• Define design responsibilities. interface documents early in the design process provides infor-
• Categorize interfaces. mation to the designer needed to ensure that interface design
is done correctly the first time. Such proactive attention to
• Define interfaces to be controlled.
interfaces will decrease review time, reduce unnecessary
• Establish formal interface control procedures. paperwork, and shorten schedule times. By the end of require-
• Disseminate scheme, framework, traceability. ments definition all interface control documents should be
Figure 3.1.—Establishment of interface control prepared, interfaces defined to the most detailed extent pos-
process during concept definition. sible, and ICD’s presented for baselining.

NASA RP–1370 13
 M M M M M M M M M M
Structure

M M M,E E
Fuel pods
SS SS
M,E
Thrusters
E
Solar arrays
SS
Heat M M M,E
converters SS SS SS
Voltage M,E M,E E E
converters SS
Antenna M,E
A
Antenna M,E E
B
Experiment E
1
Key Experiment E
E Electrical/functional 2
M Mechanical/physical Experiment M
SS Supplied services 3
Gyros

Figure 3.2.—N-squared diagram for orbital equipment. (Entries not polarized.)

Baselining is the act by which the program manager or

designated authority signs an ICD. That signature establishes
the ICD as an official document defining interface design
requirements. The term “baselining” is used to convey that the
ICD is the only official definition and that this officiality comes
from the technical management level. Not only is the initial
version of the ICD baselined, but each subsequent change or
update to an ICD is also baselined.
The baselined version of the ICD will identify (by a “void”)
any missing design data that cannot be included at that time.
Agreed-to due dates will be noted on the ICD for each data
Requirements
element required. Each void will define the data required and
definition
specify when and by whom such data will be supplied. Where
possible, the data to be supplied should be bounded initially on
• Define technologies to be used.
the ICD. These bounds will be replaced by detailed data when
• Define and categorize all interfaces. the void is filled. The initial bounds give the data user (the other
• Prepare all interface control documents. side of the interface) a range that can be used without risk, until
• Identify all voids and assign both the detailed data are supplied. Establishing these voids on
responsibilities and due dates. ICD’s provides a means of ensuring that interface design data
• Bound voids when possible. are supplied when they are required by the data user. Yet it
allows design freedom to the data supplier until the data are
• Baseline interface documents.
needed. A recommended form for use in identifying the data
Figure 3.3.—Development and control of needed is shown in figure 3.4. The criteria for choosing due
interfaces during requirements definition. dates are discussed in section 3.2.

14 NASA RP–1370
 Interface Design Data Required (IDDR)

(Drawing/document number + Void number)

Data required: Brief description of information needed

to define interface element currently
lacking details

Data supplier: (Project center/code/contractor)

Data user(s): (Project center/code/contractor)

Date due: (Date design data are needed, either actual

date or a period of time related to a specific
milestone.

Figure 3.4.—Format for interface design data required (IDDR).

Interface Design Data Required (IDDR)

__________ Program Status Report

Drawing/doc # Sheet/page Short title Supplier(s) User(s) Due date Remarks

IDDR # /Zone Data required Center/code/ Center/code/ Yr/Mo/Day

contractor contractor

Figure 3.5.—Format for monthly report on IDDR status.

Documents should be baselined as early as possible, as soon Technical information voids in interface documents must be
as the drawings contain 10% of the needed information. The accounted for and tracked. Otherwise, there is no assurance that
significance of early baselining is that both sides of the interface the needed information is being provided in time to keep the
have the latest, most complete, official, single package of design on schedule. The status of these voids must be reported,
information pertaining to the design of the interface. and the owners of the interface-design-data-required forms
The package includes all agreed-to design data plus a list of (IDDR’s) must be held responsible for providing the needed
all data needed, its current level of maturity, and when it is to information. It is recommended that the status be reported
be supplied by whom to whom. monthly to all parties having responsibility for the interfaces.

NASA RP–1370 15
A consolidated report is the most efficient, consumes the least 3.2 Preparing and Administering
paper and mail services, and allows the program manager to
track areas important to the integration of the system compo-
Interface Control Document
nents. The basic form shown in figure 3.5 is recommended for
3.2.1 Selecting Type of Interface Control Document
reporting and tracking IDDR’s.
A drawing, a specification, or some combination format
3.1.3 Systems Integration
should be selected for the ICD on a case-by-case basis. The
drawing format generally is preferred when the ICD has fea-
The interface control program continues to be active during
tures related to physical dimensions and shapes. The specifica-
the systems integration phase (fig. 3.6; from fig. 1.1). Design
tion format is preferred when the ICD needs tables and text to
changes that establish a need for a new interface will follow the
describe system performance. Combinations are used when
interface control change procedures as defined in section 3.2.
both dimensions and tables are needed. Members of the
Proposed design changes that affect existing interfaces are
coordinating activity responsible for preparing the ICD deter-
not given final approval until all participants’ and the cognizant
mine the format, which is approved by the appropriate project
center’s baselinings have been received through the ICD change
authority. Examples of drawing formats are given in appen-
notice system.
dixes A and B.
During the various design reviews that occur in the full-scale
The level of detail shown on the ICD varies according to the
engineering development phase, special attention should be
type and degree of design dependency at the interface being
given to design parameters that if altered, would affect inter-
controlled. The ICD should clearly identify and control inter-
faces controlled by the ICD. It is strongly recommended that
faces between designs and enable compatibility to be demon-
each design activity denote, on design and manufacturing
strated between the design areas. The key to a useful ICD is
documentation at the preliminary design review, through a
limiting the detail shown to what is required to provide compat-
bracket or some highlighting system, those features and char-
ibility. Any unnecessary detail becomes burdensome and may
acteristics that would affect an interface (see section 2.8). At the
confuse the contractors responsible for designing the mating
critical design review all voids should be resolved and all
interface. Again, the ICD should, at a minimum define and
detailed design drawings should comply with interface control
illustrate physical and functional interface characteristics in
documentation (see section 2.9).
sufficient detail that compatibility, under worst-case toler-
ances, can be determined from the ICD alone; or it should
reference applicable revisions of detailed design drawings or
documents that define and bracket or identify features, charac-
teristics, dimensions, etc., under worst-case tolerances, such
that compatibility can be determined from the bracketed
features alone.

3.2.2 Tracking and Resolving Missing Interface

Design Data

Missing interface data should be identified on the ICD, and

the ICD should control the date for its submission. The notation
Systems
identifying the missing data should indicate the specific data
integration required, how the data are being tracked for resolution, when
the data are needed by the interfacing design agent, and by what
• Manage and satisfy voids. date the required data will be supplied. Establishing data-
• Invoke use of brackets on design drawings. required notations (or voids) on ICD’s helps ensure that inter-
• Ensure resolution of voids by the time of critical
face design data will be supplied when needed; yet it allows
design freedom to the data supplier until the due date. Every
design review.
attempt should be made to establish realistic due dates and to
• Verify compliance of design documentation with meet that schedule unless there is a valid and urgent need to
ICD's. change a due date.
Figure 3.6.—Development and control of interfaces These criteria and procedures should be followed in estab-
during systems integration. lishing, reporting, and managing data due dates:

16 NASA RP–1370
 1. Choose the due date as the date when the data user will appropriate authority to all other activities with review and
start to be affected if agreed-upon or baselined data have not comment responsibilities for the particular ICD and to the ICD
been received. custodian.
2. When establishing a due date, allow time to process and Technical comments by all activities should be transmitted
authenticate a change notice to the ICD (i.e., once the due date to the custodian as soon as possible but not later than 30
has been established, include a period of time to establish that working days4 from receipt of the comment issue. If the
due date for the data supplier). comment issue is technically unacceptable to the Government
3. The custodian responsible for the ICD should periodi- authority or the interfacing contractor, the rationale for
cally, as determined by the appropriate project authority, unacceptability should be explained, including technical and
prepare and distribute a report on the status of all missing design cost effects if the interface definition is pursued as presented.
information for all project activities. The report should contain
the following information: 3.4.1 Resolving Comments
a. Identification of the data element needed, consisting of
the ICD number, the date, and a two- or three-digit The ICD custodian collects review comments and works in
number that provides a unique identifier for the data conjunction with project management for comment resolution
element until approval is attained, the comment is withdrawn, or the
b. A short title for the ICD ICD is cancelled. Information on comments and their disposi-
c. The activity that requires the data tion and associated resolution should be documented and
d. The date when the missing data are to be supplied or transmitted to all participants after all comments have been
the period of time after the completion of a program received and dispositioned. Allow two weeks4 for participants
event or milestone when the data are to be supplied to respond to the proposed resolution. Nonresponses can be
e. The activity from which the data are due considered concurrence with the resolutions if proper
f. The status of the data required (i.e., late data, data in prenotification is given to all participants and is made part of the
preparation, or change notice number) review and comment policy.
g. A description of the data required When comments on the initial comment issue require major
changes and resolution is not achieved through informal com-
munications, an additional comment issue may be required
3.3 Initial Issuance of ICD and/or interface control working group (ICWG) meetings may
need to be arranged.
The first issue of an ICD should be a comment issue. The
3.4.2 Interface Control Working Group
comment issue is distributed to participating centers and con-
tractors for review and comment as designated in the interface
The ICWG is the forum for discussing interface issues.
responsibility matrix (fig. 3.7).
ICWG meetings serve two primary purposes: to ensure effec-
The interface custodian generates the responsibility matrix
tive, detailed definition of interfaces by all cognizant parties,
for ICD’s. The matrix specifies the center and contractor
and to expedite baselining of initial ICD’s and subsequent
responsibilities for baselining, review and comment, and tech-
drawing changes by encouraging resolution of interface issues
nical approval. The matrix lists all ICD’s applicable to a
in prebaselining meetings. A major goal of interface control
particular program. Distribution of the ICD’s can then be
should be that baselining immediately follow a prebaselining
controlled through this matrix as well.
ICWG meeting.
The review and comment process is iterative and leads to
All ICWG meetings must be convened and chaired by the
agreement on system interface definitions and eventual approval
cognizant project organization. The project can choose a con-
and baselining of the ICD. See figure 3.8 for a flow diagram of
tractor to act as the chair of an ICWG when Government
the issuance, review and comment, and baselining procedures
commitments are not required. In all cases the ICWG members
for ICD’s. Concurrent distribution of the comment issue to all
must be empowered to commit the Government or contractor to
participants minimizes the time needed for review and subse-
specific interface actions and/or agreements. In cases where a
quent resolution of differences of opinion.
contractor is ICWG chair, the contractor must report to the
Government any interface problems or issues that surface
during an ICWG meeting.
3.4 Document Review and Comment
4The times assigned for commenting activities to respond are arbitrary and
As designated in the ICD responsibility matrix, all centers should be assigned on the basis of the schedule needs of the individual
and contractors should submit technical comments through the programs.

NASA RP–1370 17
18
(1)
Major project NASA data interface (4) Review, comment, information Technical AU Notes
applicability list responsibilities approval
Program __ (2) ______ authority
(5) (5) (5) (5) (5)

(6) (6) (6) (6) (6) (6) (6) (6) (6) (6) (7) (7) (7) (8)

(3) Interface
category:

(9)

Key:
(1) Major project/program applicability (e.g., NSTS).
(2) Primary project/program ownership of interfaces.
(3) Category of interface covered by list (e.g., electrical/functional).
(4) Review, comment, and information (RC&I) responsibilities by NASA center (listed in (5)).
(5) Center responsible for RC&I of the interface document.
(6) Center code or contractor doing RC&I.
(7) Center having technical approval signature authority (one column for each applicable center).
(8) NASA organization having authentication responsibility (single organization for authentication of a baselined document following technical approval
by the organizations in columns marked by (7)).
(9) Drawing/document number and short title.

Figure 3.7.—Interface responsibility matrix.

NASA RP–1370
 ICD custodian
develops comment
issue of ICD
Issuance Issuance

Contractors review Centers review

and comment and comment
Comments
Resolution Resolution
cycle cycle
ICD custodian
coordinates and
resolves comments* * Interface control
working group meetings
are scheduled as needed.

Technical approval
by NASA centers
and contractors

Distribution of
Monthly status reports ICD to all
participants

Figure 3.8.—Flow of interface control document production.

The ICWG chair prepares the ICWG meeting minutes or 3.4.5 Baselining
designates one of the meeting participants for this task. The
minutes should include discussions of problems, agreements Interface control documents are baselined when the owners
reached, decisions made, and action items. The ICWG chair of both sides of the interface at the next level up in the program
also ensures that any updated interface control documentation structure come to technical agreement and sign the document.
reflecting the ICWG discussions is distributed within the
timeframe agreed to by the affected participants.

3.4.3 Approval/Signoff Cycle 3.5 Change Notices

The management plan for the project assigns responsibility
The procedure for initiation, review, technical approval,
for each piece of equipment to a specific project authority and
baselining, and distribution of changes to project ICD’s
its contractor. The signoff loop for each ICD reflects this plan
(fig. 3.9) should conform to the following guidelines.
and can be related to the project and the origin of each design
requirement. For each ICD, then, the signoff loop follows the
sequence of technical approval by the contractors first and then 3.5.1 Initiating Changes
by the appropriate project authority.
Any project activity should request a change to an ICD when
3.4.4 Technical Approval
1. Data are available to fill a void.
The appropriate project authority and the primary and asso- 2. Information contained in a data-required note needs to be
ciate organizations with an interest in a particular ICD are listed modified.
in the responsibility matrix. They each sign the ICD to signify 3. Additional data are needed (i.e., a new data requirement
technical agreement and a readiness to contractually invoke its has been established).
requirements. 4. A technical error is discovered on the ICD.

NASA RP–1370 19
 Originate
change request
(any participant)

ICD custodian
Contractors Project
reviews and prepares
(for information) (for information)
proposed change notice

Issuance Issuance

Contractors review Project reviews

and comment and comments

Comments
Resolution Resolution
cycle cycle
ICD custodian
coordinates and
resolves comments

ICWG meeting
as required
Technical approval
by NASA project
and contractors
* Distribution per ICD
distribution matrix

Direction to
Authentication * Distribution of
proceed as required
by NASA change notice
to contractor

Incorporate Change master ICD to

change into incorporate change
project and distribute

Figure 3.9.—Development and flow of change notices in the ICD revision process.

20 NASA RP–1370
 5. An equipment design change and a system or equipment The proposed change notice describes the specific changes
rearrangement are proposed to improve performance, (technical or otherwise) to the ICD in detail by “from-to”
reduce cost, or expedite scheduled deliveries that would require delineations and the reasons for the changes, as well as who
changes to an interface or creation of new interfaces. requested the changes and how the change request was trans-
mitted (i.e., by letter, facsimile, ICWG action item, etc.).
3.5.2 Requesting Changes
3.5.3 Proposed Change Notice Review and
All requests for changes should be submitted to the organi- Comment Cycle
zation responsible for maintaining the ICD, with copies to all
activities that will review the resultant change notices and to the The review and comment cycle for proposed changes to
appropriate project authority. If baselining is needed in less ICD’s should follow the same system as that used for the initial
than 30 days, a critical change should be requested. All requests issuance of the ICD (see sections 3.3 and 3.4).
for changes should be submitted in a standard format that
includes the following items: 3.5.4 Processing Approved Changes

The baselined change notice should be distributed to all

1. Originator’s identification number—It is used as a refer-
cognizant contractors and project parties expeditiously to prom-
ence in communications regarding the request and should
ulgate the revised interface definition. The master ICD is
appear on resulting change notices
revised in accordance with the change notice, and copies of the
2. Originating activity—originating project and code or
revised sheets of the ICD are distributed (see sections 3.3 and
originating contractor
3.4). Approval of the change by the project constitutes author-
3. Point of contact—name, area code, telephone number,
ity for the cognizant organization to implement the related
facsimile number, and e-mail address of the person at the
changes on the detailed design.
originating activity to be contacted regarding the request
4. Document affected—number, revision letter, and short 3.5.5 Distributing Approved Changes
title of each ICD that would be affected by the change
5. Number of data voids (if applicable)—number of data The custodian distributes the baselined change notice to all
requirements for which data are being provided cognizant centers and contractors to expeditiously promulgate
6. Urgency—indication of whether this change is critical or the revised interface definition. The master ICD is then revised
routine (project decides whether to use critical route) in accordance with the change notice, and copies of the revised
7. Detailed description of change—a graphic or textual ICD sheets are distributed as was the change notice.
description of the change in sufficient detail to permit a clear The responsibility matrix (fig. 3.7) can be used to identify the
portrayal and evaluation of the request. Separate descriptions distribution of change notices as it was used for the distribution
should be provided when more than one ICD is affected. of the ICD’s.
8. Justification—concise, comprehensive description of the
need and benefit from the change 3.5.6 Configuration Control Board
9. Impact—concise, comprehensive description of the ef-
fect in terms of required redesign, testing, approximate cost, During development the project’s configuration control
and schedule effects if the requested change is not approved; board is responsible for reviewing and issuing changes to the
also the latest date on which approval can occur and not affect configuration baseline. The board reviews all class I engineer-
cost or schedule ing change proposals to determine if a change is needed and to
10. Authorizing signature of the organization requiring the evaluate the total effect of the change. The configuration
change control board typically consists of a representative from the
chairman, the project management office, customers, engineer-
Upon receipt of a change request to an ICD, the ICD ing, safety assurance, configuration management (secretary),
custodian coordinates the issuance of a proposed change notice. fabrication, and others as required.
First, the ICD custodian evaluates the technical effect of the Changes to configuration items can only be effected by the
proposed change on the operation of the system and mating duly constituted configuration control board. The board first
subsystem. If the effect of the change is justified, the ICD defines a baseline comprising the specifications that govern
custodian generates and issues a change notice. If the justifica- development of the configuration item design. Proposed changes
tion does not reflect the significance of the change, the ICD to this design are classified as either class I or class II changes.
custodian rejects the request, giving the reason or asking for Class I changes affect form, fit, or function. However, other
further justification from the originating organization. The ICD factors, such as cost or schedule, can cause a class I change.
custodian evaluates an acceptable change request to determine Class I changes must be approved by the project before being
whether it provides data adequate to generate a change notice. implemented by the contractor.

NASA RP–1370 21
 All other changes are class II changes. Examples of class II Appendix G provides seven ICD guidelines that have been
changes are editorial changes in documentation or hardware used by many successful flight projects and programs to pro-
changes (such as material substitution) that do not qualify as vide such a focus on the interface definition and control
class I changes. Project concurrence, generally, is required for process.
the contractor to implement class II changes. Government plant
representatives (Defense Contracts Administration Services
(DCAS), Navy Programs Resident Office (NAVPRO), and Air 3.6 Training2
Force Programs Resident Office (AFPRO) usually accomplish
these tasks. 1a. When should the ICD process be started?
A. Concept definition B. Requirements definition
3.5.7 Closing the Loop C. Systems integration

A wide range of methods are available for verifying by test 1b. What are the benefits of early development of the ICD
that the design meets the technical requirements. During the process?
definition phase analysis may be the only way of assessing what A. Assigns basic areas of responsibility
is largely a paper design. Typical methods are testing by B. Provides firm foundation for design, minimizes
similarity, analysis, modeling, and use of flight-proven compo- paper, shortens schedule, and concentrates efforts
nents; forecasting; and comparison, mathematical modeling,
simulation modeling, and using flight-proven experience and 1c. What tool can be used to list equipment and identify their
decisions. The actual methods to be used are determined by the interrelations in a system?
project office. Each method has associated costs, requires A. Prechart B. N-squared diagram
development time, and provides a specific level of performance
verification. The Government and industry managers must 2a. What should be done in the ICD process during require-
carefully trade off program needs for performance verification ments definition?
with the related costs. A. Define mission objectives
If any demonstrated or forecast parameter falls outside the B. Define technology and interfaces and present for
planned tolerance band, corrective action plans are prepared by baselining
the contractor and reviewed by the Government project office.
Each deviation is analyzed to determine its cause and to assess 2b. What is baselining?
the effect on higher level parameters, interface requirements, A. The designated authority signing an ICD
and system cost effectiveness. Alternative recovery plans are B. The only official definition
developed showing fully explored cost, schedule, and technical
performance implications. Where performance exceeds re- 2c. How are voids in an ICD accounted for and tracked?
quirements, opportunities for reallocation of requirements and A. Procedure or administration report
resources are assessed. B. Monthly program status report on interface design
Although functional and performance requirements are con- data required
tained in the appropriate configuration item specification, the
definition, control, and verification of interface compatibility 3a. What should be done in the ICD process during develop-
must be handled separately. Otherwise, the volume of detail ment?
will overwhelm both the designers and managers responsible A. Manage voids, invoke brackets, resolve voids, and
for meeting the functional and performance requirements of the verify compliance
system. Early establishment of the interface definition and B. Control interface developments
control process will provide extensive savings in schedule,
manpower, money, and paper. This process will convey pre- 3b. How should proposed design changes be handled?
cise, timely information to the interface designers as to what the A. Discussed at critical design review
designer of the opposing side is committed to provide or needs B. Discussed and approved by all participants
and will subsequently identify the requirements for verifying
compliance. 3c. What should be given special attention?
Whether the interface is defined in a drawing format or in a A. Design parameters that affect controlled ICD
narrative format is at the discretion of the program. What is of B. Manufacturing documentation
primary importance is that only the information necessary to
define and control the interface should be on these contractural
documents to focus the technical users and minimize the need
for updating information. 2Answers are given at the end of this manual.

22 NASA RP–1370
4a. When is the drawing format used for an ICD? 6d. Who approves and baselines an ICD?
A. To describe the type and nature of the component A. Projects at the next level up in program structure
B. To describe physical dimensions and shapes B. The project office

4b. When should a specification be used? 7a. When should a project activity request a change to an ICD?
A. To describe performance with tables and text A. At the custodian’s request
B. To describe a software function B. When data are available, requirements need change,
an error is discovered, or the design changes
4c. What is the key to providing a useful ICD?
A. Give as much detail as possible 7b. What items should be included in a change notice request?
B. Limit the detail to what is necessary to demonstrate A. Identification number, activity, contact, document
compatibility affected, number of data voids, urgency, descrip-
tion, justification, impact, and authorizing signature
5a. What is the purpose of the initial issue of an ICD? B. Those established by the ICWG
A. Issuance, review, comment, and baselining
B. Review and resolution of differences of opinion 7c. Who evaluates and issues a proposed change notice?
A. ICD custodian
5b. Who is responsible for controlling the flow of an ICD? B. Project office
A. Contractor
B. Custodian 7d. What does a proposed change notice describe?
A. Specific changes (from-to), reasons, and the
6a. Who should review ICD’s? requestor
A. Organizations designated in the responsibility B. Project notices
matrix
B. ICD custodian 7e. How is a change notice approved and distributed?
A. By the project authority to all cognizant parties
6b. How are comments resolved? B. By all cognizant parties to the contractors
A. By the project office
B. By project management and custodian working for
resolution and approval or the comment being with-
drawn

6c. Where are interface issues discussed?

A. Project office
B. Interface control working group

National Aeronautics and Space Administration

Lewis Research Center
Cleveland, Ohio, 44135, July 1995.

NASA RP–1370 23
Appendix A
Electrical/Functional Interface Example
This appendix illustrates elements of a telemetry drawing callout in table A.2 and the accompanying DDR block (fig.
interface control document showing control of waveform A.3). The DDR block notes that the responsible parties have
parameters and data rates. This interface example depicts data agreed on an amplitude band with which they can work until the
transfer between a guidance system electronics assembly and a guidance design becomes firm. However, there is also a date
launch vehicle telemetry system. The basic drawing (fig. A.1) called out that indicates when (45 days after preliminary design
covers the isolation elements of the guidance system, the jack review) the telemetry contractor must have the data to be able
and pins assigned, and shielding and grounding on the guidance to complete design and development and deliver the telemetry
side of the interface. Bus functions are named (e.g., guidance in time to support launch vehicle flight.
telemetry data 1(parametric)), and the shielding requirements The parameters called out in this example are only those
through to the first isolating elements of the telemetry system needed to control the design of either side of the interface
are provided (see notes on fig. A.1). through the first isolating element. Also note that only the
Table A.1 contains the details to be controlled for each bus shielding and wire gage of the launch vehicle cabling between
function. Signal source (electronics assembly) and destination the two systems are provided. Only pin numbers for the
(telemetry system) are identified. The waveform (fig. A.2) and guidance side of the interface are called out and controlled.
its critical characteristics (table A.2) are provided, as well as Connector types and other pertinent cable specifications are as
data rates and sources and load impedances. Telemetry load per a referenced standard that applies to all launch vehicle
impedance is further described by an equivalent circuit (see cabling. In this case the same pulse characteristics apply to each
note 3 on fig. A.1). of the functions covered; however, table A.2 is structured to
The final value of pulse minimum amplitude is missing in permit variation for each function if the design should dictate
this example. This is noted by the design-data-required (DDR) different values for the characteristics of each function.

24 NASA RP–1370
 Function Guidance Launch vehicle
Electronics
assembly
Telemetry
EJ4

NASA RP–1370
Guidance telemetry data 1
Guidance telemetry 4 Equivalent
data 1 (parametric) Guidance telemetry data 1 return circuit
3 (see note 3)
Guidance telemetry data 2
Guidance telemetry 28 Equivalent
data 2 (diagnostic) Guidance telemetry data 2 return circuit
27 (see note 3)
Guidance telemetry bit
synchronization
Guidance telemetry 51 Equivalent
Guidance telemetry bit
bit synchronization synchronization return circuit
52 (see note 3)
Guidance telemetry frame
synchronization
Guidance telemetry 1 Equivalent
Guidance telemetry frame
frame synchronization synchronization return circuit
2 (see note 3)
Guidance telemetry data 1 word
synchronization
Guidance telemetry 29 Equivalent
Guidance telemetry data 1 word circuit
data 1 word synchronization return
synchronization 30 (see note 3)
Guidance telemetry data 2 word
synchronization
Guidance telemetry 50 Equivalent
Guidance telemetry data 2 word circuit
data 2 word synchronization return
49 (see note 3)
synchronization

Launch vehicle
ground (via Notes:
electronic 1. The wire gage for signals transmitted between the electronic assemblies and launch vehicle telemetry shall
assembly's be AWG #24.
ground strap) 2. The launch vehicle cabling shall meet the requirements of WS 13953.
3. The telemetry load impedances are represented by the the following equivalent circuit:

5 kV minimum
110 V ± 15% 200 pF maximum
5 kV minimum

Figure A.1.—Guidance/launch vehicle telemetry interface.

25
26
Table A.1.—GUIDANCE/LAUNCH VEHICLE TELEMETRY DATA TRANSFER INTERFACE PARAMETERS
[Source, electronic assembly; destination, telemetry; waveform, see fig. A.2; source impedance, 50 V maximum during pulse time.]

Function Data rate Load Remarks

impedance

Guidance telemetry Bit rate: 979.2 kilobits per second 1. All timing is synchronous with the
data 1 Word rate: constrained guidance to telemetry bit synchro-
to 153- x 16-bit words nization.
Guidance telemetry per 10-ms frame 2. The guidance telemetry frame
data 2 synchronization consists of
16 pulses at a rate of (void #3) and
occurs at 100 frames per second.
Guidance telemetry Void #3 110 V ± 15% balanced to 3. The launch vehicle telemetry shall
bit synchronization ground by not less than function properly with a guidance
5000 V and shunted by telemetry bit synchronization and
Guidance telemetry 100 frames per second 200 pF maximum frame synchronization tolerance
frame synchronization (see Remarks) (excluding cabling) (see of ± 0.1%.
note 3 on fig. A.1(c)) 4. All pulse characteristics are
Guidance telemetry Coincident with first bit defined at the guidance electronic
data 1 word synchro- of each guidance assembly interface connectors.
nization telemetry data 1 word 5. Guidance signal characteristics
are defined for the minimum wire
Guidance telemetry Coincident with first bit gauge shown.
data 2 word synchro- of each guidance
nization telemetry data 2 word

NASA RP–1370
 Pulse duration

Maximum 10% of minimum amplitude

amplitude
Minimum amplitude
Noise
No-transmission level
Reference
level Offset
Rise time
Undershoot
Fall time
Interpulse period Leading Trailing Interpulse period
edge edge

Notes:
1. The interpulse period shall be the period from 150 ns after the trailing edge of
a pulse until 100 ns prior to the leading edge of the subsequent pulse.
2. The reference level shall be the average voltage for the last 200 ns of the
interpulse period.
3. The no-transmission level shall be 0 V differential at the guidance/launch vehicle
interface using the test load specified in table A.2.
4. Shielding depicted represents the telemetry shielding requirements only. For
cable routing see void #01. Telemetry shielding shall be carried through all
connectors between the electronic assembly and the telemetry subsystem.
5. A radiofrequency cap shall be provided on electronic assemblies in all launch
vehicles in lieu of this connector.

Figure A.2.—Guidance data pulse characteristics.

NASA RP–1370 27
 Table A.2.—REQUIRED PULSE CHARACTERISTICS AND TEST PARAMETERS

Pulse Guidance telemetry

characteristics
(see fig. A.2) Data 1 Data 2 Bit Frame Data 1 word Data 2 word
synchronization synchronization synchronization synchronization

Pulse duration 255 + 50 ns

Minimum amplitude 9 ± 2 V (see V027)
Maximum amplitude 15 V
Rise time 75 ns maximum
Fall time 125 ns maximum
Undershoot 2.5 V maximum
Reference level offset 0 to –4.5 V relative to no-transmission level
Noise 1.4 V maximum peak to peak
Receiver susceptibility 2.0 V minimum
Test parameters:a
Test load 75 V±5% resistive
Receiver 2.0 V minimum
susceptibility

DDR No. 3288399–V027

Data required: Guidance subsystem waveform parameter data (minimum amplitude

value to replace coordinated temporary amplitude band currently on
ICD–3288399)

Data supplier: SP–2012/guidance telemetry steering committee

Data user(s): SP–2732/launch vehicle telemetry contractor/interface coordinator

Date due: 45 days following guidance preliminary design review

Figure A.3.—Typical design data required for table A.2.

28 NASA RP–1370
Appendix B
Mechanical/Physical Interface Examples
B.1 Mechanical Interface for one or the other. Considering the function of the
mounting bolts—to locate the box relative to the
Distributed Electrical Box electrical connectors, it has to be assumed
Figure B.1 is an example of an interface development docu- that dimensions a, b, c, and d are basic dimensions.
ment (IDD) that, from initial inspection, appears to be fairly Interface control drawings cannot require the
complete. This figure contains a great amount of detail and just designer of the mating interface to assume any-
about everything appears to be dimensioned. However, closer thing. IDD’s must stand by themselves.
examination will reveal serious shortcomings. b. Figure B.3 depicts initial details of mounting bolts
First, the basic function of the interface must be defined. The for the L-shaped bracket. On first inspection there
box depicted must be capable of being removed and replaced on appears to be a great amount of detail. However, further
orbit, in many cases outside the crew habitat. In some cases it examination shows that much of the detail is not related
is to be removed and replaced robotically. The box slides along to interface definition. The interface is the bolt. Where
the L-shaped bracket held to the support structure by three is it relative to other features of the box? What is the
mounting bolts labeled “bolt 1,” “ bolt 2,” and “bolt 3.” As the relationship of bolts 1 and 2 to bolt 3 (datum C)?
box slides along the L-shaped bracket from left to right in the What is the thread of the bolt? How long is the bolt?
figure, some piloting feature on the box connectors engages the The following data on the IDD are not required:
connectors mounted to the support structure by the spring- i. Counterbore for bolt head
mounted assembly, and the connector engages fully when the ii. Diameter of bolt hole in bracket for bolts 1, 2,
lead screw is completely engaged. and 3
iii. Distance of bolt hole to first thread
1. The initial interface area to be examined is that of the iv. The fact that there is a screw retaining ring
L-shaped bracket to the support structure (i.e., the interface of Adding data not required for the interface, even if they
the three mounting bolts). The interface is being examined from are only pictorial, is expensive. It takes time for the
the perspective of the designer of the support structure. Does organization to develop and present it, and it takes
figure B.1 contain enough information for a mating interface to time for the designer of the mating interface to deter-
be designed? (The area of interest has been enlarged and is mine that the information is not necessary and discard
presented as figure B.2.) it. If the extraneous information stays on the IDD, it
a. The dimensions circled in figure B.2 and lettered a, b, must be maintained (i.e., changed if the design details
c, and d locate the position of the mounting bolts change). Only the features of a design that affect the
relative to the box data. The following pertinent features of the design of the mating interfaces need
differences are noted concerning this dimensioning: be placed on the IDD.
i. Dimension a locates the holes relative to a “refer- c. Once the unnecessary data are removed, what remains
ence datum for coldplate support structure,” but is shown in figure B.4. The data that remain are not
the datum is not defined on the drawing. Is it a line complete and are unclear. The true position notations
or a plane? What are the features that identify/locate are indicated as being those for the “mounting inter-
the datum? What is the relationship of this datum to face for bolt,” suggesting that the true position applies
other data identified on the IDD (data A, B, and D)? to the hole in the support structure. However, since the
This information is required so that the designer IDD is basically covering the features of the box, it is
of the support structure can relate his or her assumed that these locations apply to the bolts on the
interface features easily to those of the box IDD. box. It should not be necessary to have to make
ii. The IDD states that the tolerances on three-place assumptions about data on an IDD or ICD. The
decimals is ±0.010. Dimensions a, b, c, and d document should stand by itself.
are three-place decimal dimensions and would,
therefore, fall under this requirement. Elsewhere on The only other data left in figure B.4 are the callouts for
the IDD a true position tolerance for bolt locations the locking inserts. These callouts refer to the method
is indicated. A feature cannot be controlled by both used by the designer of the support structure for retaining
bilateral and true positioning tolerancing. It must be the bolts. This IDD should not have this callout, since the

NASA RP–1370 29
30
Figure B.1.—Partial interface development document for multiuse electrical power interface box showing bolt locations.

NASA RP–1370
 d c b a

Figure B.2.—Detail of L-shaped bracket interface.

Figure B.3.—Initial details of mounting bolts.

NASA RP–1370 31
 Figure B.4.—Necessary details of mounting bolts.

1.000 Max
0.875 Min 3 PL

C
L bolt 2 and 3

Figure B.5.—Minimal interface definition.

method used for retaining the bolts is not the responsibil- 2. The next area to be examined is that of the connector
ity of the box designer. Generally IDD’s and ICD’s interface. Since both parts of the connector are being provided
should not specify design solutions, especially when by the box designer, the interface is the plate on which the
the design solutions are not the responsibility of the connectors are attached to the support structure. Again, the
one specifying them. question is, Does figure B.1 contain enough information for a
What is missing is how far the bolts protrude from the mating interface to be designed? The answer to that question is,
box. These data are required so that the designer of the Definitely not! The interface of the plate (holding the connec-
support structure knows how deep to make the mating tors) that mates with the support structure is identified as datum
hole and how much of a mating thread must be supplied D. Again, there is no definition of this datum. Is it a plane
to grip the bolts on the box. passing through the three highest points of the plate or some
Considering all of the above, figure B.5 represents other features of the connector plate?
what is really required (along with the locations and If a compatible mating interface is to be designed, the
thread types already defined in fig. B.1) to define the box relationship between the surface to which the connector plate is
side of the interface and for the designers of the support attached and the surface to which the L-shaped bracket is
structure to design a compatible interface between the attached must be known. None of these data are supplied in
retaining bolts and the support structure. figure B.1. The following are data needed to establish this
relationship:

32 NASA RP–1370
 a. The required perpendicularity of D to A B.2 Space Reservation and Attachment
b. The required parallelism of D to B
c. The required angular relationship of the vertical centerline
Features for Space Probe Onboard
shown in view B–B with the vertical centerline shown in Titan IV Launch Vehicle
view A–A
d. The pattern required for the four fasteners holding the Figure B.6 is an example of an ICD that defines the space
connector plate to the support structure. View B–B does envelope available onboard the Titan IV launch vehicle for a
contain a dimension of 2.594 for a horizontal spacing of payload and the attachment feature details for the launch
the lower two features but does not indicate that this vehicle side of the interface. The intended payload is the
dimension is applicable to the upper two fasteners. In Cassini Mission spacecraft. The Titan payload fairing, as
addition, there is no dimension for the distance between would be expected, is defined. The other side of this envelope
the fasteners in the Z direction. (i.e., the spacecraft) must also be defined to show compatibility.
e. The required relationship of the hole pattern for the When the spacecraft dimensions are established, compatibility
connector plate relative to the box, namely, should be shown by a comparison of the two envelopes. The
i. The location of the hole pattern above A in the Z Titan documentation defines the available space reserved for
direction equipment (i.e., a stay-out zone for the Titan launch vehicle
ii. The location of the hole pattern relative to C in the items). Ideally, this ICD should define a minimum space
X direction available for the spacecraft. Therefore, if the spacecraft dimen-
iii. The distance of datum D from C in the Y direction sions are constrained to a maximum size equal to the launch
when the box is fully installed vehicle’s minimum, less a value for environmental effects, etc.,
then the two envelopes are compatible.
Since none of these data are identified as items to be determined Since interface data have been provided for the attachment
(TBD’s), it must be assumed either that the data are not required details for the launch vehicle side of the interface, the design of
because the connectors can be mated properly with a great deal the Cassini adapter for mounting to the Centaur launch vehicle
of misalignment or that the box designer did not recognize that at station –150.199 can be explained by using the Titan design
this type of data is required. Designers never wish to freeze a data.
design. The placement of design constraints in an ICD is The following key interface features have been established
basically freezing an area of a design or at least impeding the for this connection:
ability to change a design without that design being scrutinized
at another level. Therefore, the tendency of designers is to 1. Sheet 1 (fig. B.6(a)), note 5: Location of holes is estab-
disclose the minimum that they feel is necessary in the lished by a common master gauge tool with reference dimen-
interface for the control process. This is the primary reason sions provided.
for the ICD custodian not to be organizationally a part of 2. Sheet 3 (fig. B.6(c)), section F–F: Bearing areas are to be
the design process. Yet the ICD custodian must have access to flat within 0.006 (units), and per view G the maximum bearing
the design function of an agency or contractor organization to area has been defined.
ensure the ready flow of the data required for proper interface 3. Sheet 3 (fig. B.6(c)), view H: Shape and dimensions of the
definition. (Can interface compatibility be demonstrated from shear alignment pins have been established.
the ICD’s alone?) 4. Sheet 1 (fig. B.6(a)), note 4: How loads are to be transmit-
The ICD custodian must always test the data in interface ted is indicated.
documentation from the viewpoint of another design agent who
must develop a compatible mating interface. The following data elements missing from figure B.6 are
The preceding discussion simplifies specification of the mostly related to the lack of spacecraft design data:
L-shaped bracket and the mounting bolts. This redefinition of 1. No apparent tracking of TBD’s. A tracking system
the interface tied up loose ends and provided needed dimen- should be in place at the beginning of ICD development.
sions and callouts absent from the original document. These Each TBD should have a unique sequential identifier with
portions of the document can now be controlled more easily and due dates and suppliers established.
related to a 100% mate design. 2. No revision block for tracking the incorporation of changes.
Some type of revision record should be placed on each sheet.

NASA RP–1370 33
34
(a)

Figure B.6.—Titan IV and space vehicle physical/envelope interfaces. (a) Notes and abbreviations. (b) Orientation view. (c) Section views.

NASA RP–1370
NASA RP–1370
(b)

Figure B.6.—Continued. (b) Orientation view.

35
36
(c)

Figure B.6.—Concluded. (c) Section views.

NASA RP–1370
Upon exchange of design data relating to the Cassini probe it needed for interface compatibility. The chances for an incom-
would be expected that the probe’s maximum envelope would patibility are much less if the spacecraft side of the interface is
be established and related to the data system of the Titan/ defined. Space vehicle data, stations, and fasteners must be
Centaur launch vehicle. identified and controlled. The designer of the space vehicle is
This example is basically a one-sided interface. The Titan/ then able to commit to the design and production of an interface
Centaur side of the interface is well defined, which is to be that is defined. The launch vehicle designers can then verify
expected considering the maturity of the design. The tendency that the spacecraft interface will mate with the launch vehicle
should be resisted, in cases like this, to ignore or place less available for the spacecraft. Therefore, if the spacecraft dimen-
emphasis on the definition and documentation of the mating sions are constrained to a maximum size equal to the launch
interface, given the completeness of the launch vehicle side of vehicle’s minimum, less a value for environmental effects, etc.,
the interface. The mating interface, namely, the spacecraft side, then the two envelopes are compatible.
should be completely defined. Otherwise, the spacecraft de- Since interface data have been provided for the attachment
signer will be signing up to design a compatible interface by details for the launch vehicle side of the interface, the design
agreeing with what the interface on the launch vehicle side of the Cassini adapter for mounting to the Centaur launch
looks like. Although this approach allows freedom to go off and vehicle at station –150.199 can be explained by using the Titan
“do independent things,” it lacks the degree of positive control design data.

NASA RP–1370 37
Appendix C

Software Interface Example:

Definitions and Timing Requirements for Safety
Inhibit Arm Signals
Signal definition Centaur sequence Initiating event + time Persistence Function
control unit
switch number

Satellite vehicle (SV) 45 Main engine cutoff 3±0.5 sec Unshorts SV pyro capacitor banks
pyro unshort (MECO) 2 + 3±0.5 sec
(primary)

SV latch valve 33 MECO2 + 10±0.5 sec 3±0.5 sec Arms safety inhibit relay for SV
arm (primary) main engines

SV pyro unshort 89 MECO2 + 15±0.5 sec 3±0.5 sec Provides redundant unshort of SV
(secondary) pyro capacitor banks

SV latch valve 88 MECO2 + 17±0.5 sec 3±0.5 sec Provides redundant arm of inhibit
arm (secondary) relay for SV main engines

Radiofrequency 34 Titan IV/Centaur 3±0.5 sec Services backup (redundant to SV

monopropellant driver separation + 24±0.5 sec ground support equipment com-
backup enable mand) enable of safety inhibit SV
functions (radiofrequency sources
and reaction control system thruster
drivers)

38 NASA RP–1370
Appendix D

Supplied Services Interface Example

This appendix provides a simplistic text-based example of a numbers, location on the drawing, brief description, and due
supplied services (air-conditioning and cooling water) inter- date. The DDR block (fig. D.1) on the drawing expands on this
face control document with a typical design-data-required information and identifies supplier, user, and time urgency of
(DDR) block. This example contains elements condensed from the data needed. The DDR numbering convention used here is
a number of service documents originally used for a submarine “V09 = Void #09.” Preceding the void number with the ICD
weapons program; however, the principles contained herein are number provides a program-unique DDR number that is easily
universally applicable to any complex system of interfaces. related to its associated ICD and easily maintained in a data
Page 1 of the ICD lists the DDR’s (table D.1) showing DDR base.

TABLE D.1.—DESIGN-DATA-REQUIRED SUMMARY

AND LOCATOR
Void Location Description Date due
number

V01
A
V09 Sheet 1, Main heating 30 Days after
zone C–7 and cooling authentication of
(MHC) water data fulfilling
schedule DDR 5760242–V12
A

DDR No. 1466134–V09

Data required: Heating and cooling (HC) system upper zone
water schedule (supply water temperature versus
environmental temperature)

Data supplier: HC working group

Data user: Launch vehicle design agent

Date due: 30 days after authentication of data fulfilling DDR No.

2543150–V12

Figure D.1.—Typical design-data-required block.

NASA RP–1370 39
The following pages present the kinds of data required to fully g. Air quality: Air at the inlet to the equipment shall
define the air-conditioning requirements for suites of equip- be equivalent to or better than air filtered through
ment located in a launch control center. Table D.2 details a 0.3-µm filter with an efficiency of 95%.
conditioned-air distribution; table D.3 presents typical inter- 2. The closed-loop system shall have the capacity of
face data required to ensure that a cooling water service is removing 52.8 kW (minimum) of heat dissipated by
provided to electrical equipment and indicates requirements for equipment using closed-circuit conditioned air. This
the equipment before and after the incorporation of an engi- heat load includes 1.3 kW reserved for launcher
neering change. equipment in the launch vehicle control center (see
note 702 below).
701. Launch vehicle control center services:
A. Air-conditioning shall be provided with a dedicated 702. The system shall provide the capability of removing
closed-circuit system capable of supplying a mini- 1.65 kW minimum of heat dissipated by equipment by using
mum total flow of 12 820 scfm with a 50% backup compartment ambient air as a cooling medium while maintain-
capability. ing the compartment within specified limits.
1. The conditioned air shall be distributed to each A. The ship shall take no action that eliminates the option
equipment flue as specified in table D.2. The distrib- for launcher equipment to use compartment ambient air
uted conditioned air at the inlet to the equipment or closed-circuit conditioned air for dissipating launcher-
shall satisfy the following parameters: generated heat of 1.3 kW.
a. Temperature: The minimum temperature shall be B. Heat dissipated to ambient air by equipment using
65 °F and the maximum, 70 °F. closed-circuit conditioned air is not included.
b. Humidity: The maximum humidity shall be 75
grains per pound of dry air. 703. The system shall provide distribution trunks to equip-
c. Working pressure: The working pressure shall ment flues with total flow capacity as designated below for the
be enough to overcome equipment pressure drops conditions of table D.2:
and to maintain positive pressure at the equip-
ment outlet with respect to compartment ambi-
ent pressure. A 10% minimum leakage rate in the Trunk Minimum
compartment shall be assumed. flow,
d. Flow resistance: The system shall be able to over- scfm
come the pressure drop across the equipment (i.e., A 2700
from exit of orifice plate to top of equipment) as B 1620
shown in table D.2. C 2300
D 3400
e. Flow profile:
E 1300
(1) The flow distribution for each flue shall be F 1500
such that the flow velocity between the flue
centerline and 1.3 in. from the edge of the flue,
and (where equipment permits) 6 in. above the
flue gasket, shall not be less than 80% of the 704. Flow at reference designations marked with an asterisk
achieved average flow velocity. The achieved in table D.2 are to be considered flow reserve capabilities.
average flow velocity must equal or exceed veloc- These designated flues do not require verification of flow per
ity based on the minimum flow rate specified in table D.2 nor profiling per note 701.A.1.e(1) until these flues
table D.2. are activated. The Government-furnished pipe assemblies and
(2) Velocity profiling is not required for flues caps will be supplied for flues not activated.
designated 301 through 310, 011 through 015,
446BC, 405–2A, 405–2B, 405–6A, and 405–6B. 705. The minimum flow for flues 446BC and 447BC is
f. Adjustment capability: The system shall provide 100 scfm before change 30175 and 250 SCFM after change
flow adjustment from 0 to 300 scfm at each of the 30175.
equipment flues requiring velocity profiling.

40 NASA RP–1370
 TABLE D.2.—CONDITIONED-AIR DISTRIBUTION
Equipment Trunk Flue Minimum Flow resistance/
(see note flow, pressure drop at
703) scfm minimum flow (see
note 701A.1.d),
in. H2 O

Data cabinets A 301B 225 0.54

301C 260 –––
305B 80 .50
305C 80 .50
306B 290 .56
306C 50 .50

Data console A 308B 100 .50

308C 50 .50
309 0* –––
310B 135 .50
310C 50 .50

Control console E 405–2A 100 1.0

405–2B 100
405–6A 50
405–6B 50

Power buffer and B 011 440 2.0

conversion 012 440
013–1 150
013–2 150
015 440

Control computer D 440BC 200 1.0

group 440–441D 300
444BC 300
444–445D 250

446BC See note

447BC 705

E 471 200

Control group E 450BC 200

450–451D 200
451BC 100

C 452BC 200
452–453D 200
458BC 200
458–459D 200
459BC 150*

E 472 150*

Power distribution F 002BC 150

003BC 150
004BC 150*
004D 150*

Load F 271BC 275 1.0

271D 0* 0
005BC 100* 1.0
005D 0* 0
*Flow reserve capability.

NASA RP–1370 41
 TABLE D.3.—WATER FLOW RATE INTERFACE PARAMETERS

[Water inlet temperature: 54 °F max and 48 °F min; temperature alarm set at 56 °F ±1 deg F (increasing) and 47 °F ± 1 deg F (decreasing); see Remarks.
Working pressure: 85 psig max and 57 psig min. Test pressure, 125 psig max with binnacles to be isolated at vehicle hydrostatic test.
Pressure drop: nominal differential pressure range, 13 to 23 psid ref. Water quality: dual filters required;
filters to 10 µm with 98% efficiency by weight, 20 µm absolute.]
Function Minimum cooling Water flow rate Remarks
capability

Electrostatically supported 2.25-kW gain a6.0-gal/min nominal total flow for two Reliability of water supply shall support a navigation
gyro navigator (ESGN) and ESGN binnacles and one GSS binnacle. subsystem availability of 0.97. This service requirement
gravity sensor system (GSS) The supply shall maintain constant flow shall be continuously available during patrol and refit.
binnacle cooling of 2.0 gal/min ±10% to each binnacle. The water temperature shall not vary by more than
6 deg F when changing at the rate of 0.25 deg F/sec
maximum. This change shall not occur more than once
bA remote, low-flow alarm shall be pro- per 30-min period.
vided for the ESGN binnacles and the
GSS binnacle.

Reserve capability for future 3.25-kW gain 2.6-gal/min minimum

navigation development

ESGN binnacle cooling 1.5-kW gain a4.0-gal/min nominal total flow for two
ESGN binnacles. The supply shall main-
tain a constant flow of 2.0 gal/min ±10%
to each binnacle.

bA remote, low-flow alarm shall be pro-

vided for the ESGN binnacles.

Reserve capability for future 4.0-kW gain 4.5-gal/min minimum

navigation development

aThe system shall provide test connections at the inlet and outlet of each binnacle to permit periodic measurement of differential pressure.
bLocal flow indication shall be provided for each binnacle.

42 NASA RP–1370
Appendix E

Compatibility Analysis
E.1 Definition depends on the signal type (e.g., analog or digital)
and the intended use. In general, the interface must
Compatibility analysis of the interface definitions contained in show the characteristics of the isolating device (ele-
an ICD is a major tool of interface control. It serves a twofold ment) on each side of the interface and define the
purpose: signal characteristics in engineering terms suitable
for the particular type of signal.
1. Demonstrates completeness of interface definition. If any 4. Timing and other functional interdependencies
interface data are missing or presented in a manner that cannot be 5. System handling of error conditions
integrated by using the ICD alone as a data source, the ICD is 6. Full definition of any standards used. Most digital
considered deficient. transmission standards have various options that
2. Provides a record (traceability) that the interface has been must be selected; few, if any, standards define the
examined and found to have the right form and fit. This record data that are passed.
can then be used in evaluating the acceptability of subsequent B. Steps to be followed
change proposals. 1. Verify interoperability of connectors.
2. Size cables to loads.
3. Determine cable compatibility with signal and envi-
E.2 Kinds of Data ronmental conditions.
4. Define data in one document only.
The following compilation identifies the kinds of data that 5. Determine adequency of circuit protection devices
must be obtained for a compatibility analysis and outlines the and completeness of signal definition.
general steps that should be followed for three categories of II. Interface category—mechanical/physical
interface: electrical/functional, mechanical/physical, software, A. Type of interface—form and fit
and supplied services: 1. Data required to perform analysis
a. A datum (reference) that is common to both sides
I. Interface category—electrical/functional of the interface (e.g., a mounting hole in one part
A. Data required to perform analyses that will mate with a hole or fastener in the other
1. The following parameters are required, considering mating parts or a common mating surface of the
the specific function or signal involved: two mating parts)
a. Cabling and connectors b. Dimensions and tolerances for all features of each
b. Power requirements part provided in a manner that gives the optimum
c. Electromagnetic interference, electromagnetic interface fit and still provides the required design
compatability, electromagnetic radiation, and functions. Optimum interface means dimension-
grounding requirements ing so that the tolerance accumulation is kept to a
d. Functional flow and timing requirements minimum.
e. Signal definition 2. Steps to be followed
f. Digital data definition to the bit level a. Start with the common datum and add and subtract
g. Protocol levels dimensions (adding the tolerance accumulations
h. Seven-layer International Standards Organization for each dimension) for each feature of the part
open systems instruction stack definition or its interface.
equivalent b. Determine the dimensional location of the
i. Error recovery procedures interface-unique features by adding and subtract-
j. Startup and shutdown sequences ing the tolerance accumulations from resulting
k. Adequacy of standards used or referenced dimensions to achieve the worst-case maximum
2. Unique requirements for an interface or a piece of and minimum feature definitions.
equipment different from overall system require- c. Perform the same analysis for the mating features
ments (i.e., the hierarchy of specifications required) of the interfacing part.
3. Adequate definition of all signals crossing the inter- d. Compare and question the compatibility of the
face. “Adequate” is difficult to define precisely but worse-case features of the two mating parts (Will

NASA RP–1370 43
 the maximum condition of one part fit within the functional ICD. The purpose of an ICD is to communi-
minimum condition of the mating part?) cate equipment interface requirements to programmers
B. Type of interface—structural load in terms that the programmers readily and accurately
1. Data required to perform analysis understand and to require equipment designers to con-
a. A description of the loading conditions (static or sider the effect of their designs on computer programs.
dynamic) and the duration of those conditions B. Type of interface—hardware/software integration. The
b. Characteristics of the equipment involved: weight ICD provides an exact definition of every interface, by
or mass; mass distribution; elastic properties; and medium and by function, including input/output
sensitivity of elastic properties to temperature, control codes, data format, polarity, range, units, bit
moisture, atmospheric gas content, pressure, etc. weighting, frequency, minimum and maximum timing
2. Steps to be followed. This analysis involves placing constraints, legal/illegal values, accuracy, resolution,
the interfacing items in a position that produces the and significance. Existing documentation may be ref-
maximum loads while the items are interfacing. A erenced to further explain the effect of input/output
space experiment is primarily designed for flight operations on external equipment. Testing required to
loads, yet it must withstand the loads developed validate the interface designs is also specified.
during the launch and deployment cycles and per- IV. Interface category—supplied services
haps unique loads during launch processing. The A. Type of interface—fluid service
complexity of the compatibility analysis will vary 1. Data required to perform analysis
depending on the types of interfacing items and a. Type of fluid required by the equipment and
environments. type of fluid the service supplier will provide.
a. Attachment loads are the simplest, being a state- This may be in the form of a Federal or military
ment of the loads applied by the attaching feature specification or standard for both sides or for
(bolt) and the load capability of the component one side of the interface.
being retained (flange). b. Location of the equipment/service interface
b. Hoisting and handling loads require the calcula- (hose connection, pipe fitting, etc.)
tion of bending moments or shear for various c. Equipment requirements at the interface loca-
loading scenarios. Dynamic and environmental tion in regard to characteristics (pressure, tem-
loads must also be considered. (How quickly is the perature, flow rate, duty cycle, etc.)
load applied? What are the wind loading factors?) d. Capability of the service supplier at the interface
c. A more complex situation will be the loads devel- location
oped during a dynamic interaction of interfacing e. Manner in which the equipment can affect the
items where different material characteristics must capability of the service supplier (e.g., having a
be considered along with the reaction characteris- large backpressure that the supplier fluid must
tics of the materials (e.g., a flexible beam of push against or a combination of series and
varying moments of inertia supported by an elas- parallel paths that the supplier fluid must pass
tomeric medium where the entire system is through)
subjected to a high-velocity impulse of a few 2. Steps to be performed. Examine the supplier and
microseconds duration). Such a condition could equipment requirements to determine
produce loads that exceed those for which one of a. If the supplier capability meets or exceeds the
the interfacing items is designed. Another inter- equipment requirements. This may require con-
facing item may have to be redesigned so as not to verting a Federal/military specification or stan-
jeopardize the mission of the primary item (i.e., dard requirement into what is specified for the
increasing the strength of the item being supported equipment.
could increase the weight). b. If the supplier capability meets the require-
III. Interface category—software ments, considering the effects resulting from the
A. Type of interface—software. The ICD is required to fluid passing through the mating equipment
specify the functional interface between the computer B. Type of interface—environmental
program and any equipment hardware with which it 1. Data required to perform analysis
must operate. Often, the supplier documentation for a. Conditions required for equipment to function
standard computer peripherals and terminals is ad- properly. Storage, standby, and operating
equate for this purpose. Conversely, it has been found scenarios need to be established and defined.
that performance specifications governing the design b. Supplier’s capability to provide the environ-
of new equipment are not satisfactory for use in a ment specified in terms of time to reach steady

44 NASA RP–1370
 state from transients resulting from uncontrol- a. Simple inspection, which considers the environ-
lable external environments; the limits of the ment required by an item versus the capability of
steady-state conditions (maximum/minimum); the ambient in which the item resides
and monitoring features b. Complex analysis, which must consider uncon-
2. Steps to be performed. Perform analyses (e.g., trolled external environmental inputs, the ther-
thermal) under extreme and nominal environmen- mal properties of intermediate systems that do
tal conditions to verify that supplier’s equipment not contribute to the end environment but act as
can maintain the environment required for the conduits or resistors in the model, and the inter-
equipment. The complexity of the analysis may action of the item and the system that controls
vary depending on the types of items involved. the desired environment

NASA RP–1370 45
Appendix F
Bracket System for Interfaces
Brackets are used on hardware/engineering drawings to flag 5. Drawing errors not affecting element construction
or identify details controlled by the ICD. Changes cannot be B. Rating A2: Significant degradation to interface or
made to the drawings or designs without the effects on the mission performance
interface being assessed and coordinated through the ICD 1. Appreciable change in functional capability
process. 2. Appreciable degradation of engineering or science
The process uses a rating similar to that used in the problem/ data
failure reporting bracket system with the same controls and 3. Significant operational difficulties or constraints
traceability. Once a bracket has been assigned to an interface 4. Decrease in life of interfacing equipment
void or problem, specific analyses and actions are required for 5. Significant effect on interface or system safety
the bracketed item to be removed. The bracketed item remains C. Rating A3: Major degradation to interface or mission
in open status with assignment to the responsible cognizant performance or catastrophic effect on interface or
subsystem or design section until (1) the corrective action or system safety
coordinated information has been developed, (2) a proper risk II. Interface deficiency rating B (understanding of risk)
assessment has been performed, (3) ICD change actions have A. Rating B1: Effect of interface deficiency is identified
been completed, (4) adequate verification of the interface is by analysis or test, and resolution or corrective
planned, and (5) the proper approval signatures have been action is assigned and scheduled or implemented
obtained. and verified. There is no possibility of recurrence.
The following ratings are used to establish a category of B. Rating B2: Effect of interface deficiency is not fully
“bracket” identifiers for interface deficiencies. Any discrep- determined. However, the corrective action proposed,
ancy having an A rating greater than 1 or a B rating greater than scheduled, or implemented is considered effective in
2 will be designated a bracketed discrepancy (see figure F.1). correcting the deficiency. There is minimal possibility
of recurrence and little or no residual risk.
I. Interface deficiency rating A (S&MA impact) C. Rating B3: Effect of interface deficiency is well
A. Rating A1: Negligible effect on interface or mission understood. However, the corrective changes pro-
performance posed do not completely satisfy all doubts or concerns
1. No appreciable change in functional capability (form, regarding the correction, and the effectiveness of
fit, and function are adequate for the mission) corrective action is questionable. There is some poss-
2. Minor degradation of engineering or science data ibility of recurrence with residual risk.
3. Support equipment or test equipment failure but not D. Rating B4: Effect of interface deficiency is not well
mission-critical element failure understood. Corrections have not been proposed or
4. Support-equipment- or test-equipment-induced those proposed have uncertain effectiveness. There is
failures some possibility of recurrence with residual risk.

46 NASA RP–1370
 Interface discrepancy red flag;
project or task manager approval required

Rating A Numerical rating Rating B

(S&MA impact) (understanding of risk)

Negligible 1 1 Known deficiency with corrective action

impact assigned, scheduled, and implemented

Significant 2 2 Deficiency poorly defined but acceptable

degradation corrective action proposed, scheduled, and
implemented (low residual risk)

Major 3 3 Known deficiency but effectiveness of

degradation corrective action is unclear and does not
satisfy all doubts and concerns (residual risk)

4 Impact not defined with confidence;

corrective action with uncertain
effectiveness (residual risk)

Figure F.1.—Interface deficiency rating system.

NASA RP–1370 47
Appendix G
ICD Guidelines
1. Interface control documents should not require the designer of the
mating interface to assume anything. ICD’s should be compatible with
each other and stand alone.

2. Only the definition that affects the design of the mating interfaces
need be used.

3. ICD’s should not specify design solutions.

4. The ICD custodian should be independent of the design organiza-

tion.

5. The ICD custodian should verify that the data being controlled by
an ICD are sufficient to allow other organizations to develop the
interface described by the ICD.

6. An interface control system should be in place at the beginning of

system (hardware or software) development.

7. Each void should have a unique sequential identifier establishing

due dates, identifying exact data to be supplied, and identifying the data
supplier.

48 NASA RP–1370
Appendix H
Glossary
baseline—The act by which the program manager or a desig- of equipment and (2) providing an authoritative means of
nated authority signs an interface control document (ICD) and controlling the interface design.
by that signature establishes the genuineness of the ICD as an
official document defining the interface design requirements. interface control document (ICD)—A drawing or other docu-
The term “baseline” conveys the idea that the ICD is the only mentation that depicts physical and functional interfaces of
official definition and that this officiality comes from the related or cofunctioning items. (The drawing format is the most
technical management level. Not only is the initial version of common means of controlling the interface.)
the ICD baselined, but each change to an ICD is likewise
approved. interface control working group—A group convened to
control and expedite interface activity between the Govern-
comment issue—An issue of an ICD distributed for review and ment, contractors, and other organizations, including resolu-
comment before a meeting of the affected parties and before tion of interface problems and documentation of interface
baselining agreements

custodian—The contractor or project assigned the responsibil- interface definition—The specification of the features, char-
ity of preparing and processing an ICD through authentication acteristics, and properties of a particular area of an equipment
and subsequently through the change process design that affect the design of another piece of equipment

data—Points, lines, planes, cylinders, and other geometric interoperability—The ability of two devices to exchange
shapes assumed to be exact for the purpose of computation and information effectively across an interface
from which the location or geometric relationship (form) of
features of a piece of equipment can be established mechanical/physical interface—An interface that defines the
mechanical features, characteristics, dimensions, and toler-
interface responsibility matrix—A matrix of contractors, ances of one equipment design that affect the design of another
centers, and project organizations that specifies responsibilities subsystem. Where a static or dynamic force exists, force
for each ICD listed for a particular task. Responsibilities are transmission requirements and the features of the equipment
designated as review and comment, technical approval, that influence or control this force transmission are also de-
baselining, and information. fined. Mechanical interfaces include those material properties
of the equipment that can affect the functioning of mating
electrical/functional interface—An interface that defines the equipment or the system (e.g., thermal and galvanic
interdependence of two or more pieces of equipment when the characteristics).
interdependence arises from the transmission of an electrical
signal from one piece of equipment to another. All electrical software interface—The functional interface between the
and functional characteristics, parameters, and tolerances of computer program and any equipment hardware with which it
one equipment design that affect another equipment design are must operate. Tasking required to validate the interface designs
specified. is also specified.

interface—That design feature of one piece of equipment that supplied-services interface—Those support requirements that
affects a design feature of another piece of equipment. An equipment needs to function and that are provided by an
interface can extend beyond the physical boundary between external separate source. This category of interface can be
two items. (For example, the weight and center of gravity of further subdivided into environmental, electrical power, and
one item can affect the interfacing item; however, the center of communication requirements.
gravity is rarely located at the physical boundary. An electrical
interface generally extends to the first isolating element rather technical approval—The act of certifying that the technical
than terminating at a series of connector pins.) content in an interface document or change issue is acceptable
and that the signing organization is committed to implementing
interface control—The process of (1) defining interface re- the portion of the interface design under the signer’s cognizance.
quirements to ensure compatibility between interrelated pieces

NASA RP–1370 49
 FED–STD–209E: Airborne Particulate Cleanliness Classes in Cleanrooms and
References Clean Zones. Federal Standard, Sept. 1992.

KHB 1860.1: Kennedy Space Center Ionizing Radiation Protection Program.

1. MIL–STD–499: Engineering Management. May 1974. Kennedy Space Center, FL, 1972.
2. Blanchard, B.S.; and Fabrycky, W.J.: Systems Engineering and Analysis.
Prentice-Hall Inc., 1981. MCR–86–2550: Titan IV System Contamination Control Plan. Martin Marietta
3. MIL–STD–1521B: Technical Reviews and Audits for Systems, Equip- Aerospace Corp., Denver, CO, or Bethesda, MD, 1987.
ment, and Computer Software, Notice 1, Dec. 1985.
4. Kockler, F.; Withers, T.; Poodiack, J.; and Gierman, M.: Systems Engi- MIL–B–5087B: Bonding, Electrical and Lightning Protection for Aerospace
neering Management Guide. Defense Systems Management College, Systems. Military Standard, Dec. 1984.
Fort Belvior, VA, Jan. 1990.
5. ICD–Titan IV/Satellite Vehicle–24027, Cassini Mission. Martin Marietta MIL–N–7513F: Nomenclature Assignment, Contractor’s Method for Obtain-
Technologies, Inc., Denver, CO, Jan. 1994. ing. Military Standard, Notice 2, July 1993.
6. MIL–STD–490A: Specification Practices. Military Standard, June 1985.
7. ANSI Standard Y14.5: Dimensioning and Tolerancing. MIL–HDBK–259: Life Cycle Cost in Navy Acquisitions. Military Handbook,
8. DOD–STD–100: Engineering Drawing Practices. Apr. 1983.
9. SAMSO–STD 77–4: Format and Requirements for Interface Documents.
Space & Missile Systems Org., Jan. 1979. MIL–P–27401C: Propellant Pressurizing Agent, Nitrogen. Military Standard,
10. MIL–STD–704: Aircraft Electrical Power Characteristics. Aug. 1988.

MIL–S–83490: Specifications, Types and Forms. Military Standard, Oct.

1968.

Bibliography MIL–STD–100E: Engineering Drawing Practices. Military Standard, Sept.

1992.

MIL–STD–482A: Configuration Status Accounting Data Elements and Re-

AFR 65–3, AR 70–37, NAVELEXINST 4130.1, and 4139.1A: Joint Services lated Features. Military Standard, Sept. 1968.
Regulation on Configuration Management. Air Force Regulation, Naval Elec-
tronics Systems Instructions, Marine Corp Order. MIL–STD–973: On Configuration Management Practices for Systems, Equip-
ment, Munitions, and Computer Software. Military Standard, 1993.
AFSCP 800–7: Configuration Management. Air Force Systems Command
Pamphlet. MIL–STD–1246C: Product Cleanliness Levels and Contamination Control
Program. Military Standard, Apr. 1994.
DOD 4120.3–M: Defense Standardization and Specification Program Policies,
Procedures and Instructions, Aug. 1978. MIL–STD–1388–1A: Logistic Support Analysis Reviewer. Military Standard,
Mar. 1991.
DOD 4245.7–M: Transition From Development to Production. Military Speci-
fication, Sept. 1985. MIL–STD–1456: Contractor Configuration Management Plans. Sept. 1989.
(Cancelled July 1992.)
DOD 5010.19: Configuration Management. Military Specification, July 1990.
MIL–STD–1528A: Manufacturing Management Program. Military Standard,
DOD–D–1000B: Drawings, Engineering and Associated Lists. Military Speci- Sept. 1986.
fication, July 1990.
MIL–STD–1541: Electromagnetic Compatibility Requirements for Space
DOD–STD–480B: Configuration Control—Engineering Changes, Deviations, Systems. Military Standard, Dec. 1987.
and Waivers, July 1988. (Cancelled July 1992.)
PD 699–120: Cassini Final Targeting Specification. Program Directive, NASA
ESMC Req 160–1: Radiation Protection Program. Eastern Space & Missile or Executive Office of the President.
Center, Patrick AFB, FL.
SECNAVINST 4130: Navy Configuration Management Manual. Executive
Fairley, R.E.: Software Engineering Concepts. McGraw-Hill, New York, Office of the Secretary of the Navy.
1985.

50 NASA RP–1370
Training Answers
Chapter Answers

1 1(A); 2(D); 3(C); 4a(C), 4b(A), 4c(B)

2 1(D); 2(C); 3a(B), 3b(C); 4a(C), 4b(C), 4c(C);

5a(A), 5b(A), 5c(A); 6a(C), 6b(A), 6c(A);
7a(B), 7b(B), 7cA(i), 7cB(ii), 7cC(i); 8a(B),
8b(A); 9a(A), 9b(A), 9c(B)

3 1a(A), 1b(B), 1c(B); 2a(B), 2b(A), 2c(B);

3a(A), 3b(B), 3c(A); 4a(B), 4b(A), 4c(B);
5a(A), 5b(B); 6a(A), 6b(B), 6c(B), 6d(B);
7a(B), 7b(A), 7c(A), 7d(A), 7e(A)

NASA RP–1370 51
 Form Approved
REPORT DOCUMENTATION PAGE OMB No. 0704-0188
Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources,
gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this
collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson
Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503.

1. AGENCY USE ONLY (Leave blank) 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED
January 1997 Reference Publication
4. TITLE AND SUBTITLE 5. FUNDING NUMBERS

Training Manual for Elements of Interface Definition and Control

6. AUTHOR(S)
WU–323–42–02

Vincent R. Lalli, Robert E. Kastner, and Henry N. Hartt

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION

REPORT NUMBER

National Aeronautics and Space Administration

Lewis Research Center E–9790
Cleveland, Ohio 44135 – 3191

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSORING/MONITORING

AGENCY REPORT NUMBER

National Aeronautics and Space Administration

Washington, DC 20546– 0001 NASA RP–1370

11. SUPPLEMENTARY NOTES

This manual was edited by Vincent R. Lalli, NASA Lewis Research Center; Robert E. Kastner, Vitro Corporation,
Rockville, Maryland; and Henry N. Hartt, Vitro Corporation, Washington, DC. Responsible person, Vincent R. Lalli,
(216) 433–2354.
12a. DISTRIBUTION/AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE
Unclassified - Unlimited
Subject Category 15
This publication is available from the NASA Center for Aerospace Information, (301) 621–0390.
Multiple copies are for sale by the National Technical Information Service, Springfield, VA 22161,
(703) 487–4822.
13. ABSTRACT (Maximum 200 words)

The primary thrust of this manual is to ensure that the format and information needed to control interfaces between
equipment are clear and understandable. The emphasis is on controlling the engineering design of the interface and not on
the functional performance requirements of the system or the internal workings of the interfacing equipment. Interface
control should take place, with rare exception, at the interfacing elements and no further. There are two essential sections
of the manual. Chapter 2, Principles of Interface Control, discusses how interfaces are defined. It describes different types
of interfaces to be considered and recommends a format for the documentation necessary for adequate interface control.
Chapter 3, The Process: Through the Design Phases, provides tailored guidance for interface definition and control. This
manual can be used to improve planned or existing interface control processes during system design and development. It
can also be used to refresh and update the corporate knowledge base. The information presented herein will reduce the
amount of paper and data required in interface definition and control processes by as much as 50 percent and will shorten
the time required to prepare an interface control document. It also highlights the essential technical parameters that ensure
that flight subsystems will indeed fit together and function as intended after assembly and checkout.

14. SUBJECT TERMS 15. NUMBER OF PAGES

Systems engineering; Configuration control; Documentation; 60

16. PRICE CODE
Change notices; Interface management
A04
17. SECURITY CLASSIFICATION 18. SECURITY CLASSIFICATION 19. SECURITY CLASSIFICATION 20. LIMITATION OF ABSTRACT
OF REPORT OF THIS PAGE OF ABSTRACT
Unclassified Unclassified Unclassified
NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89)
Prescribed by ANSI Std. Z39-18
298-102