DI-SESS-82045

Firmware Development Plan

Establishes the format and content for a plan that standardizes the collection of information on firmware development and ensures appropriate rigor is applied.

Approval DateMay 25, 2016

AMSC NumberN9667

Preparing ActivityAS

Project NumberSESS-2016-027

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

—

Description & Purpose

—

Application & Interrelationship

—

Use & Relationship

The Firmware Development Plan (FDP) contains the format and content to standardize a way to collect information on the development of firmware and assure that the appropriate rigor is applied.

This Data Item Description contains the format, content, and intended use information for the data product resulting from the work task described by the contract.

Preparation Instructions

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

2FormatContractor's format is acceptable. The FDP shall adhere to the format described under Content.

3ContentThe content shall contain the following:

3.1Overview of required workThis section shall be divided into paragraphs as needed to establish the context for the planning described in later sections. It shall include, as applicable, an overview of:

3.2Requirements and constraints on the system and firmware to be developed

3.2.1Handling of critical requirementsThis paragraph shall be divided into the following subparagraphs to describe the approach to be followed for handling requirements designated critical. The planning in each subparagraph shall cover all contractual clauses concerning the identified topic.

3.2.1.1Safety Assurance

aSoftware Requirements

bSystem Software Architecture and Software Preliminary Design

cSoftware Detailed Design

dSoftware Coding and Unit Test

eComputer Software Component (CSC) Integration and Test

fComputer Software Configuration Item (CSCI) Formal Qualification Test (FQT)

3.2.1.2Cyber-Security / Software Assurance

aSoftware Requirements

bSystem Software Architecture and Software Preliminary Design

cSoftware Detailed Design

dSoftware Coding and Unit Test

eCSC Integration and Test

fCSCI FQT

gSubsystem Integration and Test

hSystem Qualification Test

iDescribe the mechanism to address constant emerging cyber-security requirements

3.3Requirements and constraints on project documentation

3.4Position of the project in the system life cycle

3.5The selected program/acquisition strategy or any requirements or constraints on it

3.6Requirements and constraints on project schedules and resources

3.7Other requirements and constraints, such as on project security, privacy, methods, standards, interdependencies in hardware and software development, etc.

3.8Plans for performing general firmware development activitiesThis section shall be divided into the following paragraphs. Provisions corresponding to non-required activities may be satisfied by the words "Not applicable." If different builds or different firmware on the project require different planning, these differences shall be noted in the paragraphs. In addition to the content specified below, each paragraph shall identify applicable risks/uncertainties and plans for dealing with them.

3.9Project Organization and ResourcesThis paragraph shall be divided into the following subparagraphs to describe the project organization and resources to be applied.

3.9.1Project OrganizationThis paragraph shall describe the organizational structure to be used on the project, including the organizations involved, their relationships to one another, and the authority and responsibility of each organization for carrying out required activities. This paragraph shall also include the definition of Systems Engineering, Software Engineering, Integrated Product and Process Development, and processes for the Division(s) responsible for the development and the principle sub-contractors responsible for software/firmware development, as applicable.

3.9.2Project ResourcesThis paragraph shall describe the resources to be applied to the project. This section shall include a description of the extent to which personnel who contributed to these previous efforts using these processes will be supporting this development effort. It shall include, as applicable:

3.9.2.1Personnel resources, including:

3.9.2.2The estimated staff-loading for the project(number of personnel over time)

3.9.2.3The breakdown of the staff-loading numbers by responsibility(for example, management, engineering, testing, configuration management, product evaluation, and/or quality assurance)

3.9.2.4A breakdown of the skill levels, geographic locations, and security clearances of personnel performing each responsibility

3.9.2.5Overview of developer facilities to be usedIncluding geographic locations in which the work will be performed, facilities to be used, and secure areas and other features of the facilities as applicable to the contracted effort.

3.9.2.6Acquirer-furnished equipment, software, services, documentation, data, and facilities required for the contracted effortA schedule detailing when these items will be needed shall also be included.

3.9.2.7Other required resourcesIncluding a plan for obtaining the resources, dates needed, and availability of each resource item.

3.9.3Peer ReviewThis paragraph shall describe the peer review process covering: System requirements, system design, firmware requirements, firmware design, firmware implementation and firmware testing.

3.10Technical Development PlanningThe following subparagraphs shall detail the planning activities associated with the firmware development. Repeat for each Module as applicable. A Module is defined as a single file of source code that contains functions or routines as well as all the variables needed to support the functions.

3.10.1Firmware EstimationThis paragraph will detail the methodology for the firmware size estimate and complexity.

3.10.1.1DefinitionsModified: Any deletion, modification, addition or development of code, documentation (e.g., test procedures), design or development environment that deviates from the predefined modules developed for production, deployment and/or use. Reuse: Any product, code, documentation or design that requires no modification from the predefined modules developed for production, deployment and/or use. Simple - Code that performs easily tested functions, has linear relationships between inputs and outputs, i.e. linear domain & range relationships, single firmware/software & hardware relationship, and performs simplistic data management functions like look up tables or library functions. The main difference between simple and routine code is the relative degree of testing required to determine code functionality. Simple code can consist of simulation, maintenance, data handling, or human interface components. Routine - Code that has multiple input and output paths requiring a moderate degree of testing to certify functionality, may be newly written or adaption of existing code from other DOD programs and generally performs non real time, non-algorithm intense functions like simulation, tools, maintenance, Graphical User Interface (GUI) or data handling. Code is rarely constrained by the operating environment. Complex - Code that has a very high number of input and output paths making it very difficult to test, may perform real time mathematical intense functions, may be constrained by the operating environment, may be written in a highly secure environment, or involves new or novel algorithms or applications. Complex code tends to be found in functions that emulate or interface with the physical world, i.e. radar signal processing, sensor and electronic warfare signal processing. Human interface is infrequent with this type of code. Key to identifying complex code is the difficulty in verifying and validating the code in a laboratory environment.

3.10.1.2Source Lines of Code (SLOC)This paragraph shall detail how the size was developed (analogy, function point, requirements analysis, etc.) along with any data justifying the estimate.

3.10.1.3Reuse and Modified FirmwareFor reuse and modified firmware, the following shall be detailed:

aLineage of the proposed reuse firmware and how it compares or relates to the target system(s)

bAbility to provide required capabilities and meet required constraint(s)

cAbility to provide required safety, security and privacy constraint(s)

dReliability/Maturity and the metrics to verify and validate the claim

eFirmware defect history

fAnticipated changes in terms of SLOC

gFielding issues

1Restrictions on copying/distributing the firmware or documentation

2License or other fees applicable to each copy

hMaintainabilityIncluding:

1Feasibility and complexity of changing the firmware to meet new or emerging requirements(ex: Anti-Tamper, Cybersecurity, Safety, etc.).

2Availability and quality of documentation

3Likelihood that the current version will not be supported, or is not supportable and the impact on the overall system

4The acquirer's data rights to firmware products and associated documentation

iShort and long term cost impact of using the firmware product

3.10.1.4Programming Language(s) to be used

3.10.1.5ComplexityDetail the relative measure of the complexity of the firmware to be developed (Simple, Routine or Complex as defined above) to include rationale and methodology.

3.10.2Firmware Requirements PlanThis paragraph shall detail the requirements plan as well as requirements documentation, requirement types, and their respective requirements attributes, specifying the information and control mechanisms to be collected and used for measuring, reporting, and controlling changes to the product requirements.

3.10.3Firmware Preliminary Design PlanThis paragraph shall detail the design plan that will correctly and completely implement the requirements. This design concept may be expressed as functional block diagrams, design and architecture descriptions, sketches, and/or behavioral hardware description language (HDL).

3.10.4Firmware Detailed Design PlanThis paragraph shall detail the design plan that will further the Preliminary Design and translate it into a gate-level design, which can then be mapped to the logic blocks of the device.

3.10.5Physical Fabrication PlanThis paragraph shall detail the implementation of the firmware.

3.10.5.1SynthesisThis paragraph shall detail the process of converting the detailed design into a lower-level implementation on the field programmable gate array (FPGA) or other programmable logic device.

3.10.5.2LayoutThis paragraph shall detail the physical arraignment and/or allocation of components on the FPGA or other programmable logic device.

3.10.6Programming equipmentThis paragraph shall describe the equipment to be used for programming and reprogramming the firmware device. It shall include computer equipment, general purpose equipment, and special equipment to be used for device erasure, loading, verification, and marking, as applicable. Each piece of equipment shall be identified by manufacturer's name, model number, and any other information that is necessary to uniquely identify that piece of equipment. A description of each piece of equipment shall be provided, including its purpose, usage, and major capabilities.

3.10.7Programming softwareThis paragraph shall describe the software to be used for programming and reprogramming the firmware device. It shall include software to be used for device erasure, loading, verification, and marking, as applicable. Each software item shall be identified by vendor's name, software name, number, version/release, and any other information necessary to uniquely identify the software item. A description of each software item shall be provided, including its purpose, usage, and major capabilities.

3.10.8Programming proceduresThis paragraph shall describe the procedures to be used for programming and reprogramming the firmware device. It shall include procedures to be used for device erasure, loading, verification, and marking, as applicable. All equipment and software necessary for each procedure shall be identified, together with any security and privacy measures to be applied.

3.10.9Firmware ToolsThis paragraph shall list all tools for the firmware development including requirements, coding, design, and testing.

3.11Firmware Development StandardsThe following subparagraphs will detail the development standards associated with the to-be-developed firmware.

3.11.1Project(s)

3.11.1.1Directory StructureThis paragraph shall detail the directory structure of the source code.

3.11.1.2Version File(s)This paragraph shall detail the firmware version name, version date, and part number and how it is documented in the source code.

3.11.1.3Make and Project File(s)This paragraph shall detail all of the information needed to automatically build the entire ROM image.

3.11.1.4Startup CodeThis paragraph shall detail, as applicable, an initial startup module that sets up the compiler's runtime package and initializes certain hardware on the processor itself, including chip selects, wait states, etc.

3.11.1.5Stack and HeapThis paragraph shall detail the rationale for determining maximum stack requirements and how the initialization code fills the entire amount of memory allocated to the stack, if applicable.

3.11.2ModulesThe following paragraphs shall describe the modules of the source code.

3.11.2.1GeneralThis paragraph shall describe the module (i.e. name, layout, functions, author, date created, if applicable).

3.11.2.2TemplatesThis paragraph shall detail any standardized templates used for modules.

3.11.2.3Module Name(s)This paragraph shall describe module name creation methodologies.

3.11.3VariablesThe following paragraphs shall describe the Variables methodology.

3.11.3.1Naming ConventionThis paragraph shall describe naming conventions.

3.11.3.2Global VariablesThis paragraph shall detail the global variables and how they are initialized and utilized in the firmware.

3.11.3.3PortabilityThis paragraph shall detail how the firmware is developed to ensure portability.

3.11.4FunctionsThis paragraph shall detail the methodology of functions, to include size, real-time constraints, parameter passing and any function prototyping used.

3.11.5Interrupt Service Routines (ISR)This paragraph shall detail the usage, or non-usage, of ISR.

3.11.6CommentsThis paragraph shall detail how the source code is commented by the author to detail the functionality of the code.

3.11.7Coding Conventions/StandardsThis paragraph shall detail coding standards to include: Line size, spacing and indentations, formatting based upon programming language and macros.

3.12Firmware TestingThese subparagraphs shall detail the testing methodology at multiple levels to ensure correct functionality and adherence to other properties. Some tests can only be done at a low level (e.g., at the chip or board level), where faults and failures of external components can be simulated. Some tests require other system elements in order to accurately reflect how the device will function in the full system.

3.12.1Post-Programming TestingDetail the methodology for how device is tested to verify correct programming and functionality.

3.12.2Integration TestingDetail the methodology for testing components or assemblies as part of a system element, to include: Hardware and firmware/software interfaces, timing, requirements that cannot be tested at a higher level, and fault injection to show that the board or assembly functions properly with anticipated faults and errors.

3.12.3System TestingDetail the methodology for system requirements verification.

3.12.4Acceptance TestingDetail the methodology for validation of the system.

3.12.5Simulation and StimulationThis paragraph shall detail all simulation and stimulation methods used in the testing if not covered elsewhere in Section 3.

3.13NotesThis 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.14AppendicesAppendices 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 may be bound as separate documents for ease in handling. Appendixes shall be lettered alphabetically (A, B, etc.).

References

—

Schema v3.0Community-maintained · Verify against ASSIST

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