DRAFT_PWS_PdM_WF_SwISS_20161116.docx

DOCX document 270 KB Posted

Attached to
Request for Information (RFI) in support of PdM Waveforms (WFs) Software In-Service Support (SwISS) Contract
Solicitation number
W15P7T-17-R-0009
Issued by

About this file

Draft PWS

View the file

Other files

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

PdM WF and NS SwISS PWS Version 1.1

Performance Work Statement (PWS)

FOR

PROGRAM EXECUTIVE OFFICE

COMMAND CONTROL COMMUNICATIONS –

TACTICAL

Project Manager Tactical Radios Product Manager Waveform AND NETWORK SERVICES SOFTWARE In-SERVICE SUPPORT

Version 1.3 16 November 2016

PROGRAM EXECUTIVE OFFICE

COMMAND CONTROL COMMUNICATIONS –

TACTICAL (PEO C3T)

6010 Frankford avenue aberdeen proving ground, MD 21005

Statement A – Approved for public release; distribution is unlimited.

1.0General Scope4
1.1General Purpose4
1.2General Background4
2.0Applicable General Documents and References6
2.1Overview6
2.2General References6
2.3Open Systems Architecture and Test References7
2.4Waveform and Network Services References9
2.5Information Assurance References10
2.6Order of Precedence11
3.0General Requirements12
3.1Overview12
3.2Reserved12
3.3Overarching Contract Documents12
3.4Processes14
3.5Data Deliverables15
3.6Security16
3.7Period of Performance17
3.8Place of Performance17
4.0Waveform Development Environment (WDE) Ecosystem19
4.1Overview19
4.2WDE Ecosystem Task19
4.3WDE Ecosystem Waveform and Network Service Requirements19
4.4WDE Ecosystem Subcomponents20
5.0Waveforms and Network Services22
5.1Overview22
5.2Waveform and Network Service Software Products22
5.3SwISS Waveform and Network Service Task23
5.4Waveform and Network Service WDE Ecosystem Utilization23
5.5Waveforms and Network Services Summary23
6.0Order Requirements29
6.1Overview29
6.2Technical Support and Integration Support29
6.3System Engineering30
6.4Program Management33
6.5Test and Evaluation37
6.6Training41
6.7Engineering Data41
6.8Modeling and Simulation (M&S)46
6.9Certifications and Qualifications47
Facility and Personnel49
Access49
Security Classification Guides49
Antiterrorism / Operations Security (OPSEC)49
IT Sensitive Duties52
Sub-Contractors Facility Clearance52
Foreign Sub-Contractor52
TEMPEST53
Visit Authorization Letters (VALs) for Qualified Employees53
Handling of Classified Material or Information53

General Scope General Purpose The purpose of this Performance Work Statement (PWS) is to support Program Executive Office Command Control Communications - Tactical (PEO-C3T), Project Manager Tactical Radios (PM TR), Product Manager (PdM) Waveforms by providing Software In-Service Support (SwISS) for the Waveform Development Environment (WDE) Ecosystem, multiple waveforms (WF) and network services (NS). The intent of the software in-service support is to provide technical support, software development, enhancement, maintenance, and product improvements to US Government (USG) managed WF and NS software products.

Section 1 of the PWS provides the purpose and background. Section 2 lists general documents and references impacting all WDE Ecosystem, WF and NS products. Section 3 provides general requirements for the SwISS contract and all orders performed under the SwISS contract. WDE Ecosystem requirements are covered in Section 4 and WF and NS requirements are described in Section 5. Section 6 provides order level requirements. Appendix 1 specifies the Security requirements, Appendix 2 specifies the Property Management Plan, and Appendix 3 provides an Acronym List.

General Background WFs and NS software products are key subcomponents of tactical Software Defined Radios (SDRs) that support net-centric operational warfare for Department of Defense (DoD) and Government missions. PEO C3T leverages an acquisition strategy to acquire and maintain enterprise software products intended for reuse on its tactical SDR hardware terminals to:

1) lower the costs for Vendors or Government to develop and maintain tactical SDRs meeting US Army and DoD requirements,

2) facilitate full interoperability across different organizational echelons and/or different services potentially using different tactical SDRs, and

3) develop and maintain a strong industrial base to enhance competition and encourage innovation.

The SwISS Contract will provide for the following:

1) the development, enhancement, maintenance, product improvement, and procurement of a WDE Ecosystem(s) for all WF and NS software products, and

2) the development, enhancement, maintenance, product improvement, and procurement of one or more of the following WF and NS software products:

Solider Radio Waveform (SRW), Wideband Networking Waveform (WNW), enterprise Over-The-Air Management (eOTAM), and Single Channel Ground and Airborne Radio System (SINCGARS), Narrowband WF, Very/Ultra High Frequency (V/UHF) Line of Sight (LOS), UHF Satellite Communications (SATCOM), Mobile User Objective System (MUOS), Network Services, Second generation Anti-jam Tactical UHF Radio for NATO (SATURN), Joint Enterprise Network Manager (JENM), next generation Waveforms and Network Services, Integrated Broadcast Service (IBS), Bowman, Have Quick II, Link-16, Soft INC, Tactical Data Controller (TDC), Air Traffic Control (ATC), Project 25 (APCO 25), Special Communications Mode (SCM), High Frequency (HF), Link 22.

Software products delivered on this contract are intended to be redistributed to Government approved Vendors and/or Government through the DoD Information Repository (IR) managed by Joint Tactical Network Center (JTNC) for the purpose of reuse, porting and integration into tactical SDRs for DoD and Government operations. Each Vendor and/or Government entity is responsible for integration and porting of this software (as applicable) into a specific tactical SDR product and ensuring its proper operation. This PWS also covers the assistance of this software porting, integration, testing, and training process into tactical SDR products.

The SwlSS contract will provide support for the Government managed WF or NS software products. In-Service Support covers software activities through the entire life-cycle of the software from development, enhancements, maintenance, instantiation, product improvements, procurement, operation, and training. The SwISS Contractors may be required to work with other DoD and Government agencies or organizations.

The SwISS contract will provide support for the Government managed WDE Ecosystem(s). In-Service Support covers WDE Ecosystem(s) activities thru the entire life-cycle from development, enhancements, maintenance, product improvements, procurement, operation, and training.

The work performed under the SwISS contract will be performed primarily within the Contractors’ facilities, Government facilities, and other Contractors’ facilities in the US. Release of some software products to coalition nations is being considered by the DoD and could become a future requirement.

Applicable General Documents and References Overview The documents listed in this section are referenced in Sections 3.0, 4.0 and 5.0 of this PWS. This section is not intended to include documents cited in other sections of this document. Documents listed should be used for additional information or as examples, and they may be used for the development of the proposal. While every effort has been made to ensure the completeness of this list, document users are cautioned that they must meet all specified requirements of documents cited in Section 3.0, 4.0, and 5.0 whether or not they are listed in this section.

Documents may be available by searching the World Wide Web (e.g. http://quicksearch.dla.mil/ for Military Standards and http://www.ieee.org. for IEEE documents), through the Contracting Officer or Contract Specialist or specific Government Furnished Information is available on the Information Repository (IR) managed by the JTNC.

Authorized Contractors may be granted access to the folder on the IR, but access will be allowed only after the Contractor has completed and submitted the request for PdM WF and NS SwISS RFP access and only after the DD Form 2345 information is verified by the Government. No classified information will be made available to any Contractors via the IR. To obtain authorization to access the IR PdM WF and NS SwISS RFP folder, each Contractor must complete the request for PdM WF and NS SwISS RFP access available only on the IR Registration website: http://www.public.navy.mil/jtnc. Those Contractors that do not have a properly certified Military Critical Technical Data Agreement (DD Form 2345) can start that process immediately by following the procedures documented at the IR registration website. Access to the registration website requires users to have a Public Key Infrastructure (PKI) certificate.

General References

Title
Reference
JTRS Operational Requirements Document (ORD) (Increment 1)
Version 3.2.1, 28 AUG 2006
PdM WF System Engineering Plan (SEP)
In-Development
PdM WF Software In-Service Support (SwISS) Plan (for Vendors)
In-development
Waveform Application Portability Guidelines
version 2.0, 12 NOV 2015

IEEE Std 12207-2008, Systems and Software Engineering — Software Life Cycle

Std 12207-2008 Published 31 JAN 2008

Joint Tactical Radio System (JTRS) Software Standards
version 1.4.3, 18 JAN 2011
Joint Tactical Networking Center Standards Standard Interface Control Working Group Policies and Processes
version 1.2, 17 DEC 2015 (or later)
DoD Open Systems Architecture Contract Guidebook for Program Managers
version 1.1, JUN 2013
Timing Service API Primer
version 1.0, 04 SEP 2014
Software Communications Architecture Specification User's Guide
version 4.1, 23 FEB 2016
JTNC Standards Open Architecture Primer
version 3.0, 04 SEP 2014
DoD Standard practice for Work Breakdown Structures
MIL-STD-881C

Open Systems Architecture and Test References

Title
Reference
Software Communications Architecture Specification
Version 2.2.2, 15 MAY 2006
Software Communications Architecture Extensions
Version 2.2.2, 22 DEC 2006
Software Communications Architecture Appendix B AEP
Version 2.2.2A, 22 OCT 2008
Software Communications Architecture Networking AEP
Version 2.2.2A.1, 28 SEP 2010
DISR 15-2.0 SCA 4.1:2015, "Software Communications Architecture Specification,"
Version 4.1, 20 AUG 2015
SCA 4.1 Correction Sheet
Version 1.0 Draft, TBD
DISR 14-3.0 Tactical Radio API, "Audio Port Device Application Program Interface (API),"
Version: 1.3.4, 29 JUL 2010
DISR 14-3.0 Tactical Radio API, "Barometric Pressure Transducer (BPT) Device Application Program Interface (API),"
Version: 1.0.1, 30 APR 2008
DISR 14-3.0 Tactical Radio API, "Device Message Control Application Program Interface (API),"
Version: 1.1.3, 31 MAR 2008
DISR 14-3.0 Tactical Radio API, "Ethernet Device Application Program Interface (API),"
Version: 1.2.2, 31 MAR 2008
DISR 14-3.0 Tactical Radio API, "Frequency Reference Device Application Program Interface,"
Version: 1.0.3, 22 OCT 2008
DISR 14-3.0 Tactical Radio API, "Global Positioning System Application Program Interface (API),"
Version: 2.1.4, 24 JUL 2014
DISR 14-3.0 Tactical Radio API, "Internet Protocol (IP) Routing Service Application Program Interface (API),"
Version: 1.2, 31 AUG 2011
DISR 14-3.0 Tactical Radio API, "Joint Tactical Radio System (JTRS) Standard, JTRS CORBA Types,"
Version: 1.0.2, 02 APR 2008
DISR 14-3.0 Tactical Radio API, "JTR Key Encryption Key Standard,"
Version: 1.3, 18 APR 2012
DISR 14-3.0 Tactical Radio API, "JTRS Platform Adapter Interface Standard,"
Version: 1.3.3, 26 JUN 2013
Tactical Radio API, JTRS Platform Adapter (JPA) Interface Standard (IS) Supplement
Version: 1.3.3, 26 JUN 2013
DISR 15-2.0 Tactical Radio API, "Key Tag Specification,"
Version: 1.2.9, 30 OCT 2014
Tactical Radio API, Tactical Radio Key Tag Field Value Affiliation Registry
Version: 1.0.1, 25 FEB 2016
DISR 15-2.0 Tactical Radio API, "Link Layer Control (LLC) Service Application Program Interface (API),"
Version: 1.0, 17 APR 2015
DISR 14-3.0 Tactical Radio API, "M1553 Device Application Program Interface (API),"
Version: 1.2.1, 01 OCT 2007
DISR 14-3.0 Tactical Radio API, "Management Information Base Object Identifier Registry,"
Version: 1.2.4, 24 APR 2014
DISR 14-3.0 Tactical Radio API, "MHAL on Chip Bus Application Program Interface,"
Version: 1.1.5, 26 JUN 2013
Tactical Radio API, MHAL On Chip Bus (MOCB) API Supplement
Version: 1.1.5, 26 JUN 2013
DISR 14-3.0 Tactical Radio API, "Modem Hardware Abstraction Layer Application Program Interface,"
Version: 3.0, 02 OCT 2013
Tactical Radio API, Modem Hardware Abstraction Layer (MHAL) API Supplement
Version: 3.0, 02 OCT 2013
Tactical Radio API, MHAL API Version 3.0 Errata
Version: 1.0, 10 SEP 2015
DISR 14-3.0 Tactical Radio API, "Network Layer Control Service Application Program Interface (API),"
Version: 1.0, 22 OCT 2008
DISR 14-3.0 Tactical Radio API, "Network Layer Service Application Program Interface (API),"
Version: 1.0.1, 11 OCT 2007
DISR 15-2.0 Tactical Radio API, "Package Management Application Program Interface (API),"
Version: 1.0, 30 OCT 2014
DISR 14-3.0 Tactical Radio API, "Packet Application Program Interface (API),"
Version: 2.0.2, 02 APR 2008
DISR 14-3.0 Tactical Radio API, "Profile Manager (PM) Service Application Program Interface (API),"
Version: 1.0, 19 MAR 2010
DISR 15-2.0 Tactical Radio API, "Radio Security Services Application Program Interface (API),"
Version: 4.0.1, 12 FEB 2015
Tactical Radio API, Radio Security Services (RSS) API Supplement
Version: 4.0.1, 12 FEB 2015
DISR 14-3.0 Tactical Radio API, "Retransmission Service Application Program Interface (API),"
Version: 1.2.2, 03 JUN 2009
DISR 14-3.0 Tactical Radio API, "Serial Port Device Application Program Interface,"
Version: 2.1.4, 26 JUN 2013
DISR 14-3.0 Tactical Radio API, "Tactical Public Key Infrastructure Interface Specification and Digital Certificate Processing Guidance,"
Version: 2.0, 17 JUL 2013
DISR 14-3.0 Tactical Radio API, "Tactical Radio API Device IO,"
Version: 1.0.2, 05 MAY 2010
DISR 14-3.0 Tactical Radio API, "TCP Sockets Service Application Program Interface (API),"
Version: 1.0, 01 OCT 2007
DISR 14-3.0 Tactical Radio API, "Timing Service Application Program Interface,"
Version: 1.4.4, 26 JUN 2013
Tactical Radio API, Timing Service API Supplement
Version: 1.4.4, 26 JUN 2013
DISR 16-1.0 Tactical Radio API, "Vocoder Service Application Program Interface,"
Version: 1.4, 26 FEB 2015
Tactical Radio API, Vocoder Service API Supplement
Version: 1.4, 26 FEB 2015
JTNC Test and Evaluation Laboratory SCA Test and Evaluation Plan
Version 3.0, 30 DEC 2015
JTNC Test and Evaluation Laboratory Standard API Verification Plan
Version 3.1, 21 DEC 2015
Tactical Radio Suite B AES OTAT KEK Specification
version 1.3, 30 OCT 2015
Tactical Radio API, Over-the-Air Management (OTAM) Interface Standard
Version: 1.0, 12 NOV 2015

Waveform and Network Services References

Title
Reference

SRW Version 1.2.2 27 June 2016 Soldier Radio Waveform (SRW), Version 1.2.2

WNW Version 4.2.1 14 April 2016 Wideband Networking Waveform (WNW), Version 4.2.1 eOTAM Version 1.1 31 July 2015 enterprise Over-the-Air Management (eOTAM), Over-the-Air Server Service (OSS), Version 1.1

SINCGARS Version 2.0 1 October 2014 Single Channel Ground and Airborne Radio System (SINCGARS), Version 2.0

SINCGARS Waveform Functional Overview (WFO) Cryptographic Modernization Initiative (CMI) Version 1.50 17 October 2016 Version 1.50, 17 OCT 2016

Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS), NSA 09-01A, Version 2.1
Version 2.1, 2 JUL 2012
TSVCIS Annex A: Tactical Secure Voice Cryptographic Interoperability Specification Implementation Details, NSA 09-01A, Version 2.1
Version 2.1, 28 AUG 2012

Target Interface Extract for Stakeholder Review Rev 3, 9/27/16

Rev 3, 27 SEP 2016

JTNC Software Defined Radio Waveforms System Threat Assessment Report (STAR),
27 MAR 2013

Information Assurance References

Title
Reference
NSA Information Assurance Security Requirements Directive (IASRD)
16 October 2012
NSA Technical Security Requirements Document (TSRD)
Version TBD, XXX
NSA Software Analysis and Assessment Process Description (SAAPD)
Version G, 21 JUL 2016
Waveform Software Security Report template
Version 1.0, 13 DEC 2005
NSA Guidance for UIC SWD Requirements Within the Joint Tactical Radio System
MAR 2007
NSA Position on the Use of Isolation Methods to Mitigate the Risk of non-UIC Compliant Software Within the JTRS Waveform Application
MAR 2009
NSA Position on Cyclomatic Complexity for JTRS Software Development Efforts
NOV 2008
JTRS NED IA Assessment Process
Version 1.0 MAY 2010
Software Defined Radio (SDR) Implementer’s Guide for Security
Version 1.2, 10 JUN 2015
Security Categorization and Control Selection for National Security Systems
CNSSI No. 1253 Version 2, 15 March 2012
Risk Management Framework (RMF) for DoD Information Technology (IT)
DoDI 8510.01, 12 March 2014
Guide for Applying the Risk Management Framework to Federal Information Systems
NIST SP 800-37 Rev 1, February 2010
Security and Privacy Controls for Federal Information Systems and Organizations
NIST S 800-53 Rev 4, April 2013

Order of Precedence In the event of conflict between the text of this PWS and the references cited herein, the text of this PWS takes precedence. Nothing in this PWS, however, supersedes applicable laws and regulations unless a specific exemption has been obtained. The Contractor shall notify the Contracting Officer's Representative (COR) of each instance of conflicting or apparently conflicting requirements.

General Requirements Overview Section 3.0 represents general requirements that will be used throughout the contract independent of order awards.

Development is the process of working out and extending the theoretical, practical, and useful applications of a basic design, idea, or scientific discovery. Development represents the design, building, modification, or improvement of the prototype of the product as determined by the basic idea or concept.

Enhancement is defined as a new requirement or additional capability that changes a product not within the current performance envelope.

Maintenance is defined as an action necessary to retain or restore an item to a specified condition. These can be corrective, event, preventative, scheduled or unscheduled.

Product Improvement is defined as a capability that improves a product within the current performance envelope.

Procurement is defined an action to acquire a complete capability without the need for any further development.

Reserved Overarching Contract Documents The Government anticipates ordering the Overarching Contract Documents, described below, to cover all orders over the life of the contract. Updates may be ordered as needed.

Management Plan – CDRL B002 The Contractor shall provide a Management Plan (CDRL B002) to ensure the work under this contract is managed effectively and efficiently. The Management Plan shall ensure effective management of cost, schedule, and performance. The Management Plan shall include adherence to the SwISS process as outlined in the PdM WF SwISS Plan. The Management Plan shall include an Organizational Conflicts of Interest (OCI) mitigation plan, if required, with respect to radio development, production, and sales. The Management Plan shall include the following:

The Management Plan shall clearly describe the following:

1) Management Structure Corporate Organization Resources Organization Conflict of Interest Mitigation Plan

2) Processes Requirements Management Configuration Management Risk Management Quality Assurance Subcontractor Management Security Plans Supply Chain Risk Reliability

3) Program Protection

4) Software Development Coding practices and standards Information Assurance Design Reviews Integration & Test Software Delivery Software Quality

5) Property Management Plan (IAW Appendix 2 – Property Management Plan) Work Breakdown Structure (WBS) – B023 The Contractor shall develop a Work Breakdown Structure (WBS) (CDRL B023) using MIL-STD 881C as a guide to a minimum level 3. The WBS is the infrastructure to summarize data for successive levels of management and provide appropriate information on projected and current status of the individual elements. For the purposes of developing a WBS the following level 1 structure shall be followed:

1.0 - WDE

2.0 - SRW

3.0 - WNW

4.0 - eOTAM

5.0 – SINCGARS

Supply Chain Risk Management (SCRM) – CDRL B024 The contractor shall deliver a Supply Chain Risk Management (SCRM) IAW B024, which addresses, at a minimum, Supply Chain Security Controls as specified in the order and described in CNSSI 1253 (companion publication to NIST SP 800-53). This contract and its associated orders are subject to the Federal SCRM policies and regulations including the Defense Federal Acquisition Regulation Supplement (DFARS) 252.239-7017 Notice of Supply Chain Risk, 252.239-7018 Supply Chain Risk, DOD Instruction 5200.44 Protection of Mission Critical Functions to Achieve Trusted Systems and Networks, Section 806 of the FY2011 NDAA Requirements for Information Relating to Supply Chain Risk, and internal SCRM Processes and Procedures.

Contract Funds Status Report (CFSR) – CDRL B001 The Contractor shall submit a quarterly CFSR (DD Form 1586) (CDRL B001). The CFSR reporting level shall provide funding requirements and time-phased detail at the CLIN level, broken out by delivery order, as well as the total program. The Contractor shall reconcile the reporting elements in the CFSR with the Work Breakdown Structure (WBS) elements in the CPR when the documents are submitted in the same month. The reconciliation shall be provided as an addendum to the CPR submittal. All time phased data shall be prepared such that it is grouped to provide visibility into the Government fiscal year. If the program is incrementally funded, it may be necessary for the Contractor to provide monthly increments at the beginning of the program or when Estimate at Completion (EAC) changes and/or contract modifications are implemented. The Contractor shall identify the elements of Termination Liability and Open Commitments in the notes section of the CFSR.

The Contractor shall deliver the final quarterly CFSR submission at the discretion of the COR.

Contract Status Report (CSR) – CDRL B003 The Contractor shall provide monthly CSRs (CDRL B003). The CSR shall include at a minimum:

Progress/status reporting against contract deliverables.

A running history of progress in meeting schedules, including a brief description of activities and accomplishments during each reporting period.

A Risk Matrix maintained by the Contractor that identifies design, schedule, technical, resources, and other program element risks. The Risk Matrix shall be updated with each monthly CSR.

The following software metrics at a minimum shall include: (1) Software Size e.g. Source Lines of Code (SLOC) to include at a minimum: New SLOC, Reused SLOC, Modified SLOC, and Total SLOC, (2) Organization Staffing, (3) Cost/Schedule Percent Complete, (4) Defects.

The Contractor shall use the CSR to propose updates and changes, and document slippages to the deliverables schedule. Government acceptance of the CSR does not indicate concurrence with the CSR content or proposed changes to schedule(s).

Processes The Contractor shall ensure that all software development, enhancements, maintenance and product improvements are to the current baseline version of the waveforms or network services and adhere to the applicable Tactical Radio APIs listed in section 2.0 (applicable versions as-specified or later), NSA Information Assurance Security Requirement Directive (IASRD), Risk Management Framework (RMF), JTRS NED Waveform Portability Guidelines, JTRS Software Standards, Software Communications Architecture (SCA) version 2.2.2 or later, System Performance Specification (SPS), and conformity to interoperability certification requirements .

The Contractor shall execute structured software engineering and program management processes that facilitate effective and high-quality software development equivalent to those articulated in IEEE Std 12207-2008, Systems and Software Engineering — Software Life Cycle, IEEE/EIA 12207.1-1997, Standard for Information Technology – Software life cycle processes – Life Cycle Data.

The Contractor shall use standard development procedures equivalent to those articulated by the Capability Maturity Model Integration for Systems Engineering and Software Engineering (CMMI SE/SW) maturity level 3 or higher.

The Contractor shall implement a rigorous Software Quality Assurance process to ensure a high level of Software Code Quality. The Joint Program Executive Office (JPEO) Joint Tactical Radio System (JTRS), "JTRS Software Standards," version 1.4.3, 18 January 2011 addresses the issue of software quality by providing guidance for good coding practices, software builds, documentation and other areas that affect overall product quality. The quality of software product directly affects the reusability the product.

The contractor shall ensure all development, enhanced and maintained software code is in compliance with the National Security Agency (NSA) Information Assurance Directorate (IAD), "Software Defined Radio (SDR) Implementer’s Guide for Security," version 1.2, 10 June 2015. The contractor shall, in addition, follow the Software Analysis and Assessment Process Description (SAAPD), version G dated 20 July 2016, which identifies the roles and responsibilities of all stakeholders involved in the development of software/firmware to be evaluated for certification or acceptance by the IAD.

To support portability, the Contractor shall deliver all software compliant with

i. SCA version 2.2.2 or later,

ii. JTNC Waveform Application Portability Guidelines, version 2.0, 12 November 2015, and

iii. Tactical Radio APIs listed in section 2.0 or later versions.

Data Deliverables The Government's rights in non-commercial technical data and software deliverables shall be governed by DFARS 252.227-7013 and DFARS 252.227-7014, respectively. The Government's rights in commercial technical data deliverables shall be governed by DFARS 252.227-7015. All non-commercial software deliverables shall be properly marked in accordance with the marking requirements set forth in DFARS 252.227-7014(f). Technical data and software deliverables with non-conforming restrictive markings shall be rejected and corrected by the Contractor at the Contractor's expense, in accordance with DFARS 252.227-7014(h)(2).

All data delivered and data made available during this contract shall be furnished electronically in accordance with DD Form 1423-1. Individual Orders will specify data deliverables. The list of CDRLS is subject to change according to the requirements of the Orders through the duration of the contract’s POP. Specific deliverables required and schedules will be stated in the Order PWS.

Classified data shall be handled and delivered in accordance with the Department of Defense (DoD) 5220.22-M “National Industrial Security Program – Operating Manual”, dated February 2006.

All data ordered in accordance with DD Form 1423-1 shall be submitted with a Letter of Transmittal (LT) or provide Government notification via an E-mail to the Government Contracting Officer. The LT shall indicate the contract number, Contract Line Item Number, Sub-Line Item Number, Data Item Number, Title and Subtitle (when applicable) of the data, PWS paragraph number reference which required the data to be prepared, and the date of transmittal.

The DD Form 250s Material Receipt and Acceptance shall be submitted with final data deliveries only as specified on the individual data item.

The Contractor shall provide a matrix, which states the delivery method for each CDRL deliverable (e.g. Compact Disk – Read Only Memory, Webpage).

Delivery Method of each CDRL will be defined in Block 16 of the DD Form 1423-1.

Security The Contractor shall follow the requirements of Appendix 1-Security of this PWS.

Program Protection The Contractor shall use Government-provided foreign intelligence and technology exploitation threat information, along with the traditional acquisition and battlefield threat information, to inform system security engineering (SSE), systems engineering, and procurement decision processes.

The Contractor shall plan for and implement countermeasures that mitigate the risk of foreign intelligence or foreign influence, technology exploitation, supply chain and battlefield threats, and vulnerabilities that result in Level I and Level II protection failures of the system; countermeasures include the following:

The application of supply chain risk management best practices, applied as appropriate to the development of the system. Supply chain risk management key practices may be found in the National Institute of Standards and Technology (NIST) Interagency Report 7622, Notional Supply Chain Risk Management for Federal Information Systems (http://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7622.pdf), and the National Defense Industrial Association (2008) guidebook, Engineering for System Assurance, both publicly available (http://www.acq.osd.mil/se/docs/SA-Guidebook-v1-Oct2008.pdf ).

The enumeration of potential suppliers of critical components, as they are identified, including cost, schedule, and performance information and proposed selection decisions for the purposes of obtaining approval from the Government and engaging in the development of mutually agreeable risk management plans for the selected suppliers of critical components.

The processes to control access by foreign nationals to program information, including, but not limited to, system design information, DoD-unique technology, and software or hardware used to integrate commercial technology.

The processes and practices employed to ensure that genuine (i.e., not counterfeit) information and communications technology (ICT) are employed in the solution and that processes and requirements for genuine ICT are levied upon sub-Contractors. ICT includes all categories of ubiquitous technology used for gathering, storing, transmitting, retrieving, or processing information (e.g., microelectronics, printed circuit boards, computing systems, software, signal processors, mobile telephony, satellite communications, and networks). ICT is not limited to information technology (IT), as defined in section 11101 of title 40, U.S. Code. Rather, this term reflects the convergence of IT and communications.

The processes used to protect both unclassified and classified DoD information, technical data (e.g., source code), and computer software in the development and support environments (e.g., Government- or Contractor-owned facilities and the integrated development environment) from entities without a need to know.

The Contractor shall protect unclassified DoD data from unauthorized access or disclosure in accordance with DoDI 8582.01, “Security of Unclassified Information on Non- DoD Information Systems,” (http://www.dtic.mil/whs/directives/corres/pdf/858201p.pdf) and the product’s Security Classification Guide.

The contractor shall implement the security requirements defined in NIST SP 800-171 per DFARS Clause 48 CFR Part 252.204.7012, Safeguarding Covered Defense Information and Cyber Incident Reporting.

For critical components of Level I Mission-Critical Functions, the PPP shall establish basic protection requirements unless justified by a cost-benefit analysis approved by the Government. Those basic protections shall include:

Establish least privilege using distrustful decomposition (privilege reduction) or a similar approach to move Level I critical functions into separate mutually untrusting programs.

Physical and logical diversification of critical components for Mission-Critical Functions which require redundancy to meet reliability or safety requirements.

Physical and logical diversification with voting to establish trustworthiness of selected Level I Mission-Critical Function components.

Wrappers for COTS, legacy, and developmental software to enforce strong typing, context checking, and other interface validation methods for interfaces with Mission-Critical Functions; see SEI-2009-TR-010 (Dougherty et al. 2009).

Wrappers for COTS, legacy, and developmental software to identify and log invalid interface data using secure logging approaches; see SEI-2009-TR-010, Secure Design Patterns, Software Engineering Institute, Carnegie Mellon University/Department of Defense (http://www.cert.org/).

Period of Performance The contract will include a five year period of performance (POP) plus five year optional ordering period. The Government anticipates issuing separate orders for product development, enhancement, maintenance, product improvements, or procurement as required. The period of performance for those orders will vary depending on the nature and size of the work to be performed and will be specified in the associated order.

Place of Performance The primary place of performance shall be the Contractor’s site. The Contractor also shall perform work at Government sites when necessary and/or directed by the Government. Contractor work at Government sites may include, but shall not be limited to short-term overnight trips as well as temporary or extended performance of work necessary to fulfill base contract or individual order requirements. Contractor travel and other direct costs (ODCs) may be incurred depending on program needs. The Contractor shall propose travel and ODCs separately per order.

The Contractor shall be required to work with other Program of Record Product Offices, SwISS Contractors, Government Laboratories, Government Agencies, Government Organizations, Federally Funded Research and Development Centers and other Contractors to include but not limited to:

Project Manager Tactical Radios in Aberdeen, MD Project Manager WIN-T in Aberdeen, MD CERDEC in Aberdeen, MD National Security Agency (NSA) in Linthicum, MD Major Range and Test Facility Base in accordance with DoDD 3200.11 SPAWAR System Center Atlantic (SSC-LANT) in Charleston, SC SPAWAR System Center Pacific (SSC-PAC) in San Diego, CA Joint Interoperability Test Command in Fort Huachuca, AZ Host Commands located at the following installations: Fort Dix, Fort Benning, Fort Bliss, White Sands Missile Range, and Fort Huachuca Joint Tactical Networking Center in San Diego, CA

Waveform Development Environment (WDE) Ecosystem Overview The WDE Ecosystem is the set of products used to support the entire lifecycle of the WF and NS software products. The goals of the WDE Ecosystem are to;

(i) Promote rapid and cost effective development, enhancement, maintenance, and product improvement of WF and NS software products by the DoD Software Defined Radio (SDR) Vendors and Government,

(ii) Provide a common radio platform for DoD SDR Vendors and Government to conduct performance, verification, and interoperability test and evaluations, and

(iii) Reduce time and costs for porting and integration of new or modified WF and NS software to DoD Vendor’s and Government’s Product Line SDRs.

The Government desires a single WDE Ecosystem common to all WF and NS software products (priority given to SRW, WNW, eOTAM, and SINCGARS). The intent of the WDE Ecosystem is that it be Contractor agnostic, open architecture, affordable, and available to DoD SDR Vendors and Government. The WDE Ecosystem should allow DoD SDR Vendors and Government the ability to quickly compile and execute WF and NS software pulled from the DoD Information Repository (DoD IR).

WDE Ecosystem Task Development Task The Contractor shall develop a WDE Ecosystem as specified in the order PWS.

Enhancement Task The Contractor shall enhance a WDE Ecosystem as specified in the order PWS.

Maintenance Task The Contractor shall provide maintenance on a WDE Ecosystem as specified in the order PWS.

Product Improvement Task The Contractor shall provide product improvement to a WDE Ecosystem as specified in the order PWS.

Procurement Task The Contractor shall provide a WDE Ecosystem as specified in the order PWS.

WDE Ecosystem Waveform and Network Service Requirements Primary Waveform and Network Service Requirements The WDE Ecosystem shall support Soldier Radio Waveform (SRW).

The WDE Ecosystem shall support Wideband Networking Waveform (WNW).

The WDE Ecosystem shall support enterprise Over The Air Management (eOTAM).

The WDE Ecosystem shall support Single Channel Ground and Airborne Radio Systems (SINCGARS).

Secondary Waveform and Network Service Requirements The WDE Ecosystem shall support Narrowband Waveform.

The WDE Ecosystem shall support V/UHF LOS.

The WDE Ecosystem shall support UHF SATCOM.

The WDE Ecosystem shall support MUOS.

The WDE Ecosystem shall support Network Services.

The WDE Ecosystem shall support SATURN.

Reserved The WDE Ecosystem shall support Service (IBS).

The WDE Ecosystem shall support Bowman.

The WDE Ecosystem shall support Have Quick II.

The WDE Ecosystem shall support Link-16.

The WDE Ecosystem shall support Soft INC.

The WDE Ecosystem shall support Tactical Data Controller (TDC).

The WDE Ecosystem shall support Air Traffic Control (ATC).

The WDE Ecosystem shall support 25 (APCO 25).

The WDE Ecosystem shall support SCM.

The WDE Ecosystem shall support High Frequency (HF).

The WDE Ecosystem shall support Link 22.

Future Waveform and Network Service Requirements The WDE Ecosystem shall support future waveform or network service software products.

WDE Ecosystem Subcomponents Waveform Test Equipment (WTE) The Contractor shall provide WTE that executes WF and NS software in real-time to allow for radio frequency test and evaluation in a Laboratory environment by other Contractors and Government. The WTE shall support the test & evaluation, of WFs and NSs software products’ functionality and performance. The WTE may be utilized in over-the-air test and evaluation within CONUS-based DoD test ranges when the appropriate frequency and Information Assurance certifications have been obtained. In addition, the WTE shall provide ability to interface and operate with JENM.

WDE Ecosystem WTE Operating Environment – CDRLs A017,A018, A019. and F001 The Contractor shall deliver the WDE Ecosystem WTE Operating Environment source code and build files as required, IAW CDRL A017, A018, A019 and F001 to support other Contractors and Government software maintenance, sustainment, training, and operations.

Software Support Tools The Contractor shall deliver software support tools to assist other Contractors and Government with the debugging of algorithms or interactions between algorithms within the WF and NS software operating in real-time on the WTE. The Contractor shall deliver the software support tools necessary for other Contractors and Government to make modifications to the Cryptographic Subsystem (CSS) and Cryptographic Engine (CE) to accommodate future Cryptographic Modification Initiatives (CMI) and algorithmic updates. The software support tools shall allow other Contractors and Government to modify, add, or delete the bypass policies within the CSS/CE.

Examples of other Software Support Tools include the following:

· A logviewer for monitoring the aggregate log output of the radio

· File loader for deploying files to the radio

· Network debug tool for monitoring traffic between various WF and NS components Software-based Radio Emulator The Contractor shall provide a Software-Based Radio Emulator that supports the operation of WF and NS software in a single PC environment for use by other Contractors and Government. The Software-based Radio Emulator shall provide an Integrated Development Environment to assist the software developer including the ability to input/output data files, evaluate proper execution of source code, set debug break points, and ability to print and plot to help evaluate functionality, performance, and debug.

WDE Ecosystem Software-based Radio Emulator Operating Environment – CDRL A017,A018, A019, and F001 The Contractor shall deliver the WDE Ecosystem Software-based Radio Emulator Operating Environment source code and build files as required, IAW CDRL A017, A018, A019 and F001, to support other Contractors and Government software maintenance, sustainment, training, and operations.

Waveforms and Network Services Overview A key tenet to the PEO C3T PM TR Tactical SDR Business Model is to provide WF and NS software, in accordance with system requirements for portability, IA, SCA, configurability, interoperability, reusability, and maintainability, to DOD Tactical SDR Industry to enable a competitive marketplace at the tactical SDR level with equivalent over-the-air capabilities that are interoperable. To help meet this key tenet, the SwISS contract is structured to assist PdM WF with the development, enhancement, maintenance, product improvement, and procurement of DOD required WF and NS software products. These software products must be designed to meet reuse, portability, security, performance and interoperability requirements. In addition, the software products and associated porting knowledge must be made accessible to approved DOD Tactical SDR Vendors.

Waveform and Network Service Software Products Primary Waveform and Network Service Software Products The Contractor shall provide SwISS support for Soldier Radio Waveform (SRW).

The Contractor shall provide SwISS support for Wideband Networking Waveform (WNW).

The Contractor shall provide SwISS support for enterprise Over The Air Management (eOTAM).

The Contractor shall provide SwISS support for Single Channel Ground and Air Radio System (SINCGARS).

Secondary Waveform and Network Service Software Products Industry will be notified formally of the Governments intent to add secondary waveforms or network services should they become a requirement. These actions may result in an on-ramping activity.

The Contractor shall provide SwISS support for Narrowband Waveform.

The Contractor shall provide SwISS support for V/UHF LOS.

The Contractor shall provide SwISS support for UHF SATCOM.

The Contractor shall provide SwISS support for MUOS.

The Contractor shall provide SwISS support for Network Services.

The Contractor shall provide SwISS support for SATURN.

The Contractor shall provide SwISS support for JENM.

The Contractor shall provide SwISS support for Integrated Broadcast Service (IBS).

The Contractor shall provide SwISS support for Bowman.

The Contractor shall provide SwISS support for Have Quick II.

The Contractor shall provide SwISS support for Link-16.

The Contractor shall provide SwISS support for Soft INC.

The Contractor shall provide SwISS support for Tactical Data Controller (TDC).

The Contractor shall provide SwISS support for Air Traffic Control (ATC).

The Contractor shall provide SwISS support for Project 25 (APCO 25).

The Contractor shall provide SwISS support for SCM.

The Contractor shall provide SwISS support for High Frequency (HF).

The Contractor shall provide SwISS support for Link 22.

Future Waveform and Network Service Software Product The Contractor shall provide SwISS support for future waveform or network service software products.

SwISS Waveform and Network Service Task Development Task The Contractor shall develop a waveform or network service as specified in the order PWS.

Enhancement Task The Contractor shall enhance a waveform or network service as specified in the order PWS.

Maintenance Task The Contractor shall provide maintenance on a waveform or network service as specified in the order PWS.

Product Improvement Task The Contractor shall provide product improvement on a waveform or network service as specified in the order PWS.

Procurement Task The Contractor shall provide a waveform or network service as specified in the order PWS.

Waveform and Network Service WDE Ecosystem Utilization The Contractor shall utilize the Waveform Development Environment (WDE) Ecosystem or Government approved alternative to execute the WF and NS software product tasking described in each Order.

Waveforms and Network Services Summary

SRW

SRW is an IP-based, wideband, Mobile Ad-Hoc Network (MANET) waveform providing simultaneous voice, video, and data communications for mounted/dismounted operations down to the squad level soldier. SRW supports dynamic and autonomous network formation, partition, and healing, and was designed for Size, Weight, and Power (SWaP) constraint platforms. SRW supports unicast, multicast, and broadcast transmissions, and can operate with or without GPS.

WNW

WNW is a self-forming, self-healing, wireless network that allows the Joint Services to communicate securely with each other in the tactical battlefield. Key capabilities include; adaptive data rates and range of bandwidths, communications for on the move Brigade-sized networks, dynamic and autonomous network formation, partition, and healing over multiple hops, High Assurance (HAIPE-based) Type 1 encryption, Transmission Security (TRANSEC), unicast, multicast, and broadcast traffic, operates with or without GPS.

SINCGARS

SINCGARS provides secure VHF communications that has both voice and data handling capability in support of command and control operations. SINCGARS implements the MIL-STD-188-241, MIL-STD-188-242, MIL-STD-188-220 specifications. SINCGARS is undergoing modernization efforts to include Cryptography.

eOTAM eOTAM is an Over The Air (OTA) Server Service (OSS), a portable OE-centric SCA component that provides an enterprise wide OTAM solution. The services are platform and networking waveform agnostic (SRW, WNW, or any IP capable network). eOTAM provides remote Unit Task Reorganization and radio management capabilities. It is based on commercial standards JSON (Java Script Object Notation) and NORM (NACK Oriented Reliable Multicast).

Narrowband Waveform NBWF provides encrypted relayed push-to-talk digital voice and critical JVMF messages operating within 25 kHz bandwidth across the VHF, UHF, and L frequency bands (30-2000 MHz). Additional data capabilities are supported with greater bandwidths. The table below summarizes the NBWF potential features:

V/UHF LOS

V/UHF LOS provides interoperable push-to-talk analog voice, digital voice, and serial data within 25 kHz bandwidth across the VHF, UHF, and L frequency bands (30-2000 MHz). Both un-encrypted (Plain Text) and encrypted (Cypher Text) modes are supported. Encrypted modes include interoperability with both currently fielded radios and modern Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS). Additional modes of operation include 12.5 kHz and 8.33 kHz bandwidths.

UHF SATCOM

UHF SATCOM provides interoperable push-to-talk analog voice, digital voice, and serial data within 5 kHz and 25 kHz bandwidths using UHF SATCOM. Both un-encrypted (Plain Text) and encrypted (Cypher Text) modes are supported. Encrypted modes include interoperability with both currently fielded radios and modern Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS). Features include the Integrated Waveform (IW) capabilities.

MUOS

Mobile User Objective System (MUOS) provides encrypted push-to-talk voice and IP data to tactical users over the MUOS Satellite system. Program Executive Office Space Systems (PEO SS) Satellite Communications Program Office (PMW 146) is responsible for development, enhancement, and maintenance of the MUOS waveform. The requirements in this PWS are for any proposed waveform enhancements or maintenance, radio porting/integration assistance, product improvements, and fielding support. All proposed waveform modifications will go through PMW 146 to ensure interoperability and strict configuration control on fielded MUOS capabilities.

For Mobile User Objective System (MUOS) interoperability, PdM WF coordinates with the Navy's MUOS program office on SDR network and terminal testing/certification. PdM WF is investigating the optimum strategy to synchronize the fielding of enhanced or new tactical waveforms across all of the PM TR portfolio of SDRs.

Network Services Network Services are common software components integrated into the radio operating environment that provide services to/from the waveform applications and the radio hardware or radio operating environment. The Table below provides a list of the radio software devices and services that currently have standardized interfaces to installed waveform(s) or application(s) for Department of Army Tactical Radios:

SATURN

SATURN provides interoperable advanced anti-jam push-to-talk voice and data communications for aircraft in the UHF band. NATO STANAG 4372 defines the SATURN waveform standard. Future modernization enhancements include possibly using TSVCIS.

JENM

The Joint Enterprise Network Manager (JENM) is the tactical edge network manager that plans, manages, monitors and controls a family of Joint tactical waveforms and services on compatible joint services radios. It is a software solution deployed on a computing environment such as a laptop PC, Common Operating Environment (COE), or virtual machine.

Integrated Broadcast Service (IBS) IBS provides secure two way satellite communications (SATCOM) for critical, near real-time multi-source threat, survivor, and Blue Force Tracker data. It enables world-wide situational awareness capability by connecting tactical users and intelligence nodes. IBS currently consists of three legacies UHF broadcasts (TIBS, TDDS, and TRIXS) which will be replaced in the future with a Common Interactive Broadcast (CIB). The CIB will be a DAMA compliant broadcast using a developing Integrated Waveform, MIL-STD-188-181C/-182B/-183B. Data carried over IBS will be an IBS Common Message Format (CMF), which will be a member of the J-Series family of message formats.

Bowman BOWMAN is the designator for the UK Tri-Service Tactical communications System. Includes BOWMAN-HF, BOWMAN-VHF, and BOWMAN-UHF.

Have Quick II MIL-STD-188-220 & -243 and JIEO-9120A compliant. Includes guard (non-hop 243.0 & 282.8 MHz et al). Data 75, 150, 300, 600 Bps; 1.2, 2.4, 4.8, 9.6, 16 Kbps with required IDM.

Link-16 MIL-STD-6016 & STANAG 5516 compliant. Data with FEC 28.8, 57.6, 115.2, 119.0, 238.1 Kbps, up to 1.137 Mbps [FDMA /TDMA /CDMA ECCM-AJ TADIL, with emerging IP bearer services.

For Link-16 interoperability, PdM WF coordinates with the Navy's MIDS-J program office on SDR network and terminal testing/certification. PdM WF is investigating the optimum strategy to synchronize the fielding of enhanced or new tactical waveforms across all of the PM TR portfolio of SDRs.

Soft INC Soft INC implements the SINCGARS and EPLRS…

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated .