MQ9 CSO AOI0002 Government RFI Responses.pdf

Questions Regarding CSO-AFLCMC-WIIK-2020-0001/AOI0002

1. On Page 9 of CSO-AFLCMC-WIIK-2020-0001 it states the Technical Proposal portion “shall not exceed 10 pages, excluding cover page and table of contents” however, adding up the suggested pages per each section (Abstract, Scope, Credentials, Work to be Performed, Performance Schedule, References) of the Technical Proposal the total is 25 pages and far exceeds the 10 page limit cited for the Technical Proposal. Will you please clarify whether the Technical Proposal page limit is 10 pages or some other number?

a. Government Response: The CSO Technical Proposal portion should read “shall not exceed 25 pages”. And updated version will be posted.

2. The SOO that was provided references the following two documents that we have not been able to find publicly; (MQ-1/MQ-9 MQ-9 Program Protection Plan; MQ-1/MQ-9 MQ-9 Reaper Security Classification Guide (SCG)). Will you please either provide these documents or point us to where we can obtain them so that we can review and determine impact to this project?

a. Government Response: References in the SOO to these 2 documents were made in error. We have removed the references to these 2 documents.

3. The TMCR provided states, “Technical manual data shall be written to a scope and depth of coverage to support the REAP PHASE 2 operations and maintenance concepts.” Will you provide us with a copy of the REAP PHASE 2 operations and maintenance concepts or let us know where we can obtain this information?

a. Government Response: An updated (“Clean”) TMCR is provided as part of this response.

REAP PHASE 2 language was inadvertently included in the TMCR and updated version of the TMCR removes that language.

4. According to the SOO (para. 3.2.1.1) that was provided, “The Contractor shall conduct the conversion and integration of MQ-9 Original Equipment Manufacturer (OEM) Source Data associated with existing capabilities to an S1000D-compliant format.” However, the TMCR that was provided states, “The Contractor shall develop TO files (tagged instances) using SGML according to the DTDs referenced in the appendix to MIL-STD-38784 and each applicable military detail specification (MIL-DTL). Multiple SGML file instances for a single TO document for final delivery are not authorized.” Are we to convert the legacy SGML to S1000D-compliant XML or is the requirement to maintain the legacy SGML per the USAF legacy specifications and standards? If it is the latter, maintain in legacy SGML, do you expect the IETM Viewer to support S1000D XML and all of the legacy USAF SGML specifications to which the MQ-9 data has been authored because we understand this solicitation asking only for an S1000D Viewer?

a. Government Response: The SOO language is correct. We require conversion of SGML textual data and CGM graphics to S1000D. This data will consists of existing data from existing capabilities (backlog) as well as future data to be provided throughout the duration of the contract PoP. There is an existing Common Source Data Base (CSDB) of previously S1000D-converted MQ-9 data that must be viewable through the provided viewer, however, has already completed all val/ver activities. Should any modifications to the pre-existing S1000D data is required (tagging, TO Updates, etc.), that capability should be provided through the authoring functionality provided as part of the viewer.

To summarize, the scope as outlined in the SOO, and the process as outlined in the TMCR, are intended to provide the government with the ability to view existing S1000D-converted CSDB and enable/support the conversion of a backlog of existing Source Data allowing for the viewing of that data in either the S1000D viewer provided by the vendor, or any other S1000D viewer.

5. Per SOO (para. 3.2.2, items 5 – 9), will the solution be required to interface with an external system(s) to submit the AFTO forms or will an email solution suffice? If required to interface with an external system(s), will we have access to each system’s Application Programming Interfaces (APIs)?

a. Government Response: In the spirit of a Commercial Solutions Opening (CSO) approach, we invite responses to introduce their most innovative solution to this requirement. As reflected in the SOO, the Government would like to be able to have an automated routing process of change requests, originating in the viewer, with subsequent notification to individual accounts. There are no APIs that will be provided by the Government at this time.

6. 6. Per SOO (para. 3.2.2, item 14), does the Automated Val/Ver tool refer to Val/Ver of the XML files against the S1000D schemas? If it’s Val/Var of the TO content, we feel that is a manual procedure done on aircraft or via tabletop Val/Ver efforts.

a. Government Response: The Val/Ver tool referenced refers to the Val/Ver of the XML files against the S1000D schemas. The TO content itself will be Val/Ver’d by people in a separate, more analog process.

7. Please clarify this requirement in item 23 of SOO para 3.2.2. Is the requirement for:

• An API from the viewer to an external authoring tool, or to a CSDB for the

“author” to make changes to the data/XML?

• Or for the viewer to provide the capability for the “author” to make changes to the local XML Data?

a. Government Response: The requirement in the SOO for the “Ability for users (by role) to author organic changes”, highlights the fact that not all data will come from the OEM, and sometimes very small changes will have to be made quickly through the viewer (to add/subtract/modify content) by a select number of individuals (permission-based). We want that ability available to a very select few individuals.

In the spirit of a Commercial Solutions Opening (CSO) approach, we invite responses to introduce their most innovative solution to this requirement.

8. Per SOO (para. 3.2.2, item 27), Ability to manually configure viewable A/C and GCS data and save said configuration, is this requirement asking if the viewer can interface into existing product configuration databases to:

• Load the data in the viewer according the specified configuration?

• Allow users to set/edit a product’s configuration and save (via APIs) to their product configuration database?

a. Government Response: Through Source Data Applicability Tagging, the viewer needs to allow for users to set the a/c configuration and parameters based on the information in the viewer. Due to the fact that not all data applies to all a/c, this ensures that when a tail number is selected, a maintainer/pilot only sees information applicable to that a/c. If configuration data is known to be wrong or needs to be modified due to mission demands and reconfiguration of an a/c, the viewer needs to be able to have viewable data changed (change the applicability tags in the source data) and saved. This is just like selecting the year, make, model and trim package of your car when shopping for parts online; we need to be able to alter the viewable data for a particular tail number.

9. Per SOO (para. 3.2.2, item 30), Open compatibility on multiple OS/iOS/Android/PC devices, will these devices be operating in a connected mode or will any of these devices be operating in a disconnected mode? If devices will be required to operate in disconnected mode, which of these devices will operate in disconnected mode?

a. Government Response: The viewer must be able to operate on multiple platforms, within multiple OS’s, in connected and disconnected modes. The devices running in disconnected modes could be anything from a tablet to a laptop.

10. 10. We understand that the MQ-9A data has been converted to a specific S1000D solution.

Is the MQ-9 Program Office looking to switch solutions (i.e., S1000D Viewer) or is the intent to convert the data to support a specific solution?

a. Government Response: The MQ-9 enterprise has a converted Common Source Data Base (CSDB) of tagged data ready for display in a S1000D viewer. We also have a (growing) future need to convert SGML and CGM data provided by OEMs to the vendor-provided S1000D solution, and then displayed in a vendor-provided S1000D viewer.

11. Are there estimates (page count or other) on the amount of data that is in legacy SGML and/or PDF that need to be converted to S1000D XML?

a. The backlog of Source Data requiring S1000D conversion (as of 1 June) is anticipated to require modifications to ~300 modules. Additionally, the MQ-9 Enterprise receives new/updated data that, on average, requires modifications to 51 modules each month. This should be anticipated as the conversion scope for the duration of the PoP. Caveat: that the numbers provided are estimates to assist offerors in creating their proposals but should not be construed as a constraint on the requirement.

12. The SOO received with the RFP is dated 20 May 2020 and the model contract under the

CLINs is dated 13 May 2020. My assumption is that the model contract is a sample only. In this case the dates are so close to each other that I do not want to assume. Is my assumption correct?

a. This 13 May date is a typo. All documents included in the RFP are up-to-date.

The model contract is indeed a sample. This will be replaced with a contract based on the sample at time of award.