WIND-TURBINE_BAA_5NOV09.doc

Department of Homeland Security Science & Technology Directorate

Broad Agency Announcement

BAA 10 - 03

Development of Wind Turbine/Radar Modeling Tool for Assessing the Effect of Wind Turbines on Radars

Published on:

5 November 2009 Table of Contents:

Introduction

1.1 Background

1.2 Scope of Work

2 General Information

2.1 Agency Name

2.2 Agency Point of Contact

2.3 Solicitation Opportunity Title 6

2.4 Solicitation Opportunity Number

2.5 Solicitation and Response Approach

2.6 Submission Deadline

2.7 Application and Submission Information

2.8 Inquiries

2.9 Award Schedule

2.10 Funding

3 Specification of Requirements

3.1 Task Requirements: Project Management and Control

3.2 Task Requirements: Meeting, Reviews, and Conferences

3.3 Task Requirements: System Design Requirements

3.4 Lifecycle Maintenance

3.5 Training

3.6 Project Deliverables

3.7 Program Duration

4 Required Format of Full Proposal

4.1 Layout of Full Proposal

5 Evaluation and Award Criteria

5.1 Qualification Process

5.2 Evaluation Criteria

5.3 Correction of Errors

5.4 Clarification of Proposals

5.5 Amended Proposals

5.6 Offeror’s Rights to Withdraw Proposal

6 Additional Information

6.1 Applicable Documents

6.2 Organizational Conflict of Interest

6.3 Prohibition on Contracting with Inverted Domestic Corporations - 35 Representation

6.4 E-VERIFY Requirements - Employment Eligibility Verification 35

APPENDIX

A: Generic Radar Parameters

B: User Roles and Privileges

C: Radar Sites with Wind Turbines

D: Obstruction Evaluation Business Rules

E: Current Obstruction Evaluation Process

F: Data Dictionaries

G: Notional Model Block Diagram

H: Turbine Types

I: Acronyms, Abbreviations, and Terms

1. Introduction

1.1 Background

The Department of Homeland Security (DHS), Science and Technology Directorate, Special Programs Division is committed to using cutting-edge technologies and scientific talent in its quest to make America safer. The DHS Directorate of Science and Technology (S&T) is tasked with researching and organizing the scientific, engineering, and technological resources of the United States and leveraging these existing resources into technological tools to help protect the homeland. The Special Projects Division (SPD) requires technical and implementation support to assist in the development of a software system or systems to model the effects of wind turbines on radar systems, command and control systems, and ultimately operations.

During the 2006-2007 timeframe, the President signed two discrete pieces of legislation; the Energy Bill and Presidential Directive-47/Homeland Security Presidential Directive-16, which directed the development of the National Strategy for Aviation Security (NSAS). The Energy Bill called for a decrease in reliance on fossil fuels and an increase in the nation’s exploits of renewable energy with an emphasis on the use of wind turbines while the NSAS called for increasing the surveillance footprint. Since the best wind resources are often near our nation’s radar systems, this presents technological challenges.

The mission needs of DHS, Department of Defense (DoD), and National Oceanographic and Atmospheric Administration (NOAA) dictate that the nation’s radar systems remain uninhibited, to the maximum extent possible, by man-made obstructions. DHS and DoD have been charged with securing and defending the nation and part of that undertaking is accomplished through the ability to monitor non-cooperative aircraft within the nation’s airspace. NOAA is charged with, keeping citizens informed of the changing environment to include weather forecasts, severe storm warnings, and climate monitoring. All agencies rely heavily on surveillance and weather radars to accomplish their respective missions. Unfortunately, studies conducted both within the United States and within the United Kingdom reveal that wind turbines do indeed have an adverse effect on our radars.

The stakeholders’ intent is not to impede the propagation of wind turbines but to discover a means to co-exist. To that end, it is imperative that the necessary tools are developed to accurately portray the impact that the turbines will have on the nation’s radar systems. The current process, although somewhat effective, lacks the capability to allow a determination of the actual extent and degree of the impact on radars, thus lending itself to a great deal of subjectivity. The overall goal with this effort is to develop a sound, unimpeachable impact assessment methodology that eliminates the subjectivity inherent in current procedures.

The main users of this system will be management personnel, engineers, technical analysts, and operations personnel from DHS, DoD, and NOAA. Other users may include engineers from the Federal Aviation Administration (FAA) and representatives from the Wind Industry.

1.2 Scope of Work

The contractor shall perform the tasks necessary to meet the requirements listed in Section 3.3 for the design, development, verification, validation, and implementation of a comprehensive system to accurately model the effects that wind turbines have on radars.

The requirements that must be designed and implemented to develop a wind turbine/radar interactive modeling tool include:

· Designing the user interface

· Modeling the radars

· Modeling the wind turbines

· Modeling the Radio Frequency (RF) propagation environments

· Modeling Command and Control (C2) systems performance

· Implementing the design

· Performing system verification

· Testing the implementation

· Performing system validation

· Training

· Developing documentation

· Verifying software release procedures

· Verifying hardware release procedures

· Deployment planning

Within this request are design goals that shall be modified to requirements at contract award based upon the contractor’s proposed design.

All deliverable documentation, including Contract Data Requirements List (CDRL) items, briefing packages, and meeting minutes, shall be in editable format utilizing the Microsoft Office Suite of tools.

2 General Information

2.1 Agency Name

Department of Homeland Security Science and Technology Directorate

Special Programs Division

Washington DC 20528

2.2 Agency Point of Contact

Contracting Officer: Susan Eicher

Email Address: susan.eicher@dhs.gov

2.3 Solicitation Opportunity Title

Development of Wind Turbine/Radar Modeling Tool for Assessing the Effect of Wind

Turbines on Radars

2.4 Solicitation Opportunity Number

BAA 10-03

2.5 Solicitation and Response Approach

The Department of Homeland Security (DHS) Science and Technology (S&T) Directorate will not issue paper copies of this announcement. DHS S&T reserves the right to select for award and fund all, some, or none of the Full Proposals received in response to this solicitation. No funding for direct reimbursement of proposal development costs will be allowed. Technical and Cost Proposals (or any other material) submitted in response to this announcement will not be returned. However; depending on the markings on the proposal, DHS S&T will adhere to FAR policy on handling source selection information and proprietary proposals. It is the policy of DHS S&T to treat all proposals as sensitive competitive information and to disclose their contents only for the purposes of evaluation. Offerors are to provide unclassified proposals. Documents containing sensitive information that are not suitable for uncontrolled public dissemination should be marked “For Official Use Only” (FOUO). When transmitted electronically, FOUO proposals should be sent with password protection.

Award may take the form of a contract or other transaction (OT) agreement. In the event an Offeror or subcontractor is a Federally Funded Research and Development Center (FFRDC), Department of Energy National Laboratory, or other Federally funded entity, DHS S&T will work with the appropriate sponsoring agency to issue an interagency agreement pursuant to the Economy Act (31 U.S.C 1531) or other appropriate authority. Depending on the nature of the Full Proposals received, DHS S&T will also consider awarding a grant or cooperative agreement. Therefore, the applicable laws and regulations governing the legal vehicle used for award will depend on the legal vehicle chosen by DHS S&T.

2.6 Submission Deadline

Full Proposals: No Later Than 4 PM EST: 5 January 2010

2.7 Application and Submission Information

To submit a Full Proposal Package, email to ST.SpecialPrograms@dhs.gov.

Potential Offerors are also requested to deliver in person 12 hard copies of the Full Proposal.

Deliveries must be pre-coordinated with susan.eicher@dhs.gov no later than 2PM EST, 4 January 2010.

No classified Proposals (or portions of proposals) will be accepted.

The Government may use selected support contractor personnel to assist as technical advisors and/or non-voting evaluators during the evaluation process and to support administrative functions pertaining to the receipt and evaluation of any ensuing proposals from this announcement. These support contractors will be bound by appropriate non-disclosure agreements to protect proprietary and source-selection information. They will not be permitted to release any source-selection information to third parties, including others in their organization.

2.8 Inquiries

The Government may engage in exchanges with offerors in accordance with FAR 15.306. Discussions with offerors will be based on the Government’s assessment of the offerors’ proposal and conducted for the purpose of maximizing the Government’s ability to attain best value, based on the requirement and evaluation factors set forth in this solicitation.

Submit any questions concerning this announcement no later than 20 November 2009 to ST.SpecialPrograms@dhs.gov. Answers to all questions will be posted on https://fbo.gov.

2.9 Award Schedule

2.10 Funding

Funding is subject to official fiscal appropriation and availability.

3 Specification of Requirements

3.1 Task Requirements: Project Management and Control.

The Offeror shall:

· Provide program management (i.e. project planning, project staffing, project control and reporting)

· Designate a Program Manager (PM) who is responsible for integrating and maintaining the total Offeror effort as described in this SOW and the Program Management Plan (PMP)

· The Offeror’s PM shall be prepared at all times, given reasonable notice, to present and discuss with the DHS Technical Representatives the status of contract activities

· Establish a Risk Management Plan

· Provide and conduct on-going risk management activities during the System Development

· Assess the impact of risks and costs on successful completion of the work effort by relating risks and costs to schedule and technical performance

· Establish a Software Configuration Management Plan

· Establish a Quality Assurance Plan

· Provide Financial Control and Contract Management

· Produce a Work Breakdown Structure (WBS) for tasks, cost, schedule, milestones, and effort that reflect and track the delivery of the system as specified by this Broad Agency Announcement (BAA)

· Implement methods and metrics for assessing the schedule, technical performance of the work, cost, and risks of this project

· Implement tools to monitor and control the progress and performance of this effort

· Provide an assessment of the project progress and/or issues at the Project Management Reviews (PMR), Technical Interchange Meetings (TIM), and via the Project Progress, Status, and Management Report (PSMR) which will include the status of the execution of the PMP

· Employ a schedule performance measurement and reporting system and ensure the management methods and procedures used provide visibility into and timely progress reporting on all contracted efforts for internal management and Government oversight purposes

· Implement tools to effectively monitor and control the progress and performance of this effort and provide the Government with an assessment of project progress and/or issues at PMRs, TIMs, and via the PSMR

· Use a schedule performance measurement and reporting system

· Maintain this system and related procedures throughout this contract

· Ensure the management methods and procedures used provide visibility into, and timely progress reporting on, all contracted efforts for internal management and Government oversight purposes

· Report the status of the execution of the PMP in the PSMR

3.1.1 Project Management Plan and Project Control.

The contractor shall submit a Program Management Plan (PMP) (CDRL 001), and shall revise such plan as necessary or required. A final PMP is due 20 days after the date of contract award. Upon Government approval, the contractor shall execute this plan without deviations. If deviations are warranted, the contractor shall obtain Government approval of said deviations from the PMP, and shall incorporate these approved changes immediately into the PMP or at the next revision of the PMP, at the Government’s discretion. The PMP must specify in the PMP the prime contractor and major subcontractor(s) management, organization, authority, responsibility, controls, testing program, methods, and procedures as they apply to the execution of this effort. The contractor shall detail in the PMP its methodology to ensure that the program management requirements set forth in this BAA are met.

The contractor shall implement tools to effectively monitor and control the progress and performance of this effort and provide the Government with an assessment of project progress and/or issues at Program Management Reviews (PMRs), Technical Interchange Meetings (TIMs), and via the Project Progress, Status, and Management Report (PSMR) (CDRL 003) and the Software Development Status Report (SDSR) (CDRL 008). The contractor shall use a schedule performance measurement and reporting system and maintain this system and related procedures throughout this contract. The contractor shall ensure the management methods and procedures used provide visibility into, and timely progress reporting on, all contracted efforts for internal management and Government oversight purposes. The contractor shall report the status of the execution of the PMP in the PSMR.

The DHS Technical Representatives will provide written approval to move forward on activities included in the Project Management Plan. If there are modifications or proposed additions to the Plan, the contractor must request prior written approval from both the DHS Technical Representatives and Contracting Officer.

3.1.2 Software Development Plan.

The contractor shall develop a Software Development Plan (SDP) (CDRL 010) that outlines the major activities, milestones, processes, and software development methods and approaches that will be used for the software development portion of this effort.

3.1.3 Risk Management Plan.

The contractor shall develop a Risk Management Plan (RMP) (CDRL 002) that outlines the risks identified in the software project by utilizing a risk analysis method that provides risk identification, risk factors, risk assessment, risk prioritization, risk management strategies, risk resolution, and risk monitoring techniques. The contractor shall document the contingency procedures for each area of risk on the project.

3.1.4 Configuration Management Plan. The contractor shall develop a Software Configuration Management Plan (SCMP) (CDRL 021) to document the software configuration management activities, how they will be accomplished, and what resources are required.

The contractor shall establish and implement a system to identify, define, control, and verify software configuration. The system must include, but not be limited to:

· Identification of software configuration items

· Control and implementation of change

· Recording and reporting change and problem report implementation status

· Conducting configuration audits

· Review and approval cycles as well as approval authority

3.1.5 Quality Management Plan.

The contractor shall develop a Quality Management Plan (QMP) (CDRL 007) to identify any standards, processes, and procedures that will apply to this project.

The contractor shall conduct quality inspections in accordance with the QMP and provide documentation that verifies the project follows established standards, processes, and procedures; and that the project produces the required internal and external (deliverable) products.

3.2 Task Requirement: Meetings, Reviews, and Conferences.

The contractor shall plan and host the following:

· Post Award Conference

· Program Management Reviews

· Preliminary Design Reviews

· System Verification Reviews

· Critical Design Review

· Risk Meetings

· System Working Group Meeting

· Technical Interchange Meetings

· Test Planning Meetings in support of system/software development and test and evaluation projects

· Project Closeout Meeting

The Government will review contractor documents and provide comments within 30 days of their receipt.

3.2.1 Post Award Conference.

The contractor shall conduct a project start up meeting with the Government’s team to review the contract, introduce Offeror and Government staff, review and approve a comprehensive PMP, and identify and prioritize initial activities. The Conference Agenda (CDRL 005) must be submitted to the Government no later than 10 days after contract award. The Conference Minutes (CDRL 006) and other applicable documents must be submitted to the Government no later than 5 days after the conference is held.

3.2.2 Project Management Reviews.

The contractor shall host bi-monthly Program Management Reviews (PMR) throughout the lifecycle of the project to provide the Government with periodic progress reviews. The entire project will be reviewed at each PMR. The PMP must provide the outline for the agenda and review each aspect of the project. The contractor shall review plans for accomplishing project milestones. The contractor shall address the following:

· Project performance as related to technical, cost, and schedule performance

· Accomplishments since the last PMR

· Project baseline management

· Expected accomplishments prior to next PMR

· Program risks and risk mitigation efforts

The initial PMR can be held during the Post Award Conference (PAC) to demonstrate the program management tools that will be used throughout the life of the project.

The frequency of the PMRs may be increased or decreased at the discretion of the Government depending on the Offeror’s performance.

3.2.3 System Requirements Review.

Within 30 days after contract award, the contractor shall host a System Requirements Review (SRR) to assess the system requirements identified in the contract Statement of Work. During the SRR, the contractor and the Government will review the requirements line by line to evaluate whether the requirements are fully defined and understandable. The review will afford the contractor the opportunity to gain a clear understanding of the requirements and to address any potential issues or risks.

During the SRR, the requirements approved by the Government will be captured in the System Requirements Specification (SRS) (CDRL 012) document. The contractor shall submit a SRR Summary Report (CDRL 009), 10 days after completion of the SRR. The report shall include any assumptions and/or issues as well as an established plan to follow-up on these items. The Government’s approval of the SRS, the SDP and the SRR Summary Report will finalize and formalize the requirements of the systems and subsystems.

The SRR may be held in conjunction with the PAC, if approved by the Contracting Officer.

3.2.4 Functional Design Review.

The contractor shall host a formal Functional Design Review (FDR) of the system. The FDR shall address the overall structure of the system from a functional viewpoint. The FDR shall describe the logical system flow, data organization, system inputs and outputs, processing rules, and operational characteristics of the system from the user’s viewpoint. The contractor shall prepare a draft Functional Design Specification (FDS) (CDRL 004) document for review and approval. Prior to entering the FDR, the Government must approve the System/Subsystem Specification (SSS) (CDRL 013).

The FDR is considered complete when:

· Minutes and the review summary report are published

· All Change Requests (CR) are classified with “Approved for current release,” “Immediate change,” “Deferred,” or “Disapproved with explanation” resolution status

· The Government approves the FDS, Requirements Traceability Matrix (RTM) (CDRL 011), SRS, and accepts the FDR Summary Report (CDRL 014)

3.2.5 Preliminary Design Review.

The contractor shall conduct a formal Preliminary Design Review (PDR) to assess the basic design approach for each Configuration Item (CI). During the PDR, the contractor shall describe all design changes made with respect to the original requirements disclosed in the SRR Summary Report and to provide rationale for the changes as well as identify any derived requirements. The contractor shall provide preliminary details of its plans for developing the required software to meet contract requirements. The contractor shall discuss the implementation strategies, sequence of events, and resources.

The PDR shall focus on:

· Evaluating the progress, consistency, and technical adequacy of the selected top-level design and test approach

· Analysis of the compatibility between software requirements and preliminary design

· Identifying design assumptions, constraints, and issues The PDR shall be considered complete when:

· Minutes and the review summary report are published;

· All CRs are classified with “Approved for current release,” “Immediate change,” “Deferred,” or “Disapproved with explanation” resolution status

· The compatibility of the physical and functional interfaces is established

· The Government approves the SRS, FDS, and accepts the PDR Summary Report (CDRL 015).

Upon completion of the PDR and before the Critical Design Review (CDR), the contractor shall develop an Interface Control Document (ICD) (CDRL 031) to detail all possible inputs to and all potential outputs from the system for users of the system. The document should also illustrate all hardware and software interfaces and all data exchanges between the interfaces. The system should be briefly summarized with special emphasis on the functionality related to the interface.

3.2.6 Critical Design Review.

The contractor shall conduct a formal Critical Design Review (CDR) to assess whether a sufficient level of detail has been provided to allow detailed design to commence. The purpose of the CDR is to determine the acceptability of the detailed design, performance, test characteristics, and the adequacy of support documents. Additionally, the CDR determines whether the critical design satisfies cost, schedule, and performance requirements, and establishes detail design compatibility among all the Computer Software Configuration Items (CSCI).

The CDR shall focus on:

· Evaluating the detailed relationship between modules

· Mapping the detailed design back to the functional description

· Identifying design assumptions, constraints, and issues The CDR shall be considered complete when:

· Minutes and the review summary report are published

· All CRs are classified with “Approved for current release,” “Immediate change,” “Deferred,” or “Disapproved with explanation” resolution status

· Formal identification of specific software documentation that will be released for coding and testing is established

· The Government approves the Preliminary Design Documents, Database Design Description (DBDD) (CDRL 025), System/Software Test Plan (SSTP) (CDRL 018), System/Software Design Description (SSDD) (CDRL 022), ICD, and accepts the CDR Summary Report (CDRL 016)

The Government deems it acceptable for the contractor to conduct incremental CDRs if it better facilitates the contractor’s approach.

3.2.7 Test Readiness Review.

The contractor shall conduct a formal Test Readiness Review (TRR) to demonstrate to the Government an assessment of the system’s readiness for testing and that the system has reached a degree of completeness. The scope of the TRR is to inspect the test products and test results from the completed test phase for completeness and accuracy, and to verify that test procedures, test cases, test scenarios, test scripts, environment, and test data have been prepared for the next test phase.

The TRR will be considered complete when:

· Minutes and the review summary report are published

· All CRs are classified with “Approved for current release,” “Immediate change,” “Deferred,” or “Disapproved with explanation” resolution status

· The Government approves the System/Software Test Description (SSTD) (CDRL 019), and accepts the TRR Summary Report (CDRL 017)

· All discrepancies determined by the Government to be within the scope of the contract have been corrected.

3.2.8 Implementation/Software Release Readiness Review.

The contractor shall host an Implementation/Software Release Readiness Review (I/SRRW) to conduct a formal inspection for the purposes of ensuring the system/software has been developed and tested, and is ready for release to the Government.

During the I/SRRW, the Government will ensure that priorities, assumptions, constraints, issues, and risks are identified and addressed. Any issues that are raised as a result of the I/SRRW must be satisfied prior to declaring the system as operationally ready.

Prior to the contractor’s conduct of the I/SRRR, the Government must approve all of the following documents: System/Software Installation Plan (SSIP) (CDRL 024), Software Support Transition Plan (SSTrP) (CDRL 028), Software User’s Manual (SUM) (CDRL 026), Software Version Description (SVD) (CDRL 027), System Maintenance Plan (SMP) (CDRL 029), Software Product Specification (SPS) (023), Operator’s Manual (OM) (CDRL 033), and System/Software Test Report (SSTR) (CDRL 020).

The contractor shall submit an I/SRRW Summary Report (CDRL 032) for Government approval. The Government representative’s signature on the report signals Government acceptance of the end product. The report shall address at a minimum, the following information:

· Issues raised during the I/SRRW

· Issue Resolution

· Unresolved Issues

· Recommendations

· Risk Mitigation Strategies

· Assumptions

· Constraints

3.2.9 Project Closeout Meeting.

At the conclusion of the project, the contractor shall host a Project Closeout Meeting. The contractor shall prepare a Post Implementation and Evaluation Report (PIER) (CDRL 030).

3.3 Task Requirement: System Design Requirements.

The overall system design shall meet the immediate need to support obstruction evaluation assessments as outlined in Appendix E, while remaining open to future requirement capabilities such as addressing mitigation strategies as well as providing wind industry partners a “first-look” assessment tool.

· This tool shall assess the impact that wind turbines have on radar and C2 performance. Emphasis shall be placed on Probability of Detection (Pd) degradation (throughout the volume of coverage, including radar shadowing as it relates to the near field and far field antenna patterns), false target analysis, and track performance.

· In addition to wind turbines, this tool shall model other obstruction types, to include, but not be limited to the following: buildings, towers, antennas, tanks, poles, etc.

· The tool shall be designed to be readily adaptable to migrate to an application that will serve as an engineering analysis tool and support radar optimization studies, explore wind turbine placement/mitigation solutions, and investigate radar modifications.

The system shall provide the capability to perform both low and high fidelity levels of analysis.

· The low fidelity model shall provide the analyst a “first-look” radar impact assessment.

· The high fidelity model shall provide an in-depth analysis capability with respect to radar and C2 performance. This model shall characterize the extent/degree of impact to key radar and tracking parameters.

The contractor shall implement analysis techniques for both the low and high fidelity modeling processes. Each analysis technique shall fully characterize the impact to radar and C2 performance. The contractor shall include the capability to perform a Monte Carlo type analysis.

The contractor shall design the model to facilitate changes to: wind-turbine designs, wind-farm designs, radar hardware/software designs, target characteristics, RF atmospheric propagation, terrain databases, cultural databases, and other components that enable model flexibility.

The contractor shall provide output products with a fidelity that corresponds to the radar(s) and C2 system design characteristics.

The contractor’s software shall be developed utilizing Capability Maturity Model Integration (CMMI) Level 3 approved software methodologies; this includes conducting requirements analysis, functional and design requirements, requirements definition and attributes.

The contractor shall design the system to interface with the OE/AAA system database (currently Oracle 11g, moving to PostGRES, PostGIS, and PostXML) to perform initial data load, accept updates, and push analysis results along with other relevant information. More detailed technical specifications pertaining to the OE/AAA system will be made available upon contract award.

The contractor shall utilize Government off the shelf (GOTS) software where advantageous.

3.3.1 Key Performance Requirements.

The tool shall be designed to process a low fidelity project within 15 minutes and a high fidelity project within 8 hours. The contractor shall provide the capability to process up to 8500 turbines per project.

3.3.2 Model Accuracy Requirements.

The contractor shall develop a model that provides accuracies as follows:

· PROBABILITY OF DETECTION: Throughout the volume of coverage, within a radar’s coverage cell size (e.g., 1/16th nmi range, 1.4 deg azimuth, and 500 ft altitude), the low-fidelity model output data shall compare to real-world data within 10% Pd (90% confidence interval)). The high-fidelity model shall compare within 5% Pd (90% CI). The statistical comparative analysis shall include an appropriate two population binomial procedure (π1 – π2), (i.e., real-world “hit/miss” data versus model output “hit/miss” data). This Pd requirement shall apply to multiple points within the radar model to include the signal processor and radar data processor.

· FALSE TARGETS (Clutter): Throughout the volume of coverage, comparing 10 scan averages, the low-fidelity model must compare to real-world data within 20 false targets (90% CI). The high-fidelity model shall compare within10 false targets (90% CI). The statistical comparative analysis shall include an appropriate two population mean procedure (µ1 – µ2). This false target requirement shall apply to the radar data processor output.

· C2 TRACKING PERFORMANCE: With emphasis on non-cooperative (search-only) targets, key performance parameters, such as track acquisition, tracking continuity, track coast, track re-acquisition, and track positional accuracies, must be assessed against real-world C2 system data. In general, using a two-population statistical test (µ1 – µ2), the low fidelity model data shall demonstrate accuracies within 10% of the real-world data (90% CI). The high fidelity model shall demonstrate accuracies with 5% (90% CI).

· In-phase/ Quadrature-Phase (I/Q) DATA GENERATION: Throughout the volume of coverage, I/Q predictions shall exhibit the following accuracy: Over a typical wind farm, a high fidelity model shall be within 1 dB (I/Q values). An appropriate two-population test (µ1 – µ2), real-world versus model, shall be accomplished (90% CI).

· WEATHER SIMULATION: Throughout the volume of coverage, where wind-turbines have potential to influence weather processing, using a “LVL II” I/Q comparative analysis (i.e., real world versus model data), using an appropriate statistical analysis (µ1 – µ2).

· The low-fidelity model shall meet the following accuracy requirements (90% CI):

· Location, placed within one bin (1 km, 1 deg azimuth, 1 deg elevation)

· Reflectivity, within 8 dbZ for each bin

· Radial velocity, within +/- 5 m/s for each bin

· Spectrum width, within +/- 5 m/s for each bin

· The high-fidelity model shall meet the following accuracy requirements:

· Location, placed within one bin (0.25 km, 0.5 deg azimuth, 1 deg elevation)

· Reflectivity, within 5 dbZ for each bin

· Radial velocity, within +/- 3 m/s for each bin

· Spectrum width, within +/- 3 m/s for each bin

3.3.3 Radar Model Requirements.

The contractor shall:

· Design the application to model a radar at two levels of complexity to support the low and high fidelity level of analysis and corresponding products.

· At each primary processing stage within the high fidelity model, the application shall have the capability to inject/extract data (see Appendix G, “Notional Block Diagram”).

· Provide the capability to model overlapping radars and assess cumulative impacts to probability of detection and C2 system track performance.

· Design the software to have the ability to maintain a radar database. This database must include the radar type parameters and settings as well as site-specific radar parameters.

· Provide the capability to allow user updates for radar system upgrades and design changes, as well as site-specific parameter changes.

· Provide the ability to store the result of user-defined characteristics for use during future modeling sessions.

· Design the software to model a generic radar for low fidelity analysis based on the user-definable input characteristics as described in Appendix A.

· Develop more detailed radar models for high fidelity analysis based on the user-definable input characteristics as described in Appendix A. The detailed models should be available for the radar types listed below:

High Priority

ARSR 1/2 (include CD2 and ACC)

ARSR 3 (include Smart Radar)

ARSR 4

AN/FPS-20 (include CD2 and ACC)

CARSR

ASR-11

Medium Priority

ASR-8

ASR-9

WSR-88D

AN/FPS 117

AN/FPS 124

Low Priority

GTACS

TARS

TDWR

CASA

MPAR

· Develop the model to import actual I/Q data, process through the radar model, and export into required output products. The application shall accept formats recorded with standard FAA recording tools and weather radar recorded I/Q data. The application shall have the capability to superimpose model derived wind turbine I/Q values onto the actual I/Q data sets.

· Develop the application to model I/Q data, process through the radar model, and export in required output products. This will include search and weather radar I/Q.

· Develop the model to import real-world level 2 data from weather systems to assess change in level 2 values due to wind-turbine influence.

3.3.4 Wind Turbine Model Requirements.

The contractor shall:

· Design the application to model wind turbines at the required level of complexity to support both low and high fidelity analysis.

· Provide the capability to access data from various databases of turbine projects (existing, approved, and proposed projects) and emulate the cumulative wind turbine environment for a radar site.

· Provide the capability to accurately model wind turbines to include the following characteristics:

· Tower size, shape and construction (tubular or lattice) including material layup and internal/external coating (i.e., passive radar absorptive material).

· Nacelle construction

· Blade-size, shape, pitch, aspect and rotational speed

· Composition of the blade including material layup and internal/external coating.

· Provide the capability to accurately model different turbine types using Computer Aided Design (CAD) input data.

· Create an aspect versus Radar Cross Section (RCS) look-up database to employ with the low and high fidelity models.

· Provide the capability to model wind turbines with, without and varying wind characteristics to include speed and direction.

· Design the model to approximate the operating parameters of existing turbines (i.e., wind speed and direction) and simulate the expected operating parameters of proposed wind turbines given the available environmental data.

· Provide the capability to model a total aggregate depiction of a wind-turbine development.

· Design the software to characterize the change in radar performance between existing/approved wind turbines versus the addition of wind turbines under study.

3.3.5 Environment Propagation Model Requirements.

The contractor shall:

· Design the application to model the RF propagation/environment at the required level of complexity to support both low and high fidelity analysis.

· Design the capability to provide a realistic model of the environment/propagation with respect to radar operation at a defined location; to include:

· Capability to import/model terrain, survey data and cultural data (Digital Terrain Elevation Data (DTED) Level 1, or 2)

· Capability to model refraction (standard, superrefraction, subrefraction and ducting).

· Capability to model multipath and multi-bounce.

· Capability to model diffraction over terrain and around obstructions such as wind turbines or other cultural structures such as towers and buildings

· Model effective clutter environment with respect to the radar, as well as provide capability to import/process site specific recordings containing clutter environment

3.3.6 User Interface Requirements.

The contractor shall:

· Design a graphical user interface (GUI) to allow users access to the system.

· Include the capability to allow user access via the Web.

· Limit access to certain screens and/or options as identified by the user roles defined in Appendix B.

· Design a GUI mock-up/prototype of all user interface screens for Government approval prior to implementing.

· Design the software to be accessible and responsive to multiple users at multiple locations.

· Design the software to accommodate the following:

· Execution/product generation must meet user timeline requirements (i.e., Obstruction Evaluation/Airport Airspace Analysis (OE/AAA) timelines)

· Adaptable levels of access for different user types including access to radar, site, wind turbine, cultural data, and products

· Design the application to input the characteristics of one or more wind turbines. This would include dimensions, materials, and model specific characteristics. In addition, this data set would include the location and Mean Sea Level (MSL)/Above Ground Level (AGL) height of the wind turbines.

· Design the capability to input a basic structure (building, tower, tank, etc.) in three dimensions and model corresponding coverage loss. This structure will be linked to one or more cases.

· Design the application to use current user databases that contain radar type, radar site, basic atmospheric refractive models, and wind turbine information. The application should interface or store this information for repeatable scenario implementation.

3.3.7 External Industry/Guest Account.

The contractor shall:

· Provide a limited functionality account to provide an external user (such as a wind energy project developer) with a limited content report using the low fidelity modeling capability.

· Provide a means to develop, store, and verify a login profile for every external user including name, company, position/title, telephone number, address, e-mail address, and any additional contact information. This information shall be stored so that an external user can log in without developing a new profile every time.

· Use a means of validation of the above information before granting system access such as e-mail based account activation or other such mechanism.

· Provide a means of performing a single analysis of a possible wind turbine development containing multiple turbines.

· Provide a capability to enter wind turbine identification, location, type, tower height, and blade-tip height for each prospective turbine in the proposed development. This information shall be not permanently stored, and shall not be accessible by another user.

· Provide a means to upload information using a standard file format. (For example, file format could be a tab or comma separated variable text file, or a Microsoft Excel spreadsheet.)

· Provide the user an estimated processing and report delivery time.

· Ensure that the guest account shall be given the lowest processing priority.

· Provide user access to the Wind Turbine Database to determine whether type exists in library. The Offeror shall provide a means to identify closest match selection to the desired tower height and blade-tip height if the exact turbine is not already present in the database.

· Identify whether the proposed project will interfere with Long Range Radar (LRR), Air Traffic Control (ATC) radar and/or WSR-88D system or systems and identify the interfering system or systems. When a specific system is identified, Points of Contact (POC) shall be identified for further analysis.

· Provide a means of identifying which individual turbines are possibly interference sources out of the entire proposed development.

· Ensure that the tool has the capability of adjusting the parameters of turbine blade tip height and tower height to determine if interference can be mitigated through these simple planning means.

· Provide a means to download a report of this analysis in the Portable Document Format (*.pdf). This report shall include project information entered by Guest, and preliminary analysis results.

3.3.8 Obstruction Evaluation Requirements.

The contractor shall:

· Design the software to support the current OE/AAA process (see Appendix E).

· Provide the capability to import the OE/AAA case data as defined in the sample format in Appendix F.

· Design the software to comply with the established business rules, as outlined in Appendix D, currently in use by the OE/AAA assessment process.

· Ensure that the naming convention for case or case projects is consistent with OE/AAA naming convention. The application must provide a link between OE case numbers and the project or evaluation naming convention.

· Design the software to pre-process the imported case list and perform a radar line-of-sight (RLS) determination. The Offeror shall consider the following in the process:

· For cases outside RLS, provide a summary of information for each case and ability for the technician to change the status to “minimal impact”

· For cases within RLS, provide a list of cases with a summary, potentially impacted radars, and a visual depiction of each project.

· Check the cumulative wind turbine or structure location database and perform a duplicate check of cases under study and associate other duplicates as prior case studies.

· Provide a method for users to associate multiple cases and process, analyze, and create products as a project.

· Account for mission/radar site and notify appropriate user(s).

· Design the capability to identify wind turbines by OE status, associate a distinct color and/or symbol for each type in corresponding output products, and provide for specific user types to change the status of one or more wind turbines in the database.

· Existing

· Approved

· Proposed

· Project under study

· Design the capability for specific user types to change the OE status of cases. Examples include:

· DET-DNE-PSR-Removed

· DET-DNE-PSR-Sent

· EVL-Exam

· OLD

· TER-ABA

· TER-Sup

· TER-PSR

· TER-MIS

· DNE - Does not Exceed

· DNE-EXT - Extension was requested

· DNE-Fasttrack - closed out early did not exceed Part 77 standards

· DNE-PSR-Sent - Project Status Report send to proponent

· DNH - Determination of No Hazard

· DPH - Determination of Presumed Hazard

· DOH - Determination of Hazard

· M&L - Marking and Lighting Determination

· NPH - Notice of Presumed Hazard

· EBO - Exceeds but Okay

· NNR - No Notice Required

· WRK - Work

· Design the capability for specified user types to assign an impact level of minimal, moderate, or significant to a case or group of cases and allow users to update/change this level as the project is processed through completion.

· Design the capability to establish suspense dates, after cases are imported, to process the analysis products, complete the technical and operations reviews, and complete final processing.

· Design the capability to extract workload summaries and status by user or user type as well as identify late projects by suspense dates.

· Design the capability for users to upload reports or supporting documentation.

· Design a “Process Tracking Tool.” All cases and case projects shall be tracked and accessed throughout duration of their respective analysis periods and archived after completion for future reference.

· Include the capability to maintain configuration control (check-in/check-out) of data, analysis, and products.

· Include the capability for users to mark products at the appropriate classification level.

· Design the capability to notify users when case(s) or project status has changed and ready for next level of review (i.e., Once a wind farm project technical assessment is marked “completed”, an email and/or notification in the system will alert the associated users for the next level review (operational assessment)).

3.3.9 Output Requirements.

The contractor shall:

· Design the application to automatically generate comprehensive presentation quality reports with specific details regarding each analysis. These reports shall be tailored to meet various end-user (see Appendix B) requirements.

· With consideration of the modeled wind farm and radar site environment, provide output products that depict the impact to radar performance over the volume of radar coverage. The Offeror shall design the output to include:

· Impact to performance, presented with respect to the radar output of the signal and data processors (target/track) and the C2 system at the output of the tracker.

· At a minimum, radar performance criteria should include Pd (or target detection) false targets, target accuracy, and track quality/accuracy.

· Provide visual and tabular output products in a modern and intuitive manner to include 2D, 3D and numerical. This should include visualization of the end-state coverage volume reduction and the associated impacts or degradation to existing radar coverage, terrain, geographical boundaries, cultural data, turbine layout, and geotyping output files to include Keyhole Markup Language (KML), Shape Files (SHP) and Image Files (IMG).

· Provide the capability to compare radar performance with/without the presence of wind turbines. The intent is to provide operational users output products that illustrate radar impact before, and after wind-turbine placement, as well as the net difference.

· Provide the capability to conduct a comparative analysis to determine the probability of dropping tracks at the sensor output (where applicable).

· With consideration of the modeled wind turbine(s) and multiple radar sites, provide the capability to determine the impact to cumulative performance over the volume of composite radar coverage. The output shall illustrate:

· Impact to radar performance, presented with respect to the cumulative environment at the user’s C2 system.

· At a minimum, radar performance criteria, including Pd (or target detection), false targets, target accuracy, and track quality/accuracy.

· Weather radar performance criteria, to encompass impact to reflectivity, radial velocity and spectrum width.

· Impact to multiple sensors where applicable, with/without the presence of wind turbines.

· Accurately depict extent/degree of shadowing regions.

· Design the output to provide a cursor based distance-measuring tool.

· Design the output to provide an interactive mouse-over tool.

· Design the software to have the capability to depict theoretical turbine locations in latitude and longitude format.

· Design the software to display products for low and high fidelity models.

· For weather radars, through graphical and tabular presentations, show the amount of turbine penetration into vertically stacked cells (1 km, 1 deg azimuth, and 1 deg elevation), for each weather radar range cell, for all azimuths and elevation scan angles that are influenced by wind-turbines (e.g., Volume Coverage Pattern 12 (VCP12) for WSR-88D).

· For weather radars, show the average turbine vertical penetration into vertically stacked cells (1 km,1 deg azimuth, and 1 deg elevation), within a user-defined coverage area.

· For weather radars, provide the amount of shadowing/reduction of radar signal, on a cell basis (1 km, 1 deg azimuth, and 1 deg elevation).

· Provide a graphical depiction of range cells where turbines are within Radar Line-of Sight (RLS).

· Provide a graphical depiction of model-generated weather radar based products (reflectivity, mean radial velocity, and spectrum width) that include the resultant simulated wind turbine impacts on the products.

· Provide model-generated I/Q data in conformance to the applicable weather radar ICD.

· Provide a graphical depiction of the weather radar base products (reflectivity, radial velocity, and spectrum width) from model-generated I/Q data. This shall include the input I/Q data (whether from weather radar observed I/Q or model-generated) and the resultant simulated wind turbine impacts on the I/Q data. The output I/Q data shall conform to the weather radar ICD. In addition, this process shall have the capability to model and insert the turbine effects on weather radars into archived Level II data for play back.

3.3.10 Tracking Model Requirements.

The contractor shall design the application to emulate the primary C2 systems in a multiple radar environment. The primary C2 systems include the Air Marine Operations Surveillance System (AMOSS) at the Air Marine Operations Center (AMOC), and Battle Control System-Fixed at the Air Defense Sectors (ADS). The C2 analysis shall characterize the degradation of track performance within the 3D airspace to include track quality, initiation, drop and accuracy.

3.3.11 System/Software Verification Requirements.

The contractor shall:

· Develop, document, and maintain a comprehensive verification and certification System/Software Test Plan (SSTP)(CDRL 018)…