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

BAA-AFRL-RQKS-2015-0009

Attachment 2

OPEN ARCHITECTURE DATA TRANSFER CHARACTERIZATION

TASK ORDER 0001 - STATEMENT OF OBJECTIVES (SOO)

25 January 2016

1.0 BACKGROUND

The Open Mission Systems (OMS) Definition and Documentation (D&D) architecture standard provides three different forms of data interconnection methods: the Critical Abstraction Layer (CAL), Bulk Data Transfer (DT), and Special Signals (SS). The OMS CAL allows OMS services, regardless of their location, to communicate using

OMS Messages. The Bulk Data Transfer interconnect provides a standard unified mechanism for OMS services to transfer data to and from a file system as well as transfer data directly from one service/subsystem to another (with or without an intermediary file system). Finally, the Special Signals interconnect provide high-speed data lines to move data payloads when latency or bandwidth requirements exceed the capacity of the message-based network. This interconnect is defined by the system integrator.

Numerous integration experiments have been conducted to demonstrate the capability of the OMS message and Bulk Data Transfer interconnects as well as efforts to collect performance parameters for a representative set of mission scenarios. However, additional experimentation needs to be conducted on other applications and combinations of interconnects and network transports. The challenge is collecting the required information without adversely affecting mission system performance. Parameters of interest include, but are not limited to, memory usage; overhead; latency; and throughput. A set of relevant parameters must be defined as well as an efficient means to collect them, for different configurations of the transports, and under different mission scenarios. Lastly, a methodology to repeat this process is needed. A repeatable methodology will facilitate comparisons between different OMS and Bulk Data Transfer implementations, and ensure mission requirements are met or exceeded. The goal of this task order is to quantify aspects of OMS data transfer methods to understand potential impacts on critical mission applications.

2.0 OBJECTIVE

The objective of this task order is to research and develop methods, tools, and techniques to characterize the performance of OMS data interconnection methods for representative mission system applications in order to evolve current Open System Architecture (OSA) standards to meet platform technical challenges. Of particular interest are the OMS Critical Abstraction Layer (CAL), the Avionics Service Bus (ASB), and the Bulk Data

Transfer interconnects.

3.0 TASKS AND TECHNICAL REQUIREMENTS

3.1 Quantitative Metrics Definition

The contractor shall select a set of metrics to characterize the data transfer method with consideration given to avionics constraints. The contractor shall define a set of parameters to collect computer relevant metrics.

Parameters that could be collected include, but are not limited to, use of memory; stack and heap; latency;

throughput; jitter; and other behavioral aspects to characterize overall performance

3.2 Automated Tools for Data Transfer Characterization

The contractor shall develop methods and tools to collect data. The contractor shall investigate the use of automated tools and techniques to collect parameters. To the extent possible, the contractor shall develop techniques to non-intrusively instrument the transfer method to collect performance data. The contractor shall demonstrate the use and effectiveness of the collection tools and techniques.

3.3 Prototype Design and Development

The contractor shall provide an advanced component prototype experimentation testbed in which to integrate the characterization tools and techniques to perform data transfer characterization. The testbed may include development of a testbed or integration within an existing testbed. The contractor shall define a methodology to perform continuous characterization of the transfer method for different interfaces, network transports, and/or different data types. The testbed shall be configurable to accommodate substitution and comparison of different CAL/ASB implementations, combinations of payloads, subsystems, and services, and network load conditions. The contractor shall document all key interfaces including services, subsystem, and platform in accordance with the OMS standard or other applicable standards as appropriate. The contractor shall develop and operate research networks as necessary to support prototype design, development, and evaluation. The networks must adhere to applicable security standards and meet performance requirements for associated task(s).

3.4 Evaluation and Demonstration

The contractor shall select a representative platform configuration to evaluate the effectiveness of the characterization method(s). The configuration shall include any combination of payloads, subsystems and services. At a minimum, the platform configuration shall include one service running in an Open Computing

Environment (OCE) as defined in the OMS D&D. The contractor shall document the functions, data exchanges, and interfaces of all services and subsystems in accordance with the OMS D&D. The contractor shall select a transfer method that the aforementioned configuration will use including the CAL and network transport, if applicable, and a data transfer method. The contractor shall select a mission scenario with representative performance characteristics. The contractor shall conduct an integrated experiment that uses the mission scenario, platform configuration, and data transfer method(s) which will be evaluated to demonstrate the transfer characterization methods and to collect performance data in accordance with the parameters selected in Task 3.1. The contractor shall demonstrate the repeatability of the transfer characterization methods for different scenarios and platform configurations.

3.5 Change Proposals to Open System Standards

Research and development accomplished in the aforementioned tasks may result in change proposals to the

OMS standard. The Government shall approve all change proposals prior to submission. Any proposed changes shall follow the change processes defined by the respective standards.

4.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 the TO as appropriate.

In addition, software and hardware (including source code, firmware, libraries, and executables) developed on this TO should be delivered with unlimited rights at the end of the technical period of performance. All software developed under this TO 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 this TO with full disclosure of any dependencies upon third party software/hardware.

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

6.0 SECURITY

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

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

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

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

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