Phoenix Rodden




"Practices Guide: Interface Control." <http://www.hhs.gov/ocio/eplc/EPLC%20Archive%20Documents/31-Interface%20Control/eplc_interface_control_practices_guide.pdf>.

This is a governmental guide on the best practices of project management, more specifically interface control. As said in the document, "The interface control document is one of the components of the Design Document. It is used to describe the inputs and outputs of a single system, the interface between two systems or the interface protocol between physical components." Interface control documents clearly document all the possible interactions between parts of a system. Level of detail, such as whether one describes even the smallest interactions like circuits and voltage, depends on individual requirements to complete the project. It is important that the interface control is used only to describe the interaction and not the actual characteristics, meaning, or intended use. This is important because groups don't need to know all the details of the interaction, only how the interaction is taking place, avoiding time lost due to confusion and learning such information. Interface control has the potential to have many levels, due to the different types of interfaces, such as network, physical, and application. This article also lists some of the best practices for interface control. It is important to follow all of these practices in order to have a successful, organized project and output. By following these practices, one can be sure to produce an output which is in line with the original requirements and intentions.




Majcen, K., and H. Vallant. "LEAF Interface Control Document." 23 Apr. 2003. Web. <http://www.crxnet.com/leaf/docs/ICD_JR04.pdf>.

This is an interface control document from LEAF (Linking and Exploring Authority Files), and was created "to ensure that the integration of the LEAF components developed by
different partners of the LEAF consortium can be performed without too many problems." The document is divided into sections. The first section describes the scope of the document, i.e. what is the purpose and who will be reading the document. The next sections describes the overall system, including a basic diagram of the highest level interfaces. The sections that follow break down the interfaces even more, down to the most basic data movement between structures. These sections are bulleted with lists of what requirements each interface needs to function. The document ends with definitions and references to provide context and clarification. It should be noted that in other examples of these documents, depending on who the document is intended for, the definitions and references are placed at the beginning, an organization most likely intended for those with little to no experience with the system being described.


Jenna Shorkey




John S. Yaniec and Dominic Del Rosso. "Interface Control Document NASA 932 C-9B" 7 Jan. 2008. Web. <http://jsc-aircraft-ops.jsc.nasa.gov/Reduced_Gravity/docs/AOD_33912.pdf>.

This is an example of an interface control document from NASA detailing their "guideline for existing and potential users of the Reduced Gravity Program. This document provides detailed interface definition." The ICD is divided into two sections. The first detailing the aircraft, and the second, the ground facilities. The first section goes in depth to describe the cabin environment and how it interfaces with the electrical and power. This document was written with the assumption that the reader has a large amount of experience with NASA's projects. This can help the freshman in Imaging Science by giving them a template to read and emulate.




Dennis Coyne. "Laser Interferometer Gravitational Wave Observatory." 14 Jun. 2005. Web. <http://www.ligo.caltech.edu/~coyne/AL/Systems%20Site/ICD/E030647-01_master.pdf>.

This document details the company LIGO's interface between groups within the project. It also graphically shows how the groups within the project correlate to each other. It is not very in depth, because it is generally for the use of people involved in the project. However, it does detail how an interface control document can help a project, and how to present an ICD. This can help the freshman in the Imaging Science Project by giving them a template to work with while creating their own interface control document for the polynomial texture mapping device.

Carl Stahoviak



Jay Mace (University of Utah) and Qiuqing Zhang (University of Utah). "CloudSat Project: 2B-GEOPROF-LIDAR Interface Control Document." 7 November 2007. http://www.cloudsat.cira.colostate.edu/icd_pdf.php?avid=115&pvids=214

The CloudSat Project Interface Control Document for the LIDAR software system. This ICD is very simplified and only describes the I/O ports and a description of the data they communicate. Each of these I/O data channels contains information such as a time-stamp, latitude and longitude coordinates, the data type andrdata range, and other parameters to define the data on each of the I/O channels.



Byron K. Lichtenberg. "Zero Gravity Boeing 727-200 Interface Control Document." 30 January 2009. http://jsc-aircraft-ops.jsc.nasa.gov/Reduced_Gravity/docs/ZG-InterfaceControlDoc-RevA2.pdf

The Zero Gravity Corporation has designed an aircraft to be used by NASA to simulate a reduced/hyper gravity environment aboard a ZGC 727 aircraft. The parabolic flight pattern used to simulate varying gravity ranges can replicate the microgravity environment of space flight (0 g) as well as Lunar (1/6 g) , Martian, (1/3 g) or other reduced gravity levels. Increased or “hyper gravity” levels from 1.1 to 1.8 g can also be provided. The Interface Control Document for the Zero Gravity Program only discusses the interfaces between the aircraft and equipment as well as services and data provided by the aircraft.


To read more articles about online project management then checkout event project management.