The definition, management, and control of interfaces are crucial to successful programs or projects. Interface management is a process to assist in controlling product development when efforts are divided among parties (e.g., Government, contractors, geographically diverse technical teams, etc.) and/or to define and maintain compliance among the products that should interoperate.
Interface control document (ICD)
An interface control document serves as a contract between two parties to ensure the compatibility of their respective systems. The document thoroughly defines all points and methods of interaction of the two systems. The level of detail should eliminate the need for any assumptions by either party and allow for compatibility even under worst-case tolerances.
The creation of an interface control document typically commences after system requirements have been set
In the instance of a service-oriented relationship, especially, the ICD is essential for defining expectations. The customer is assured of the available services for their payload and given guidelines for design development. The spacecraft provider ensures the safety of their system as well as any other customers’ payloads and renders the eventual integration process more efficient. Furthermore, the document facilitates clear communication between the two parties.
The Spacecraft section is a significant inclusion to the service-oriented space program interface control document. The Overview subsection will summarize the spacecraft mission objectives and major subsystems.
The Mission Profile section describes the mission timeline of the spacecraft. The Overview will define the distinct mission phases and describe the critical events within each. A typical mission flow should be provided here. however, the specification of discrete mission phases allows for a clear and uniform way to describe how elements may change throughout the mission timeline. The Environments subsection will define and quantify relevant
Any interface can be described in terms of its physical and functional characteristics.
The Payload Operational Modes subsection should identify and define the modes of operation expected of each payload. A description, and rationale should be provided for each mode. The spacecraft provider should be sure to specify in which mode the payload should power up.
The basic tasks that need to be established involve the management of internal and external interfaces of the various levels of products and operator tasks to support product integration. These basic tasks are as follows:
- Define interfaces;
- Identify the characteristics of the interfaces (physical, electrical, mechanical, human, etc.);
- Ensure interface compatibility at all defined interfaces by using a process documented and approved by the project;
- Strictly control all of the interface processes during design, construction, operation, etc.;
- Identify lower level products to be assembled and integrated (from the Product Transition Process);
- Identify assembly drawings or other documentation that show the complete configuration of the product being integrated, a parts list, and any assembly instructions (e.g., torque requirements for fasteners);
- Identify end-product, design-definition-specified requirements (specifications), and configuration documentation for the applicable work breakdown structure model, including interface specifications, in the form appropriate to satisfy the product life cycle phase success criteria (from the Configuration Management Process); and
- Identify product integration-enabling products (from existing resources or the Product Transition Process for enabling product realization).
Typical inputs needed to understand and address interface management would include the following:
- Interface Requirements: These include the internal and external functional, physical, and performance interface requirements developed as part of the Technical Requirements Definition Process for the product(s).
- Interface Change Requests: These include changes resulting from program or project agreements or changes on the part of the technical team as part of the Technical Assessment Process.
Other inputs that might be useful are:
- System Description: This allows the design of the system to be explored and examined to determine where system interfaces exist. Contractor arrangements will also dictate where interfaces are needed.
- System Boundaries: Documented physical boundaries, components, and/or subsystems, which are all drivers for determining where interfaces exist.
- Organizational Structure: Decisions on which organization will dictate interfaces, particularly when there is the need to jointly agree on shared interface parameters of a system. The program and project WBS will also provide organizational interface boundaries.
- Boards Structure: Defined board structure that identifies organizational interface responsibilities.
Typical outputs needed to capture interface management would include:
- Interface control documentation. This is the documentation that identifies and captures the interface information and the approved interface change requests. Types of interface documentation include the Interface Requirements Document (IRD), Interface Control Document/Drawing (ICD), Interface Definition Document (IDD), and Interface Control Plan (ICP). These outputs will then be maintained and approved using the Configuration Management Process and become a part of the overall technical data package for the project.
- Approved interface requirement changes. After the interface requirements have been baselined, the Requirements Management Process should be used to identify the need for changes, evaluate the impact of the proposed change, document the final approval/disapproval, and update the requirements documentation/tool/database. For interfaces that require approval from all sides, unanimous approval is required. Changing interface requirements late in the design or implementation life cycle is more likely to have a significant impact on the cost, schedule, or technical design/operations.
- Other work products. These work products include the strategy and procedures for conducting interface management, the rationale for interface decisions made, the assumption made in approving or denying an interface change, the actions taken to correct identified interface anomalies, the lessons learned in performing the interface management activities, and the updated support and interface agreement documentation.