Attachment 13_FMDS RFI-2 Comment and Question Matrix (Completed).xlsx
XLSX spreadsheet 54 KB Posted
- Solicitation number
- FMDS-2022-MS2
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Attachment 14.1_Document Security Notice(2).docx | DOCX document | |
| Attachment 14_Instructions to Obtain Sensitive Unclassified Information.docx | DOCX document | |
| Attachment 15_Business Declaration Form.docx | DOCX document | |
| Attachment 14.2_Non-Disclosure Non-Use Agreement.docx | DOCX document | |
| Attachment 3_FMDS Implementation Strategy White Paper - Final.docx | DOCX document | |
| Attachment 2_FMDS pPRD - Final.pdf | ||
| Attachment 1_FMDS ConOps - Final (2).pdf | ||
| Attachment 14.3_Consolidated Employee Screening List.xlsx | XLSX spreadsheet | |
| Attachment 13_FMDS RFI-2 Comment and Question Matrix.xlsx | XLSX spreadsheet | |
| Attachment 5_FMDS Acquisition Strategy White Paper v1.0.docx | DOCX document | |
| Attachment 15_Business Declaration Form.pdf | ||
| FMDS Market Survey 6-30-2022.docx | DOCX document | |
| Attachment 14.1_Document Security Notice.docx | DOCX document | |
| Attachment 14_Instructions to Obtain Sensitive Unclassified Information.pdf |
Show all 14
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Comment Resolution Comment # Document Section Text Question / Comment / Discussion Recommendation, Suggested Text, or Rationale Criticality C = Critical S = Substantive
| A = Administrative | FAA Response | ||||
| 1 | Attachment 1: Concept of Operations | 3.1.3.1 Shortfall | In 2018, both Advanced Flight-Specific Trajectories (AFST) and Enhanced NAS Impact Modeling (ENIM) were indefinitely postponed… | ||
| Page 46 | Could the FAA describe the challenges encountered in the development and implementation of these enhancements? Does the FAA plan to revisit these enhancements in FMDS? | Understanding of these challenges ensures they are considered in solution development. | S | These enhancements will be revisited. The TFMS applications are based on 20+ year infrastructure that is already strained to meet existing functionality (reference TFMS shortfalls). The current FMDS investment analysis addresses only existing TFMS functionality. | |
| 2 | Attachment 1: Concept of Operations | 4.4 Concept of Operations | To the extent practicable, these services will be common across the | ||
| Page 54 | This sentence is incomplete. Would the FAA kindly provide the missing information in this sentence/paragraph? | S | The sentence should end with "NAS automation systems." | ||
| 3 | Attachment 1: Concept of Operations | 1.5 Alignment | Tables 1-2, Table 1-3, Table 1-4 | 1. Would the FAA provide the Concept Alignment documentation in either a public accessible web link or an electronic copy? |
2. Would the FAA provide an electronic copy of Business and Technology Improvement (BTI) number 508120?
| 3. Would the FAA provide an electronic copy of the Next Generation Air Transportation System (NextGen) Operational Improvement (OI) Increments listed in Table 1.4? | Documentation would provide vendors additional insights into FAA's objectives and enable to vendors towards solution development. | C | These reference documents are for internal FAA use only and are not made available through this market survey. The relevant information for the FMDS acquisition is included in the approved FMDS Concept of Operations. | |||||
| 4 | Attachment 1: Concept of Operations | 7 References | List of Reference Documentation | Would the FAA provide electronic copies or public accessible web links to the references listed in Section 7? Excluding those references that are provided as a web link already (examples #6, #10, #11) | Documentation would provide vendors additional insights into FAA's objectives and enable to vendors towards solution development. | C | These reference documents are for internal FAA use only and are not made available through this market survey. The relevant information for the FMDS acquisition is included in the approved FMDS Concept of Operations. | |
| 5 | Attachment 3: Implementation Strategy White Paper | 4. Implementation Strategy | Do you think it is feasible to deploy the new FMDS system using a phased implementation approach? If so, how would that be accomplished? Provide feedback on the strategy proposed by the FAA in Attachment 3: Implementation Strategy White Paper. | To support Transition can FAA confirm if the existing workstations at TRS and other locations support the integrated situation display simultaneously with TFMS applications? | We recommend that the FAA provide the hardware specs and capability of the workstations so we can assess the performance impact from the web browser instances to CPU and memory, especially given the volume of data and dynamic functions of the integrated situation display. | S | The workstations at the TRSs will be due for replacement at the time of FMDS deployment. New hardware for the TRSs will be procured at that time. The current hardware will not be used by FMDS and will not need to support the integrated situation display. | |
| 6 | Attachment 3: Implementation Strategy White Paper | 4. Implementation Strategy | Do you think it is feasible to deploy the new FMDS system using a phased implementation approach? If so, how would that be accomplished? Provide feedback on the strategy proposed by the FAA in Attachment 3: Implementation Strategy White Paper. | Can FAA confirm if the releases in Phase 1 operationally deployable or just developmental releases? Section 4.3 suggests that they are operationally deployable. | S | Each release would be operationally deployable. The FAA desires to replace the legacy applications incrementally, minimizing the training and operational impacts. | ||
| 7 | Attachment 3: Implementation Strategy White Paper | 4. Implementation Strategy | Do you think it is feasible to deploy the new FMDS system using a phased implementation approach? If so, how would that be accomplished? Provide feedback on the strategy proposed by the FAA in Attachment 3: Implementation Strategy White Paper. | Would the FAA please share the criteria established to determine the order for replacing the capabilities identified in Section 4.3 (1. TSD, 2. SV, 3. FSM, and 4. NTML+ESIS)? | Understanding FAA's priority would enable vendors to propose best value implementation strategy. | S | The order is not yet finalized, but the main criteria are to (1) ensure that functions are deployed in an order to address any functional dependencies; (2) replace the applications with the highest performance risks; and (3) address users' priorities. The FAA welcomes recommendations on the deployment order as a part of this market survey response. | |
| 8 | Attachment 1: Concept of Operations | 7. References | [4] V. Sud and B. Fordham, "Traffic Flow Management System (TFMS) Reliability | Can the FAA please provide these two (2) documents which we cannot find to be publicly available? | We would like to request the two documents be provided via a prompt Amendment to the Market Survey as new Attachments – so that Industry may receive them in time to inform our responses that we need to submit by the end of August. | C | These reference documents are for internal FAA use only and are not made available through this market survey. The relevant information for the FMDS acquisition is included in the approved FMDS Concept of Operations. | |
| Assessment - Modernization Recommendations to Improve Performance," 2016. |
| [5] Mosaic ATM, Inc., "Health of Traffic Flow Management System (TFMS) | ||||||||
| Assessment and Recommendations," 2019. | ||||||||
| 9 | Attachment 1: Concept of Operations | 1.4 Concept Overview | Alternatively, or in addition, FMDS may provide CDM members access to a web-based version of the integrated situation awareness display that will allow them to perform similar tasks as they can do today via FSM and the remote desktop version of the Traffic Situation Display (TSD) application. | Additional, more detailed requirements on the functionality expected for the web-based version of the integrated situation awareness display would help choose the right architecture for the thin-client version of it. For example, does it need to support multiple monitors? Display preferences, etc.. | Please clarify. | S | These detailed requirements are not yet available. The FAA welcomes recommendations on how to meet the needs of both FAA and CDM users as a part of this market survey response. | |
| 10 | Attachment 1: Concept of Operations | 4.2 Constraints | Implementation of FMDS should not complicate traffic managers’ working environment or require additional floor space in the field facilities | Is this constraint applicable during the TFMS to FMDS transition? | Please clarify. | S | Yes, that is the goal. Disruption to working environments during transition must be minimized. | |
| 11 | Attachment 1: Concept of Operations | 4.4 Concept of Operations | To the extent practicable, these services will be common across the | Incomplete sentence | Please clarify. | A | The sentence should end with "NAS automation systems." | |
| 12 | Attachment 1: Concept of Operations | 4.4 Concept of Operations | New features will be released into the operational environment on demand as opposed to as part of large, scheduled updates. | Agile deployment of features does not fully align with FAA Order 6000.19 (assumed applicable in 4.1.1). What process will the FAA use to determine certification requirements as applicable to different FMDS functions and features? | Please clarify. | C | (Response assumes FAA Order 6000.15 rather than 6000.19). The FAA is looking for ideas from industry on how to evolve to a more agile-like development process that includes the government in final V&V acceptance of releases. The FAA welcomes recommendations as a part of this market survey response. This includes recommendations on performing a certification analysis. | |
| 13 | Attachment 1: Concept of Operations | 4.4.1.2.2 Develop TMIs | The integrated situation awareness display will provide the interface for all TMI modeling, implementation, and management. In the near term, modeling will be limited to those TMIs that can be modeled in TFMS, with the addition of Reroutes with associated MIT restrictions | Do the current implementations of the different models have an automated test suite with a high coverage (>95%) that can be leveraged to validate potential reimplementation's of the different algorithms? | Please provide additional information | S | The FAA welcomes recommendations on how to ensure algorithm integrity as a part of this market survey response. No additional information is available at this time regarding current testing capabilities. | |
| 14 | Attachment 1: Concept of Operations | 4.4.1.2.2 Develop TMIs | The integrated situation awareness display will provide the interface for all TMI modeling, implementation, and management. In the near term, modeling will be limited to those TMIs that can be modeled in TFMS, with the addition of Reroutes with associated MIT restrictions | Please define timeline associated with "near term" TMI modeling in TFMS. | Please provide additional information | S | Near-term refers to the initial scope of the FMDS baseline and this initial acquisition. It is envisioned that future enhancements to FMDS will include additional modeling capabilities. | |
| 15 | Attachment 1: Concept of Operations | 4.4.3 Training Personnel for TFM Automation System Improvements | n/a | Section does not seem to address training of NAS users, including CDM members. | Please clarify. | S | The FAA welcomes recommendations on how to support training needs for NAS users. | |
| 16 | Attachment 1: Concept of Operations | 4.5.2 Infrastructure External to FMDS | n/a | Should CSS-FD be included? Also, FMDS access is based on role; is identity management potentially provided as a NAS enterprise service or as a FMDS shared service? | Please clarify. | S | CSS-FD falls into the category of "…and others as they are developed." The FMDS program will align with other programs as needed, to include CSS-FD and SWIM. Identity Management services could be provided via a SWIM shared service. | |
| 17 | Attachment 1: Concept of Operations | 7. References | n/a | The majority of the documents referenced do not appear to be publicly available. | Please consider releasing referenced documents, for example, in an FAA-controlled data repository made available to Vendors | A | There are several reference documents that are for internal FAA use only and are not made available through this market survey. The relevant information for the FMDS acquisition is included in the approved FMDS Concept of Operations. | |
| 18 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 2.3.1 Constraints | Implementing FMDS will not impose changes on other NAS systems that are not specified in baselined requirements documents. | Is this statement intended to clarify that changes to other NAS systems will not be required, or that changes when required will be incorporated in the requirements baselines of those other systems? | Please clarify. | S | The former: the FAA will not make changes to other NAS systems as part of this FMDS investment. | |
| 19 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 2.3.1 Constraints | Implementation of FMDS should not complicate traffic managers’ working environment or require additional floor space in the field facilities than TFMS. | Is this constraint applicable during the TFMS to FMDS transition? Given that FMDS is intended to provide users new hardware and networking, during the transition additional space could be required if FAA desires to maintain parallel operations for any period of time. | Please clarify. | S | Yes, that is the goal. Disruption to working environments during transition must be minimized. | |
| 20 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 2.3.1 Constraints | FMDS options for data exchange standards may be constrained if FMDS needs to maintain legacy interfaces between NAS automation systems. | As stated, this is a risk, not a constraint. This situation may be handled better with requirements statements for (a) support of legacy interfaces inclusive of data transformation; and (b) specifying the data exchange standards for the baseline FMDS capabilities. | Suggest removing from list of constraints and capturing in specific requirements for legacy interfaces support and data exchange standards for baseline capability. | S | Please include any recommendations in your response to this market survey. | |
| 21 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 2.3.2.1. Operational and Technical Environment Assumptions | FMDS will leverage new and existing SWIM services for receiving relevant data as appropriate. | Is use of SWIM services intended for consuming data only, or also for distribution of data? | Suggest changing to "FMDS will leverage new and existing SWIM services for exchanging relevant data as appropriate." if the intent is to use SWIM for ingest and distribution of data as applicable. | S | Please include any recommendations in your response to this market survey. | |
| 22 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 2.3.2.1. Operational and Technical Environment Assumptions | FMDS components will be certified if needed according to FAA Order 6000.15. | FAA Order 6000.15 is only available on the FAA network. Please make available to vendors. | A | These reference documents are not made available through this market survey. Any relevant FAA Orders will be made available as part of the SIR. | ||
| 23 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 2.3.2.3.3 Data Exchange | Data exchanges between TFMS and TFDM. | Statement seems incomplete | Please clarify. | A | TFDM is not yet operational; when made operational, there will be new data exchanges between TFMS and TFDM. | |
| 24 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 3.1.1.1 Ingest Data | n/a | Does the FAA intend to release information on standards for data to be ingested by FMDS as part of subsequent specifications? | Please clarify. | A | Yes. | |
| 25 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 3.1.1.1 Ingest Data | ||||||
| 4.2.2.2.1 CSS-FD Phase 1 | extensive (see document) | There is duplication in requirements between these two sections. | Please consider removing duplicate requirements | A | These duplicates were included intentionally to account for multiple options. They will be removed in the final PRD. | |||
| 26 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 3.1.3.5.10 Log Telcon Events | FMDS_pPRD_783. The FMDS system must log a summary of voice communication collaboration conversations between traffic managers and stakeholders. | This requirement implies that somehow the FMDS system can transcribe or detect voice communication. Is this interpretation correct? Or is the requirement about providing the functionality for a summary of voice communication to be entered by a user? | Please clarify. | S | The latter: providing the functionality for a summary of voice communication to be entered by a user. This is met via the NTML application today. | |
| 27 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 3.3 Performance Requirements, 3.4 RMA and Resiliency Requirements, … | NAS-RD-2013 | The NAS Systems Requirements Specification is not publicly available. Please make available to vendors. | Document request: NAS-RD-2013. | S | This reference document is not made available through this market survey. Any relevant documents will be made available as part of the SIR. | |
| 28 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 3.3.1 System Performance | n/a | The set of performance requirements defined in the pPRD for FMDS seems incomplete. The FAA may want to consider additional service requirements such as performance parameters including latency, data integrity, load, etc. | Please review and update the performance requirements as appropriate. | C | The more specific RMA requirements will be included in the final PRD. The FAA welcomes recommendations as a part of this market survey response. | |
| 29 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 3.4.3 Availability | n/a | Three availability levels are specified, but there is no information on what FMDS services are efficiency-critical, essential, and routine. | Please clarify service classification by FMDS function; availability is a major driver for system architecture (and cost) | C | The more specific RMA requirements will be included in the final PRD. The FAA welcomes recommendations as a part of this market survey response. | |
| 30 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 4.2.4, FMDS_pPRD_312 | The FMDS system must adhere to the principles of microservices design. | "Principles of microservices design" is vague and open to interpretation | Please clarify the specific principles the FMDS system must adhere to. | S | Please include any recommendations in your response to this market survey. | |
| 31 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 4.3 Human Factors | FMDS_pPRD_643. The FMDS Program Office must mitigate adverse impacts on staffing. | Please define the difference between 'Program Office' and 'System.' It is unclear who 'Program Office' requirements apply to. For this requirement in particular, which skill sets need to be taken into consideration? | Please detail the expectation for use of the system in terms of staffing so the impacts may be identified. Alternatively, please provide a stakeholder analysis. | S | The Program Office is defined as joint FMDS program team (FAA and contractor). The FAA must perform the FMDS implementation in such a way that staffing is impacted as minimally as possible. The FAA welcomes recommendations as a part of this market survey response. The FAA will derive requirements and establish processes with the FMDS contractor(s) that will mitigate adverse impacts on staffing. | |
| 32 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 4.3.1 Human-Systems Engineering | FMDS_pPRD_553. The FMDS Program Office must comply with 29 United States Code (USC) 749D, The Rehabilitation Act Amendments (Section 508). | This is a "Program Office" requirement. Will Section 508 requirements be levied on the FMDS system and need to be tested? What documentation is required to prove Section 508 compliance? | Please specify the Section 508 sections that need to be satisfied and if these need to be tested with a tool such as JAWS. | S | Yes, section 508 requirements will be levied on the FMDS system. Specific requirements and verification method(s) have not been determined yet. | |
| 33 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 4.3.1 Human-Systems Engineering | FMDS_pPRD_567. The FMDS system must comply with FAA HF-STD-001B, Human Factors Design | |||||
| Standard (HFDS). | Applicable sections of the HFDS are referenced in each section of Attachment 6_HIG. The HIG provides a design checklist with 73 items in the appendix. Is it assumed this checklist will be verified by the HF SME, and that completion of the checklist satisfies pPRD_567? | Please clarify. | S | The system must comply with the HFDS in its entirety, regardless of the HIG. | ||||
| 34 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 8. Implementation and Transition Requirements | n/a | Is the FAA's intent to clarify requirements on parallel operations (or shadow mode operations) in a future release of the pPRD or the lower level specifications? The NAS EA roadmaps provided in Figures 1 and 2, and the FMDS To-Be High-Level Concept Overview hint to such requirements, but they are not stated. | Please clarify. | C | Yes, additional details will be provided in the fPRD and/or the specifications. | |
| 35 | Attachment 2: Preliminary Program Requirements Document (pPRD) | Appendix 3 | n/a | Many of the documents referenced do not appear to be publicly available. | Please consider releasing referenced documents, for example in an FAA-controlled data repository made available to Vendors | Some reference documents are for internal FAA use only and are not made available through this market survey. The relevant information for responding to the FMDS market survey is included in the provided documents. | ||
| 36 | Attachment 2: Preliminary Program Requirements Document (pPRD) | Appendix 5 Program Requirements Traceability and Verification | FAD_ID: The functional identifier from the Functional Analysis Document (FAD) to which the requirement maps. | Is the Functional Analysis Document available to interested FMDS vendors as part of the RFI? | Please consider releasing the requested document | S | This document may be provided in the future and is not included in this market survey. | |
| 37 | Attachment 3: Implementation Strategy White Paper | 4.1 TFMS Rehosting | The TFMS program will soon be rehosting the Web Applications portion of the Auxiliary Subsystem in a virtual environment (see Figure 4 1). This platform, referred to as the TFMS Web Platform, will utilize the existing TFM Support System (TSS) Forwarders to obtain the needed data for the rehosted web applications, which will have little to no changes in their software. | Is the intent for the TFMS Web Platform to become part of the final FMDS architecture (as shown in figure 4-3)? If so, could the FAA provide information on the TFMS Web Platform and/or clarify allocation of pPRD requirements to this system component? Will the web applications meet the FMDS RMA requirements? | Please provide additional information on requirements and implementation of the TFMS Web Platform | S | Additional information is not available at this time, but will be included in the eventual system specifications provided with the SIR. The program is investigating the possibility of hosting the web applications on a different platform than the rest of the system due to the likelihood of less stringent RMA requirements and a more diverse user base. The FAA welcomes recommendations as a part of this market survey response. | |
| 38 | Attachment 3: Implementation Strategy White Paper | 4.3 FMDS Releases | After this initial release in Phase 1, users would begin using the new SD for TSD functionality alongside the existing FSM, NTML, and other legacy applications. | Section 2.2 of the pPRD indicates that FMDS will provide end user hardware and networking for FAA facilities. Is it correct to assume that until all Phase 1 releases have been transitioned into operations, the end users at FAA facilities will interact with the TRS legacy hardware where legacy applications not yet transitioned will reside and the FMDS new hardware on which the integrated display is provided? Specify user group(s). | Please clarify hardware expectations and users during Phase 1 at remote sites. | S | That is correct. During the roll out of Phase 1 there would be a mix of legacy hardware with the new FMDS hardware. The intent is to deploy thin clients, minimizing the hardware footprint at the TRSs. | |
| 39 | Attachment 3: Implementation Strategy White Paper | 4.3 FMDS Releases | After this initial release in Phase 1, users would begin using the new SD for TSD functionality alongside the existing FSM, NTML, and other legacy applications. | What is the expected timeline for IOC and ISD relative to the multiple releases contemplated in Phase 1 of the implementation strategy? | Please clarify. | C | The operational dates associated with each release in the implementation strategy have not yet been determined. | |
| 40 | Attachment 3: Implementation Strategy White Paper | FMDS Concept Overview | FMDS will use NAS enterprise services and standard industry data formats when appropriate [...] | Please define "standard industry data formats". | Please clarify. | S | This includes standards such as AIXM, FIXM, MMIXM, and WXXM, along with other industry standards such as GML. The intent is to move away from custom formats for data exchange as much as possible. | |
| 41 | Attachment 5: Acquisition Strategy White Paper | 3.1 Multiple Vendor system acquisition | Figure 1 - "monitor & sustain FMDS in the NAS)" | How is this responsibility divided among FAA, Integrator and Platform Provider? | Please clarify. | S | The details of this shared responsibility are under development. The FAA welcomes recommendations as a part of this market survey response. | |
| 42 | Attachment 5: Acquisition Strategy White Paper | 3.1.4 Platform/Infrastructure Provider Responsibilities | […] the platform/infrastructure vendor […] | Does the FAA envision a single platform/infrastructure vendor or multiple? | Please clarify. | A | While a single platform provider is envisioned, the use of multiple vendors is under investigation. The FAA welcomes recommendations as a part of this market survey response. | |
| 43 | Market Survey Announcement | Question 12 | […] how would you recommend architecting the solution with respect to FAA cybersecurity concerns regarding FAA security policy and processes? | The FAA cybersecurity concerns expected to be addressed in this question do not appear to be addressed in any of the technical documentation released with the RFI. | Please specify/clarify the requirements. | S | The FMDS system must meet FISMA High and FedRAMP requirements. The FAA seeks recommendations on achieving these requirements using a service-based model. | |
| 44 | Market Survey Announcement | Question 13 | The FAA is considering use of Other Transaction Authority (OTA) for industry collaboration during the investment analysis process. This OTA could enable sharing of TFMS code and iterative prototype development […] | Is the prototype intended to exercise the ConOps in collaboration with the CDM Community? | Please clarify. | S | The scope of the OTA is not yet defined. FAA desires to maximize the utility of a prototype and possible partnership and desires industry recommendations accordingly. | |
| 45 | Market Survey Announcement | Question 13 | The FAA is considering use of Other Transaction Authority (OTA) for industry collaboration during the investment analysis process. This OTA could enable sharing of TFMS code and iterative prototype development […] | Is it intended throughout the OTA process for the FAA to receive rights in any derivative prototype IP created by the OTA Recipient from the FAA-provided TFMS code? | Please clarify. | S | The scope of the OTA, including data rights, is not yet defined. FAA desires to maximize the utility of a prototype and possible partnership and desires industry recommendations accordingly. | |
| 46 | Market Survey Announcement | Question 6 | Please specifically address security considerations and controls necessary for integration with primary FAA users located in FAA facilities | Does FAA envision FMDS to be categorized as a FIPS 199 High or Moderate system? | Please clarify.. | S | FMDS is categorized as FISMA High. | |
| 47 | Market Survey Announcement | X. Submission Instructions | […] Responses to this market survey should be no more than 30 pages long […] | Would oversized pages (e.g. 11x17) pages be allowed as part of the response? Would oversized pages count as one page or two pages? | Please clarify. | A | Oversized pages are permitted and will count as two pages. | |
| 48 | Market Survey Announcement | X. Submission Instructions | […] Times New Roman 12 Font […] | Would different and smaller fonts be allowed for graphics and table, assuming the information remains readable? | Please clarify. | A | Smaller fonts (8 pt.) are permitted for graphics and tables. | |
| 49 | Attachment 6: FMDS Human Interface Guide | Section 1.2 | […] expected to be deployed in 2026. | This deployment date for FMDS is inconsistent with the 2027 date identified in the ConOps. | Please clarify. | A | The Human Interface Guide is not to be used for deployment scheduling. | |
| 50 | Attachment 5: Acquisition Strategy White Paper | 3.2.1 FAA Responsibilities | 2. Approve design, development, and testing of vendor service | In a services model, the service provider owns service development; how does FAA propose they approve the development of the vendor service? | Please clarify how the FAA would approve the service development? | C | The FAA would approve the development methodology and processes used by vendors. The FAA welcomes recommendations as a part of this market survey response. | |
| 51 | Attachment 5: Acquisition Strategy White Paper | 3.2.2 Service Provider Responsibilities | The relationship between the FAA and the service provider is shown in Figure 3 | In Figure 3, within the FAA circle, lists "Own System Requirements". How does the FAA own system requirements within a service model? | Should this text read, "Own Service Requirements"; please clarify. | C | Yes, the FAA owns service requirements in a service model. | |
| 52 | Attachment 5: Acquisition Strategy White Paper | N/A | N/A | Does the FAA envision providing GFI/GFE for either of these acquisition alternatives? | Please provide clarification. | C | The FAA will provide GFI/GFE to the extent deemed necessary and productive for the acquisition. | |
| 53 | Attachment 5: Acquisition Strategy White Paper | 3.2 Service Acquisition | N/A | This section does not address data storage. How does the FAA plan on handling this within the Services Model? | We recommend the service provider own the data storage environment. | The FAA welcomes such recommendations and associated rationale. | ||
| 54 | Attachment 1: Concept of Operations | The various TFMS web applications that NAS users must currently monitor separately will be streamlined and accessible via a centralized portal. NAS users will be able to subscribe to notifications of changes in TMIs, operations plans, and other information, relieving them from the need to poll or scrape2 several websites. | A streamlined and accessible centralized portal is described as the new means of accessing the web applications detailed in Con Ops Appendix B, TFMS Web Applications. There are no preliminary requirements for this streamlined and accessible centralized portal in Attachment 2, Preliminary Program Requirements for Flow Management Data and Services (FMDS) for Investment Analysis Readiness Decision (IARD). | Please provide clarification on preliminary requirements for the streamlined and accessible centralized portal for accessing TFMS Web Applications. | S | The functionality provided via the web applications are included at a high level in the pPRD. Detailed specifications for specific applications will be provided via the specs as part of the SIR. | ||
| 55 | Attachment 3: Implementation Strategy White Paper | 4.1 TFMS ReHosting | The TFMS program will soon be rehosting the Web Applications portion of the Auxiliary Subsystem in a virtual environment (see Figure 4‑1). | The FAA describes a two phased approach and also mentions that the TFMS Web Apps will be “rehosted”. It is unclear as to if this rehosting will be in place prior to award or if it is actually part of the FMDS contract. Is this essentially a phase 0 approach? | Need to understand if the TFMS Web Apps will be rehosted prior to contract award or if it will be part of the FMDS contract | C | The rehosting of the web applications is not part of the FMDS acquisition. It will be done prior to FMDS by the TFMS program as a sustainment activity as the hardware is at end of life. | |
| 56 | Attachment 3: Implementation Strategy White Paper | 4 Implementation Strategy | Phase 1 &2 discussion on retiring capability | Will there be an FAA defined process involving V&V acceptance of releases for an agile process? What is the FAA engagement in Witnessing and Monitoring Agile activities as part of supporting timely acceptance process? Are their plans or concepts for the shared use of testbed(s) by the vendor and FAA? | Please clarify. | C | The FMDS program is looking for ideas from industry on how to evolve to a more agile-like development process that includes the government in final V&V acceptance of releases. The FAA welcomes recommendations as a part of this market survey response. | |
| 57 | Attachment 3: Implementation Strategy White Paper | 5 Implementation Strategy | Phase 1 &2 discussion on retiring capability | Are then any plans or requirements for acceptance criteria before a legacy application is retired? | ||||
| For example: Are there any plans on maintaining legacy applications running simultaneously to new Applications? | Please clarify. | C | There will need to be acceptance criteria established before a legacy application is retired, but that has not been developed yet. The FAA welcomes recommendations as a part of this market survey response. | |||||
| 58 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 3.1.4.1 Replay TFM Data | N/A | Replay of TFM Data capability may have impacts on architecture and local workstation memory. Please clarify if this capability is desired at all or select locations and workstations, and is there a maximum desired Replay TFM Data time frame (e.g., 24, 48, 72 hours, etc…) | Recommend specific requirements for maximum desired Replay TFM Data time frame by location, workstation, user category, or other desired parameter. | S | Assume that replay capabilities are required at all FAA locations for the past 15-days. | |
| 59 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 3.1.5.1 Display Flight Data | N/A | Display Flight Data doesn’t provide performance requirements for any hover or mouseover type commands which will drive local workstation design (e.g., memory cache). For instance, aircraft icon data blocks will be depicted on the integrated display within one second of hovering over the aircraft icon. | Recommend a specific requirement for User Interface performance requirements, such as displaying flight data. | |||
| Please provide additional information on the FAA's operational testing on the user interface. | C | Detailed performance requirements are under development. Please include any recommendations in your response to this market survey. | ||||||
| 60 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 3.1.6.2 Archive Data | N/A | Archive Data is silent on the duration of time information is required to be archived, which may have impacts on architecture. | Recommend a specific requirement defining the time parameters for archive data (e.g., ten years), or if archive has no time bounds. | C | Please include any recommendations in your response to this market survey. | |
| 61 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 3.1.6.1.4.2 Record Demand Capacity Imbalance | N/A | Record Demand Capacity Imbalance Notifications does not include the recording of in-use Monitor Alert parameters and sector occupancy values, which are fundamental to conducting post-operations analyses of demand-capacity imbalances. Recommend a specific requirement to record the in-use Monitor Alert parameters and sector occupancy values. | Recommend a specific requirement to record the in-use Monitor Alert parameters and sector occupancy values. | S | Please include any recommendations in your response to this market survey. | |
| 62 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 3.1.6.2.4.2 Archive Demand Capacity Imbalance Notifications | N/A | Archive Demand Capacity Imbalance Notifications does not include the archiving of in-use Monitor Alert parameters and sector occupancy values, which are fundamental to conducting post-operations analyses of demand-capacity imbalances. | Recommend a specific requirement to archive the in-use Monitor Alert parameters and sector occupancy values. | S | Please include any recommendations in your response to this market survey. | |
| 63 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 3.2.3 Data Retention | 3.2.3 Data Retention |
FMDS_pPRD_958. The FMDS Program Office must establish a data retention policy to determine the data-specific minimum time frame for access to operational data.
FMDS_pPRD_959. The FMDS Program Office must establish a data retention policy to determine the data-specific minimum time history for access to archived data.
FMDS_pPRD_960. The FMDS system must implement operational data retention in compliance with the data retention policy.
FMDS_pPRD_961. The FMDS system must implement archived data retention in compliance
| with the data retention policy. | 3.2.3 Data Retention policies for minimum time frame and minimum time history will need to be defined prior to RFP in order for contractors to developing pricing values. | Recommend Data Retention policies for minimum time frame and minimum time history be defined prior to RFP issuance | C | Please include any recommendations in your response to this market survey. | ||||
| 64 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 3.1.6.8.1.2 Save Scenario | 3.1.6.8.1 FMDS_pPRD_885. The FMDS system must provide authorized users the capability to save a scenario. | There is no mention of the number of scenarios that can be saved and whether or not the saved scenarios fall under the FAA recommended data retention policy or if not, how long the scenario can or will be retained after saving. | Please provide clarification on the data retention policy. | C | Please include any recommendations in your response to this market survey. | |
| 65 | Attachment 3: Implementation Strategy White Paper | 1.4 TFMS Architecture | A simplistic view of today’s TFMS architecture is shown in Figure 1-3. | Is there a reference document that describes specific functionality or business application, by subsystem (Transition, Auxiliary, Portal, Application and Production Data), that will be either be kept, replaced, retired or consolidated in FMDS? Additional detail will provide better insight into size and scope of TFMS transformation. (i.e. provide a product roadmap and timeline). | Please provide clarification or additional TFMS reference documents. | S | By the end of Phase 2, all of the TFMS system will be retired and replaced by FMDS. The program is open to the idea of repurposing existing TFMS code within the FMDS architecture, and welcomes recommendations and feedback on that approach. No additional TFMS documentation is available for release at this time. | |
| 66 | Attachment 5: Acquisition Strategy White Paper | 3.0 Acquisition Alternatives | The FAA is considering multiple acquisition approaches for use in FMDS. Currently, the desired strategy is described below. The FAA may choose either of the strategies below or may pursue a traditional acquisition for FMDS via a prime vendor | Market Survey Question #13 states: "The FAA is considering use of Other Transaction Authority (OTA) for industry collaboration during the investment analysis process. This OTA could enable sharing of TFMS code and iterative prototype development. Please provide activities, considerations, and timeline for this approach that should be considered." |
OTA is not mentioned in the Acquisition Strategy Whitepaper, is this now a third alternative the FAA is considering?
| Please provide clarification. | S | The use of an OTA is not an acquisition alternative itself but may be used as a mechanism to aid a specific acquisition approach. The scope of an OTA has not yet been determined and could be used, for example, for prototype development in support of any identified acquisition approach. | ||||
| 67 | X Submission Instructions | Responses to this market survey should be no more than 30 pages long and must be in PDF format in Times New Roman 12 Font. | The submission instructions are silent on the font size of tables, figures, and graphics, and 12 point font is very large for tables, figures, and graphics. | We request that respondents be permitted to use no smaller than 8 point font for tables, figures, and graphics. | Smaller fonts (8 pt.) are permitted for graphics and tables. | |
| 68 | FMDS Market Survey 6-30-2022 | V. Requested Information, Question 1 | N/A | Is the Government looking for high-level feedback or would the Government consider allowing additional page count for industry to provide more thorough, comprehensive and valuable feedback on the content, clarity or completeness of the Attachment 2: FMDS Preliminary Program Requirements Document (pPRD)? | Given the amount of content in Attachment 2: FMDS Preliminary Program Requirements Document (pPRD), recommend the Government consider extending the page count (i.e. 10-15 pages) to obtain more thorough, comprehensive and valuable feedback from industry. |
| Suggested Text: X. SUBMISSION INSTRUCTIONS, “…Responses to this market survey should be no more than 40 (or 45) pages long and must be in PDF format…” | S | The preliminary PRD is high level, specifications are under development. High level feedback from industry is sufficient, and there is no increase in page limit. | ||||
| 69 | Attachment 1: Concept of Operations | All | N/A | Would the Government consider seeking feedback, along with adding additional page count, to offer industry the opportunity to provide thorough, comprehensive and valuable feedback on the content, clarity or completeness of Attachment 1: Traffic Flow Management Concept of Operations for Flow Management Data and Services (FMDS) for Investment Analysis Readiness Decision (IARD)? | Given the importance of the Traffic Flow Management Concept of Operations for Flow Management Data and Services (FMDS) for Investment Analysis Readiness Decision (IARD) document, industry believes there may be benefit to the Government in offering industry the opportunity to provide feedback during this phase of the acquisition. |
| Suggested Text: “Please provide feedback on the content, clarity, or completeness of Attachment 1: Traffic Flow Management Concept of Operations for Flow Management Data and Services (FMDS) for Investment Analysis Readiness Decision (IARD).” | S | The preliminary PRD is high level, specifications are under development. High level feedback from industry is sufficient, and there is no increase in page limit. | ||||||
| 70 | FMDS Market Survey 6-30-2022 | V. Requested Information, Question 9 | If a phased implementation is pursued by the FAA, do you think it is reasonable to leverage TFMData to provide the required services during the rollout of FMDS? | Could the Government please provide further detail or a list of the “required services” from TFMData necessary to support the rollout of FMDS during a phased implementation? | Rationale: In order to provide a thorough and comprehensive response of reasonableness to leverage TFMData during the rollout of FMDS, providing a list of the “required services” from TFMData would be beneficial to industry. | S | The TFMData services are defined in Attachment 4. Required services would include Flight Data, Flow Information, and the majority of the Request/Response services, with the exception of those designed to support data exchange with CDM members. | |
| 71 | While the documentation provides a potential implementation strategy, it doesn't address the programmatic transition of overall program from the incumbent to the new contractor. | Recommend development of a transition strategy and model that is loosely coupled with acquisition strategy, and then tightly coupled post award. This should include some type of governance activities that include the FAA, the new contractor and the incumbent. | ||||||
| S | The FAA welcomes recommendations and associated rationale. | |||||||
| 72 | There are various acquisition options in play. The decision on which will be used will impact at least the program requirements, service level agreements, and associated reporting metrics. Does the FAA foresee and plan for having to pivot with what content is produced and required for the eventual SIR based upon acquisition decision? | |||||||
| S | Yes. The format and content of the SIR will be shaped by the acquisition decision. | |||||||
| 73 | We don't see the 2 controlled documents that were distributed in the first Market Survey. And there isn't a clear revision in this survey. |
- Attachment 1: Traffic Flow Management (TFM) Functional Analysis Document for Flow Management Data and Services (FMDS), Draft Version 0.63, September 15, 2020
- Attachment 2: FMDS Data Lexicon V0.63
| Please provide to ensure all of the participating industry has all of the same information and thus having a level competitive playing field. | C | Those documents are now outdated and should not be used as a reference. All documents needed to respond to this market survey have been provided. | ||
| 74 | What additional technical documentation will FAA provide regarding the As-Is TFMS model and the To-Be FDMS model during the pre proposal and proposal timeframe? What can we expect to receive and use post award? | |||
| S | The FAA welcomes recommendations industry and what models and other document will be helpful. | |||
| 75 | Market Survey Announcement | October 15 destruction requirement | Why the 90 day destruction in the middle of an active acquisition process and the docs will be valid and active thru the whole process. Will FAA re-distribute and destroy for each Release? | |
| C | Yes, documentation will be updated and re-released throughout the acquisition process. Program documentation will evolve throughout the investment analysis and acquisition. | |||
| 76 | Attachment 1: Concept of Operations | Is the use of existing data stores and analytics tools that may currently exist within the FAA for post event analysis anticipated? | ||
| S | FMDS requirements for post-event analysis are limited to those functions needed to support day-of operations and that are part of the TFMS tools today (such as replay or Real Time FSA). Other FAA programs will continue to support and/or evolve post event analysis capabilities. | |||
| 77 | Attachment 1: Concept of Operations | 2.3.2.5 | The CONOPS contains links that are not externally accessible (page 41). Can these links be updated or can the information be supplied in another way? |
| C | These reference documents are for internal FAA use only and are not made available through this market survey. The relevant information for the FMDS acquisition is included in the approved FMDS Concept of Operations. | ||||
| 78 | Attachment 1: Concept of Operations | 7 | Referenced documents | Referenced documents are not accessible. Can the FAA provide the documents? | |
| C | These reference documents are for internal FAA use only and are not made available through this market survey. The relevant information for the FMDS acquisition is included in the approved FMDS Concept of Operations. | ||||
| 79 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 2.3.2.1 | FMDS will be deployed in a NAS automation environment that is evolving to embrace new processes and technologies such as enterprise services; Cloud computing; continuous testing and continuous integration practices; and Agile acquisition, software development, and deployment processes [8, 9]. | ||
| If the service model acquisition strategy is adopted, this needs to be reworded to discuss interfacing within the NAS automation evolution strategy. | Recommend rewording after the acquisition strategy decision. | S | Please include any recommendations in your response to this market survey. | ||
| 80 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 3.4 | RMA requirements 3.4.1 through 3.4.3 | If the service model is selected, these requirements must be reworded to reflect Service Level Agreement metrics. | |
| Recommend development of SLAs based on industry best practices if the Service Model is selected. | S | Please include any recommendations in your response to this market survey. | |||
| 81 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 4.1.1 | Environmental Requirements | If the service model is selected, these requirements must be reworded to reflect Service Level Agreement metrics. | |
| Recommend development of SLAs based on industry best practices if the Service Model is selected. | S | Please include any recommendations in your response to this market survey. | |||
| 82 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 4.1.2 | Land and Facility | If the service model is selected, these requirements must be reworded to reflect Service Level Agreement metrics. | |
| Recommend development of SLAs based on industry best practices if the Service Model is selected. | S | Please include any recommendations in your response to this market survey. | |||
| 83 | Attachment 2: Preliminary Program Requirements Document (pPRD) | 4.1.3 | Telecomm | If the service model is selected, these requirements must be reworded to reflect Service Level Agreement metrics. | |
| Recommend development of SLAs based on industry best practices if the Service Model is selected. | S | Please include any recommendations in your response to this market survey. | |||
| 84 | Attachment 3: Implementation Strategy White Paper | 4 | The implementation strategy will be affected by the choice of the acquisition model. This section seems to be written with the 3.1 Multiple Vendor System Acquisition strategy and will need significant reconsideration using a service model. | ||
| Please clarify. | C | The implementation strategy should work with any acquisition model with the exception of a service-based contract. The FAA is interested in hearing from industry about commercial products that could be acquired via a service-based contract as opposed to custom development in order to assess the feasibility of that acquisition model. | |||
| 85 | Attachment 5: Acquisition Strategy White Paper | 3 | Currently, the desired strategy is described below. The FAA may choose either of the strategies below or may pursue a traditional acquisition for FMDS via a prime vendor. | In the first sentence, the use of the word "strategy" is singular whereas in the second sentence the FAA states "either of the strategies" or "traditional acquisition". | Should the first instance of the word "strategy" be plural indicating that the preference is either one of the two strategies described, or the traditional strategy, or is one of the referenced strategies the "desired?" If so, please indicate which one is "desired." |
| C | The desired strategy is the use of multiple vendors, listed first in the white paper. |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .