MODIFICATION
A -- Cyber Asymmetric Force Applications for Unmanned Aircraft Systems
- Notice Date
- 1/26/2017
- Notice Type
- Modification/Amendment
- NAICS
- 541712
— Research and Development in the Physical, Engineering, and Life Sciences (except Biotechnology)
- Contracting Office
- Department of the Air Force, Air Force Materiel Command, AFRL/RIK - Rome, 26 Electronic Parkway, Rome, New York, 13441-4514, United States
- ZIP Code
- 13441-4514
- Solicitation Number
- FA8750-17-S-7001
- Point of Contact
- Gail E. Marsh, Phone: 315-330-7518
- E-Mail Address
-
Gail.Marsh@us.af.mil
(Gail.Marsh@us.af.mil)
- Small Business Set-Aside
- N/A
- Description
- AMENDMENT 1 for BAA FA8750-17-S-7001 The purpose of this Amendment to BAA FA8750-17-S-7001 is to make the following changes: 1) SECTION I, "Funding Opportunity Description": Added a Focus Area - Cyber Asymmetric Force Applications for Unmanned Aircraft Systems (C-sUAS) Command and Control (C2) Framework; 2) SECTION III, "Eligibility": Updated to include access restrictions for foreign nationals; 3) SECTION IV, "Application and Submission Information": a) SUBMISSION DATES AND TIMES (IV.1): Revised to include a specific FY17 submission date for the C-sUAS C2 focus area; b) HANDLING AND MAILING INSTRUCTIONS, CLASSIFICATION GUIDANCE (IV.3.a): Revised to include an additional change to the NATIONAL INDUSTRIAL SECURITY PROGRAM OPERATING MANUAL, (NISPOM); and 4) SECTION VII, "Agency Contacts": Revised to add the new Ombudsman. No other changes have been made. SUMMARY OF CHANGES: 1) SECTION I, Add a Focus Area entitled: Cyber Asymmetric Force Applications for Unmanned Aircraft Systems (C-sUAS) Command and Control (C2) Framework directly under the fourth paragraph in this section; FOCUS AREA - Cyber Asymmetric Force Applications for Unmanned Aircraft Systems (C-sUAS) Command and Control (C2) Framework Background: The government is looking for an open architecture solution that enables command and control (C2) of Counter-small Unmanned Aircraft Systems (C-sUAS) segments. This "C2 Framework" includes several aspects as outlined below. It is expected to leverage existing government off-the-shelf (GOTS) C-sUAS tactical C2 code. The C2 Framework is to include the appropriate middleware and interfaces to enable the open architecture. Segments/subsystems may include detection, identification, tracking, or defeat capabilities. A typical C-sUAS deployment likely includes a mixture of disparate segments from various vendors to meet the mission needs and budget of each site. These may be a mixture of commercial off-the-shelf (COTS) products or custom built under government contract. Given this composition, interoperability and integration are a prime concern. The goal is to define a government-owned interface specification (i.e., a set of interface control documents [ICD]) and an interoperability certification process. This is similar to the approach taken by the UAS Control Segment (UCS) Architecture for control of large, blue-force drones. Discussion : Small UAS threats typically involve dynamic targeting which brings effects to bear via the kill chain. C-sUAS targeting effects involve the 5D's (disrupt, deny, degrade, destroy, or deceive) on any component of the threat sUAS or its control. Effects could go after threat payloads as well (e.g., blind the camera). The C-sUAS system needs to operate in multiple modes: both human-in-the-loop (HITL) and human-on-the-loop (HOTL). In HITL mode the operator must initiate defeat options based on system recommendations. In HOTL mode, the system will automatically execute authorized 5D effects unless overridden by the operator. The latter mode is necessary due to the very tight dynamic targeting kill chain timeline associated with various sUAS threat scenarios. (It is assumed that policy will allow some HOTL parameters in the future.) The government intends to integrate best-of-breed C-sUAS segments from multiple vendors, thus emphasizing the need for interoperability. Vendors need the flexibility to design C-sUAS segments implementing various compute architectures and operating systems with applications written in their software language of choice. Items needed to ensure cross-platform interoperability include: (1) A common or translatable data model; (2) Shared data semantic understanding; (3) Platform-independent mechanism for data exchange; (4) Connectivity between segments; (5) Agreed communications protocols, integration pattern, and message exchange pattern(s); (6) A wire format and data serialization amenable to all parties; and (7) Shared cybersecurity mechanisms such as authentication. The C2 Framework intends to accomplish this via a C2 command set or message set (with associated schema/data model) in some industry standard format and serialization (e.g., eXtensible Markup Language [XML], Protocol Buffers, or JavaScript Object Notation [JSON]). The goal is to balance specificity and flexibility to achieve the necessary interoperability. Some C-sUAS segments may adhere to the ICD; it is assumed that some will not for various reasons (e.g., legacy system). Vendor funding, roadmaps, or motivations may delay or preclude ICD alignment. The C2 Framework must enable the ability to interface with legacy segments (e.g., radar, EW) via adapters, services, or similar technology that can perform the necessary data model and data format transformation or protocol bridging. Information exchange requirements (IER) include real-time data exchanges, possibly in a publish/subscribe or event-based design pattern (To be Determined [TBD]), needed to prosecute the dynamic targeting kill chain necessary to defeat sUAS, which possibly involves a swarm. These segments communicate over a network likely involving a mixture of wired and wireless links via agreed to protocols. The local network must provide basic services such as time synchronization to attached segments. The segments communicate with the C2 Node to enable C2, health/status, etc. Use of "C2 node," "C2 segment," or "C2 logic" does not necessitate hub and spoke architecture. These terms are used interchangeably. Additionally, the C2 logic may be distributed. Use of the term, "C2 Framework," refers to the entire construct that enables C2. Segments require different levels of integration. For example, a radar detection segment may get by with publishing bogey/contact tracks to the correlation engine and not understand-or even receive-all the C2 messages defined in the ICD. An adapter may translate these tracks (e.g., geodetic datum transformation) to conform with the ICD so that the rest of the system understands the data. A hunter-killer (HK)-blue-force interceptor drone-on the other hand, needs a much closer level of integration. The HK must understand C2 messages such as a launch command to counter the threat sUAS. Other HK-related commands may be warm-up/initialize, intercept waypoints, and employ defeat mechanism. The HK should send C2 acknowledgements and status information (e.g., available time on station, successful arrest) back via the C2 Framework to the C2 Node. Existing message sets may be leveraged such as Micro Air Vehicle Link (MAVLink). The C2 Node will present information to the human operator via a User Interface (UI). The UI may involve a mobile device, workstation, or display integrated into a command center or vehicle. Flexibility is the key. UI likely consists of a display as well as audible and possibly tactile feedback. The C2 Framework comprises automated C2 logic and a rules engine or expert system that can escalate the dynamic kill chain IAW the Rules of Engagement (ROE) as the threat increases. This C2 logic (1) presents recommendations and options to the operator via the UI and (2) controls segments IAW the HITL/HOTL mode for that particular effect. (C2 logic will be expounded in a future BAA focus area/addendum.) The C2 Framework will leverage COTS Application Programming Interfaces (API) where appropriate. For example, a HK may be based on a COTS sUAS carrying a C2 payload mounted on a gimbal that leverages the COTS API or MAVLink for sUAS flight control. The C2 Framework will leverage existing standards as appropriate such as Eurocontrol's All Purpose Structured Eurocontrol Surveillance Information Exchange (ASTERIX) standard ( https://www.eurocontrol.int/asterix-specifications-library ) for radar tracks. Other standards include but are not limited to Cursor on Target (CoT), U.S. Message Text Format (USMTF), and Variable Message Format (VMF). Several of these are employed by the GOTS C-sUAS tactical C2 code. One segment of a C-sUAS is expected to comprise a Library. It is envisioned that Library contents include various COTS sUAS characteristics, signals of interest (SOI), and targeting effects (i.e., EW and cyber). Thus the C2 Framework message set must support requests/queries to the Library. For example, a cyber/EW segment may request/query what effects are available in the Library for a particular sUAS. To ensure proper cybersecurity and resiliency, the C2 Framework will include appropriate controls. Authentication, authorization, and accounting mechanisms need to be established to ensure confidentiality, integrity, and availability of the various services and data exchanges between segments. Appropriate trade studies (with various levels of formality) should be performed to ensure the framework can meet the expectations placed upon it (e.g., latency, security, and performance). These expectations are based on the myriad employment scenarios in which a C-sUAS system may be engaged and the expected concept of operations (CONOPS). Scenarios include austere environments where a robust implementation is needed to account for networks with low bandwidth, high latency, and intermittent connectivity. Other information exchange aspects include selecting the appropriate technologies for the following areas: Integration patterns, message exchange patterns (aka service interaction patterns), wire format (aka wire protocol), middleware and messaging alternatives, and data serialization (aka data interchange format). It is possible that the C2 Framework incorporates multiple options to facilitate interoperability. The C2 Framework should facilitate interfaces with external Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) systems or integration with another C2 system (e.g., a base integrated defense system). The C-sUAS C2 Node needs to: (1) Receive threat intelligence, (2) Receive C2 (including ROE), and (3) Send situational awareness (SA) and status data and reports to external C4ISR systems. Particular external C4ISR systems are TBD. Communication with external systems likely involves messaging standards such as USMTF, VMF, CoT, or others. Based on existing capabilities and planned improvements of the GOTS C-sUAS tactical C2 code, the forward-looking BAA focus area with be on the following aspects: (1) Integration of advanced C2 logic/autonomy; (2) Addition of HK C2 leveraging COTS sUAS APIs and standards; (3) Cybersecurity hardening; (4) Evaluation of adapter/translator architecture that alleviates latency and complexity; (5) Integration with higher-level C2 systems and external C4ISR systems; and (6) Open architecture messaging as well as queueing and transformation services/middleware to evaluate messaging requirements such as guaranteed delivery, durability, etc. C2 Framework Tenets: (1) Open Systems Architecture (OSA) (formerly known as Modular Open Systems Approach [MOSA]) based on industry standards and technologies (2) Cross-platform interoperability and platform-independence (i.e., independent of Central Processing Unit [CPU] instruction set and operating system [OS]) that allows implementation on different computing infrastructures with possibly differing communication protocols (3) Unlimited Rights (UR) for both computer software and associated technical data to facilitate 3rd party integration and maintainability (4) Extensible to support technology insertion and adoption (5) Facilitate legacy systems via adapters/translators (6) Cybersecurity and resilience baked-in rather than bolted-on (7) Applies applicable Global Information Grid (GIG) Technical Guidance Federation (GTG-F) Standards (formerly DoD Information Technology Standards Registry [DISR]) (8) Cross-agency governance 2) SECTION III, "Eligibility" is deleted in its entity and replaced with the following: III. ELIGIBILITY INFORMATION: 1. ELIGIBILITY: All qualified offerors who meet the requirements of this BAA may apply. 2. FOREIGN PARTICIPATION/ACCESS: a. This BAA is closed to foreign participation at the Prime Contractor level. b. Foreign Ownership, Control or Influence (FOCI) companies who have mitigated FOCI may inquire as to eligibility by contacting the contracting office focal point, Gail E. Marsh, Contracting Officer, telephone (315) 330-7518 or e-mail Gail.Marsh@us.af.mil for verification prior to submitting a white paper. Please reference BAA FA8750-17-S-7001. c. Contractor employees requiring access to USAF bases, AFRL facilities, and/or access to U.S. Government Information Technology (IT) networks in connection with the work on contracts, assistance instruments or other transactions awarded under this BAA must be U.S. citizens. For the purpose of base and network access, possession of a permanent resident card ("Green Card") does not equate to U.S. citizenship. This requirement does not apply to foreign nationals approved by the U.S. Department of Defense or U.S. State Department under international personnel exchange agreements with foreign governments. Any waivers to this requirement must be granted in writing by the Contracting Officer prior to providing access. The above requirements are in addition to any other contract requirements related to obtaining a Common Access Card (CAC). If an IT network/system does not require AFRL to endorse a contractor's application to said network/system in order to gain access, the organization operating the IT network/system is responsible for controlling access to its system. If an IT network/system requires a U.S. Government sponsor to endorse the application in order for access to the IT network/system, AFRL will only endorse the following types of applications, consistent with the requirements above: 1. Contractor employees who are U.S. citizens performing work under contracts, assistance instruments or other transactions awarded under this BAA. 2. Contractor employees who are non-U.S. citizens and who have been granted a waiver. Any additional access restrictions established by the IT network/system owner apply. 3) SECTION IV, "Application and Submission Information", SUBMISSION DATES AND TIMES (IV.1) is deleted in its entity and replaced with the following: IV. APPLICATION AND SUBMISSION INFORMATION: 1. SUBMISSION DATES AND TIMES: It is recommended that white papers be received by 2 PM Eastern Standard Time (EST) on the following dates to maximize the possibility of award: FY17 by 31 Jan 2017 NOTE - The Submission Date for the Cyber Asymmetric Force Applications for Unmanned Aircraft Systems (C-sUAS) Command and Control (C2) Framework Focus Area is 31 Mar 2017 FY18 by 31 Jan 2018 FY19 by 31 Jan 2019 FY20 by 31 Jan 2020 FY21 by 29 Jan 2021 White papers will be accepted until 2 PM EST on 30 Sep 2021, but it is less likely that funding will be available in each respective fiscal year after the dates cited. This BAA will close on 30 Sep 2021. All offerors submitting white papers will be contacted by the TPOC, referenced in Section VII of this announcement. Offerors can email the TPOC for status of their white paper/proposal no earlier than 45 days after submission. 4) SECTION IV, "Application and Submission Information", HANDLING AND MAILING INSTRUCTIONS, CLASSIFICATION GUIDANCE (IV.3.a) is deleted in its entity and replaced with the following: 3. HANDLING AND MAILING INSTRUCTIONS: a. CLASSIFICATION GUIDANCE. All Proposers should review the NATIONAL INDUSTRIAL SECURITY PROGRAM OPERATING MANUAL, (NISPOM), dated February 28, 2006 and incorporating Change 1, dated March 28, 2013, and Change 2, dated May 18, 2016, as it provides baseline standards for the protection of classified information and prescribes the requirements concerning Contractor Developed Information under paragraph 4-105. Defense Security Service (DSS) Site for the NISPOM is: http://www.dss.mil/. 5) SECTION VII, "Agency Contacts" is revised to add the new Ombudsman's contact information: Ms. Kimberly Yoder AFRL/PK 1864 4th Street Building 15, Room 225 Wright-Patterson AFB OH 45433-7130 FAX: (937) 656-7321; Comm: (937) 255-4967 Email: kimberly.yoder@us.af.mil
- Web Link
-
FBO.gov Permalink
(https://www.fbo.gov/spg/USAF/AFMC/AFRLRRS/FA8750-17-S-7001/listing.html)
- Record
- SN04382623-W 20170128/170126234540-0c4e41161547c0c80e38df3c4e627721 (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |