Attch 1 - SOO CLEER_Rev6_JUL2020.pdf

45TH Weather Squadron Statement of Objectives (SOO) for

Cloud and Lightning Evaluation for Eastern Range (CLEER)

16 July 2020

1. Purpose In support of Eastern Range (ER) launches, the 45 Weather Squadron (WS) is required to determine the distance from the launch vehicle's flight path to both the edge of clouds and to lightning strikes.

2. Scope

The 45th Space Wing is seeking a computer system which will ingest and display government provided live Eastern Range (ER) weather radar data, live ER lightning events, weather balloon data, and nominal vehicle trajectory data in a virtual 3-Dimensional (3-D) view on one display, referenced to launch complexes on Cape Canaveral Air Force Station.

Weather radar, and lightning data will be provided via continuous data feeds. Temperature data will be uploaded by the operator after each data set becomes available, and the launch trajectories will be uploaded by an operator once for each launch. The system shall be capable of displaying audible and visual alerts for violating Eastern Range weather launch rules for safe weather conditions. The system must also comply with applicable DoD cybersecurity requirements, including Department of Defense (DoD) Instruction 8510.01, National Institute of Standards and Technology (NIST) 800-53v4, and Federal Information Security Modernization Act (FISMA) guidelines.

The contractor shall be responsible for the creation and delivery of Risk Management Framework (RMF) artifacts. A subset of artifacts, defined by the government, shall be delivered with each software sprint delivery in support of cybersecurity approved testing.

The contractor shall deliver all cybersecurity artifacts as up to date draft at the midterm of the period of performance. The delivery of all finalized cybersecurity artifacts in support of final system accreditation will be delivered with the finalized software at contract end.

The contractor shall deliver capabilities utilizing a software development “sprint” approach with incremental capabilities delivered for evaluation bi-weekly. The sprint technical requirements are outlined in section 3.

3. Performance Objectives

3.1 Develop a three-dimensional (3-D) visualization tool to display near real-time weather radar, lightning events, vehicle nominal trajectory, and vehicle safety margin overlays on an earth-centered, earth fixed map.

3.2 Ingest Data

3.2.1 Provide capability to ingest near real-time, local weather radar and lightning events.

3.2.2 Provide capability for operator to upload vehicle nominal trajectory, vehicle safety margins, and user defined temperature level data.

3.3 Graphically Display Data

3.3.1 Launch Trajectories and Stand-off Areas.

3.3.1.1 Display graphical representation of up to two (2) government provided nominal launch trajectories.

3.3.1.2 Using government provided safety margin data, display a 3-D volume encompassing area inside of safety margins for each trajectory.

3.3.1.3 Using government provided safety margin data, display a 3-D volume encompassing area inside of safety margins plus 3 nm (3nm stand-off) for each trajectory.

3.3.1.4 Using government provided safety margin data, display a 3-D volume encompassing area inside of safety margins plus 5 nm (5nm stand-off) for each trajectory.

3.3.1.5 Using government provided safety margin data, display a 3-D volume encompassing area inside of safety margins plus 10 nm (10nm stand-off) for each trajectory.

3.3.1.6 The user will independently control transparency and color of each displayed launch trajectory and stand-off area.

3.3.1.7 The user will have the ability to independently toggle the view of each trajectory, and safety margin and stand-off volumes.

3.3.2 Graphical Display of Lightning Events

3.3.2.1 Ingest and display two-dimensional lightning events (lat/long clamped to ground).

3.3.2.2 The user shall control the height of represented lightning events (extrude lat/long to user defined height).

3.3.2.3 Displayed lightning events refreshed every 15 seconds or less.

3.3.2.4 Continuous lightning data feed will be provided by the government.

3.3.2.5 The user shall control the time relevance of lightning events displayed, up to one hour.

3.3.2.6 Display a time-phased color representation of lightning events based on a user defined color code in 15-minute increments (4 colors).

3.3.2.7 Time-phased color representation of lightning events shall be displayed with a user-selectable gradient of 4 colors.

3.3.2.8 Display a map key of the time-phased color representation of displayed lightning events.

3.3.2.9 The user shall control transparency of displayed lightning events.

3.3.2.10 The user will have the ability to toggle the view of lightning events (all or none).

3.3.3 Weather Radar Data

3.3.3.1 Ingest and display an industry-standard graphical representation of smoothed radar data as the default view.

3.3.3.2 Provide the capability to graphical display native (“pixelated”) radar data at user’s request.

3.3.3.3 Display radar data representation in 3-D as the default view.

3.3.3.4 Display radar data, 2-D, at user’s request.

3.3.3.5 Display refreshed radar data, updated every 2.5 minutes.

3.3.3.6 The user shall control transparency of displayed radar data.

3.3.3.7 The user will have the ability to toggle the view of weather radar data.

3.3.3.8 Continuous weather radar data feed will be provided by the government.

3.3.4 Temperature Data

3.3.4.1 The user shall have the ability to display and label a transparent horizontal x, y plane at user-specified atmospheric temperature levels (i.e. 5ᵒC, 0ᵒC, -5ᵒC, - 10ᵒC, and -20ᵒC).

3.3.4.2 The user will have the ability to toggle the view of temperature data.

3.3.4.3 Temperature data will be uploaded by the operator after each data set becomes available.

3.4 Display Controls

3.4.1 For transparent requirements above, allow user configuration of transparency from

0-100%.

3.4.2 Provide the ability for user-controlled pan, tilt, and zoom of 3-D display.

3.4.3 User will have the ability to set and change the displayed radar data based on a user defined minimum and maximum values (dBZ, atmospheric temperature, and altitude).

3.4.4 Display a distance between two (2) user-defined points or objects on the 3-D display.

3.4.5 Provide capability to measure the shortest distance between a radar volume bin and the trajectory safety margin or specified standoff distance (i.e. slant distance).

Standoff distances include 3nm standoff, 5nm standoff, and 10nm standoff.

3.4.6 Create an option for the user to select any point on the display to temporarily plant a ruler in the vertical to provide a vertical scale reference.

3.4.7 Controls and user interfaces shall minimize screen clutter; System will maximize screen area to display data identified in section 3.3.

3.4.8 User shall have the ability to change units. (e.g. knots to mph; Celsius to Fahrenheit, etc.).

3.4.9 Allow the user to create and save multiple, individual map overlays (i.e. shape files, etc).

3.4.10 Set the default map home location to the trajectory origin.

3.4.11 Allow user to set the map home location.

3.4.12 Allow user to set a default zoom level based on home location.

3.5 Rules and Rules Evaluation

3.5.1 The systems will have predefined rules with user selectable inputs (sub-rules).

3.5.1.1 Sub-Rule 1: Identify lightning at a slant distance ≤ [input] nm from the safety margin.

3.5.1.2 Sub-Rule 2: Identify consecutive reflectivity radar values ≥ [input] that cover a vertical extent ≥ [input] ft at a slant distance ≤ [input] nm from the safety margin.

3.5.1.3 Sub-Rule 3: Identify cloud top colder than [input] ᵒC at a slant distance ≤ [input] nm from the safety margin.

3.5.1.4 Sub-Rule 4: Identify reflectivity radar values ≥ [input] dBZ at a slant distance ≤ [input] nm from the safety margin.

3.5.1.5 Sub-Rule 5: Identify cloud top colder than or equal to [input] ᵒC at a slant distance ≤ [input] nm from the safety margin.

3.5.1.6 Sub-Rule 6: Identify cloud top colder than or equal to [input] ᵒC and warmer than [input] ᵒC at a slant distance ≤ [input] nm from the safety margin.

3.5.1.7 Sub-Rule 7: Identify cloud top with reflectivity values ≥ [input] dBZ at a temperature level colder than or equal to [input] ᵒC at a slant distance ≤ [input] nm from the safety margin.

3.5.2 Create User-defined Lightning Launch Commit Criteria (LLCC) rules

3.5.2.1 User definition method:

3.5.2.1.1 User selects from a list of pre-established Sub-Rules, Options, and Action Items and groups and arranges them to create an overarching LLCC Rule.

3.5.2.1.2 User inputs desired threshold value(s) into designated user input prompt(s) within each Sub-Rule, Option, and Action Item.

3.5.2.2 Sub-rule nesting - sub-rules may be nested to as many as 6 layers.

3.5.2.3 System rule evaluation hierarchy:

3.5.2.3.1 LLCC rules are evaluated beginning with the designated Sub-Rules on the lowest tier of evaluation.

3.5.2.3.1.1 Each Sub-Rule on the same tier is evaluated independently.

3.5.2.3.2 If a Sub-Rule threshold is met, then the subsequent Sub-Rule(s) are evaluated as applicable.

3.5.2.3.3 Sub-Rules tied to an “Option”, in which the resulting outcome of the Sub- Rule (e.g. Reflectivity value) is used to evaluate the subsequent Option.

3.5.2.3.4 Sub-Rules tied to an “Action” shall trigger the prescribed action after Sub- Rule criteria is met (e.g. 30 minute countdown timer activated after lightning identified in Sub-Rule 1).

3.5.2.4 Setting Alerts for Sub-Rules and Options: User can select an “Alert” option for designated Sub-Rules and Options which will flag the prescribed feature (i.e., lightning or radar reflectivity value). This will alert the user of a “potential LLLC violation” when the stated criteria is met.

3.5.2.5 Setting the LLCC on Launch Day: User can toggle calculations of each LLCC in order to focus operator attention, and computing resources on the LLCC of concern for violation depending on the current or expected weather.

3.5.2.6 Lightning Rule Set

3.5.2.6.1 Sub-Rule 1 (Alert): Identify lightning at a slant distance ≤ [user input] nm from the safety margin.

Action 1: Start [user input] min countdown timer from the time lightning was detected in Sub-Rule [user input].

3.5.2.7 Thick Cloud Rule set

3.5.2.7.1 Sub-Rule 2a: Identify consecutive reflectivity radar values ≥ [user input] dBZ that cover a vertical extent ≥ [user input] ft at a slant distance ≤ [user input] nm from the safety margin.

Option 1 (Alert): Any of the identified reflectivity volume bins in Sub- Rule [user input] is detected between [user input]ᵒC and [user input]ᵒC temperature levels, inclusive.

3.5.2.7.2 Sub-Rule 2b: Identify consecutive reflectivity radar values ≥ [user input] dBZ that cover a vertical extent ≥ [user input] ft at a slant distance ≤ [user input] nm from the safety margin.

Option 1: Any of the identified reflectivity volume bins in Sub-Rule [user input] is detected between [user input]ᵒC and [user input:]ᵒC temperature levels, inclusive.

Option 2 (Alert): Reflectivity volume bins identified in Sub-Rule [user input] and true for Option [user input] are connected to other reflectivity values ≥ [user input] dBZ at a slant distance ≤ [user input] nm from the safety margin.

3.5.2.8 Disturbed Weather Rule

3.5.2.8.1 Sub-Rule 3: Identify cloud top colder than [user input] ᵒC at a slant distance ≤ [user input] nm from the safety margin.

Option 3 (Alert): Identify reflectivity radar values ≥ [user input] dBZ connected to the reflectivity volume bins identified in Sub-Rule [user input] at a slant distance ≤ [user input] nm from the safety margin.

3.5.2.9 Cumulus Rule

3.5.2.9.1 Sub-Rule 4: Identify reflectivity radar values ≥ [user input] dBZ at a slant distance ≤ [user input] nm from the safety margin.

3.5.2.9.2 Sub-Rule 5 (Alert): Identify cloud top colder than or equal to [user input] ᵒC at a slant distance ≤ [user input] nm from the safety margin.

3.5.2.9.3 Sub-Rule 5 (Alert): Identify cloud top colder than or equal to [user input] ᵒC at a slant distance ≤ [user input] nm from the safety margin.

3.5.2.9.4 Sub-Rule 6 (Alert): Identify cloud top colder than or equal to [user input] ᵒC and warmer than [user input] ᵒC at a slant distance ≤ [user input] nm from the safety margin.

3.5.2.10 Triboelectification Rule

3.5.2.10.1 Sub-Rule 7 Alert: Identify cloud top with reflectivity values ≥ [user input] dBZ at a temperature level colder than or equal to [user input] ᵒC at a slant distance ≤ [user input] nm from the safety margin.

3.5.3 Rule Evaluation

3.5.3.1 The system shall continuously evaluate rules and notify users when active rules are violated.

3.5.3.2 User selects from a list of pre-established and/or user-defined Sub-Rules, Options, and Action Items to continuously evaluate.

3.5.3.3 User inputs desired threshold value(s) into designated user input prompt(s) within each Sub-Rule, Option, and Action Item.

3.5.3.4 The system shall continuously evaluate rules and notify users when rules are violated.

3.5.4 Alerts and Alarms

3.5.4.1 Alerts and alarms shall be both visual and audible.

3.5.4.2 Alerts and Alarms shall require acknowledgement by the user.

3.5.4.3 Violation of rules/sub- rules shall trigger alerts and alarms.

3.5.4.4 Users shall be able to independently turn off alarms and alert functions.

3.5.4.5 Users shall be able to control the audible alarm volume.

3.5.4.6 Activation of alerts, alarms and user acknowledgement shall be captured in an event log.

3.6 System Integration, Test and Demonstration

3.6.1 The contractor shall utilize an agile type methodology with testable, operational deliveries every two weeks to the government.

3.6.2 The 45 WS will test/utilize each incremental software delivery until the next incremental delivery, and provide feedback on future development.

3.6.3 The contractor shall develop incremental test procedures for verifying completion of incremental software deliveries.

3.6.4 The contractor shall develop a test plan documenting the overall test methodology to verify completion of all requirements.

4. Delivery and Place of Performance:

4.1 Delivery of a complete functional Display System, conforming to the requirements herein, is required within 12 months of contract award. The Government is planning for the work to begin by end of FY20 or early FY21.

4.2 Places of Performance will be:

4.2.1 Government facilities on Cape Canaveral Air Force Station (CCAFS), Florida

4.2.1 Contractor location(s)

5. Background

In the current method of operation for all launches, the Launch Weather Officer (LWO) manually determines weather (lightning and specific clout types/densities) infringement on the projected flight path safety margins. The LWO visually determines if storm clouds and lightning events displayed on the monitor violate stand-off safety distances from the trajectory.

The Government requires a detailed proposal to provide the capability identified in para 2, Scope. This project will include (but not be limited to) all design, material, procurement, cyber certification, and building needed to provide a complete and usable end product to the Government. The contractor must provide all labor, materials, equipment, and transportation, required to install new equipment, then perform an operational checkout in lieu of formal

Developmental Test and Evaluation (DT&E) testing of the affected 45 SW operational systems. All work must be accomplished in accordance with all contract specifications, common work practices, and industry standards.

6. Administrative and Program Support

6.1 The contractor shall be available for program reviews and project meetings. Meeting locations are expected to be limited to CCAFS and contractor facilities.

6.2 The contractor shall schedule and facilitate a technical development team/Government kickoff meeting within 7 calendar days after beginning performance, to review and clarify, as required, technical requirements listed in section 3.0. This meeting must also identify development team and Government points of contact, to include names, email addresses, and phone numbers. Meeting may be conducted via teleconference/video conference or in person at government facilities.

6.3 Following the kickoff meeting, the contractor shall further collect, develop, and analyze project requirements and schedule and facilitate a Preliminary Design Review (PDR) meeting with the technical development team and Government within 30 days of performance start. This meeting will detail the approach to meeting all requirements, clarifying any questions/concerns discussed during the kickoff meeting, and provide a preliminary 9-month development schedule of the 12-month period of performance, including 2-week agile sprint development milestones for the duration of the project, including timelines for functional demonstrations of capabilities.

6.4 The contractor shall provide “hands-on” user training to 45 SW personnel at Cape

Canaveral Air Force Station (CCAFS) or via video conference once the final capability has been delivered but before the end of contract performance.

6.5 Contract Data

6.5.1 Data Rights. The contractor shall deliver technical data in accordance with Defense

Acquisition Regulation Supplement (DFARS) 252.227-7017. The Government will be offered options of data rights/licensing for any modifications made to the commercial data provided to and paid for by the government resulting from requirements specified with this SOO.

6.5.2 Data Deliverable Requirements. All deliverables generated in support of 45 SW’s program shall be submitted to the government in accordance with requirements specified in the DD Form 1423s, Contract Data Requirements Lists.

6.5.3 Data Preparation. Data preparation instructions are identified on individual DD Form 1664s authorized by the Department of Defense Acquisition Management System and the Data Requirements Control List (DoD 5000.19L, Vol II).

7 Deliverables

7.1 Cybersecurity

7.1.1 Overall Guidelines

7.1.1.1 Ensure all software and hardware are on the Approved Products List

(APL)/Evaluated Products List (EPL), or provide evidence of another Government approval for the use of the items.

7.1.1.2 Ensure that no Foreign Nationals were employed in the development of the software or the hardware.

7.1.1.3 Apply/implement all applicable DISA STIGs to products delivered, including but not limited to operating systems, network or storage devices, and custom software.

7.1.1.4 If any of the cybersecurity items cannot be met, it is imperative that the Contractor provide full disclosure of why the item cannot be provided

7.1.2 Artifact Deliverables per Sprint Delivery (CDRL A0002 and A0004)

7.1.2.1 Current Topology (As-Built) of the logical and physical architecture of the system.

7.1.2.1.1 Ensure topology diagram follows DISA guidelines

7.1.2.1.2 Ensure each item is clearly identified with Function Name, Hostname, Software/OS Version, Hardware Manufacturer, Hardware Make/Model, Firmware Version, as applicable

7.1.2.2 Current Data Flow Diagram

7.1.2.2.1 Using topology diagram with unnecessary information removed, use colored lines with port names and numbers from source to destination to identify data flow paths.

7.1.2.3 Current Ports, Protocols, and Services Management Spreadsheet used by the system

7.1.2.3.1 Template shall be provided by the government.

7.1.2.4 Current Hardware and Software List for contractor delivered system

7.1.2.4.1 Template shall be provided by the government

7.1.2.5 Current Applicable STIG List

7.1.2.5.1 Listing of all DISA STIGs or SRGs applicable to any hardware or software within the contractor delivered system

7.1.3 Artifact Deliverables as required to support system cyber accreditation; support to cyber activities as needed for Authorization To Connect (ATC) for each sprint of the approved sprint schedule (A0002); and at end of the contract period of performance.

7.1.3.1 Topology Diagram

7.1.3.2 Data Flow Diagram

7.1.3.3 Ports, Protocols, and Services Management Spreadsheet

7.1.3.4 Hardware and Software List

7.1.3.5 STIG Applicability List

7.1.3.6 Compliance Scan Results (using Security Content Automation Protocol ((SCAP) tool or equivalent)

7.1.3.6.1 This process can be manual

7.1.3.6.2 Must use up to date STIGs

7.1.3.6.3 FINAL DELIVERY ONLY: Must include justifications and/or mitigations for any finding that cannot be corrected.

7.1.3.7 Vulnerability Scan Results (using Assured Compliance Assessment Solution (ACAS) tool or equivalent)

7.1.3.7.1 Must use up to date plug-ins

7.1.3.7.2 Must deliver at least raw scan results

7.1.3.7.3 FINAL DELIVERY ONLY: Must include justifications and/or mitigations for any finding that cannot be corrected

7.2 Project sprint milestones:

7.2.1 Contractor shall provide a schedule of all projected sprints for government approval.

(CDRL A0002)

7.2.2 Contractor shall conduct a functional demonstration of capabilities no later than 5 business days after the conclusion of each sprint

7.2.3 Contractor shall deliver updated capabilities for government use in the intended operational environment at the conclusion of each sprint. Feedback on usability and capabilities will be provided back to the contractor for refinement.

7.2.4 At the conclusion of each sprint contractor shall deliver RMF artifacts documenting any changes to the delivered software which effect the cybersecurity posture including all requirements listed in section 7.1.2.

7.2.5 Requirements Traceability Matrix updates. The requirements traceability matrix shall be updated to document which product requirements have been satisfied and what software deliverable satisfied each requirement. (CDRL A0005)

7.3 Documentation:

7.3.1 Preliminary Design Review (PDR) Report. PDR Report documents the proposed approach to meet all requirements and implementation schedule. (CDRL A0003)

7.3.2 Contractor shall provide a schedule of all projected sprints for government approval.

(CDRL A0002)

7.3.3 Final Requirements Traceability Matrix. The requirements traceability matrix is a grid that links product requirements from their origin to the deliverables that satisfy them.

(CDRL A0005)

7.3.4 Software Version Description Document (VDD). The VDD shall take the form and contain information as identified by the Defense Acquisition University. (CDRL A0006)

7.3.5 Delivery of installation disk with source code and executable block software upgrades each sprint and final software baseline. (CDRL A0008)

7.3.6 Manuals and Instructions. Provide all user documentation, including but not limited to, software user manuals, system administrative manuals, system and software architecture documentation, and software design documentation. (CDRL A0007)

7.3.7 Cyber Security documentation. Complete and revise all cyber security documentation required by the RMF accreditation process. (CDRL A0004)

7.3.8 Develop and distribute Meeting Minutes not later than 2 business days as required in the CDRL. (CDRL A0009)

7.3.9 Bi-Monthly reports that include a summary of work performed on, and current status of, each agile sprint identified in paragraph 7.2 and related technical requirements listed in section 3.0. Reports must also summarize any issues or concerns that may negatively impact progress on any requirement identified in this SOO. (CDRL A0001)

7.3.10 Test Documentation. Provides an overall test methodology, including incremental test procedures for each sprint (CDRL A0010)

8 Task Schedule

Deliverable/Task SOO/CDRL Reference

Delivery Format Due By

Provide bi-monthly reports detailing work performed and project status

7.3.9 A0001

Via email

NLT 10th day of every other month starting after the 3rd month after performance start Contractor schedule and facilitate technical development team/Government kickoff meeting

6.2

Electronically or in person

NLT 7 calendar days after performance start

Contractor software sprint development schedule (milestones) documentation

7.2.1 A0002

Initial NLT 4 weeks after contract start and subsequent deliveries Bi- Weekly throughout development

Contractor schedule and facilitate Preliminary Design Review meeting

7.3.1 A0003

Electronically or in person

NLT 30 days after performance start

Provide Preliminary Design Review report

7.3.1 A0003

NLT 2 weeks after Preliminary Design Review meeting

Provide all Cyber Accreditation artifacts to support approved

IATT

7.1.2 A0002, A0004

Via electronic delivery

At the conclusion of each sprint

Provide draft Software Version Description Document

7.3.4 A0006

Via electronic delivery

NLT end of 5th month of contract performance

Final Delivery of Test Documentation

7.3.10 A0010

Via email NLT 10 months after contract award

Provide a Requirements Traceability Matrix 7.2.5, 7.3.3 Via electronic delivery NLT end of the 12th month of contract performance

Provide manuals and instructions

7.3.6 A0007

Via electronic delivery

NLT end of 12th month of contract performance

Provide a demonstration of how system meets all technical requirements listed in SOO

3.6 Electronically

NLT end of 9th month of contract performance

Provide functional demonstration of capabilities at the conclusion of each sprint.

7.2.2 Electronically

NLT 5 days after conclusion of each sprint

Provide all final Cyber Accreditation artifacts, Final Requirements Traceability Matrix, Software Version Description Document and User Manual

7.1, 7.3.3, 7.3.4, and

7.3.6 A0004 A0005 A0007

Electronic media

NLT end of 12th month of contract performance

Installation Disk

7.3.5 A0008

Electronic media

As required to support sprint/demonstration schedule, final NLT end of 12th month of contract performance

Meeting Minutes 7.3.8 A0009 Via email NLT 2 days after meeting

User Training 6.4 Electronically or in person

After demonstration prior to completion of performance