DI-SESS-82544

Hardware Design Description (HDD)

Describes the design of a hardware Configuration Item (CI), including CI-wide design decisions and detailed hardware unit design, serving as the basis for implementing and supporting the hardware design.

Approval DateMay 21, 2026

AMSC NumberN10667

Preparing ActivityAS

Project NumberSESS-2026-031

OPR—

DTIC Applicable—

GIDEP Applicable—

Limitation—

Applicable Forms—

Approval Limitation—

Form Version—

DID Formatfree_text

963C CompliantYes

DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.

Supersedes

—

DI-IPSC-81436DI-IPSC-81432

Description & Purpose

—

Application & Interrelationship

—

Use & Relationship

The Hardware Design Description (HDD) describes the design of a hardware Configuration Item (CI). It describes the CI-wide design decisions and the detailed design of the hardware. The HDD may be supplemented by Interface Design Descriptions (IDDs) (DI-IPSC-81436) and System/Subsystem Design Descriptions (SSDDs) (DI-IPSC-81432), as described below.

The HDD, with its associated IDDs and SSDDs, is used as the basis for implementing the hardware design. It provides the acquirer visibility into the design and provides information needed for design support.

This DID is used when the designer is tasked to define and record the design of a hardware CI. Design pertaining to interfaces may be presented in the HDD or in IDDs. Design pertaining to systems may be presented in the HDD or SSDDs.

This DID contains the format, content, and intended use information for the data product resulting in specific and discrete tasks and requirements described in the contract Statement of Work (SOW).

Preparation Instructions

1Reference documentsNone.

1.2General instructions

1.3Automated techniquesUse of automated techniques is encouraged. The term "document" in this DID means a collection of data, regardless of its medium.

1.4Alternate presentation stylesDiagrams, table, matrices, and other presentation styles are acceptable substitutes for text when data required by this DID can be made more readable by using these styles.

2FormatThe contractor's format is acceptable. Format shall be machine-readable by the government.

3ContentThe HDD shall contain the following:

3.1Title page or identifierThe document shall include a title page that contains the following information, as applicable:

3.1.1document number

3.1.2volume number

3.1.3version/revision number

3.1.4security markings or other restrictions to document handling

3.1.5date

3.1.6title

3.1.7hardware item name, abbreviation, and any other identifier for the system, subsystem, or item to which the document applies

3.1.8contract number

3.1.9CDRL item number

3.1.10organization for which the document has been prepared

3.1.11name and address of the preparing organization

3.1.12distribution statement

3.2For data in a database or otherFor data in a database or other alternative form, this information shall be included on external and internal labels or by equivalent identification methods.

3.2.1Table of contentsThe document shall contain a table of contents with the number, title, and page number of each, titled paragraph, figure, table, and appendix. For data in the database 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.2.2Page numbering/labelingEach page shall contain a unique page number and display the document number, including version, volume, and date, as applicable. For data in a database or other alternative form, files, screens, or other entities, shall be assigned names or numbers in such a way that desired data can be indexed and accessed.

3.2.3Response to tailoring instructionsIf 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 or other alternative form, the representation need occur only in the table of contents or equivalent.

3.2.4Multiple paragraphs and subparagraphsAny section, paragraph, or subparagraph in this DID may be written as multiple paragraphs or subparagraphs to enhance readability.

3.2.5Standard data descriptionsIf the contract has a data description that will be published in a standard, data-element dictionary, then tailor down this requirement in the CDRL to address receiving the information through the dictionary's entry instead of providing the description through this DID.

3.2.6Substitution of existing documentsCommercial or other existing documents may be substituted for all or part of this DID's content requirements if they contain the required data.

3.3The HDD shall contain the followingThe HDD shall contain the following document sections:

3.3.1ScopeThis section shall contain the following paragraphs.

3.3.2IdentificationThis paragraph shall contain a full identification of the system and the hardware to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).

3.3.3System overviewThis paragraph shall briefly state the purpose of the system and the hardware to which this document applies, it shall describe the general nature of the system and hardware; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, designer, and support agencies; identify current and planned operating sites; and list other relevant documents.

3.3.4Document overviewThis paragraph shall summarize the purpose and contents of this document and shall describe any security or privacy considerations associated with its use.

3.3.5Referenced documentsThis section shall list the number, title, revision, and date of all documents referenced in this document. This section shall also identify the source for all documents not available through normal Government stocking activities.

3.3.6Hardware characteristicsThe HDD shall contain design architecture, key component characteristics, design verification methods and results of the following key characteristics:

3.3.6.1Predicted Continuous Wave (CW) EIRP performance over bandwidthPredicted Continuous Wave (CW) EIRP performance over bandwidth, polarization and field of regard vs. specification for each required assignment case under installed pod environmental constraints, with the supporting RF chain analysis and load-pull analysis and antenna performance

3.3.6.2Spectral purity including frequency lockout, linear modeSpectral purity including frequency lockout, linear mode, and any amplifier linearization used

3.3.6.3RF level control for required EIRP andRF level control for required EIRP and flatness within Instantaneous Bandwidth (IBW), including input interface allocations

3.3.6.4Amplifier output power, port impedance, loadAmplifier output power, port impedance, load Voltage Standing Wave Ratio (VSWR), load pull test results/parameters, linearity, linearity control, output power flatness and its control, and noise floor output during stand-by mode and radiate mode, including spurious emissions

3.3.6.5Out-of-band rejection

3.3.6.6Transmitter self-protection methods and validation results

3.3.6.7MMIC die packaging materials, processes and techniquesMMIC die packaging materials, processes and techniques used, material properties, stack-up, as well as overall thermal performance and junction temperatures

3.3.6.8Transmitter weight relative to budget, including chassisTransmitter weight relative to budget, including chassis, power distribution, and cooling components

3.3.6.9Power handling approaches and reliability including receivePower handling approaches and reliability including receive power protection. Power handling and cooling evaluations relative to average power, peak power, instantaneous peak power

3.3.6.10Power subsystem interface allocations, including support ofPower subsystem interface allocations, including support of frequency/state transitions and blanking

3.3.6.11Cooling subsystem interface allocations

3.3.6.12A description of DC bias and RFA description of DC bias and RF characteristics (e.g. S-parameters) of component

3.3.6.13Antenna electrical and mechanical design (including radiatingAntenna electrical and mechanical design (including radiating element design for arrays)

3.3.6.14Random and systematic radiating element amplitude andRandom and systematic radiating element amplitude and phase error budget/analysis

3.3.6.15Active VSWR (as applicable) and its performanceActive VSWR (as applicable) and its performance impact over frequency, polarization and FOR

3.3.6.16Installed antenna realized gain over frequency, polarizationInstalled antenna realized gain over frequency, polarization and FOR

3.3.6.17Antenna feed network design and performanceTransmission lines, transitions, connectors, etc.

3.3.6.18Detailed description and analysis results for designDetailed description and analysis results for design techniques such as antenna amplitude tapering and phase distribution, impedance matching approach (i.e. circulator, tapered, etc.)

3.3.6.19Beam former, beam steering designs, including beamBeam former, beam steering designs, including beam characteristics and beam transition time, group delay

3.3.6.20Design toleranceselement-to-element pattern variation and its effects on array performance (especially at higher frequencies)

3.3.6.21Antenna test planning, including measurement error budgetsAntenna test planning, including measurement error budgets, test methodologies and assumptions

3.3.6.22Radome cross sectional dimensions in key regionsRadome cross sectional dimensions in key regions as pertains to RF performance

3.3.6.23Radome boresight error and transmission loss evaluationRadome boresight error and transmission loss evaluation as pertains to RF performance

3.3.6.24Dielectric constant and loss tangent of materialsDielectric constant and loss tangent of materials (including radome, as pertains to RF performance)

3.3.6.25RF switch characteristics (if applicable)

3.3.6.26Lightning protection approach

3.3.7CI-wide design decisionsThis section shall be divided into paragraphs that are needed to present CI-wide design decisions, that is, decisions about the CI's behavioral design (how it will behave, from a user's point of view, in meeting its requirements, ignoring internal implementation) and other decisions affecting the selection and design of the hardware units that make up the CI. This section shall state when decisions are explicit in the CI requirements or are deferred to the design of the CI's hardware units. Design decisions that respond to requirements designated critical, such as those for safety, security, or privacy, shall be placed in separate paragraphs. If a design decision depends upon system states or modes, this dependency shall be indicated. Design conventions needed to understand the design shall be presented or referenced. Examples of CI-wide design decisions are the following:

3.3.7.1Design decisions regarding inputs the CI willDesign decisions regarding inputs the CI will accept and outputs it will produce, including interfaces with other systems. If part or all of this information is given in Interface Design Descriptions (IDDs), they may be referenced.

3.3.7.2Design decisions on CI behavior in responseDesign decisions on CI behavior in response to each input or condition, including actions the CI will perform, response times and other performance characteristics, description of physical systems modeled, selected equations, and handling of inputs or conditions exceeding design thresholds.

3.3.7.3Selected approach to meeting safety, security, and privacy requirements.

3.3.7.4Other CI-wide design decisions made in responseOther CI-wide design decisions made in response to requirements, such as selected approach to providing required flexibility, availability, and maintainability.

3.3.8CI detailed designThis section shall be divided into the following paragraphs to describe each hardware unit of the CI. If part or all of the design depends on system states or modes, this dependency shall be indicated. If design information falls into more than one paragraph, it may be presented once and referenced from other paragraphs. Design conventions needed to understand the design shall be presented or referenced. Interface characteristics of hardware units may be described here, in Section 3, or in Interface Design Descriptions (IDDs).

3.3.8.1(Project-unique identifier of a hardware unit, or designator of a group of hardware units)This paragraph shall identify a hardware unit by project-unique identifier and shall describe the unit. The description shall include the following information, as applicable:

3.3.8.1.1Unit design decisions, if any, if not previously indicated.

3.3.8.1.2Any constraints, limitations, or unusual features inAny constraints, limitations, or unusual features in the design of the hardware unit.

3.3.8.1.3The software packages are used to modelThe software packages are used to model and generate detailed engineering drawings of the hardware unit.

3.3.9Alternatively, this paragraph may designate a groupAlternatively, this paragraph may designate a group of hardware units and identify and describe the hardware units and identify and describe the hardware units in subparagraphs. Hardware units that contain other hardware units may reference the descriptions of those units rather than repeat information. Requirements traceability. This section shall contain:

3.3.9.1Traceability from each hardware unit identified inTraceability from each hardware unit identified in this HDD to the CI requirements allocated to it.

3.3.9.2Traceability from each CI requirement to theTraceability from each CI requirement to the hardware units to which it is allocated.

3.4NotesThis 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.5A. AppendicesAppendices may 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. Appendixes shall be lettered alphabetically (A, B, etc.).

3.6The applicable issue of the documents citedThe 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.

References

—

Schema v3.0Community-maintained · Verify against ASSIST

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