DID FinderBack
Source
DI-MGMT-82411

Acquisition & Sustainment Data Package (ASDP) Interface Control Document (ICD)

The ASDP ICD specifies all shared boundaries between major system platforms, components, and subsystems to the lowest level, providing bidirectional traceability across interfaces.

Approval DateMay 16, 2023
AMSC NumberF10404
Preparing Activity11 (AFLCMC/EZSI)
Project NumberMGMT-2023-008
OPR—
DTIC ApplicableNo
GIDEP ApplicableNo
Limitation—
Applicable Forms—
Approval Limitation—
Form Version—
DID Formatfree_text
963C CompliantYes
DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.
Supersedes
—
Related
—

Description & Purpose

—

Application & Interrelationship

—

Use & Relationship

ASDP Interface Control Document (ICD) specifies all shared boundaries between major system platform(s), major system component(s), and subsystem components to the lowest level as defined by various physical, logical, and functional characteristics by providing bidirectional traceability. System is defined as the highest level of design hierarchy for the associated contract (e.g., system, subsystem, component) and all subordinate design levels to the lowest level of the architecture and corresponding interfaces. An interface is a relationship among two or more entities (modular system, subsystem, or major system component (e.g., Configuration Items (CIs), Computer Software Configuration Items (CSCIs)). An ICD can cover any number of interfaces (e.g., hydraulic, pneumatic, electrical, mechanical, software, etc.).

The ASDP ICD references all requirements imposed on one or more systems, subsystems, CIs, CSCIs, human machine interface, system integration laboratories (SILs), services (hardware, firmware, and software), or other components required to achieve one or more interfaces among these entities. All system interfaces utilizing the Government-approved Open Mission Systems (OMS) standard will be captured and any non-OMS compliant systems will be identified. Other interface information such as drawings, diagrams, tables, textual information, Computer Aided Design/Computer Aided Manufacturing (CAD/CAM), computer generated interface information, and any other physical interface depiction will be included in the ICD or referenced if delivered under a different DD Form 1423 on same contract. (Copies of this form are available online at https://www.esd.whs.mil)

a. This Data Item Description (DID) contains the format, content, and intended use information for the data deliverable resulting from the work task described in the solicitation.

Preparation Instructions

1Reference documents.The applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments, notices, and revisions, shall be as specified in the contract.
2Format.Following are the format requirements.
2.1The ASDP ICD shall be provided in Word, PDF, or SysML.When ICD is developed using digital tool(s) or software, the ICD shall be provided in native format in addition to Word or PDF format. If SysML is being used, the ICD shall be provided in native format and shall include view(s) or viewpoint(s) for the data required below.
2.2The Data Objects/Attributes and Associated Metadata (DOAM) listingshall be in a Microsoft Excel spreadsheet format in accordance with the template provided in the DOAM Specification attached to the contract. All data shall be in the English language. The final ICD shall have all outstanding changes incorporated before final delivery.
2.3The primary document shall be unclassified;classified content, if any, shall be placed in a separate classified appendix or annex.
3Content.The ASDP ICD shall consist of the following:
3.1Title page or data identifier.The document shall include a title page containing, as applicable: document number; volume number; version/revision indicator; security markings or other restrictions on the handling of the document; created date; released date; document title; name, abbreviation, and any other identifier for the system, subsystem, or item to which the document applies; organization for which the document has been prepared; name and address of the preparing organization; and distribution statement (as specified in the Contract Data Requirements List (CDRL)).
3.2Table of contents.The document shall contain a table of contents providing the number, title, and page number of each titled paragraph, figure, table, and appendix. For data in a database, system model, or other alternative form, this information shall consist of an internal or external table of contents containing pointers to, or instructions for, accessing each paragraph, figure, table, and appendix or their equivalents.
3.3Page numbering/labeling.Each page shall contain a unique whole page number (no decimal-number sequences) and display the document number and version/revision. For data in a database, system model, or other alternative form, files, view(s), viewpoint(s), or other entities shall be assigned names or numbers in such a way that desired data can be indexed and accessed.
3.4Response to tailoring instructions.If a paragraph is tailored out of this DID, the resulting document shall contain the corresponding paragraph number and title, followed by "This paragraph has been tailored out." For data in a database, system model, or other alternative form, this representation need occur only in the table of contents or equivalent.
3.5The numbering shown below designate the schema for the ASDP ICD.
3.5.1Scope.This section shall be divided into the following paragraphs.
3.5.1.1Identification.This paragraph shall contain a full identification of the systems, subsystems, CIs, CSCIs, manual operations, SILs, services, or other component applications to which the ICD applies. Each item will be assigned a unique identifier including, as applicable, identification number(s), title(s), abbreviation(s), version/revision number(s)/letters(s), and release number(s). Additionally, each interface will be designated as "Compliant OMS", "Non-Compliant OMS" or "Non-OMS" interface. OMS Compliance is assessed against the three tiers as called out in the Open Mission Systems (OMS) Standard (Copy of this standard can be found at https://restricted.vdl.afrl.af.mil/programs/oam/wiki/Main_Page).
3.5.1.2System overview.This paragraph shall briefly state the purpose of the systems, subsystems, CIs, CSCIs manual operations, SILs, services, or other component applications to which the ICD applies. It shall describe the general nature of the system and software; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.
3.5.1.3Document overview.This paragraph shall summarize the purpose and contents of this document and shall describe any security or privacy considerations associated with its use.
3.5.2ASDP ICD Referenced documents.This section shall list the number, title, revision, and date of all documents referenced in the ICD. This section shall also identify the source for all documents not available through normal Government stocking activities.
3.5.3Requirements.The ASDP ICD shall specify the requirements imposed on one or more systems, subsystems, CIs, manual operations, SILs, services, or other component applications to achieve one or more interfaces among these entities. Each requirement shall be assigned a project-unique identifier to support testing and traceability and shall be stated in such a way that an objective test can be defined for it. All requirements shall be annotated with associated qualification method(s) and traceable to system (subsystem or component, if applicable) requirements if not provided in those sections. Additionally, all system interfaces shall be designated either as utilizing the OMS Information Exchanges or OMS Isolators for external non-OMS systems, per the guidance outlined in the OMS Definition and Documentation (D&D) Standard between subsystems, services, and platforms. In the event a particular interface is critical (e.g., safety, operational, mission) to the execution of machine-to-machine command and control, other applicable specifications such as Universal Command & Control Interface (UCI) communication standards shall be documented as necessary. The degree of detail to be provided shall include those characteristics of the interfacing entities that are conditions for their acceptance. If an interfacing entity included in the ICD operates in multiple states or modes, each requirement or group of requirements for that entity shall be correlated to each unique state or mode. The correlation can be indicated by a table or other method, reference to an appendix, or by annotation of the requirements where they appear.
3.5.4Interface identification and diagrams.For each interface identified in Table 1, this paragraph shall include a project-unique identifier and shall designate the interfacing entities by name, number, version/revision, and documentation references, as applicable. The identification shall state which interface will be designated as "Compliant OMS or UCI", "Non-Compliant OMS or UCI" or "Non-OMS or UCI" interface, and which are being developed or modified (thus having interface requirements imposed on them). One or more interface diagrams shall be provided to depict the interfaces. The System, Subsystem, LRU, Component shall be cross referenced to the specification(s) and drawing tree. A summary table shall be included, see example below. The table shall also indicate part number along with the nomenclature name. This paragraph shall reference other documents (such as data dictionaries, standards for communication protocols, government approved OMS/UCI interface standards, etc.) in place of stating the information here. The requirements shall include the following, as applicable, presented in any order suited to the requirements, and shall note any differences in these characteristics from the point of view of the interfacing entities (such as different expectations about the size, frequency, or other characteristics of data elements):
3.5.4.1Priority that the interfacing entity(ies) must assign the interface.The priority shall be driven based on the following:
3.5.4.1.1Safety Critical Functions (SCFs)which are defined as a function whose failure to operate, or incorrect operation will directly result in a mishap of either Catastrophic or Critical severity. (AC-17-01/MIL-STD-882) (Copies of these documents are available online at https://quicksearch.dla.mil and https://usaf.dps.mil/teams/23230/Airworthiness/SitePages/Circulars.aspx)
3.5.4.1.2Mission Critical Functions (MCFs)which are defined as any function, the compromise of which would degrade the system effectiveness in achieving the core mission for which it was designed (Ref. DoDI 5200.44). Mission Critical Functions are analogous to Mission Essential Functions. (Copies of this document are available online at https://www.esd.whs.mil)
3.5.4.1.3Critical Program Information (CPI)which is U.S. capability elements that contribute to the warfighters' technical advantage, which if compromised, undermines U.S. military preeminence. U.S. capability elements may include, but are not limited to, software algorithms and specific hardware residing on the system, its training equipment, or maintenance support equipment. (DoDI 5200.39) (Copies of this document are available online at https://www.esd.whs.mil) NOTE: SCFs, MCFs, and F-CPI shall be determined during the Functional Thread Analysis
3.5.4.2Requirements on the type of interface (such as OMS or UCI standards, real-time information transfer, storage, and retrieval of information, etc.) to be implemented.
3.5.4.3Required characteristics of individual data elements that the interfacing entity(ies) must provide, store, send, access, receive, etc., such as:
3.5.4.3.1Names/identifiers.
3.5.4.3.1.1Project-unique identifier
3.5.4.3.1.2Part number
3.5.4.3.1.3Non-technical (natural language) name.
3.5.4.3.1.4Department of Defense (DoD) standard data element name.
3.5.4.3.1.5Technical name (e.g., variable or field name in code or database).
3.5.4.3.1.6Abbreviation or synonymous names.
3.5.4.3.1.7DoD Nomenclature
3.5.4.3.2Data type (string, integer, etc.).
3.5.4.3.3Size and format (such as length and punctuation of a character string).
3.5.4.3.4Units of measurement (such as meters, dollars, nanoseconds).
3.5.4.3.5Range or enumeration of possible values (such as 0-99).
3.5.4.3.6Accuracy (how correct) and precision (number of significant digits).
3.5.4.3.7Priority, timing, message set, data package, frequency, volume, sequencing, and other constraints, such as whether the data element may be updated and whether business rules apply.
3.5.4.3.8Security and privacy constraints.
3.5.4.3.9Sources (setting/sending entities) and recipients (using/receiving entities).
3.5.4.4Required characteristics of data element assemblies (records, messages, files, arrays, displays, reports, etc.) that the interfacing entity(ies) must provide, store, send, access, receive, etc.:
3.5.4.4.1Names/identifiers.
3.5.4.4.1.1Project-unique identifier.
3.5.4.4.1.2Non-technical (natural language) name.
3.5.4.4.1.3Technical name (e.g., record or data structure name in code or database).
3.5.4.4.1.4Abbreviations or synonymous names.
3.5.4.4.1.5DoD standard data element name.
3.5.4.4.2Data elements in the assembly and their structure (number, order, grouping).
3.5.4.4.3Medium (such as disk) and structure of data elements/assemblies on the visual and auditory characteristics of displays and other outputs (such as colors, layouts, fonts, icons and other display elements, beeps, lights).
3.5.4.4.4Relationships among assemblies, such as sorting/access characteristics.
3.5.4.4.5Priority, timing, message set, data package, frequency, volume, sequencing, and other constraints, such as whether the assembly may be updated and whether business rules apply.
3.5.4.4.6Security and privacy constraints.
3.5.4.4.7Sources (setting/sending entities) and recipients (using/receiving entities).
3.5.4.5Required characteristics of communication methods that the interfacing entity(ies) must use for the interface:
3.5.4.5.1Project-unique identifier(s).
3.5.4.5.2Communication links/bands/frequencies/media and their characteristics.
3.5.4.5.3Message formatting.
3.5.4.5.4Flow control such as sequence numbering and buffer allocation.
3.5.4.5.5Data transfer rate, whether periodic/aperiodic, and interval between transfers.
3.5.4.5.6Routing, addressing, and naming conventions.
3.5.4.5.7Transmission services, including priority and grade.
3.5.4.5.8Safety/security/privacy considerations, such as encryption, user authentication, compartmentalization, and auditing.
3.5.4.6Required characteristics of protocols the interfacing entity(ies) must use for the interface:
3.5.4.6.1Project-unique identifier(s).
3.5.4.6.2Priority/layer of the protocol.
3.5.4.6.3Packeting, including fragmentation and reassembly, routing, and addressing.
3.5.4.6.4Legality checks, error control, and recovery procedures.
3.5.4.6.5Synchronization, including connection establishment, maintenance, termination.
3.5.4.6.6Status, identification, and any other reporting features.
3.5.4.7Other required OMS characteristics (e.g., physical compatibility of the interfacing entities (dimensions, tolerances, loads, plug compatibility, fluid type, flow rate, pressure etc.), voltages, etc).
3.5.5Precedence and criticality of requirements.This paragraph shall be numbered as the last paragraph in Section 3 and shall specify, if applicable, the order of precedence, criticality, or assigned weight factor of one requirement against another indicating the relative importance of the requirements contained in this ICD. Examples include identifying those requirements deemed critical to safety, to security, or to privacy for purposes of singling them out for special treatment. If all requirements have equal weight, this paragraph shall so state.
3.5.5.1The precedence and criticality of requirements shall be driven based on the following:
3.5.5.1.1Safety Critical Functions (SCFs).
3.5.5.1.2Mission Critical Functions (MCFs).
3.5.5.1.3Functions Associated with Critical Program Information (F-CPI).NOTE: SCFs, MCFs, and F-CPI shall be determined during the Functional Thread Analysis
3.5.6Proof of ICD validation.This section defines that the ICD(s) accurately represent(s) the Final Product Baseline. The Contractor shall demonstrate proof that the ICD accurately represent(s) the final system design, corresponding interfaces, data, and data values as derived from this DID. For each ICD provide the qualification method(s) and artifact(s) used to ensure that the ICD has been met. Qualification methods shall include:
3.5.6.1Demonstration:The operation of interfacing entities that relies on observable functional operation not requiring the use of instrumentation, special test equipment, or subsequent analysis.
3.5.6.2Test:The operation of interfacing entities using instrumentation or special test equipment to collect data for later analysis.
3.5.6.3Analysis:The processing of accumulated data obtained from other qualification methods. Examples are reduction, interpretation, or extrapolation of test results.
3.5.6.4Inspection:The visual examination of interfacing entities, documentation, etc.
3.5.6.5Special qualification methods:Any special qualification methods for the interfacing entities, such as special tools, techniques, procedures, facilities, and acceptance limits.
3.5.7Traceability.For each system, subsystem, or lower-level interfacing entity contained in this ICD, this paragraph shall contain:
3.5.7.1Traceability to/from requirements.Traceability to and from each requirement imposed on the entity in this data set to the system (subsystem or component, if applicable) requirements it addresses. This traceability shall be provided by annotating each requirement in Section 3. NOTE: Each level of system refinement may result in requirements not directly traceable to higher-level requirements. For example, a system architectural design that creates multiple Computer Software Configuration Items (CSCIs) may result in requirements about how the CSCIs will interface, even though these interfaces are not covered in system requirements. Such requirements may be traced to a general requirement such as "system implementation" or to the system design decisions that resulted in their generation.
3.5.7.2Traceability to drawings.Interface parameters (e.g., pin locations, etc.) shall be documented in the ICD. Reference applicable drawings developed in accordance with the contract.
3.5.7.3Traceability to architectures.Reference applicable architectures developed in accordance with contract.
3.5.8Notes.This section shall contain any general information that aids in understanding this document (e.g., background information, glossary, rationale). This section shall include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of any terms and definitions needed to understand this document.
3.5.9Appendices.Appendices shall be used to provide information published separately for convenience in document maintenance (e.g., charts, classified data). As applicable, each appendix shall be referenced in the main body of the document where the data would normally have been provided. Appendices may be bound as separate documents for ease in handling. Appendices shall be lettered alphabetically (A, B, etc.).
3.6DOAM.The completed ASDP ICD template, provided in the DOAM Specification attached to the contract, shall comply with the format requirements in 2. above so that it can be ingestible into a Product Lifecycle Management (PLM) solution to ensure proper tying, tracing, and linking. Any field not applicable shall be marked "NA."

References

Copies of this form are available online at https://www.esd.whs.mil

Copy of this standard can be found at https://restricted.vdl.afrl.af.mil/programs/oam/wiki/Main_Page

Copies of these documents are available online at https://quicksearch.dla.mil

Copies of these documents are available online at https://usaf.dps.mil/teams/23230/Airworthiness/SitePages/Circulars.aspx

Copies of this document are available online at https://www.esd.whs.mil

Copies of this document are available online at https://www.esd.whs.mil

Figures

Figure 1: EXAMPLE Interface Identification

Figure 1. EXAMPLE Interface Identification

Schema v3.0Community-maintained · Verify against ASSIST
Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer