SOW_Smartronix_IDIQ_2018_20180810.docx

ATLANTIC TEST RANGE TELEMETRY BRANCH

OMEGA NEXT / iNET TELEMTRY NETWORK SYSTEM

SOFTWARE ENGINEERING SUPPORT

STATEMENT OF WORK

1. BACKGROUND

1.1. Telemetry processing systems running Smartronix Omega software are used by the Range Department at NAS Patuxent River, MD to support real-time telemetry data processing and display. These systems lack telemetry network capabilities. Specific systems of interest with respect to this SOW are:

· The Real-Time Telemetry Processing System (RTPS). Through the RTPS V Improvement and Modernization (I&M) program, the Atlantic Test Range (ATR) Telemetry Systems Branch upgraded RTPS by replacing the Telemetry Front End Processing System with the Smartronix Series-5000 running Omega NExT software.

· The Ground Service Equipment (GSE). GSE trucks and carts running Omega are used by the Airborne Instrumentation Division (AID) to preflight telemetry instrumentation systems on test aircraft.

1.2. The integrated Network-Enhanced Telemetry (iNET) project is a multi-service funded effort to add ground-to-test-article wireless network connectivity to telemetry systems that are currently based on the existing, downlink-only architecture. The iNET project has been working on prototype components to be integrated into a demonstration Telemetry Network System (TmNS). The TmNS and its constituent components are governed by a set of TmNS interface standards, which have been added to the Range Commander’s Council (RCC) IRIG 106 Telemetry standards. Modification of Omega NExT to comply with these standards is required so that Omega NExT can be part of the demonstration TmNS.

1.3. The iNET project is focused on development, integration and test of the TmNS at NAS Patuxent River, MD. Additional component development and maturation will occur in parallel to the effort described by this SOW. Demonstration of the full list of iNET TmNS required capabilities will occur during an Advanced Flight Tests (AFT) phase of the project, which will begin here at NAS Patuxent River beginning in FY19.

2. SCOPE

From the ground processing perspective – the perspective of ATR’s RTPS V and AID’s GSE - the iNET project is introducing new data source types and formats, new time formats, new metadata formats, and new system control functions. All of these are governed by the iNET TmNS interface standards, now part of the Range Commander’s Council IRIG 106 Telemetry standards. Smartronix’s Omega NExT software does not support the data source types, time formats, or metadata formats established via these standards. The Atlantic Test Range (ATR) Telemetry Branch and the Airborne Instrumentation Division (AID) both require software modifications to the Smartronix NExT suite in order to support TmNS integration and test, and eventually operations, at NAS Patuxent River, MD. Throughout the remainder of this SOW, the term “on base” will refer to NAS Patuxent River, MD.

3. APPLICABLE DOCUMENTS

These documents are provided as references necessary to accomplish the work described in this SOW. It is important to note that some of these documents are in the process of being matured by the iNET project. This documentation can be located at the following hyperlink http://www.irig106.org/docs/106-17/, or obtained from the Government POC listed in Section 8.0, below.

3.1. RCC IRIG 106 Telemetry Standards, chapters describing TmNS.

3.2. iNET TmNS System Documents

· Telemetry Network System Specification (latest version)

· Telemetry Network System Design Document (latest version)

3.3. RTPS V Interface Description (latest version)

4. TECHNICAL REQUIREMENTS

4.1. Fetch Data Functionality

The Contractor shall enhance the current release of the Omega NExT suite with the capability to acquire, process, display and output data from the TmNS, to include real-time data (e.g. from a TmNS DAU), or recorded data. At a minimum, this capability shall include the following functionality working in concert:

4.1.1. Configure the Omega NExT system based on content of TmNS Standard Metadata Language (MDL) file(s) in combination with User inputs via the Omega NExT GUIs.

4.1.2. Accept and process requests for TmNS data originating from within the Omega NExT environment (e.g. from user input to GUIs or from displays). Request parameters supported shall include measurement names, and either time slices or request for real-time data streaming.

4.1.3. Accept and process requests for TmNS data originating from outside the Omega NExT environment from the RTPS V interface. Request parameters supported shall include measurement names, and either time slices or request for real-time data streaming.

4.1.4. Subscribe to, and receive, TmNS data from a test article Data Acquisition Unit using the TmNS standard LTC interface.

4.1.5. Request, and receive, TmNS data from a test article TmNS Recorder using the TmNS standard RC interface.

4.1.6. Process received TmNS data using data descriptions provided in MDL file(s).

4.1.7. Process TmNS standard 1588 time (PTP format) embedded in TmNS messages and packages.

4.1.8. Output results of processing to the native Omega NExT display environment. Output options shall include - in addition to processed data – raw data as received, and information about the TmNS Data Messages & Packages (TmNS message and package header information).

4.1.9. Output results of processing via the RTPS V interface (for eventual use in the IADS display system).

4.2. PCM Backfill Functionality

Leveraging functions described in Section 4.1, the Contractor shall enhance the current release of the Omega NExT suite with the capability to identify dropouts in PCM data sources; repair them by acquiring the lost data via the TmNS; and process / display / output the resulting lossless data. At a minimum, this capability shall include the following functions working in concert:

4.2.1. Detect dropouts (lost/corrupted frames) in real-time PCM stream(s) received via the system’s PCM input interface(s).

4.2.2. Continue to process and output data from the real-time the PCM Stream(s) as normal.

4.2.3. Additionally, identify lost PCM frames associated with the dropouts detected, and request replacement frames (embedded in TmNS messages) from the test article TmNS recorder via the RC interface.

4.2.4. Receive TmNS messages containing replacement frames and process a complete reconstructed “pristine” data set(s) created by merging buffered good frames received via the PCM interface(s) with the replacement frames received via TmNS. (Note: this buffering and subsequent processing shall not interfere with ongoing real-time processing identified above).

4.2.5. Output results of processing the pristine data set(s) to the native Omega NExT display environment.

4.2.6. Output results of processing via the RTPS V interface (for eventual use in the IADS display system).

4.2.7. Accept and process requests to start and stop the PCM backfill functions originating from User inputs to the Omega NExT GUIs, or from the RTPS V interface.

4.3. Configuration Functionality

The Contractor shall enhance the current release of the Omega NExT suite with the capability to respond to a TmNS standard configuration notification by an external TmNS System Manager. In response, Omega NExT shall ingest the appropriate TmNS Metadata Language (MDL) file, and use it to populate the Omega NExT database. In reponse to a TmNS export command, Omega NExT shall translate the current Omega NExT database to TmNS standard MDL format, and export to the file to the external System Manager.

4.4. Calibration Functionality

The Contractor shall enhance the existing calibration functions in the current release of the Omega NExT suite with the capability to perform calibrations and display calibration results using a TmNS data source (vs. PCM data source) when requested via user input.

4.5. Logging Functionality

The Contractor shall enhance the current release of the Omega NExT suite with a TmNS standard log function. This function shall receive Data to be Logged as one of its inputs. Data to be Logged shall consist of all data that is to be written to the Log File. Log File shall consist of a filename and path where data is to be logged. This function shall append log entries to Log File or create a new file if Log File does not exist. All log entries shall contain a timestamp, and the Data to be Logged.

4.6. Status Reporting Functionality

The Contractor shall enhance the current release of the Omega NExT suite with the capability to respond to a TmNS standard status request notification by an external TmNS System Manager. In response, Omega NExT shall respond to the System Manager with a TmNS standard status response.

5. OTHER REQUIREMENTS

5.1. Requirements Review

The Contractor shall hold a Requirements Review at the Contractor’s facility. The Requirements Review shall be held within 30 days after award of the contract to ensure a common understanding of the contract and statement of work by the Government and the Contractor’s development team. Minutes for the review shall be delivered in accordance with CDRL A001.

5.2. Technical Interchanges

The Contractor shall conduct Technical Interchange Meetings (TIMs) as required to support development and testing efforts. TIMs will be conducted on an as-needed basis, as agreed upon by the Contractor and the Government, to discuss issues concerning requirements, standards, design alternatives, or other topics of importance. These meetings will be conducted at the Contractors site and at times via Telephone Conferences or Web Conferencing. Minutes for the TIMs shall be developed and delivered in accordance with CDRL A001.

5.3. Project Status Reporting

The Contractor shall provide a Periodic Status Report (PSR) to the Government by the 6th business day of the reporting period for the closing reporting period. The PSR (CDRL A002) shall be in electronic form in a format mutually agreeable to the Contractor and Government. The PSR shall address performance, schedule, and cost by providing an accumulative project summary of accomplishments, tasks accomplishments for the month along with hours expended, tasks planned for the upcoming month along with a projection of hours to be expended, and a forecast relative to the completion of the work – or significant portions thereof - identified in this SOW.

5.4. Testing and Test Documentation

It is planned that the Government will witness/review Contractor testing conducted throughout the development cycle and at various locations. The Government expects that multiple levels of test and integration will be conducted throughout the performance of the work described in this SOW.

Early testing – before significant build-up of the TmNS on base by the Government occurs - will likely first be limited to Contractor testing using sets of TmNS data files with matching MDL metadata files supplied by the Government, and then progress to include Contractor use of Government-provided reference applications (e.g. the EQDR as stand-in for a TmNS recorder) in order to more fully test Contractor implementation of TmNS standard interfaces.

As the Government TmNS builds up the TmNS on base, opportunities will arise to perform integration tests of Contractor developments on base.

5.4.1. Contractor Development Testing

The Contractor shall, upon request by the Government, provide opportunity for the Government to observe ongoing development tests, and/or conduct a demonstration either at the Contractor’s facility, or on base. The Contractor shall treat these events as TIMs (Section 5.2), and therefore deliver Minutes in accordance with CDRL A001 as documentation of the event.

5.4.2. Site Acceptance/Demonstration Testing of Deliveries

When delivering software, the Contractor shall provide support on base for Acceptance Tests / Demonstrations for the Government. The tests shall be conducted by installing the deliverable on one or more government owned & controlled Omega NExT systems.

The Contractor shall develop and deliver Software Acceptance Test Procedures in accordance with CDRL A003 and Software Acceptance Test Reports in accordance with CDRL A004.

5.4.3. Government-Led TmNS Integration Testing

The Contractor shall provide support on base for additional TmNS system level integration testing to be performed by Government.

For these tests, the Contractor shall – if requested by the Government - develop and deliver Integration Test Procedures in accordance with CDRL A005 and Integration Test Reports in accordance with CDRL A006.

5.5. Deliveries

5.5.1. Partial Deliveries

In order to support ongoing Government component and TmNS test and integration, the Government may request partial deliveries (e.g. individual functions or groups of functions among those described in Section 4 above). Upon request of the Government POC (See Section 8), the Contractor shall coordinate with the Government to make partial delivery in a manner, and at a time mutually agreed upon between the Contractor and the Government. If requested, the Contractor shall support on base installation, integration and acceptance/demonstration testing.

5.5.2. Fiscal Year and Final Deliveries

At the end of each fiscal year, and upon completion both of the work described in this SOW and the Contractor’s Software Engineering Process, the contractor shall coordinate with the Government to make the deliveries in a manner, and at a time mutually agreed upon between the Contractor and the Government. If requested, the Contractor shall support on base installation, integration and acceptance / demonstration testing. The Contractor shall also mail a copy of the updated Omega NExT software package to the Government POC (Section 8).

5.5.3. Software User Documentation

For each Fiscal Year delivery and for the Final Delivery, the Contractor shall deliver in accordance with CDRL A007, an updated version of the existing Omega NExT Software User Manual to describe – at a level of detail consistent with the existing documentation - the functionality added via this SOW. Additionally, the Contractor shall also update online documentation within the Omega NExT (e.g. help menus) to describe the functionality added via this SOW.

5.6. Contract Data Requirements List

The Contractor shall provide all personnel and resources necessary to produce and deliver the Data Items identified in the Contract Data Requirements List (CDRL). Contractor’s format and content for these deliverables must be submitted for approval to the Government prior to delivery.

DATA ITEMS

6. PERIOD OF PERFORMANCE

This software engineering support shall expire within one (3) years of contract award.

7. GOVERNMENT FURNISHED ITEMS

Software tools and reference applications are available for use as the Contractor sees fit from https://www.tena-sda.org/display/INET/Home, or via request to the Government POC listed in Section 8, below. These tools are offered in good faith, “as is”, to support interoperability; however, the Government makes no claims or guarantees relative to the use of the tools.

8. GOVERNMENT POC:

The primary Government POCs for coordination of all technical aspects of this SOW are:

Spencer Quade 23013 Cedar Point Road, BLDG 2118 NAS Patuxent River, MD 20670 Spencer.quade@navy.mil (301)342-8232

Thomas Grace 47758 Ranch Road, BLDG 1492 NAS Patuxent River, MD 20670 Thomas.grace@navy.mil (301)342-1227