SIC_SOW_FINAL_1JUL2024_with Appendices.pdf

For the best experience, open this PDF portfolio in

Acrobat X or Adobe Reader X, or later.

Get Adobe Reader Now!

http://www.adobe.com/go/reader

OSS&E Checklist SW-Version 6.0 PMOD

Project Title Checklist Status Mod Type Date Created Checklist Version PMod SW-Version 6.0

Program Manager Phone Email

Modification Description Describe the software modification/update, explain what equipment/software it will interact with or affect.

Findings / Exceptions

Program Manager Comments

Approval Phase Approval Status Scheduled Completion Date Final Approval Date Requirements

Certification

Modification Approvals

SW_PM Airworthiness Certification PROC-24-759

Process Info: This area is Always Affected.

Description:

To ensure that each aircraft software modification is produced, operated, and maintained in accordance with the design and associated technical data identified in the airworthiness approval.

Software/firmware installation and or updates require an Airworthiness Plan to be completed to determine the (AWHI) Airworthiness Hazard Index. Modifications with a AWHI of 8 or less are reportable and will require an AW Plan and CB/CR to be approved by EN/EZ.

If you have an ADF that already addresses the risks of this modification, then you do not need a separate ADF/AW Plan please reach out to the Focal with any questions.

Software that does not affect Safety Critical Functions (SCF) can use the Airworthiness Assessment Report (AAR) in lieu of this checklist please reach out to the Focal with any questions.

AW Plan, Airworthiness Assessment Report (AAR) and Airworthiness Plan Example located in OSS&E at: Processes Documents>OSS&E>OSS&E Checklists>2. SW Checklist

Guidance Documents:

AFI 62-6

AFI 62-601

MIL-HDBK-516

DODI 5000.87 Section 3.1

IAW AFPD 62-6

MIL-STD-498

DOD-STD-2168

MIL-STD-882

MIL-HDBK-1467

DO 178

AWB-100A Airworthiness Process Overview AWB-004A Development of Airworthiness Certification Basis AWB-110 AW Plan AWB-120 AW Related/Reportability AWB-130 Certification Basis AWB-140 Compliance Report AWB-150 Airworthiness Risk Assessment and Acceptance AWB-1009 Airworthiness Approval AWB-018A Military Certificate of Airworthiness

Recommended Data Deliverables:

DI-SESS-80776/T Technical Data Package (TDP) DI-SESS-81766 (Airworthiness CB) DI-SESS-81768 (Airworthiness CR) DI-MGMT-80004 (Management Plan)

SOW/PWS Language:

AWACS Guidance Documents listed above are in OSS&E at:

Processes Documents>OSS&E>OSS&E Checklists>2. SW Checklist>Circular AC-20-06 16JUN2021

US Focal Point: Rick Cox US Alternate Focal Point: Ken Fairchild

Requirements Approval

Criteria for Requirements Approval (Explain how this program will apply this area's requirements):

#1. Submit the Airworthiness Plan to the Airworthiness POC/Focal Point.

#2. Has the modification been determined to be Reportable? If yes provide the copy of the ADF/AW Plan and Certification Basis (CB) to the Airworthiness POC for review? If no, was the ADF/AW Plan approved and signed?

#3. Is the modification Airworthiness impacting? If yes, a Military Flight Release (MFR) is required.

Certification Approval

Criteria for Certification Approval (Explain how the above requirements have been satisfied):

#1. Have the Artifacts of Compliance been provided to, and certified by, all the Airworthiness Focal Point SMEs? Note: This means that all Airworthiness areas that have a red check in the required column of the checklist have been approved.

#2. Provide the copy of the Compliance Report (CR) to the Airworthiness POC for review.

#3. Is your modification reportable to EN/EZ? If yes, provide a link to the completed and signed Military Flight Release (MFR) for Focal Point review. If no, this is not applicable.

SW_PM Validated Modification Requirement Document PROC-24-760

Process Info: This Process Area is Always Affected.

Description: This modification area is where the program provides the validated requirement document for a configuration change to the weapons system. That requirement may be identified & submitted by any one of the following documents:

AF Form 1067 Modification Proposal (Primary Document Used) Engineering Change Proposal (ECP) Capability Development Document (CDD) Capability Production Document (CPD) Joint Capabilities Integration and Development System (JCIDS) Urgent Operational Need (UON) ACC or 552 ACW Request for Deviation/Waiver Request for Engineering Support (DLA Form 339) Joint Deficiency Reporting System (JDRS) Deficiency Report (DR)

This document MUST be uploaded to the Systems Engineering SharePoint site at this link, into the Program’s folder, to ensure that Focal Point can review it and sign off VMRD process area (see an OSS&E Admin for access if necessary).

Guidance Documents: The most current version of the following:

AFI 10-601

AFI 63-101/20-101, chapter 9 AFMCI 63-1201, paragraph A2.6.

CJCSI 5123.01I (Instruction on JCIDS development and staffing)

US Focal Point: Andrew Mathias US Alternate Focal Point: Shane Bouleware

Criteria for Requirements Approval (Explain how this program will apply this area's requirements):

#1: Has an acceptable modification requirement document been submitted and validated through appropriate levels? Place a copy of the document in the Program's Modifications Documents folder.

Criteria for Certification Approval (Explain how the above requirements have been satisfied):

#1: Have AF 1067 (if used), parts IV & V been validated/signed by the SPM & Lead Command Certification Official? Or, if utilizing another acceptable VMRD document, have all required approvals been granted? Place a copy of the signed/completed document in the Program's Modifications Documents folder.

SW_PM CCBD PROC-24-761

This area tracks the formal requests for Configuration Control Board approval. The CCB will be given a number and the CCB meeting will be scheduled. The Program Team will be required to complete the latest approved CCB Briefing PowerPoint Template and schedule a Pre-CCB and a CCB with the US Focal Point. After the Program Team briefs at CCB and gets CCB approval the formal CCB document of record the approved AFTO Form 872 (PMod) will be completed by the CCB Secretariat. The CCB Secretariat will upload the CCB slide deck and AFTO 872 CCBD approval form.

Guidance Documents:

Configuration Management Plan (CMP)

AFMCI 63-1201

Government Documents:

CCB Briefing Template - contact the CCB Secretariat for the current version

US Focal Point: Ryan Higgins US Alternate Focal Point: Colleen Dailey

Criteria for Requirements Approval:

#1. Provide an AFTO 872 signed by the SPM or an approved CPR signed by the Chief Engineer, with no critical program limiting actions for Requirements Approval.

Criteria for Certification Approval:

#1. Provide an AFTO 872 signed by the SPM or Chief Engineer and all CCB Action Items must be closed to get Certification Approval.

SW_C2 Compliance

SW_PM GATM and Navigational Safety PROC-24-762 Process Info: If Requirements question #2 or #3 is Yes, this area is Affected.

Description:

Global Air Traffic Management (GATM) System helps to control and manage the Air Traffic Control System by providing message communications and data link information used to maintain safe aircraft separation and manage air space. GATM command and control C2 applications.

Guidance Documents:

MIL-HDBK-514 (current version) TCTO 1E-3-841 Integrated DAMA GATM mod

USAF 003-97

AFI 63-1301

AFMCPD 63-4 (Software Requirements Review)

Recommended Data Deliverables:

DI-SESS-81769

DI-MISC-80508/T Software Impact Study including 1553 bus ICD study DI-IPSC-81440 Software Test Report DI-RELI-80687 Failure Modes, Effects, and Criticality Analysis (FMECA) Report DI-MISC-80508/T Failure Modes and Effects Testing (FMET) DI-SAFT-80101 System Safety Hazard Analysis Report (SSHAR) DI-ILSS-81495 Failure Mode Effects and Criticality Analysis (FMECA)

US Focal Point: Ken Fairchild US Alternate Focal Point: Ben Greiner

#1. Is this a modification to a ground system that does not affect navigational functionality? If yes, this area is not affected.

#2. Will this modification impact the 1553 bus and/or the TANS server, GPS/LN100, ESM, Radar, TACAN etc.? If yes, a Software Impact Study is required, and you must notify the Dragon PM and/or EN. Provide a link to the contractual document that requires the contractor to provide a Software Impact Study.

#3. Is this an upgrade to a non-dragon aircraft, will there be an impact to the 1553 bus and/or flight management computer or TANS (Time and Navigation Server)? If yes, provide a link to the contractual document that requires the contractor to provide a Software Impact Study.

#4. Does this upgrade impact the flight crew’s ability to safely navigate the aircraft? If yes, provide a link to the contractual document (SOW, PWS, SOC) that requires the Failure Modes and Effects Testing (FMET), System Safety Hazard Analysis Report (SSHAR) and the Failure Mode Effects and Criticality Analysis (FMECA).

#1. For Dragon aircraft modifications, provide a link to the completed Software Impact Study/Analysis and Software Test Report for Focal Point review. Also, send a link to the Dragon PM/EN and Sustainment Engineering.

#2. For non-dragon aircraft, provide a link to completed Software Impact Study/Analysis and Software Test Report for Focal Point review. Also send a link to Sustainment Engineering.

#3. If applicable, provide a link to the completed Failure Modes and Effects Testing (FMET), System Safety Hazard Analysis Report (SSHAR) and the Failure Mode Effects and Criticality Analysis (FMECA).

SW_PM Design Integration PROC-24-763

Process Info: If Requirements question #1 is Yes, this area is Affected.

Software Integration is the process of connecting a software application with another bringing together various types of software sub-systems, so they create a unified single system and ensure that all systems work together.

Modernization of the AWACS platform requires integrating new technology solutions and information systems to be integrated into the legacy AWACS system. Software integration will require the program PM/EN to provide the following documentation (software block diagrams, Internal ICD (Interface Control Documents, SVD Software Version Description)

Guidance Documents:

DoDI 5000.87 AFMCPD 63-4 Software Requirements Review

Recommended Data Deliverables:

DI-IPSC-81442 Software Version Description (SVD) DI-SESS-81248 Interface Control Document (ICD) DI-MGMT-81650 Integrated Master Schedule (IMS) DI-IPSC-81434 Interface Requirement Specification (IRS) Software Release Plan

US Focal Point: Shane Bouleware

#1. Is any new software being introduced or updated on any equipment? If yes, identify the new software/changes and explain if there is an impact to any aircraft software Mission Computing OS and/or MC Apps (AOCP), ESM, Radar.

#2. Will your modification interface with any other modifications being developed at the same time as your program? If yes, identify all affected programs, include the (PM/EN) contact information for each affected program and the date you have notified the contact that their program may be affected.

#3. Are there any known technical requirements that will affect concurrent and/or future modifications/changes? If yes, provide a link to the contractual document (SOW/SOC/PWS) that requires the Integration Assessment that includes associated ground systems, Interface Requirements Specification (IRS), Interface Control Document (ICD) and the Software Version Description (SVD).

#1. Provide a link to the Integration Assessment, Interface Requirements Specification (IRS), Interface Control Document (ICD) and the Software Version Description (SVD).

SW_PM Joint Interoperability Documentation PROC-24-764

Process Info: If Requirements question #1 is yes, this area is Affected.

Description Interoperability is the ability to exchange information (all formats, voice, data etc.) on and off the aircraft with joint platforms (anyone not AF).

The Program Team must reach out to the Focal Point and the current DODAF SME to update the platform DODAF and ISP documents.

AWACS Guidance Documents:

JITCP3014 Combined Interoperability Test Plan (CITP) For Tactical Data Links (TDL) And United States Message Text Format (USMTF)

AWACS Guidance Documents listed above are in OSS&E at:

Processes Documents>OSS&E>OSS&E Checklists>2. SW Checklist>

Government Data Documents:

Existing Platform DODAF Documents and ISP

Recommended Data Deliverables:

DI-MISC-80508/T (to get data to update the platform DODAF documents & ISP) DI-MISC-80508/T (Joint Interoperability Impact Study)

Guidance Documents:

AFMCPD 63-4 (Software Requirements Review) JSSSEH (Joint Software System Safety Engineering Handbook)

C4ISR Architecture Framework

AWACS C4ISP

AFI 33-124

AFI 17-140

AFI 60-106

DoDI 4630.8 DoDI 8330.01

MIL-STD-188-203-1A

MIL-STD-187-700

MIL-STD-188-105

MIL-STD-6011

MIL-STD-6016

MIL-STD-6020

ADA 535060

CJCSI 3312.01A

CJCSI 2700.01G

CJCSI 3170.01A

DODI 8100.04

Joint Interoperability Test Command Interoperability Process Guide, Version 2.0 IER Standards

Recommended SOW/PWS Language:

SOW and CDRL requirements for contracts/RFPs, can be found in OSS&E at: Processes Documents>OSS&E>OSS&E Checklists>2. SW Checklist> Requirements_Product Support Contract Requirements Tool (PS CRT).xlsx

US Focal Point: Norman Ma

US Alternate Focal Point: Patricia Beaulieu

#1. Does this modification change software that produces, uses, or exchanges information (voice/text) in any electronic form to/from other services, agencies, or countries for operational use? If yes, work with the Focal Point and the current DODAF SME to update the platform DODAF documents and ISP (Information Support Plan).

#2. If #1 is yes, provide a link to your contractual document that requires an Interoperability Impact Study.

#1. Provide a link to the Interoperability Impact Study.

#2. Provide a link to the updated platform DODAF documents and ISP.

SW_PM Joint Interoperability (AFSIT/ Desert Timber & JIC) PROC-24-

Process Info: If either Requirements question is Yes, this area is Affected.

Description All Information Technology (IT) systems and National Security Systems (NSSs) that exchange and use information to enable units or forces to operate effectively in joint, combined, coalition, and interagency operations and simulations must be Interoperability certified before they are fielded. Fielded systems must be recertified every three years or after any changes that might affect interoperability.

Work with the Focal Point and contact Joint Interoperability Test Command (JITC) early in the acquisition program to ensure that certification is timely and cost-effective.

Air Force Systems Interoperability Test (AFSIT) is conducted by the USAF ACC/A5JI, is a series of tests that provides system level interoperability testing to validate compliance with TDL standards and verify compatibility and interoperability.

The emphasis is to use the actual hardware-in-the-loop (HWIL) assets to confirm interoperability of hardware or software modifications. Successful completion of an Air Force Systems Interoperability Test (AFSIT), or a letter from the AFSIT Director stating why no AFSIT was required, is needed is a prerequisite for participation in a Desert Timber (Joint Interoperability Testing).

The Desert Timber is conducted by Joint Interoperability Test Command (JITC) and addresses the System’s TDLs’ ability to support joint interoperability as described in the user-defined Joint Staff/J6 approved Net Ready Key Performance Parameter (NR-KPP) Table and supporting DoDAF Architectures.

Once the TDL military standard (MIL-STD) compliance certification is obtained then the joint interoperability certification (JIC) can be sought with JITC via the GTG-F (GIG Technical Guidance Federation) submittal process.

Joint interoperability testing and evaluation can be a repetitive process as conditions change.

Non TDL Any SW change that affects Joint Interoperability will also need a Joint Interoperability Certification (JIC) and can be sought with JITC via the GTG-F (GIG Technical Guidance Federation) submittal process.

Prerequisites: Platform DODAF and ISP needs to be updated per the SW_Joint Interoperability Documentation process area.

AWACS Guidance Documents:

JITC Plan 3014 Combined Interoperability Test Plan (CITP) For Tactical Data Links (TDL) And United States Message Text Format (USMTF)

AWACS Guidance Documents listed above are in OSS&E at:

Processes Documents>OSS&E>OSS&E Checklists>2. SW Checklist>

Government Data Documents:

Joint Interoperability Test Command Interoperability Process Guide Version 2.0.

Guidance Documents:

AFMCPD 63-4 (Software Requirements Review) JSSSEH (Joint Software System Safety Engineering Handbook) C4ISR Architecture Framework

AWACS C4ISP

AFI 33-124

AFI 17-140

AFI 60-106

DoDI 4630.8

DoDI 8330.01

MIL-STD-188-203-1A

MIL-STD-187-700

MIL-STD-188-105

MIL-STD-6011

MIL-STD-6016

MIL-STD-6020

ADA 535060

CJCSI 3312.01A

CJCSI 2700.01G

CJCSI 3170.01A

DODI 8100.04

Recommended SOW/PWS Language:

SOW and CDRL requirements for contracts/RFPs, can be found in OSS&E at: Processes Documents>OSS&E>OSS&E Checklists>2. SW Checklist>

US Focal Point: Patricia Beaulieu

US Alternate Focal Point: Frank Hayes

#1. Will this modification require a change to Technical Data Links? If yes, AFSIT & Desert Timber certification and a new or updated JIC is needed.

#2. Will this modification require a change to other communications and/or navigation systems? If yes, then a new or updated JIC is needed.

NOTE: If the answer to both 1 & 2 are yes only one new or updated JIC is needed to cover both.

#1. Provide a link to the AFSIT/Desert Timber certification.

#2. If Requirements #1 is Yes, and the change includes the IFF/Mode 5 system, provide a link to the current AIMS certification.

SW_PM AIMS CERTIFICATION PROC-24-766

AIMS (Air Traffic Control Radar Beacon System Identification friend or foe Mark XII System) Certification is required for all new, modification or upgrade programs that will directly or indirectly affect hardware or software for equipment, on the affected equipment list (link provided below) or the IFF system.

Any hardware, software or communications modification programs that directly affects or interfaces with any affected equipment will require AIMS certification determination. Any affected hardware or software that has been previously certified must be re-certified when upgraded or modified.

The purpose of this process area is to provide the necessary forms and information to the AIMS Certification Office so they can determine if AIMS certification or re-certification is required.

NOTE: If it is determined that AIMS certification is required the Program must provide funding for the certification.

Guidance Documents:

DoD AIMS Form 2011-1_D DoD AIMS Technical Standards 17-1000 DoD AIMS 03-1000A Addendum 3 to DoD AIMS Technical Standards 17-1000 AIMS Affected Equipment List AIMS Certification ASAF

All Guidance Documents located in OSS&E at:

Processes Documents>OSS&E>OSS&E Checklists>2. SW Checklist

Supporting Documentation:

IMS Integrated Master Schedule ICD Interface Control Document

Recommended Data Deliverables:

DI-NDTI-80809 Test/Inspection Report DI-MGMT-82377 Test Plan DI-MGMT-81996 Critical Plan of Action (CPOA) DI-SESS-81248 Interface Control Document (ICD) DI-MGMT-81650 Integrated Master Schedule (IMS)

US Focal Point: John Banzhaf

US Alternate Focal Point: Frank Hayes

#1. Are there any proposed Software or Firmware upgrades/updates that will affect or interface with any of the equipment on the affected equipment list or the IFF system? (see the Affected Equipment List at the path listed above). If yes, you must fill out the DoD AIMS 2011-1 form and submit it to the AIMS Certification Office.

#1. Was your DoD AIMS 2011-1 completed and submitted to the AIMS certification Office? If yes, provide the date that it was submitted and a link to the DoD AIMS 2011-1 that was submitted.

#2. Where you notified that your program requires certification/re-certification? If yes, what type (platform, system, box level) of certification is required?

#3. Did you receive your AIMS certification approval letter? If yes, please provide a link to the document.

If no, please provide details on the status of the certification.

SW_Configuration Management and Technical Data

SW_PM Requirements and Verification PROC-24-767

Prepare, or acquire, and maintain and deliver engineering data, which defines all equipment item(s) made a part of, installed in, or attached, as well as spares.

Engineering data will be completed, with regards to the dimensions needed, processes, methods, specifications, and ensure that all installation, assembly, and parts manufacturing or operations sequencing data is included in the package.

Data shall be loaded into the AF Drawing Repository by the Engineering Data Management Office (Joint Engineering Data Management Integrated Control System (JEDMICS)).

The Requirements Baseline Matrix (RBM) is a spreadsheet listing of all requirements maintained by the 558th. The Program Team will reach out to the 558th POC for the latest version of the RBM. The RBM is sent to the Primary Focal Point for SCN creation and approval. The SCN provides the approval to update the Requirements Baseline Matrix (RBM) and the official baseline in the DOORs database with the program Software Requirements Specifications (SRS’s).

Guidance Documents:

AFI 21-402

AFI 21-403

AFMC 21-1

MIL-STD-32216

MIL-HDBK-61

MIL-HDBK-516 (current version)

Recommended Data Deliverables:

DI-SESS-80776 Technical Data Package (TDP) DI-SESS-81000 Product Drawings/Models DI-SESS-81248 Interface Control Document (ICD)

Recommended SOW/PWS Language:

SOW and CDRL requirements for contracts/RFPs, can be found in OSS&E at:

Processes Documents>OSS&E>OSS&E Checklists>2. SW Checklist>

Focal Point: Rick Cox Alternate Focal Point: Andy Mathias

#1. Is this modification a new requirement or changed requirement? If yes, provide a link to the Software Requirement Specification (SRS) changes in the form of an RBM (see process area above). If no, explain if this is a maintenance change.

#2. Provide a list of Technical Requirements documents for this modification. (Allocated Baseline, SRS, SRD, TRD, SCD etc.)

#3. Have any COTS or other specific equipment requirements been waived? If yes explain why and list who the approver(s) of the E-3 requirements change are.

#1. Provide a link to the updated RBM with the verification information (RTM).

#2. Provide a link to the document(s) that approve any requirement(s) that were waived.

#3. Provide a link to the final test report that will verify this modification.

SW_PM CPIN PROC-24-768

Description:

The Software Control Center (SCC) is responsible for issuing Computer Program Identification Number (CPINS) and managing CPIN revision requests IAW TO 00-5-16. The Software Control Center (SCC) serves as the master repository for all weapon system software/documentation maintained at Tinker AFB and serves as the distribution point for software.

The approval of CCB’d AFMC Form 872 shall authorize the software release. The Program Office will contact the SCC to authorize release of the CPIN for software installation.

An alternative method for authorizing CPIN release is by Software Release Letter from the E-3 Program Manager or Chief Engineer.

Guidance Documents:

AFMCI 21-401

AFI 21-402

AFI 21-403

AFMCI 21-301

AFMC 21-1

MIL-HDBK-61 (current version) MIL-HDBK-516 (current version)

TO 00-5-16

1E-3A-8-1

CPIN Process located in OSS&E at: Processes Documents>OSS&E>OSS&E Checklists>2. SW Checklist

Recommended Data Deliverables:

DI-SESS-80776 Technical Data Package (TDP) DI-SESS-81000 Product Drawings/Models DI-SESS-81248 Interface Control Document (ICD)

Recommended SOW/PWS Language:

SOW and CDRL requirements for contracts/RFPs, can be found in OSS&E at:

US Focal Point: Stephen Ashley US Alternate Focal Point: Julie Ngo

#1. Are annual software licenses required? If yes, explain how funds have been allocated for the procurement of licenses?

#2. Will a CPIN be created or revised? If yes, has a AFMC Form 872 been completed and sent to the SCC? If no, explain why (i.e., Software release letter was done instead) and provide a link to the appropriate documentation.

#1. Provide the CPIN number and all the associated application and documentation information for the

CPIN.

SW_PM TCTOs PROC -24-769

Time Compliance Technical Orders (TCTOs) are directives issued to provide instructions to Air Force activities for accomplishing one-time changes, modifications, or inspections of equipment, or installation of new equipment.

Guidance Documents:

MIL-DTL-38804

TO 00-5-3

TO 00-5-15

TM 86-01 (latest rev)

MIL-HDBK-245

DOD 5010.12-M

MIL-HDBK-516 (current version)

Recommended Data Deliverables:

DI-MISC-80508/T Technical Order Source Data DI-TMSS-81810 Technical Manual Organization Plan DI-TMSS-81817 Technical Manual Quality Assurance Plan DI-SESS-80858 Suppliers Configuration Management Plan DI-TMSS-81812 Technical Manual Schedule and Status Report

Recommended SOW/PWS Language:

SOW and CDRL requirements for contracts/RFPs, can be found in OSS&E at:

Processes Documents>OSS&E>OSS&E Checklists>2. SW Checklist>

US Focal Point: Jon Sullivan

US Alternate Focal Point: Brad Darling

#1. Is a TCTO being provided for this modification? If yes, explain how the TCTO is being provided (in-house, contractor source data, etc.) and who will perform the TCTO instructions (PDM, contractor field team, depot field team, Organization).

#1. Has the final TCTO been verified and accepted? If yes, provide a copy of the final TCTO, if no provide the status of the TCTO.

SW_PM Flight Manuals PROC-24-770

Process Info: If Requirements question #1 is yes, this area is Affected.

Software Development also includes the generation of source data for Flight Manuals and identify the deltas that occur, as a result, of the new CSCI/IRS baseline.

The Flight Manuals are updated and maintained by the Technical Order Management Agency (TOMA) the Program Manager should contact the TOMA office to determine if/what funding changes will be required and to ensure they are using the most current TM86-01.

Guidance Documents:

TO 00-5-3

TM 86-01

AFI 11-215

US Focal Point: Mark Musselman

US Alternate Focal Point: Raymond Seiler

#1. Will Flight Manuals be updated? If yes, explain whether the proposed changes have been coordinated with the TOMA, if the TM86-01 has been initiated/submitted and provide the current status.

#2. Has an estimated cost for preparation and printing of the manuals been provided by the AFLCMC Tech Order Manager? If yes, has funding been allocated? If no explain why.

#1. Provide a link to the final Flight Manual changes.

#2. Provide a link to the TM86-01 that was completed and accepted by TOMA.

SW_PM Technical Orders PROC -24-771

Process Info: If Requirements question #1 or #3 is Yes, this area is Affected.

Air Force Technical Order (TO) System provides educational and operational tools for supporting AF-wide operations and maintenance programs. The system acquires, maintains, stores, distributes, and manages technical information, instructions, and safety procedures pertaining to Air Force equipment.

The Flight Manuals are updated and maintained by the Technical Order Management Agency (TOMA) the Program Manager should contact the TOMA office to determine if/what funding changes will be required and to ensure they are using the most current TM86-01.

Guidance Documents:

TO 00-5-3

TM 86-01

MIL-STD-38784

MIL-HDBK-516 (current version)

Recommended Data Deliverables:

DI-MISC-80508/T Technical Order Source Data DI-TMSS-81810 Technical Manual Organization Plan DI-TMSS-81817 Technical Manual Quality Assurance Program Plan DI-SESS-80858 Supplier Configuration Management Plan DI-TMSS-81812 Technical Manual Schedule and Status Report

Recommended SOW/PWS Language:

SOW and CDRL requirements for contracts/RFPs, can be found in OSS&E at: Processes Documents>OSS&E>OSS&E Checklists>2. SW Checklist>Requirements_Product Support Contract Requirements Tool (PS CRT).xlsx

US Focal Point: Shannon Naylor US Alternate Focal Point: Brian Bussen

#1. Are Technical Orders (TOs) including preliminary TOs, Operating Instructions (OIs), or similar operating documentation required/needed? If yes, list the documents that will be developed and/or updated.

#2. Is the most current version of the TM86-01 being used? If the TM86-01 is not being used, where are the tech order requirements stated and have these requirements and proposed tech order work been coordinated and agreed upon by the TOMA?

#3. Has an estimated cost for prep and print of the manuals been provided by the AFLCMC Tech Order Manager? If yes, has funding been allocated? If no explain why.

#1. Has the Technical Orders (TOs) including preliminary TOs, Operating Instructions (OIs), or operating documentation from Requirement #1 been provided? If yes, provide a link to the final/draft documents and any documents that are not final, list the document name and current status of the documents.

#2. Provide a link to the TM86-01 that was completed and accepted by TOMA.

SW_Engineering

SW_PM Software System Safety/Hazard Analysis PROC-24-772

The Software System Safety process area validates the application of system safety principles to software. Software includes new development, complex programmable logic devices (firmware), NDI, COTS, GOTS, re-used, GFE, and software used in the system.

The assessment of risk for software, and consequently software-controlled or software-intensive systems, cannot rely solely on the risk severity and probability. Determining the probability of failure of a single software function is difficult at best and cannot be based on historical data. Software is generally application-specific and reliability parameters associated with it cannot be estimated in the same manner as hardware. Therefore, another approach shall be used for the assessment of software’s contributions to system risk that considers the potential risk severity and the degree of control that software exercises over the hardware. See MIL-STD-882 (current version) for guidance.

The program should conduct a Hazard Analysis and consider potential software impacts to any new or existing Safety Significant Function. Areas of emphasis for software safety include software that affects safety of flight including flight controls and displays, safety of flight messages, high power, high voltage, and RF transmission.

Programs must complete and document their Software Safety Analysis and Assessment as well as successful completion of Level of Rigor tasks. Every software change impacting a new or existing safety signification function must have a Software Criticality Assessment and Level of Rigor tasks successfully completed.

Guidance Documents:

MIL-STD-882 (current revision) Joint Software Systems Safety Engineering Handbook JSWRBs Endorsement JS SSA Software System Safety Implementation Guide 29JUN2016 MIL-HDBK-516 (current revision)

Recommended Data Deliverables:

DI-SAFT-81626 Software System Safety Program Plan (SSPP) DI-SAFT-80101 Preliminary Hazard Analysis Report (PHA) DI-MISC-80508/T Functional Hazard Analysis (FHA) DI-SAFT-80101 System Safety Hazard Analysis Report (SSHAR) DI-ILSS-81495 Failure Mode Effects and Criticality Analysis (FMECA) DI-SAFT-80102 Safety Assessment Report (SAR) DI-SAFT-81300 Mishap Risk Assessment Report DI-MISC-80508/T – Requirements Analysis, Architecture Analysis, Design Analysis, Code Analysis

Recommended SOW/PWS Language:

SOW and CDRL requirements for contracts/RFPs, can be found in OSS&E at:

Processes Documents>OSS&E>OSS&E Checklists>2. SW Checklist>Requirements_Product Support Contract Requirements Tool (PS CRT).xlsx

US Focal Point: Ben Greiner US Focal Point: Nathan Diperri

#1. Provide a link to the preliminary SSHAR that contains a list of new or modified safety significant functions and the SWcI assigned to each.

#2. Provide a link to the contractual document (SOW, PWS, SOC) that requires the contractor to perform Software System Safety activities and associated deliverables. (See recommended information in the process area above)

#1. Per your SOW/PWS, have all the Software System Safety CDRLS been delivered? If yes, provide a link to the CDRLs, if no provide a list of CDRLs not delivered and why.

#2. Have all Level of Rigor Tasks (i.e. Requirements Analysis, Architecture Analysis, Design Analysis, Code analysis, in-depth safety testing, safety specific testing (including any T2 safety test results) been successfully completed? If yes, provide a link to the completed artifacts. If no provide a link to the Formal Risk Acceptance with the signature of the Approval Authority.

SW_PM Risk Assessment and Management PROC-24-773

The focus of this process area is to identify the top Technical Risks with clear risk statements. List risks in the form IF risk, THEN consequence, impact.

Both Contractor and Government risk assessment and management is to be documented in this process area. In addition to contractor risk requirements, every government program team is required to perform their own risk assessment, manage risks, and do periodic re-assessments.

Risks are potential future events or conditions that may have a negative effect on achieving program objectives for cost, schedule, and performance. Defense programs encounter risks that should be anticipated and addressed on a continuing basis.

DoDI 5000.88

DTM 17-001

DoDD 5000.1 DoD 5000.2-R

AWB-013

MIL-HDBK-516 (current version)

DSMC Risk Management Guide can be found in OSS&E at:

Government Risk Data:

5x5 Risk Matrix

AFI 63-101

AFI 20-101

DAFPAM 63-128

Recommended Data Deliverables:

DI-MGMT-81808 Contractor’s Risk Management Plan DI-MGMT-81809 Risk Management Status Report

US Focal Point: Lisa O`Leary US Alternate Focal Point: Ben Grenier

#1. When was the Government risk assessment done and who participated in the assessment (stakeholders, sustainment organization, acquisition agency)?

#2. Provide a link to the contractual document (SOW, PWS, SOC etc.) that requires the Contractor to conduct risk assessment and management and provide a Risk Management Plan.

#3. List all Government technical risk (IF Then format) and the associated mitigation plans for each risk identified in the risk assessment.

#4. How and when will the Government technical risks be monitored and tracked (IPT, working group briefings etc.)?

#1. Provide a link to the Contractor’s Risk Management Plan and a list of technical risk(s) and associated mitigation plan(s).

#2. Provide documentation that shows review and burndown of the Government technical risks (risk tracker or burndown plan Excel/Word/PowerPoint, etc.).

#3. Are there any remaining Government technical risks? If yes, explain how and when, will they be addressed.

SW_PM Information Operations and Security PROC-24-774

Process Info:

Program Managers are required to reach out to the HBS Cyber Division regarding their modification program.

ACAS (Assured Compliance Assessment Solution) and SCAP (Security Content Automation Protocol) scans provided by the test team. These classified scans tell which STIGs have been applied and will NOT uploaded to the OSS&E database and are sent to the Cybersecurity team via SIPR.

AFI 10-701

AFI 33-201

AFI 33-202

AFI 17-101

DoD 8140.01 DoDI 5000.02 DoDI 5200.44 DoDI 5000.82 DoDI 5000.90 DoDI 500083 DoDI 8500.01

DoDI 8551.01 DoDI 8510.01 NIST.SP.800.53r5 NIST.SP.800-161r1

NIST SP 800-88 R1

CNSSI 1253

AFMAN 17-1301

MIL-HDBK-516 (current version) DOD Zero Trust Reference Architecture

Systems Security Engineering Cyber Guidebook

US Focal Point: Jason Weingarten US Alternate Focal Point: Joseph Iacoviello

Criteria for Requirement Approval:

1. Have you reached out HBS Division Cyber regarding your modification (Y/N)? If yes, has it been determined what type of authorization is required for your modification (ie.

Authorization to Operate [ATO]/Cybersecurity Impact Evaluation Recommendation [CIER]? If no, explain why.

#2. Please list all the supporting documentation requested by your ISSO that is required for your ATO/CIER and ensure they are posted in the Mod Docs folder.

#3. Have you provided Static Code Analysis Scans (ie. Coverity, Fortify, SonarCube) for your modification to your ISSO via SIPR (Y/N)? If yes, provide the type of scan and the date of submittal to the ISSO. If no, explain why.

#4. Have you provided up to date Assured Compliance Assessment Solution (ACAS) and Security Content Automation Protocol (SCAP) Scans for your modification to your ISSO via SIPR (Y/N)? If no, explain why.

#5. Is there a plan in place for applying System Updates (to include Security Patches) to your modification post initial installation? What is the scheduled update/patching frequency that is planned for your modification (ie. Quarterly, bi-annually, annually)? If yes, explain the schedule and frequency of patching/updating, if no explain why.

1. Provide a link to the ATO/CIER that has been signed by the Authorizing Official.

SW_PM Software Test and Evaluation (FQT/DT/OT) PROC -24-775

Process Info: If any of the Requirement questions are Yes, this area is Affected.

Formal Qualification Test and Evaluation (QT&E) is performed by government test representatives and is a tailored type of DT&E for which there is little to no RDT&E-funded development effort. It validates how a system integrates into its intended environment, how it meets specified requirements in accordance with the approved design, and how it meets performance standards.

Developmental Test & Evaluation (DT&E) is a test used to compare a system or components against requirements and specifications to reduce risk and inform developers of current performance status.

The purpose of DT&E is to provide the Program Manager and decision-makers with information to measure a project’s progress, identify problems, examine how a system is going to satisfy key requirements, and manage and reduce risk. DT&E will verify that the system can meet all contractual and technical requirements and is ready to continue development and prepare for Operational Test & Evaluation (OT&E).

Operational Test and Evaluation is to test a system in the actual or simulated environment that it was designed for with users of the system in realistic operational conditions. This will determine if the system is operationally effective and operational suitability for combat.

AFPD 99-1

DODI 5000.89

DAFI 99-103

DAFI 99-106

AFI 99-109

AFMAN 63-119

MIL-HDBK-516 (current version) T.O. 00-35D-54

Recommended Data Deliverables:

DI-MISC-80508/T Tailor include test plans, test reports, equipment and procedures DI-SESS-81785 Systems Engineering Management Plan DI-IPSC- 81438 Software Test Plan DI-IPSC-81439 Software Test Description DI-IPSC-81440 Software Test Reports

Processes Documents>OSS&E>OSS&E Checklists>2. SW Checklist>Requirements_Product Support

US Focal Point: Stephen Ashley

#1. Does the program plan to conduct Formal Qualification Testing, Developmental Testing, and Operational Testing? If yes, provide link to the contractual document (SOW, PWS, SOC) that describes the software test activities and deliverables for all phases of testing. If no explain why and provide all supporting documents/artifacts.

#2. Does the program plan to establish a Software Integrated Test Team (ITT)? Provide link to the contractual document (SOW, PWS, SOC) that describes ITT requirement. If no explain why.

#3. Explain how DRs are being reported and documented? Provide a link to the contractual document (SOW, PWS, SOC) with the defect reporting (DR) requirement.

#1. Provide a link to the test report.

#2. Have all deficiencies been reviewed and approved at a Material Improvement Process Reviewed Board (MIPRB) and entered into an approved database?

SW_Training, Training Devices, and Support Facilities

SW_PM Training, Simulators and Trainers PROC -24-776

Training includes training resources, actual training and equipment used to train civilian and military personnel to acquire, operate, maintain, and support a system. This element addresses the processes, procedures, curricula, techniques, training devices, simulators, other equipment, and software necessary to train civilian and active duty/reserve duty personnel to operate and support/maintain the defense system; includes acquisition, installation, operation, and support of training equipment/devices. The system design/modification should provide the user with the necessary support infrastructure for achieving the user’s readiness requirements.

Guidance Documents:

DoDD 1322.18

AFPD 36-22

AFI 16-1007

AFI 36-2650

AFI 36-2251

AFMC 63-4

Recommended Data Deliverables:

DI-MISC-80508/T Technical Report, Study/Services DI-ILSS-80872 Training Materials

Recommended SOW/PWS Language:

SOW and CDRL requirements for contracts/RFPs, can be found in OSS&E at:

Processes Documents>OSS&E>OSS&E Checklists>2. SW Checklist>Requirements_Product Support Contract Requirements Tool (PS CRT).xlsx

US Focal Point: Bob Burger US Alternate Focal Point: Kwabena Boateng

#1. Does this modification require any mission simulators, career field trainers, or any training facility, training courses or materials to be updated/modified or developed? If yes, provide a link to the contractual document (SOW/PWS/SOC) that documents the training course/materials requirement.

#2. Has your team reached out to Wing XR for training requirements? If yes provide the training requirements. If no explain why.

#3. Who will provide the initial training/difference training? Provide a link to the contractual document (SOW/PWS/SOC) or a document that details how this training will be provided.

#4. Has ACC determined if this modification impacts SIMCERT/SIMVAL (Simulator Certification/Simulator Validation) requirements? If yes, please explain the requirements that will change and why.

#5. Has funding been provided for or allocated to training activities? If yes, is simulator/trainer modification funding available or budgeted?

#6. Are Tech Orders for trainers and simulators being updated? If yes, provide a link to the contractual document that requires the TOMA or Wright Patterson SPO to update the TOs.

#1. Provide a link to the training deliverables (i.e., Training Materials).

#2. Provide a link to the SIMCERT/SIMVAL certification.

#3. Provide a link to the approved TO(s).

SW_PM Development/Qualifications Labs PROC -24-777

Process Info: If Requirements question #2 is Yes, this area is Affected.

This area is used to identify the lab that will be used for complete integrated software testing and provide evidence for compliance with software requirements including sustainment. This area will ensure that software modifications will provide all associated hardware to the lab with the proper documentation plans for installation and maintenance.

Any new lab equipment must be lab certified, please contact the POC for the appropriate lab to verify their lab requirements.

Guidance Documents:

MIL-STD-498

MIL-STD-1644

MIL-STD-1679

Recommended Data Deliverables:

DI-IPSC-81427 Software Development Plan DI-IPSC-81428 Software Installation Plan

DI-IPSC-81440 Software Test Report DI-IPSC-81443 Software User Manual

Recommended SOW/PWS Language:

SOW and CDRL requirements for contracts/RFPs, can be found in OSS&E at:

Processes Documents>OSS&E>OSS&E Checklists>2. SW Checklist>Requirements_Product Support

US Focal Point: Jeff Cramer

US Alternate Focal Point: Tuan Dao

#1. Will software be installed into a lab? If yes, identify which lab (refer to the AWACs Lab Reference Spreadsheet) and explain the purpose for installing this software in the lab.

#2. Will this software require a change to the lab baseline configuration? If yes, please explain.

#3. Provide a link to the contractual document (SOW, SOC, SORA) that requires the software to be maintained/sustained?

#4. Is there any special equipment (test, etc.) required to support this software change in the lab? If yes, provide a list of the equipment needed, why it is needed and whether the equipment is lab certified or will need to be lab certified.

#1. Provide a link to the software drawings/documents (including additional equipment).

#2. Provide a link to the plan for keeping the software up to date.

SW_PM Software Sustainment PROC -24-778

Software sustainment includes actions that change the software baseline (adaptive, corrective, perfective, and preventative) as well as modifications or upgrades that add capability or functionality.

This area is to identify the plans to maintain and sustain software/firmware.

Guidance Documents:

MIL-HDBK-1467

AWACS Software Management Plan AWACS Maintenance Agreement/Sustainment Plan

DFARS 227.7203

DFARS 252.227

Recommended Data Deliverables:

DI-ESSS-82046 Software Licensing Requirements DI-MGMT-82404 Software Acquisition & Sustainment Package

DI-TMSS-80527 COTS

DI-IPSC-82134 Software Sustainability Package

Recommended SOW/PWS Language:

SOW and CDRL requirements for contracts/RFPs, can be found in OSS&E at:

Processes Documents>OSS&E>OSS&E Checklists>2. SW Checklist>Requirements_Product Support Contract Requirements Tool (PS CRT).xlsx

US Focal Point: Jeffrey Cramer US Alternate Focal Point: Lisa O’Leary

#1. Will additional licensing (licensing, OEM licensing, COTS, Organic, etc.) and maintenance be required?

If yes, provide a link to the contractual document (SOW, SOC, PWS) that requires additional licensing and maintenance.

#2. Provide a link to the contractual document (SOW/SOC/PWS) for the requirement that delivers the source code including intellectual property rights to be delivered as a CDRL.

#1 Provide a link to the documentation for additional licensing and maintenance.

#2 Provide a link to the CDRL for source code delivery and intellectual property rights.

Secure Iridium Communications TRD F19628-01-D-0016 DO91 i

ATTACHMENT 2

TO

CONTRACT F19628-01-D-0016

Delivery Order 0091

Secure Iridium Communication

Technical Requirements Document

RELEASE/REVISION: RELEASE/REVISION DATE

21 June 2012

Distribution Statement D Applies: Distribution authorized to the Department of Defense and U.S. DoD Contractors Only. (Critical Technology)(Date of Determination – 21 June

2012), other requests for this document shall be referred to ESC/HBSG, 3 Eglin St., Hanscom AFB MA 01731 which is the DoD Controlling Office. DESTRUCTION NOTICE:

Destroy by any method that will prevent disclosure of contents or reconstruction of the document.

Secure Iridium Communications TRD F19628-01-D-0016 DO 0091 ii

Table of Contents

1.0 SCOPE

2.0 APPLICABLE DOCUMENTS

2.1 Government Documents

3.0 REQUIREMENTS

3.1 General Requirements

3.2 Functional/Performance

3.3 Interfaces

3.3.1 Internal Interfaces

3.3.2 External Interfaces

3.4 Physical/Technical/Environmental Characteristics

3.4.1 Electrical Power and Loads Analysis and Power Quality

3.4.2 Structural Design and Loads

3.4.3 Environmental/Cooling Systems

3.4.4 Air Vehicle Performance

3.4.5 Structural Materials and Processes Control

3.4.6 System Safety

3.4.7 Environmental Conditions

3.4.8 Electromagnetic Compatibility/Interference

3.4.9 Survivability and Vulnerability

3.4.10 Spectrum/Frequency Management

3.4.11 GATM and Navigational Safety

3.4.12 Interoperability

3.4.13 Reliability and Maintainability

3.4.14 Information Operations and Security

4.0 QUALITY ASSURANCE/TESTING

4.1 Formal and Informal Verification

4.2 Methods of Verification

4.3 Regression Test

iii

4.4 Laboratory, Ground and Flight Tests

4.5 Verification Cross-Reference Matrix

5.0 ACRONYMS AND DEFINITIONS

5.1 Acronyms

5.2 Definitions

1.0 SCOPE

1.1 This document establishes the requirements for the Secure Iridium Communication (SIC) capability to be added to the Block 40/45 E-3G Airborne Warning and Control System (AWACS). SIC will provide a 40/45 E-3G platform with a secure tactical chat solution to satisfy CENTAF, PACAF, NORTHAF, and SOUTHAF operational requirements. SIC is based on a satellite communication device that provides Beyond Line-Of-Sight (BLOS) connectivity, Internet-Protocol (IP) support, and a narrow bandwidth capability for data and voice collaboration. The SIC program will build off the initial chat capability implemented on 30/35 E-3A/B AWACS fleet via Time Compliance Technical Orders (TCTOs) 1E-3-909 and 1E-3-924.

2.0 APPLICABLE DOCUMENTS

2.1 Government Documents

CFR, Part Chapter XVII, Part 1910 Occupational Safety and Health Standards

CNSS Advisory Memorandum

TEMPEST 01-02

CNSS Advisory Memorandum TEMPEST 01-02

DFARS 252.211.7003 Defense Acquisition Regulations System - Item Identification and Valuation.

EPA-17 Environmental Protection Agency 17 Priority Pollutants

MIL-HDBK-1568 Materials and Processes for Corrosion Prevention and Control in Aerospace Weapons Systems

MIL-STD-461E Requirements for the control of Electromagnetic Interference Characteristics of Subsystems and Equipment

MIL-STD-464A Electromagnetic Environmental Effects Requirements for Systems

MIL-STD-882D System Safety

MIL-STD-1472F Human Engineering

NSTISSAM TEMPEST/2-95 RED/BLACK Installation Guidance

NSTISSP No. 11 National Policy Governing the Acquisition of Information Assurance (IA) and IA-Enabled Information Technology (IT) Products, Revision June 2003

SS775-16001 US AWACS specification, General Specification for Performance and Design Requirements for the Block 40/45

TCTO 1E-3-909 Installation of Transitional Networking Capability (TNC) Phase-I Equipment on USAF E-3B/C Series Aircraft

TCTO 1E-3-924 Installation of Transitional Networking Capability (TNC) Phase-II Equipment on USAF E-3B/C Series Aircraft

Title 40 CFR, Part 82, Protection of Stratospheric Ozone

3.0 REQUIREMENTS

3.1 General Requirements.

3.1.1 The SIC modification to the Block 40/45 E-3G, hereafter referred to as the SIC, will provide two independent iridium communications channels, each capable of supporting clear voice and secure data communications between the aircraft and other appropriately configured airborne and/or ground systems.

3.1.2 Each iridium communication channel will support: connection activation, Iridium signal strength monitoring, encryption and voice/data communication with distant C2 systems.

3.1.3 Reserved.

3.2 Functional/Performance.

3.2.1 The SIC system shall provide two (2) simultaneously operable and independent communications channels.

3.2.2 Each SIC communications channel shall support clear voice and secure data communications.

3.2.3 Each SIC channel shall be capable of reconfiguration for operation at different classification levels.

3.2.4 The SIC…