Inactive

***OADR Enhanced Safet Services Round 1 Responses are published as of September 2, 2022. Open Architecture Data Repository (OADR) – Enhanced Safety Service Request for Information (RFI) The Satellite ... ***OADR Enhanced Safet Services Round 1 Responses are published as of September 2, 2022. Open Architecture Data Repository (OADR) – Enhanced Safety Service Request for Information (RFI) The Satellite and Information Acquisition Division (SIAD) of NOAA's Acquisition and Grants Office (AGO) is seeking information on behalf of the National Environmental Satellite, Data and Information Service (NESDIS), Office of Space Commerce (OSC) on existing or planned commercial Space Situational Awareness (SSA) services for tracking objects orbiting Earth and related capabilities that will be available in the 2022 through 2024 timeframe. This Request for Information (RFI) is for informational purposes only; it is not a request for proposals or a solicitation for a contract or grant award and it does not obligate the Government in any way. The Government will not reimburse respondents for any costs associated with responding to this request. I. BACKGROUND: NOAA’s OSC is exploring the viability of commercial SSA services of active satellites and debris in preparation of future OSC SSA products. The US Air Force (USAF), and now the United States Space Force (USSF), has been monitoring and managing space assets, including live objects and debris, ever since the former Soviet Union launched Sputnik, the world’s first artificial satellite, in 1957. Currently, the United States Space Command (USSPACECOM) delegates SSA and military Space Traffic Management (STM) to the USSF 18th Space Control Squadron (18 SPCS), located at Vandenberg Space Force Base, CA. The 2020’s have brought tremendous growth to the satellite industry, resulting in a large increase of commercial satellites in orbit. The 18 SPCS is finding its SSA/STM mission focused more and more on managing commercial objects, tracking approximately 5,000 active satellites and over 20,000 debris objects. These numbers are expected to continue to increase in the foreseeable future. II. PURPOSE: In response to executive branch directives, and the Government’s effort to leverage commercially available data and services, OSC is seeking information from commercial SSA companies on products, services, and other capabilities to support development of an Open Architecture Data Repository (OADR) for commercial space situational awareness. For the purposes of this RFI, OSC’s primary interest is in commercial services that will comprise the Enhanced SSA Safety Service (previously referred to as the Basic Space Situational Awareness Services or Basic Safety Service), a free-from-fee service mandated in Space Policy Directive – 3 (June 2018) and described in OSC’s Industry Day presentation (November 2020) and Media Briefing, “Open Architecture Data Repository” (February 2022) https://www.youtube.com/watch?v=XAJE7VpOelo Information on both current and near-term capabilities available in the 2022 through 2024 timeframe is desired. Responses to this RFI will be used to inform plans for OADR development and other acquisition activities related to commercial space situational awareness by OSC and other government agencies. Respondents may address any or all of the sections below in their response. Respondents providing multiple or integrated services across more than one of the below sections should address whether their services: are severable; can be run in other environments; can be provided as containerized microservices; or, otherwise, describe the architectural model of their services. 1.0 Data Calibration and Validation, Pre-purchase As stated in the NOAA Space Object Commercial Data RFI, released in Feb. 2022, the OSC is interested in leveraging commercially available data and services to support the development of the OADR to promote data sharing for safety of space operations. Suppliers were invited in the previously mentioned RFI to submit capability statements describing their data offerings. Here, we would like to invite respondents to submit capability statements for data calibration and validation techniques which might be applied to data products prior to their incorporation into the OADR. Particular areas of interest to OSC include, but are not limited to: A. Information on approach and methodology used to calibrate and validate sensors and data products i. What data types/products does the respondent’s capability address? E.g., sensor observations (optical, radar, passive RF, other?), derived orbital states and/or ephemerides, derived decision support products (conjunction screening results, maneuver plan assessments). B. List of all truth sources used in calibration and any data agreements for data used for calibration or validation i. If precision data on orbiting objects is used, how does the respondent obtain the data? ii. What processing of the source data is performed by the respondent (e.g., processing laser ranging data into states/ephemerides), and how have these processes been validated? iii. To what extent are the truth sources openly available to the space operations community vs. proprietary to the respondent? C. Describe monitoring methods in place to capture “drift” of data from calibrated and validated values. D. How often can the respondent generate new and updated results? Describe whether/how this varies with orbital regime or object type. E. Describe Service Level Objectives (SLOs) for data products, giving details on scope of services to be covered, performance metrics, customer responsibilities, data response times, and other relevant conditions that impact data availability such as sensor availability, downtime, and maintenance schedules. F. Describe your approach to contracting and pricing for providing this capability to the government. G. Are there any restrictions on your algorithms or software, i.e., are they open-source, proprietary, or International Traffic in Arms Regulations (ITAR)-protected? H. Describe your hardware requirements. I. Describe the software design and implementation methodology (architecture pattern, languages employed, DevSecOps practices, etc.). J. Examples of tracked validation metrics for data or calibrated data products and their associated truth data are invited in the RFI response. 2.0 Data Ingestion The OADR will be capable of coordinating ingestion of multiple real-time data streams from commercial, civil, international, academic, public, and DOD sources (including Unified Data Library (UDL) and Space-Track.org). We invite potential Suppliers to submit capability statements describing in detail their existing ingestion techniques and protocols. Particular areas of interest to the OSC include, but are not limited to: A. Describe data formats and protocols currently implemented by the respondent’s data ingest software. In addition to ingestion of data formats such as radar, passive RF, and optical tracking observation and satellite ephemerides, which were also covered in the Data RFI, OSC is interested in ingestion of the following data types: i. Owner/operator PNT (position/navigation/timing) data ii. Maneuver plans iii. Space weather data iv. Additional data (e.g., time constants, Earth polar constants, etc.) B. Provide descriptions of system performance metrics of existing data ingest software – throughput, latency, etc. Please include any known limitations of the ingestion system (size, rates, volumes, etc.). C. Provide Interface Control Document (ICD) for any current function/component of the data ingest software. D. Describe your approach to contracting and pricing for providing this capability to the government. E. Are there any restrictions on your algorithms or software, i.e., are they open-source, proprietary, or ITAR-protected? F. Describe your hardware requirements. G. Describe the software design and implementation methodology (architecture pattern, languages employed, DevSecOps practices, etc.). H. Estimate of effort to develop data ingest software for data sources that are not currently ingested by software, for example the additional sources listed in Part 2.0(A)(i-iv). 3.0 Real-time monitoring of incoming and derived data products for quality, quantity, and latency thresholds Within the operational OADR system, OSC has a need for real-time monitoring of incoming and derived data products, to ensure that they meet the minimum thresholds necessary for customer reliance on OSC products. We invite the Suppliers to describe in detail their existing software systems for conducting this task, with a particular emphasis on outlining the following, as well as any additional monitoring functionalities of their services: A. Describe the nature of real time monitoring of minimum thresholds and the delivery mechanism of the results of this monitoring i. What data types does the respondent’s capability address? a. e.g., sensor observations, derived orbital states/ephemerides, conjunction alerts ii. How is the monitoring implemented in software? a. Architecture and/or design pattern, technology stack, etc. iii. What are the capacity and/or throughput constraints? a. What scaling approaches can be employed to achieve higher performance, and at what cost? B. Describe current and past experience with detailed focus on the monitored data types, data sources monitored, and methods employed. i. If applicable, provide links to active real-time dashboards or other demonstrations of existing capabilities C. Describe and explain the specific metrics used by monitoring services and the associated rationale for use of these metrics. Some examples of metrics to include are accuracy/precision/realism of results, latency/timing of data products, or volume of expected data for a given data source (for primary data product), or a service (for derived data). i. If applicable, please provide sample reports utilizing these metrics. D. Describe any external dependencies (including any contractual relationships) for the threshold monitoring system, including truth data, software licensing, etc. E. Describe any automation used in monitoring. F. Describe any data archiving services used or provided. G. Describe your approach to contracting and pricing for providing this capability to the government, service, for example SLOs and Service Level Agreements (SLAs) for the service, etc. H. Are there any restrictions on your algorithms or software, i.e., are they open-source, proprietary, and/or ITAR-protected? I. Describe your hardware requirements. 4.0 Mission Planning The OADR requires a planning capability to assess pre-planned and real-time data requirements and deficiencies, and dynamically coordinate tasking of radar, electro-optical (EO), and passive radiofrequency (RF) ground and space-based sensors, as well as requesting additional data such as ephemerides and maneuver plans. This can be accomplished either by using in-house assets (i.e., sensors controlled by the provider of this OADR service) or through tasking requests to another vendors and operators, including the Department of Defense (e.g. Space Surveillance Network), civil (e.g. NASA, NOAA), international partners, and/or commercial SSA providers. In any case, the provider(s) need to ensure the confidentiality, integrity, and availability of taskings and/or the observations and data received in response to a dynamic tasking. A. What capabilities do you have to execute dynamic tasking or data requests with your owned and/or operated assets (i.e., with in-house sensors) in the presence of a standing task schedule? B. What interface protocols, use agreements, and data formats do you use to request additional data from the following sources: i. In-house? ii. DOD? (Dedicated, Collateral, Contributing) iii. Civil (NASA/NOAA)? iv. International partners? v. Other commercial providers? vi. Other sources (please specify)? C. What protocols and data formats do you use to verify tasking or data request receipt and execution (e.g., return receipt) from the above sources? D. Please describe any SLAs you have in place with any of the sources above to provide or consume dynamic sensor tasking and data, including metrics such as time to notification, response time, etc. E. What capability does your SSA mission planning software have to dynamically prioritize pre-planned and real-time sensor taskings, and what criteria are used to generate the collection priorities? F. How do you ensure the confidentiality (e.g., protect data use rights and agreements), integrity (e.g., non-repudiation, data quality), and availability (e.g., guaranteed delivery) of responses to dynamic task requests? G. Can your SSA mission planning service be executed independently from the rest of your software suite? Is your process containerized? H. Describe how your software can scale. I. Describe your approach to pricing for providing this software service to the government. J. Are there any restrictions on your algorithms or software (i.e., are they open-source, proprietary or ITAR-protected?) K. Describe your hardware requirements. L. Describe the software design and implementation methodology (e.g., architecture pattern, languages employed, DevSecOps practices, etc.). M. Provide descriptions of system performance metrics of your software: throughput, latency, etc. Please include any known limitations of the software (e.g., size, rates, volumes, etc.). 5.0 Models Given that the goal of operational orbital safety is to protect active satellites from collisions with space debris and with each other, the enabling first step is to know what objects are in Earth orbit, where they are, and where they are expected to be some number of days into the future. This section describes the types of models needed to perform conjunction analysis. Note that the government may choose to procure multiple models from different vendors and integrate them into a government-managed platform. The following questions apply to whatever parts of this section you respond to. A. Can your process be executed independently from the rest of your software suite? Is your process containerized? B. Describe how your process can scale with increases in space objects, data volume, and number of users. C. Describe your approach to contracting and pricing for providing this capability to the government. D. Are there any restrictions on your algorithms or software, i.e., are they open-source, proprietary, or ITAR-protected? E. Describe your hardware requirements. F. Describe the software design and implementation methodology (e.g., architecture pattern, languages employed, DevSecOps practices, etc.). G. Provide descriptions of system performance metrics of your software: throughput, latency, etc. Please include any known limitations of the software (e.g., size, rates, volumes, etc.). 5.1 Orbit Determination Orbit determination refers to estimating an object's orbit based on observations using a statistical estimation algorithm, along with associated covariance. A. Describe your orbit determination capabilities, including algorithms and underlying orbit models. Provide a quantitative description of the accuracy of your orbit determination process. Outline the different satellite object maintenance/control parameters used to guide the corrections. Describe the manual process and associated tools for addressing difficult-to-maintain or problematic orbits, if your OD toolset includes these. How do your capabilities differ between orbital regimes (e.g. LEO vs. GEO)? B. Describe your approach to handling sensor calibration in the orbit determination process. (See Section 1.0 on data calibration and validation.) 5.2 Ephemeris Generation An essential function of the OADR is generating ephemerides for thousands of objects from initial state and covariance. Ephemeris generation requires high precision orbit propagation for several days into the future. A. Describe your approach to ephemeris generation, including algorithms and underlying astrodynamic models. Include details on your approach orbit modeling, including atmospheric drag. Provide accuracy at the 50th and 95th percentiles at epoch, 18 and 72 hours for different orbit regimes ( i.e., LEO, MEO, HEO, GEO, etc.). Provide information on covariance and your approach to covariance realism. What coordinate frames do you support? What ephemeris formats do you support (e.g., CCSDS OEM)? B. Describe how you would ensure that the approach to propagating state vectors is consistent with the tool/theory that generated them in the orbit determination process. 5.3 Data Fusion Process The government expects that the OADR will use tracking data (observations) from both the DOD Space Surveillance Network and commercial providers, either directly or indirectly. If it is not possible to obtain and combine sensor measurement data, a plausible alternative is to purchase predicted satellite ephemerides from commercial providers and “fuse” these with an ephemeris generated from the DoD Satellite Catalog in order to produce a single, presumably more accurate, ephemeris. A similar approach could be used to combine an owner/operator ephemeris and a DOD or commercial ephemeris for the same object. Another alternative is to take DOD ephemerides for a set of objects and perform conjunction screening with commercial or owner/operator ephemerides for a disjoint set of objects. A. Describe your approach to data fusion, including estimation algorithms and underlying astrodynamic models. Include necessary data inputs to your fusion process. Explain the advantages and disadvantages of your approach. Describe your approach to realistic state uncertainty estimation. 5.4 Conjunction Analysis Conjunction screening involves identifying future close approaches between satellites. For any conjuncting satellites, the states and uncertainties for both objects at the time of closest approach, as well as some other amplifying information, are used to generate a conjunction data message (CDM), which is then dispatched to the satellite's owner/operator (O/O). Results may be screened by probability of collision (Pc) and/or proximity. Conjunction analysis may involve the entire catalog ("all vs. all"), a subset of protected satellites ("many vs. all"), or detailed analysis of a single conjunction ("1 vs. 1"). Conjunction analysis may be done continuously, periodically, or on-demand. A. Describe your approach to conjunction analysis, including algorithms and underlying astrodynamic models. Describe your approach to calculating Pc, including low relative velocity events. B. What input ephemeris formats and sources do you support? Can you do conjunction analysis with ephemerides that are generated externally from your software suite? What are the output data products of your process? C. Does your approach use batch or continuous processing? 5.5 Risk Assessment Risk Assessment is the careful examination of the conjunction to determine if it represents a high-risk situation. A. Describe your risk assessment capabilities. What are the output data products of your process? 5.6 Mitigation Planning Mitigation Planning is the identification of a trajectory change, in response to a worrisome risk assessment, that will both avoid the risky conjunction and not introduce any new risky conjunctions. A. Describe your mitigation planning capabilities. What are the output data products of your process? 6.0 Message Publication Service The basic and advanced data and services of the OADR will require the ability to send notifications of various events (e.g., emergency notifications for sensor outages and notices to space operators, conjunction alerts, maneuver alert, etc.) to external registered users. This service should maintain a store of stakeholder contact information, business logic, conditions for sharing, preferred notification channel(s) (e.g., email, website, automated alert, phone call), and message formats and content (where applicable). The message publication service provider would need to ensure the confidentiality (i.e., protecting user information), integrity (i.e., non-repudiation, data quality), and availability (i.e., data persistence, guaranteed delivery) of all stored and in-transit messages and data. A. What technologies and practices do you use to store, protect, and update user information for the purposes of information sharing? B. What metrics do you use to measure the effectiveness and performance of your message publication service? C. Please describe the channels (e.g., email, website), protocols, and data formats you use for notifications, including: I. Emergency notifications II. Conjunction alerts III. Reentry notifications IV. Static content V. Other message types (please describe) D. How does your service ensure the confidentiality, integrity, and availability of all stored and in-transit messages and data? E. Does your message publication service for delivery of basic or advanced data and services include the ability for automated, machine-to-machine interaction? 7.0 OADR Enhanced Services System Integrator The government may choose to procure multiple software components from different vendors and integrate them into a government-managed platform. In that case, the government will need a system integrator to combine the layers and components into a functioning system to support the basic safety service. For purposes of this section, you may assume that the software components are provided by vendors as containerized services. Refer to Section 10.3 for notional software architecture diagrams. The functions of Conjunction Analysis components are described in Section 5.0 Models and Section 8.0 Presentation. The functions of the Data Ingest, Data Conditioning and Data Integrity components are described in Sections 1.0, 2.0 and 3.0. On 18 July, 2022 the government previously issued an RFI for cloud environment compute and storage services and OADR data integration and management. These services correspond to Infrastructure Services and Data Services layers in Section 10.3 below. The government seeks to create a multi-cloud-capable and hybrid-capable software platform. That is, the software platform should be capable of being deployed to multiple cloud service providers as well as on-premise data centers. The OADR performs a safety-critical function for the commercial space industry and requires high availability. A highly available environment has a minimal service interruption. High availability combines software with industry-standard hardware to minimize downtime by quickly restoring essential services when a system, component, or application fails. While not instantaneous, services are restored rapidly. The OADR system will require centralized event logging. Event logs record events taking place in the execution of a system to provide an audit trail that can be used to understand the activity of the system and to diagnose problems. They are essential to understand the activities of complex systems. A. Please describe your approach to integrating service layers possibly provided by separate vendors. B. Describe your approach to integrating services within each layer into a single functioning system, including requirements specification, software interfaces, continuous integration and test, verification and validation, and ongoing updates and deployment. What protocols and data standards will you use for software interfaces to ensure interoperability? How will you make sure that interfaces are communicated to all relevant stakeholders? What type of change management will be put in place to ensure that interface changes do not occur without coordination and approval by the government customer and affected development teams? C. If you propose a different division of layers or components, provide your rationale. D. Certain Conjunction Analysis workloads, such as ephemeris generation and conjunction screening, are known to be data and I/O intensive, and are expected to drive processor memory, and networking requirements. Describe your approach to minimize platform cost, including charges from the cloud service provider, e.g., block storage, server instances, data exfiltration, etc. Describe your approach to scaling out the platform as the number of space objects and data increases. E. What specific tools would you use to instantiate Software Services? F. How will you monitor and manage overall system performance? Provide descriptions of system performance metrics. Describe service level objectives (SLOs) for data products, giving details on scope of services to be covered, performance metrics, customer responsibilities, data response times, and other relevant conditions that impact data availability such as sensor availability, downtime, and maintenance schedules. G. Describe your approach to providing high availability. H. Describe your approach to system security. I. Describe your approach to using free and open-source software, commercial off-the-shelf software, and government software in system integration. If you use commercial software, how will you avoid vendor lock-in for major components? J. What is your approach to making the OADR system cloud-agnostic, i.e., able to be deployed on multiple cloud service providers and/or on-premise data centers? K. The OADR will have an operational environment and a "proving ground" development and test environment for industry and researchers to test new software algorithms. Please describe your approach to separating these two environments and managing the exchange of data and software between them. How will you approach vetting and testing experimental software before deploying it to the operational environment? L. Describe your approach to system-wide event logging to support traceability as well as system monitoring and fault recovery. M. Describe your approach to contracting and pricing for providing this integration and management service to the government. 8.0 Presentation The government intends for the OADR to have an intuitive and friendly user interface. Previous sections of this RFI have described OADR basic services needed to generate conjunction warnings. As noted by Borowitz, “The impact of warnings is not just about the quality of the data and analysis, but also … the ability to communicate this information in a way that users understand and know how to respond to. We should keep in mind that satellite operators include not only large, experienced firms, but increasingly include new space actors...” The government intends to have a presentation service or layer for authorized users that may include displays such as A "big picture" representation of all potential conjunctions over some number of days above some adjustable probability of collision threshold Detailed information on individual conjunctions similar to the contents of a CDM in graphical form Plots similar to those used by NASA’s Conjunction Assessment and Risk Analysis (CARA) software, including debris production 3D visualization of conjunctions and covariance ellipsoids Information on tracking assets with line of sight to the relevant objects Rough Delta-V calculations for mitigating collision risk A. Describe your capabilities to present results from a conjunction screening basic safety service, as well as simple risk assessment and mitigation. Screen shots are encouraged, along with text explaining navigation between displays. Include information latency of generating displays (especially displays with large amounts of data) and navigating between displays. How often are your displays refreshed, and what is your process for refresh? What underlying technologies, protocols and software stack do you use? What standard data formats do you use to import, present, and export data to the user interface? B. Can your process be executed independently from the rest of your software suite? Is your process containerized? C. Describe how your process can scale with increasing number of users and data volume. D. Describe your approach to contracting and pricing for providing this capability to the government. E. Are there any restrictions on your algorithms or software, i.e., are they open-source, proprietary, or ITAR-protected? F. Describe your hardware requirements. G. Describe the software design and implementation methodology (architecture pattern, languages employed, DevSecOps practices, etc.). H. Provide descriptions of system performance metrics of your software: throughput, latency, etc. Please include any known limitations of the software (size, rates, volumes, etc.). I. Does your presentation software use an API? If so, describe your API. Can human or machine users access the API directly? How do you limit data extracted via the API? J. How do you ensure the confidentiality, integrity, and accessibility of the data in the user interface? 9.0 Other Applicable Services Please provide information on any other applicable service not listed above that you expect to be able to be commercially available during the next two years. 10.0 Appendix 10.1 Acronyms CA: Conjunction Assessment. CCSDS: Consultative Committee for Space Data Systems. CDM: Conjunction Data Message. COLA: Collision Avoidance. LCOLA: Launch Collision Avoidance. OADR: Open Architecture Data Repository. OD: Orbit Determination. OEM: Orbit Ephemeris Message. O/O: Owner/Operator. OPM: Orbit Parameter Message. Pc: Probability of collision. RFI: Request for Information. SSA: Space Situational Awareness. STM: Space Traffic Management. TCA: Time of Closest Approach VCM: Vector Covariance Message. 10.2 References Aerospace OTR 2022-00578, Statement of Dr. Matthew Hejduk to the Subcommittee on Space and Aeronautics, Committee on Science, Space, and Technology, U.S. House of Representatives. Aerospace VTR-2021-02062, Analysis of Alternatives for Providing SSA and STM Services. DoD Data Strategy, 2020. Statement of Dr. Mariel Borowitz to the Subcommittee on Space and Aeronautics, Committee on Science, Space, and Technology, U.S. House of Representatives, April 29, 2022. NASA Spacecraft Conjunction Assessment and Collision Avoidance Best Practices Handbook, December 2020. National Oceanic and Atmospheric Administration (NOAA) Cloud Platform Management Services Request for Information (RFI), Notice ID NOAA-22-CPMS-OSC, July 19, 2022. Department of Defense, Instruction 8510.01: Risk Management Framework (RMF) for DoD Information Technology (IT); 2020. National Academy of Public Administration (NAPA); Space Traffic Management: Assessment of the Feasibility, Expected Effectiveness, and Funding Implications of a Transfer of Space Traffic Management Functions, Washington, DC, 2020. 10.3 Architecture Reference Diagram See Attachment "Architecture Reference Diagram" III. Response Instructions: Responses are due no later than 4:00 pm EST on September 16, 2022. Late submissions will not be accepted or reviewed. In order to ensure timely response and consideration of your feedback, we ask each company to limit itself to one (1) response. Please submit all responses to this RFI via Google Forms using the link below: https://docs.google.com/forms/d/e/1FAIpQLSd4gaxOAw0QLPk69IGFjvOdRYL93pdPye_whVpKWjmX8CHojw/viewform It is highly recommended that respondents draft their responses outside of the Google Form and then copy and paste responses into the form to avoid loss of data. If you are unable to access Google Form, you may submit your response via using the attachment "OADR Enhanced Safety Service RFI - Questions for Industry.xlsx". There are no character limits associated with Google Form. When providing multiple responses within a question, please start a paragraph for each response (i.e. click "enter" twice). Responders will automatically receive a copy of their response from "Google Forms". IV. Use of Results and Confidentiality: This RFI does not guarantee that the Government will issue a solicitation or award a contract for supplies or services. No specific solicitation is planned to follow this RFI; however, the responses could impact the Government’s decision to...