Loren Data's SAM Daily™

fbodaily.com
Home Today's SAM Search Archives Numbered Notes CBD Archives Subscribe
FBO DAILY ISSUE OF AUGUST 13, 2009 FBO #2819
SOURCES SOUGHT

A -- Common Operational Picture/Command and Control (COP/C2) - COP/C2 Appendices1 and 2

Notice Date
8/11/2009
 
Notice Type
Sources Sought
 
NAICS
541712 — Research and Development in the Physical, Engineering, and Life Sciences (except Biotechnology)
 
Contracting Office
Department of Homeland Security, Customs and Border Protection, Secure Border Initiative Acquisition Office, 2010 W. Ajo Way, Building 8, Tucson, Arizona, 85713, United States
 
ZIP Code
85713
 
Solicitation Number
HSBP1209RCOPCC
 
Archive Date
10/30/2009
 
Point of Contact
Mary G. McKinzie, Phone: 2023254203, Mario D. Dizon, Phone: 2023254049
 
E-Mail Address
Mary.McKinzie@dhs.gov, mario.dizon@dhs.gov
(Mary.McKinzie@dhs.gov, mario.dizon@dhs.gov)
 
Small Business Set-Aside
N/A
 
Description
COP/C2 Appendices1 and 2 THIS IS A REQUEST FOR INFORMATION (RFI) ONLY (IAW FAR 52.215-3). This RFI is issued solely for information and planning purposes; it does not constitute a Request for Proposal (RFP) or a promise to issue an RFP. Furthermore, those who respond to this RFI should not anticipate feedback with regards to its submission, other than acknowledgment of receipt – IF a request for an acknowledgement is requested by the submitter. This RFI does not commit the Government to contract for any supply or service. Customs and Border Protection (CBP) is not seeking proposals at this time. Responders are advised that the U.S. Government will not pay any costs incurred in response to this RFI. All costs associated with responding to this RFI will be solely at the interested party’s expense. Not responding to this RFI does not preclude participation in any future RFP. The Government may request additional information from specific responders. The purpose of this RFI is to determine the current state of use of Open Architecture standards and precepts for providing Common Operational Picture/Command and Control (COP/C2) capabilities. This RFI will provide market research to determine whether there is a currently available or developmental open architecture solution for CBP COP/C2 capabilities. 1.0 BACKGROUND CBP utilizes COP/C2 capabilities to provide for control and fusion of sensor data, coordination of resources, access and consolidation of information from multiple databases, and many other applications. It is envisioned that future COP/C2 applications will be built with open standards based interfaces for sensor integration, enterprise service bus tools, and presentation of individual COP/C2 services that will readily allow for replacement, interoperability, rapid integration of new technology, and competitive upgrade of capabilities. CBP anticipates in the future that developments of these capabilities will also include the granting at a minimum of Government Purpose Rights for software code, libraries, and associated build scripts (either in an open sourced computer language or a COTS based compiler language), otherwise the proprietary based source code will be provided with its associated non-COTS proprietary based compiler, developmental technical design and test artifacts in its native formats and associated tools specification to allow for software reuse, configuration control, and the minimization of proprietary elements to the lowest levels possible. 2.0 DEFINITIONS The definitions of terms used in this RFI are provided as Appendix 1 to this document. 3.0 SCOPE The system envisioned for future use by CBP will utilize open standards based interfaces and have components that are developed to provide maximum interoperability. The goal is to provide a system that can accommodate future or innovative sensors, new or updated hardware and software components, and is extensible for new and as yet unenvisioned capabilities. Proprietary capabilities will be allowed to exist in components but interfaces to and between these components must be defined and readily available to other parties. The system needs to correlate multiple disparate sources of data to provide the operators with a shared picture of activity. The user interface of the system will require user access controls and all displays should be user -configurable. The system must support Geographic Information System (GIS) standard referencing and geotagging capabilities. The system will provide the capability to access multiple data bases including those used exclusively by the law enforcement community, publicly available, and subscription databases. The system needs to be able to log, store, and replay information from sensors to forensic and law enforcement evidentiary standards. The system will need to be accreditable at multiple levels of network security to process unclassified, law enforcement sensitive and classified information. The Department of Homeland Security (DHS) has recognized and will enforce the National Information Exchange Model (NIEM) as the information exchange model for future DHS systems, such as the COP/CC2. More information can be found at www.niem.gov. 4.0 OBJECTIVE The COP/CC2 system open architecture will support modular capabilities such as track management from individual sensors, sensor control and management for multiple sensor types, track correlation and track fusion to allow target handovers and updates of track data from various sources, integration of blue force tracking, calculation of track accuracy and resource management of not only sensors but also for transitory mobile assets such as airborne and waterborne platforms, and law enforcement officers or other personnel supporting operations. The capabilities described are not intended to be all encompassing, but rather to represent the complexity of the inputs and capabilities of the COP/C2 system. The system should be able to report fault information provided by sensors and provide fault indication if no sensor data reports are provided. Sensor physical interfaces will be based on published standards from unifying bodies such as ASME, ASTM, or IEEE or from government bodies such as NIST or DOD. Logical interfaces will include SensorML or other recognized sensor interface standards. De facto standards will be allowed when no suitable published open standards exist. The system is expected to have sufficient Availability and Reliability to support operations 24 hours a day 7 days a week. It is expected that individual capabilities will eventually be available as published services in a CBP C2/COP Service Oriented Architecture. The system will have to provide interoperation between multiple sectors, and can be expected to have up to fifty users per sector at any given time. The system must be adaptable to a wide variety of physical and logical transportation layers, as network services available at all required locations may not be equivalent. Any local system instantiations should be capable of remote data backup and archiving to support robust data security and availability. The system should be extensible, scalable and interoperable to enable information sharing among a large number of local and remote nodes. Many of the services required by the system will be accessed through the DHS OneNet to utilize and leverage its enterprise services. 5.0 RESPONSE INSTRUCTIONS Responders need not be able to address ALL of the capabilities indicated above, the listed capabilities are illustrative. CBP is interested in getting information to help do cost versus capability trade-offs. Total cost of ownership will be an important factor in any future system and CBP will consider limiting capability if cost saving is significant. CBP is interested in novel and non-traditional approaches to meet the needs described above. For sources that can provide complete COP/C2 products, please answer all of the questions in the section below. For other sources that can provide elements of or modules for the COP/C2 solution, we encourage replies to the questions to the extent possible. Responses are to be provided no later than 3 September 2009. Responses are limited to 10 single sided pages, including cover or other administrative content, with 1 inch margins in Times New Roman 12 point font. A response shall consist of ONE electronic file in portable document format (PDF). The submissions will be protected from unauthorized disclosure in accordance with FAR 15.207(b), applicable law, and DHS regulations. Respondents are expected to appropriately mark each page of their submission that contains proprietary information. Please be advised that all submissions become Government property and will not be returned. All government and contractor personal reviewing RFI responses will have signed non-disclosure agreements and understand their responsibility for proper use and protection from unauthorized disclosure of proprietary information as described 41 USC 423. The Government shall not be held liable for any damages incurred if proprietary information is not properly identified. Only unclassified submissions will be accepted. 6.0 QUESTIONS CONCERNING CURRENT AND FUTURE SYSTEMS A list of questions for response is provided below. 1) What is the description of the product you have developed or are developing? Please describe the capabilities of the product with emphasis on Open Architecture attributes and on its presentation of functions and capabilities through Open Standards Application Programming Interfaces and /or message based services. The description should include definition of standards used for internal and external interfaces and a description of the software development environment. Please describe any proprietary portions of the product. 2) What are the hardware requirements to support the product? Identify all utilized proprietary hardware components. 3) What is the systems readiness level of the proposed system? Is it currently used in support of other systems, customers, or organizations, if so please describe the customers and locations of usage? The description of SRL levels being used for purposes of this RFI can be found in Appendix 2. 4) Where does the product exist within its life cycle? Is there a specific technical and software refresh cycle plan? 5) Please describe your approach to incorporation of both legacy and new sensors and services. 6) How open is your product to third party vendors and how do you incorporate those capabilities? 7) Does the product use open or commercial source code with license or patent restrictions on the government’s use of the product? For example, is there a requirement to freely distribute modified code? 8) Is the product source code available to the government? If so, what license and patent restrictions exist? 9) What is the commercial licensing model for the product? 10) Does the product require purchase of additional commercial licenses or updates (for example, Oracle Enterprise, SAP, ArcGIS) for the capability or for the development and test environment? What is the estimated cost and the unit of purchase for these licenses? 11) Does the government already hold any rights to this product or any part thereof? Please describe the level of rights and to what portions of the product they apply and the specific Government organization(s) that holds the rights. 12) Would any of the products be delivered with less than Government Purpose Rights as defined herein? If yes, please describe these limitations. 13) Is there a cost associated with obtaining at least Government Purpose Rights for the described product? If so please, provide a non-binding Rough Order of Magnitude (ROM) estimate. 14) Are there existing engineering artifacts for the described capability? Please describe, not provide, the available information. Examples include specifications, design review documents, requirements documents, etc…
 
Web Link
FBO.gov Permalink
(https://www.fbo.gov/spg/DHS/USCS/SBIAO/HSBP1209RCOPCC/listing.html)
 
Place of Performance
Address: 1300 Pennsylvania Avenue, N.W., Washington, District of Columbia, 20229, United States
Zip Code: 20229
 
Record
SN01907195-W 20090813/090812000652-18d3d8d9553d398ea128b7cddb676856 (fbodaily.com)
 
Source
FedBizOpps Link to This Notice
(may not be valid after Archive Date)

FSG Index  |  This Issue's Index  |  Today's FBO Daily Index Page |
ECGrid: EDI VAN Interconnect ECGridOS: EDI Web Services Interconnect API Government Data Publications CBDDisk Subscribers
 Privacy Policy  Jenny in Wanderland!  © 1994-2024, Loren Data Corp.