DI-MGMT-82404

Acquisition and Sustainment Data Package (ASDP) - Functional Thread Analysis (FTA) Report

The FTA Report describes the functional decomposition of the system processing architecture and documents Mission Critical and Safety Critical Functions to support certifications such as cyber and airworthiness.

Approval DateFebruary 24, 2023

AMSC NumberF10380

Preparing Activity11 (AFLCMC/EZSI)

Project NumberMGMT-2023-004

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 Functional Thread Analysis (FTA) Report describes the functional decomposition as part of planning activities and records the resulting data from the FTA. The FTA Report provides the analysis of the system processing architecture (including hardware, software and firmware) that supports the execution of Mission Critical Functions (MCFs), Safety Critical Functions (SCFs) being developed or modified. In addition, functions associated with Critical Program Information (CPI) for system/components should be identified with the applicable MCFs and SCFs. The FTA Report data is used by the government to understand the architecture and interfaces of the functions of the weapon system and aid certifications like cyber and airworthiness.

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 contract.

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.The FTA Report shall be provided in Comma-Separated Values (CSV) format or Systems Modeling Language (SysML). For CSV format, the FTA shall be segregated from the other information below (e.g. system description, methodology, etc.). When FTA is conducted using analysis tools or software, the FTA shall be provided in native format in addition to CSV format. If SysML is being used, the FTA shall be provided in native format and shall include view(s) or viewpoint(s) for the data required below.

2.1The Data Objects/Attributes and Associated Metadata (DOAM) listing shall be in Microsoft Excel populated spreadsheet formatin accordance with (IAW) the template provided in the DOAM Specification attached to the contract. Each artifact and data set submitted IAW this DID shall have a designated row in the template. All data shall be in the English language. The final FTA shall have all outstanding changes incorporated into the data.

3Content.The FTA report shall document the results and shall include:

3.1Section 1. Front Matter.Cover and title page. The following information shall be included on the cover and title page:

3.1.1Date of issue.

3.1.2Revision date.

3.1.3Document identification number.

3.1.4Contract number.

3.1.5Contractor's name and physical address.

3.1.6Identification of the system to be analyzed.

3.1.7Security classification.The applicable classification marking, as necessary, in accordance with Department of Defense Manual (DoDM) 5200.01, Volume 2, DoD Information Security Program: Marking of Information. (Copies of this document are available online at www.esd.whs.mil/DD.)

3.1.8Distribution Statement.Distribution Statement (i.e., A, B, C, D, E, etc.), in accordance with DD Form 1423 and CDRL General Instructions/Notes.

3.1.9Record of changes.A record of change(s) page(s) shall be included to provide for tracking of changes to the FTA report.

3.1.10Table of contents.

3.2Section 2. System Description.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.

3.2.1Identification of the system overview, scope, level of FTA, assumptions, summary of results, and documentation of the data sources and techniques used in performing the FTA.This section shall include the following:

3.2.1.1Nomenclature.

3.2.1.2Model or part number.

3.2.1.3National Stock Number (NSN), NATO Item Identification Number (NIIN), Logistic Control Number (LCN)

3.2.1.4Specification(s) in which system components and corresponding requirements reside.

3.2.1.5System Mission Profile(s).Describe(s) the operational and physical environmental context(s) within which the system meets its objective(s) (e.g., fixed installation versus mobile system operations, geography, mission time constraints, weather, day/night, humidity, terrain, vegetation density, enemy force concentration, enemy weapons and countermeasures capabilities, enemy order of battle, presence or absence of other cooperating systems).

3.3Section 3. Function Identification.This section shall include the following:

3.3.1Identification and Definition of Mission Critical Functions (MCFs) for each mission tied to the system mission profile(s).

3.3.2Identification of the thread of corresponding system(s), subsystem(s), Line Replaceable Unit(s) (LRUs), and Component(s) needed to execute each MCF.

3.3.3Identification and Definition of Safety Critical Functions (SCFs) for each mission tied to the system mission profile(s) and categorized by precluded aviation state resulting in unsafe flight condition (i.e., cannot: aviate, navigate, communicate, takeoff, land, and emergency function(s) (e.g. ejection seat, egress lighting, oxygen))

3.3.4Identification of the entire thread of corresponding system(s), subsystem(s), Line Replaceable Unit(s) (LRUs), and Component(s) needed to execute each SCF.

3.3.5The System, Subsystem, LRU, and Component shall be cross referenced to the specification(s) and drawing tree.

3.3.6Documentation of the manufacturer of each system, subsystem, LRU, and component.See Table 1 and Table 2 examples. The tables indicates at which Systems Engineering Technical Review (SETR) the data must be populated. At System Requirements Review (SRR), systems are identified. At System Functional Review (SFR), subsystems are identified. At Preliminary Design Review (PDR), LRUs, and components are identified. At Critical Design Review (CDR), LRUs and components updated.

3.4Section 4. Thread diagrams.This section shall include the following:

3.4.1Graphical representations of each MCF(s) and SCF(s)along with association of Function(s) associated with CPI identified in Section 3 that show all the supporting elements, the interfacing between the elements (various data channels that interconnect elements and support operation for each MCF, SCF, and Function associated with CPI), the Data Sources and Data Receivers (input and output of the each thread respectively), redundancy of elements and interfaces in the thread, and how the software architecture supports each thread as approved by the government.

3.5Section 5. Interface Identification.This section shall include the following:

3.5.1Identification of internal and external interfaces.

3.5.2Reference to all Interface Control Documents in which system components and corresponding interfaces reside.

3.6Section 6. Manufacturer and supplier Threat Identification.This section shall include the following:

3.6.1Identification of supplier(s) including sub-tiers, Original Equipment Manufacturers (OEMs), Commercial Off-The-Shelf (COTS) developers, etc., of critical components.

3.7DOAM.The completed ASDP Product FTA Report, provided in the DOAM Specification attached to the contract, shall comply with the format requirements above so that it can be ingestible into a Product Lifecycle Management (PLM) solution to ensure proper tying, tracing, and linking. Any field that is not applicable shall be marked "NA."

References

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

Figures

Figure Table 1. EXAMPLE Critical Function Thread Identification

Figure Table 2. EXAMPLE Interface Functional Thread Identification

Schema v3.0Community-maintained · Verify against ASSIST

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