BAA-AFRL-RQKS-2015-0009-Atch1.pdf

BAA-AFRL-RQKS-2015-0009

Attachment 1

MISSION SYSTEMS OPEN ARCHITECTURE SCIENCE AND TECHNOLOGY (MOAST)

IDIQ STATEMENT OF OBJECTIVES (SOO)

25 January 2016

1.0 BACKGROUND

The Avionics Vulnerability Mitigation branch (AFRL/RYWA) in the Air Force Research Laboratory, Sensors

Directorate, is conducting research to promote the use of Open Systems Architecture (OSA) approaches for the design and development of mission-critical avionics systems. These systems include but are not limited to

Radar; Electronic Warfare; and Intelligence, Surveillance, and Reconnaissance (ISR). The challenge facing many

DoD programs is to reduce life-cycle costs while rapidly fielding technologically superior warfighting capability.

Design strategies based on widely supported open standards increases the likelihood that future changes to the system will be accomplished in a cost-effective manner. Characteristics of an open system architecture include modular design of software; decoupling of software from hardware; non-proprietary interface definition; use of a well-defined data model to describe data exchanges within the system; and use of commercial-off-the-shelf

(COTS) components. A plethora of open system architecture standards exists today, including the Air Force

Open Mission Systems (OMS) and Unmanned Aerial Command and Control Standards Initiative (UCI). OMS is an industry-led initiative by the Air Force to develop and demonstrate a consensus-based, non-proprietary, open architecture for integrating subsystems and services into airborne platforms. The Unmanned Aerospace

Systems C2 Standards Initiative (UCI) mission is to establish a common message set for mission-level command and control of unmanned aerospace systems. The OMS and UCI standards have been adopted by multiple AF platforms, and several others are considering adoption. However, more research related to OSA standards is needed to: 1) Accommodate a vast array of subsystems and mission scenarios of existing and future weapon systems; 2) Allow adopting programs to take advantage of technological advances throughout the system life-cycle more affordably than with traditional, proprietary system architectures; 3) Support methods to protect avionics systems against cyber attack or compromise of Critical Program Information (CPI); and 4) Be synergistic with other OSA approaches to the maximum extent possible.

2.0 OBJECTIVE

The objective of this effort is to conduct applied, advanced technology development, and advanced component development and prototypes research to evolve and expand emerging open system architecture standards and approaches for existing and next-generation Air Force and DoD weapon systems. This effort will develop and demonstrate methods, tools, and technologies to enhance OSA standards and produce mature, robust solutions to affordable capability evolution, sustained competition across the system life-cycle, and resilience to cyber attack.

3.0 TECHNICAL AREAS

3.1 Evolution of Open System Architectures Standards

The objective of this task area is to evolve OMS and UCI standards to address platform technical challenges for current adopting programs. This task area seeks to broaden the applicability of OSA standards to accommodate a variety of aircraft types and missions plus a diverse set of mission systems and capabilities as well as to accommodate the implementation of current and anticipated security approaches. Research conducted in this task area includes, but is not limited to, the following: develop techniques to prove and extend the utility of the OMS Critical Abstraction Layer (CAL) and Avionics Service Bus (ASB) for additional middleware, operating systems, and transport layers; evolve the Open Computing Environment (OCE) to host common mission services as well as to support modularization of Operational Flight Program (OFP) services;

prove and expand the OSA message set to accommodate additional payloads and services; refine isolation interfaces for Safety of Flight subsystems, communication Gateways, and bridges; explore concepts for adaptation and migration of legacy systems, and development of tools to support rapid OSA-based implementations. An OSA platform shall be established and maintained to demonstrate prototype component technology as well as evolving technologies. While this area is primarily focused on methods to prove and evolve the OMS and UCI standards, consideration will be given to approaches to evolve other OSA standards.

Research accomplished in this area may result in proposed changes to the OMS and UCI standards. Proposed changes to the standards shall follow the change processes defined by the respective standards.

3.2 Cyber Resiliency for Open System Architectures

The objective of this task area is to develop and demonstrate innovative cyber security techniques to build affordable, cyber-resilient avionics systems. This task involves the following: 1) Research and develop innovative cyber security techniques to augment OSA implementations such as OMS and UCI as well as other standards; 2) Demonstrate the technical feasibility of promising cyber security techniques in a representative application; and 3) Evaluate the maturity of the cyber security techniques as integrated in an avionics system concept(s), research concept(s) or prototype(s) and demonstrated in a realistic environment. OSA approaches have been employed on many DoD weapon systems as a design consideration and technical solution to reduce the risk and cost of building new systems as well as upgrading existing systems. However, most current weapon systems were designed without considering cyber security and cyber resilience as well as Anti-Tamper

(AT) requirements. Cyber security and safety certifications have focused on known operational ranges and known fault conditions but not on intelligent cyber attacks executed by a sophisticated and well-resourced adversary. In addition, OSA implementations are based on widely-known and well-documented standards that are easier to understand and, therefore, facilitate rapid development of exploits that could affect multiple weapon systems. Thus, it is especially important to incorporate added cyber security, IA, and AT into an OSA implementation. An OSA with built-in cyber security features can facilitate resilience to cyber attacks against avionics systems mission assurance. Research conducted in this task area includes, but is not limited to, security services and protocols to ensure authentication, access control, and assured delivery of data techniques to manage and maintain cyber security health along with approaches to isolate trustworthy and untrusted components. Technical solutions applicable to component, system, and system of systems are of interest. Research accomplished in this area may result in proposed changes to the OMS and UCI standards.

Proposed changes to the standards shall follow the change processes defined by the respective standards.

3.3 Open System Architecture Emerging Concepts and Technologies

The objective of this task area is to explore emerging concepts for improved development, integration, and fielding of future OA-based systems. Research in this task area shall identify technological advances in hardware and software that can dramatically improve the development, integration, and performance of OSA implementations. Research in this task area includes, but is not limited to, advanced tools for analysis, construction, and proof and evaluation of OA-based technology as well as multi-core processing and other improvements to accommodate throughput and latency demands of additional subsystems and payloads.

3.4 Open System Architecture Risk Reduction Studies and Experimentation

The objective of this task area is to conduct short-term, OSA-related studies and experiments to determine the viability of an OSA implementation prior to system design and development. Research conducted in this task area may include, but is not limited to: 1) Assessing the value and impact of applying open system standards and technologies to avionics systems; 2) Understanding and reconciling conflicting differences between open system architecture standards to promote cross standards interoperability; 3) Performing usability, feasibility, and performance tests on different OSA implementations; 4) Developing and evaluating systems built using multiple open system standards; and 5) Researching tools, technologies, and techniques to more rapidly design, develop, test, and field systems based on open standards. Research in this area will develop the needed technical SME expertise to address adopting program challenges. Research accomplished in this area may result in proposed changes to the OMS and UCI standards. Proposed changes to the standards shall follow the change processes defined by the respective standards.

3.5 Open System Architecture Advanced Technology Demonstrations

The objective of this task area is to integrate technology solutions and advanced prototype components developed in the previous areas and to conduct advanced technology demonstrations of mature OSA capability. This task area is critical to future adoption of OSA solutions by AF and DoD programs as it seeks to evaluate the technology prototypes under realistic operating scenarios to the maximum extent possible in order to reduce integration risk. Plans, processes, and measures of effectiveness must be defined and executed in order to illustrate the capability, determine the maturity, and quantify the benefit to ensure ease of integration and reduced risk. Component prototypes resulting from the aforementioned task areas shall be integrated and demonstrable in a realistic operating environment in order to determine maturity and future incorporation with the OSA standards. Research and advanced prototype development accomplished in this area may result in proposed changes to the OMS and UCI standards. Proposed changes to the standards shall follow the change processes defined by the respective standards.

3.5.1 This may involve performing one or more areas (listed above) on a production unit or system under development. (3010/3080)

3.5.2 This may involve performing one or more areas (listed above) on a system or unit currently fielded.

(3400)

4.0 MANAGEMENT: The contractor shall exercise program administrative and financial functions during the course of this effort. These functions shall include: scheduling and tracking activities/milestones;

subcontractor management; reporting program status and identifying risks, problems, and mitigation strategies; ensuring deliveries; planning, forecasting, recommending funding, funding changes, and follow-on efforts; and documenting technical breakthroughs or discoveries. The contractor shall support conducting research and development both on-site (i.e., at a Government facility) and off-site (i.e., at the contractor’s facility) as appropriate for each task order.

5.0 DELIVERABLES: Data shall be delivered in accordance with the Contract Data Requirements Lists (CDRLs) as attached to the solicitation. The contractor shall propose additional deliverables for individual TOs as appropriate. In addition, software and hardware (including source code, firmware, libraries, and executables) developed on TOs should be delivered with unlimited rights. All software developed under TOs shall be delivered in a format acceptable to both parties. The contractor shall identify, within the proposal, any restrictions on the type of rights to be provided with software and hardware delivered but not developed on

TOs with full disclosure of any dependencies upon third party software/hardware.

6.0 TECHNICAL REVIEWS: The contractor shall plan and conduct periodic technical review meetings (estimated quarterly). The contractor shall ensure required contractor, subcontractor(s), AFRL, and other research personnel are involved.

7.0 SECURITY

7.1 Program Security Requirements

Individuals must be US citizens and may be required to have SCI DCID 6/4 Top Secret Eligibility based on a

SSBI/SBPR to work classified efforts. Any/all SCI and/or SAP work will be required to be conducted within an accredited Special Access Program Facility (SAPF) and/or a Sensitive Compartmented Information Facility (SCIF).

Specific security details and requirements will be outlined within future task orders. All classified efforts must be in compliance with National Industrial Security Program Operating Manual (NISPOM). Other regulations/policies that may apply to this contract are JAFAN 6/0 (Revision 1); DoD Directive 5205.07 (Vol 1-4);

AFMAN 16-703 V3; SAF/AAZ Memorandum” Air Force Special Access Programs Nomination Process (SAPNP)”

(30 Sep 2013); USD(I) Memorandum, Special Access Programs Nomination Process (20 May 2013); JAFAN 6/3

Implementation Guide, Version 1 (Sep 2006); DoD SAPCO Memorandum, Transition to the Risk Management

Framework (RMF) (18 Dec 2013); Joint Special Access Program Implementation Guide (JSIG) (9 Oct 2013);

Intelligence Community Directives (ICD) 704 and 705; other applicable SCI regulations/policy; other applicable

Security Classification Guides (SCG); and other applicable regulations/policy and subsequent revisions.

7.2 Operational Security (OPSEC)

General OPSEC procedures, policies and awareness are required in an effort to reduce program vulnerability from successful adversary collection and exploitation of critical information. OPSEC will be applied throughout the lifecycle of the contract. The Critical Information List will be provided upon request by the RYOY

Information Protection Office. While working on the government installation OPSEC will be provided by the

RYOY Information Protection Office.

7.3 Security Training

The contractor will be required to participate in the USG's in-house and web-based security training program under the terms of the contract. The USG will provide the contractor with access to the on-line system. The contractor will be required to take specialized security training as deemed applicable by USG.

8.0 SAFETY: The contractor must comply with all Air Force, federal, state, and local safety and environmental regulations. The effort requires an approved Safety Plan (AFI 91-202 AFRL Sup 1) before any experiment may be conducted outside of a laboratory environment. The contractor must comply with safety requirements contained in MIL-STD 882E, Section 4 “General Requirements” for any deliverable systems or hardware. The contractor must identify safety-critical components of those systems or hardware and software interfaces with those components. The contractor must test and verify the safety-critical hardware and software for safety acceptance.

9.0 BASE SUPPORT: Laboratory space/equipment (on a non-interference basis) and computer/network access in AFRL/RYWA for this contract shall be available for the purpose of conducting this effort, if proposed.