DRAFT_Attachment 8 - Performance Work Statement_TO1_C2PL-25-3.docx

Draft RFP: 70Z04426RC2PL2503

DRAFT ATTACHMENT 8

TASK ORDER 1 (TO1)

PERFORMANCE WORK STATEMENT (PWS)

NEXT GENERATION SURFACE SEARCH RADAR (NXSSR) SOFTWARE DEVELOPMENT KIT (SDK) AND AUTOMATIC RADAR PLOTTING AID (ARPA) APPLICATION FOR THE UNITED STATES COAST GUARD (USCG) COMMAND, CONTROL, COMMUNICATIONS, COMPUTERS, CYBER, AND INTELLIGENCE SERVICE CENTER (C5ISC)

1 GENERAL

BACKGROUND

The Coast Guard (CG) uses Surface Search Radar (SSR) to provide operators with an advanced system for collision avoidance, safe navigation, and enhanced situational awareness of the maritime environment. There are currently five (5) separate radars (AN/SPS-50, AN/SPS-78, AN/SPS-79, AN/SPS-73, and Terma Scanter 2001) in use across 14 cutter platforms and 113 Vessel Traffic Service (VTS) remote sites. In May 2019, the Coast Guard was notified that the FAR 2XXX series (which includes the AN/SPS-50 radar) was in final production and end-of-support. The AN/SPS-78 and AN/SPS-79 radars precede the AN/SPS-50, are significantly degraded, and overdue for recapitalization. Ashore, the VTS Terma Scanter 2001 Radars are end-of-support and require replacement. The AN/SPS-73 radar is beyond its service life and needs replacement.

The current state SSRs utilize several different interfaces for afloat Command and Control (C2) and ashore VTS systems. For afloat applications, the AN/SPS-50 radar is a proprietary Furuno system that interfaces with CG Electronic Chart Display and Information System (ECDIS) and CG Electronic Charting System (ECS) by use of a Buffalo Computer Graphics integration solution, NAVNET IMO, for radar overlay. The AN/SPS-78 and AN/SPS-79 radars utilize Furuno turning units and arrays with SSR Engineering Radar Processors (PCRPs) which interface to the C2 Systems, SeaWatch and Sea Commander. The PCRPs interface via COMRIC which feeds the C2 system clients running the current state Command, Display and Control (C) – Automatic Repair Plotting Aid (C-ARPA) Application.

For ashore, the Terma Scanter 2001 and AN/SPS-73 radars interface with the VTS Ports and Waterways Safety System (PAWSS), a Lockheed Martin Corporation core software product (MTM-300). PAWSS interfaces with TERMA Scanter 2001 radars via a Curtis Wright Dual channel radar interface card that processes video, trigger, and azimuth data that translates into centroids and track data. The AN/SPS-73 radars interface with PAWSS by use of SSR Engineering PCRP 201A radar processors. Furuno radar data is processed into track data and transmitted to the PAWSS core software.

SCOPE

The Coast Guard (CG) seeks to procure a Software Development Kit (SDK), a correlating Automatic Radar Plotting Aid (ARPA) Application, and necessary enterprise licensing. The SDK must be a customizable radar integration application to leverage across the scalable, IMO-certified Surface Search Radar (SSR) system. The ARPA application must interface with C2 systems by use of a Local Area Network (LAN) and enable video data, target data, and control functions providing Plan Position Indicator (PPI) duplication and functionality to include AIS track correlation for all CG Enterprise Electronic Navigation System solutions to include but not limited to, CG-ECS, CG-ECDIS, SeaWatch, and Sea Commander.

There are four (4) distinct tasks associated with this effort:

· Task A - Software Development Kit (SDK)

· Task B – ARPA Application

· Task C – SDK/ARPA Application Licensing

· Task D – SDK Documentation

GOVERNMENT TERMS AND DEFINITIONS

REQUIREMENTS

2.1 Task A - Software Development Kit (SDK) (CDRL A001)

2.1.1 The contractor must provide an SDK which exposes video data, target data, and control functions for inclusion in other products developed by the Government or other contractors, including exposing the functions via Application Programming Interface (API).

2.1.2 The functions provided by the SDK must deliver control of the system based on prioritization by the Government and identified through the NXSSR Technical Specification at the IDIQ level.

2.1.3 Software installation procedures for Windows and Linux must be contractor-provided, to include requirements of the target host/platform which must be met to allow for installation.

2.1.4 SDK must be provided to the Government in Contractor format no later than 30 calendar days after date of task order award.

2.2 Task B – Automatic Radar Plotting Aid (ARPA) Application (CDRL A002)

2.2.1 The contractor must develop an ARPA Application based on Software Development Kit (SDK) that uses exposed functions via Application Programming Interface (API) with Windows 11 and Linux variants.

2.2.2 The ARPA Application must allow direct radar interface via Local Area Network (LAN) with existing C2 Systems providing radar video (PPI), target data, and control functions.

2.2.3 ARPA Application functionality must include AIS track correlation with radar targets.

2.2.4 Each Minimum Viable Product (MVP) must include a Software Bill of Materials (SBOM) for each component.

2.2.5 Initial ARPA Application delivery and any future deliveries throughout the life of the order must include Git repository updates with the associated change history including a Software Version Document (SVD) noting all changes from the previous software version.

2.3 Task C – SDK/ARPA Application Licensing

2.3.1 The contractor must provide an enterprise license for the SDK to include unlimited usage for CG Enterprise.

2.3.2 The contractor developed ARPA Application must be provided with an unlimited license for use to include rights to use, modify, reproduce, perform, display, release, or disclose technical data in whole or in part, in any manner, and for any purpose whatsoever, and to have or authorize others to do so. This includes modifications to the ARPA Application for further development, as required.

Task D - SDK Documentation (CDRL A003)

2.4.1 The contractor must provide manual(s) explaining each method of the SDK, with examples of implementation for the methods, written to the knowledge level of a software developer.

2.4.1.1 API calls must be described in adequate detail to include all available methods and possible responses, including any returned error conditions and success codes/messages. API examples for explanation should be documented at the level of a software developer.

2.4.3 The SDK documentation must be provided in a digital markdown format for use in a Git repository in addition to the source code.

3 DELIVERABLES