QandA_20250820.docx

UNCLASSIFIED

1. Will NGA remove all the FAA data from their DAFIF data file prior to providing it to the Contractor for merging?

The process to accomplish this will need to be developed, the details have not been determined yet. The answer to many of these questions will need to be answered during an iterative process development.

2. Which data source would be populating airways?

NGA data. However, we realize there are seams in between enroute and terminal data that will need to be worked through, see #1.

3. Will NGA be maintaining FAA enroute waypoints/data?

Yes

4. If CONUS-related airway data will be handled by NGA, will the FAA foundational data (Navaids/Waypoints) also be included in the dataset provided by NGA?

Per paragraph 3.1.3.1 of the SoW, “…This data shall include all required supporting data, including navigational aids (NAVAIDs) and waypoints.” All of the data required to code the instrument procedures will need to be included.

5. Is there guidance about how foundational data conflicts between neighboring countries/DoD airfields/dual-use airfields are to be deconflicted?

See #1. This will need to be worked through.

6. Are there expectations about alignment between CADP and NGA’s FLIP library coverage in CONUS?

There should be no alignment required. NGA currently does not “alter” or “correct” any FAA data, so NGA’s FAA data should be the same or very similar to data from a commercial provider.

7. Are FAA heliports and associated procedures expected to be included in the merged content?

No. NGA will provide all DoD heliport data to the contractor.

8. Will NGA own the CADP file and/or the tools which produce the CADP DAFIF File?

Paragraph 10 of the SoW addresses this directly: “10. DATA OWNERSHIP - The Contractor will maintain its own database(s) as required to execute the requirements within this contract. The deliverable data, data sets, databases, database content and finished products created under this effort shall be retained as NGA property and shall be used and maintained by the Contractor solely for executing these requirements. Ownership of the data, data sets, databases, database content and finished products shall not pass to the Contractor.” NGA will not own the tools, but paragraph 3.1.10 of the SoW has specific requirements for software tools.

9. What is defined as CONUS? Is it just the lower 48 states or does CONUS also include Alaska, Hawaii, and US Territories in Latin America and Western Pacific?

The CONUS term was incorrectly applied to this contract. Paragraph 2.0 states, “The CONUS Aeronautical Data Procurement (CADP) contract will provide instrument flight procedure (IFP) content, and all required foundation or additional data necessary, for all airports under the authority of the Federal Aviation Administration (FAA) in a digital format.” It is our intent to include all procedures produced and published by the FAA, as opposed to a sub-set of that data. This is a “cleaner” way to sub-divide the data in our opinion. If it becomes obvious that a different concept is a better option, we can adjust during the iterative process development period.

10. Per Sections 3.1.3, 3.1.5, and 3.1.7 - What is the official subset of DAFIF files and fields Garmin would be responsible for supporting for this effort? Can we get a definitive list so we can assess any data coverage gaps?

The affected DAFIF folders are: ARPT, HLPT, TRM, TRMH, WPT, PAPP, NAV, SUPP and SUPPH.

11. Related to Section 3.1.5 - Garmin generates terminal waypoints when ANSP-defined waypoints are lacking, using ARINC 424-style identifiers that rely on Airport Ident for uniqueness. DAFIF, by contrast, requires unique waypoint identifiers - independent of Airport Ident. Can computed waypoint identifiers be accepted temporarily? These computed identifiers would comply with DAFIF rules, but lack specificity in referencing radial or distance information in the ident. This should be acceptable.

12. Related to Section 4.2.1 - When exactly are T_TRANS records required - for adds, mods, deletes? Any format/validation edge cases we should know up front?

The T_TRANS files include only those records that were added, modified, or deleted when compared to the previous cycle only. We do not put this file through the same validation and verification process as the files in the DAFIFT folder. We note this in our release statement and tell users the T_TRANS files are not to be used for navigation.

13. In Section 3.1 the SOW says, "The contractor must submit to annual audits, or as required by the terms of their LOA." Are these audits from NGA or not?

As required to satisfy your LOA, by whichever entity conducts those audits. Section 5.3 covers Second Party Audits. These would be conducted by NGA.

14. In Section 3.1.10.1 the SOW says, "All tools and software must be reviewed and qualified per DO-330/ED-215, as adapted by DO-200B/ED-76A, as required." Is grandfathering of tool qual under DO-200A acceptable?

Yes. The intent of this statement is to ensure the contractor is in full compliance with DO-200/330 tool qual requirements. If the grandfathering is in compliance, it is acceptable.

15. In Section 3.1.11 the SOW says, “Any major production or process change requires written notification and NGA approval prior to implementation." Can we use our Major/Minor criteria defined in our SOP or does NGA have their own?

The contractor can use their own criteria.

16. In Section 5.3 – Secondary Party Audits, who is the "Second Party" referring to? Is it NGA, USAF, etc?

See 13 above. This would be NGA. NGA’s CNS/ATM audit authority is the FAA with USAF (HBAI) assisting. We do not anticipate a need for FAA/USAF to participate in any second-party audits of the contractor.

17. Can you further clarify Section 10 - Data Ownership? I can’t tell whether NGA is only claiming property right on the delivered data, or even data we’d be retaining in internal databases that is used to create Garmin Navigation database products today? Will we retain any ownership/rights to any additional data collected specifically for this effort?

The contractor will have no ownership of any data transferred to them under this contract that is not already part of their data holdings. The initial production concept is NGA will send its complete DAFIF dataset to the contractor without the FAA procedures. The intent of this section is that any data contained in this dataset that is not already part of the contractor’s data collection cannot then be used in the contractor’s products distributed to user’s not associated with this contract. Much of this foreign data is obtained by NGA through formal foreign government information sharing agreements. Many of these agreements limit the distribution. DAFIF is UNCLASSIFIED, but is considered LIMDIS (Limited Distribution), even though it is not marked as such. It is intended only for US DoD, other US government agencies, and approved foreign partners. The contractor would be permitted to use the data for internal processes, such as data verification and validation.

18. Are there any timekeeping requirements? I don’t think I saw any but want to make sure either way.

No.

19. Section 1 - There is language regarding suppliers being cloud native. “Suppliers must be flexible in adjusting to NGA’s cloud implementation as it rolls out. Suppliers must be in step with our shift to the unclassified cloud environment.” What is intended by this with regards to the deliverables of this SOW?

The language here refers to general IT concepts being implemented by NGA. These statements may not be directly related to this effort.

20. Section 2 and 3.1.7.1 mention ARINC424-34 XML. Can we separate out the DAFIF 9.0 (XML format) output as a separate piece of the SOW that we can bid/estimate once DAFIF 9.0 is finalized and published or does that need to be accounted for in this proposal?

The SoW mentions ARINC 424-23, not -34. It states, “…the Contractor will be required to produce a product IAW the DAFIF® 8.1 specification now, and possibly the ARINC 424-23 XML specification… at a future date under this contract. The purpose of adding this statement about the 424-23 XML specification is to inform the contractor that NGA is currently working on a DAFIF output using this specification, and that it will be a future need. As stated in section 2, the exact date of implementation that would drive contractor requirements is not known at this time, so it is difficult to determine when there would be contract implications.

21. Section 3.1.10 says "Any tools, software, database, or automated processes shall be approved by NGA prior to use." What does this entail?

The intent of this section is to ensure any changes to software and tools are communicated to NGA. This would entail email notification with enough detail for NGA to understand how the change potentially impacts the final DAFIF dataset. If questions remain, a dedicated discussion may be required to ensure NGA is satisfied of the impacts of the change. This process may be similar to requirements that may be in a data suppliers LOA that require them to report “minor and/or major” changes to production processes to their LOA issuance authority.

22. Section 5.4 - The language regarding SUPPLIER CORRECTIVE ACTION REPORT (SCAR) seems to imply that NGA has broad leeway to direct contractor to resolve a problem or observation within a timeline established by NGA, arbitrated by NGA. What standard is the contractor being judged against here? Doesn't the contractor's compliance with their own Type 1 FAA LOA make such audits unnecessary since FAA would serve as the compliance authority? The process to merge the contractor’s data with NGA’s data will be an unusual arrangement, at least for NGA. NGA will consider the final DAFIF dataset to be 100% NGA’s data, and therefore our responsibility. Although we have had discussions with our audit authority about this process, we do not know the exact effect on NGA’s LOA, or if it will impact the contractor’s LOA. Therefore, NGA will reserve the right to conduct second party audits of the contractor’s processes, to ensure compliance with NGA’s LOA. The SCAR process is not directly related to the second party audit, except that a serious issue identified by a SCAR may result in an audit. The lack of a defined timeline for SCAR resolution is only intended to provide flexibility, as some issues identified by a SCAR may be minor, and some more serious, therefore requiring different timelines to resolve.

23. Section 5.5 - Verification and validation software (e.g., RAV tool) is mentioned in Table 1, is contractor intended to perform this function? Can NGA provide this software to contractor?

NGA’s RAV tool is mentioned in the table only as an example of how a data supplier can meet verification and validation requirements. NGA does not know the details of other suppliers’ processes and therefore cannot reference them by name. It’s assumed that each supplier has their own V & V tools. It may become obvious during the iterative process development that all or part of NGA’s RAV tool should be used by the contractor.