Encl-3_White.Paper.Submission.Instr_ FINAL.docx

W900KK-22-R-00XX

ENCLOSURE 3: W900KK-22-R-0012

WHITE PAPER SUBMISSION INSTRUCTIONS

OFFEROR CONSIDERATIONS AND CAVEATS

Step-One Call for White Papers See Enclosure 1 - Research Opportunity Guidance’s respective Opportunity Notice for the established date for timely submission of white papers. All white paper submission must be received before the prescribed cut-off date, if identified, or will not be considered. This enclosure is specific to STEP-ONE white paper submissions only. Instructions for submissions in response to Request for Proposal/Solutions, if solicited, are provided in Enclosure 4 - Proposal Submission Instructions. Offerors are reminded that they will be solicited under Enclosure 4 instructions if the Government assesses a favorable review of the white paper with other factors considered.

The primary basis for selecting white papers for acceptance is technical, importance to agency programs and funds availability (with cost/price realism considered).

Teaming Perspectives This BAA is intended to encourage the use of complementary, interdisciplinary research and development teams consisting of industry, academia, national test centers, and/or laboratories that leverage individual strengths coupled with unique resources and experience. Offerors must be willing to cooperate and exchange software, data and other information in an integrated program with other contractors. The TRMC T&E/S&T Program will not actively participate in the creation of project teams. If an offeror is proposing a contribution arrangement with a Government/Federal laboratory (personnel, services, facilities, and equipment) as a joint effort to develop the technology, a Cooperative Research and Development Agreement (CRADA) may be required. If an established CRADA exists between the offeror and the intended Government laboratory/entity, the offeror shall provide a copy of the CRADA when submitting the proposal.

Offerors may propose subcontracting and teaming arrangements; however, it is expected for FAR based solutions that the submitting offeror will lead and perform 50% of the effort by cost. For OTs, the lead offeror, if seeking to qualify as a non-traditional defense contractor, must participate to a "significant extent." There is no set dollar amount or percentage of work that is considered a "significant extent" and offerors must provide justification to support a determination by the Contracting Officer that they are participating to a "significant extent."

System for Award Management Registration All potential offerors, in order to be considered must be registered in the System for Award Management (SAM) at https://www.sam.gov. By submission of a white paper, the prime offeror acknowledges the requirement that they shall be registered in the SAM database. NOTE: New registrations can take an average of 7-10 business days to process in SAM.

Submission Marking Requirements Potential offerors are responsible for clearly identifying proprietary information. Submissions containing proprietary information must have the cover page and each page containing such information clearly marked with a label such as “Proprietary” or “Company Proprietary.” NOTE: “Confidential” is a classification marking used to control the dissemination of U.S. Government National Security Information as dictated in Executive Order 13526 and shall not be used to identify proprietary business information. Per the Enclosure 5 - Administrative and National Policy Requirements section for Disclosure of Information and Compliance with Safeguarding Covered Defense Information Control, applicable page markings for any identified CUI or CTI information must be indicated.

TRMC will protect all white papers and proprietary information from unauthorized disclosure and will only disclose the contents for the purpose of evaluation. Offerors are responsible for marking proprietary information with the proper disclosures. This requirement applies to both white paper and full proposal submissions, if solicited.

Government Intentions Regarding White Paper Submissions The Government intends to select solutions without discussions based upon its evaluation of white papers; however, the Government reserves the right to hold discussions or obtain clarifications of the white paper with the offeror, if deemed necessary.

This announcement does not commit the Government to pay for the preparation of white papers. The cost of preparing a response to this announcement is not considered an allowable direct charge to any resulting award.

Research Project Eligibility Considerations Offerors are reminded this BAA is for the acquisition of advanced technology directed toward advancing the state-of-the-art of test and evaluation technologies, and increasing knowledge and understanding of the trade-offs between optimizing different parametric elements that are required to enable the advancement. White papers related to the development of a specific system will not be accepted since they are non-conforming to the intent of this BAA.

All research projects must meet the following eligibility requirements for consideration:

· T&E Need. The candidate project must address limitations in the current T&E infrastructure to measure or assess performance of a DoD military capability, system, prototype, or concept.

· S&T Proposed. The candidate project shall develop one or more specific innovations distinct from engineering efforts to improve an existing capability, involving technology at TRL 3-6. DoD TRL definitions: https://api.army.mil/e2/c/downloads/404585.pdf A submission that does not identify a T&E Need and the S&T Proposed within TRL3-6 will be considered non-compliant.

Research interests are defined as topics within specified domains per Enclosure 1 – Research Opportunity Guidance. The functional domain of a topic is amplified in the Annex – TTA Descriptions document. The listed topics are based upon either validated, critical technology shortfalls that satisfy DoD T&E infrastructure investment roadmaps, or for TRMC-identified short-notice, critical needs.

Highlighted Policy Areas Regarding Offeror Participation Expectations TRMC’s Test and Training Enabling Architecture (TENA) is a system architecture designed to bring interoperability to United States Department of Defense test and training systems. TENA is designed to promote integrated testing and simulation-based acquisition through the use of a large-scale, distributed, real-time synthetic environment, which integrates testing, training, simulation, and high-performance computing technologies, distributed across many facilities, using a common architecture. TRMC-sponsored technology and capability development pursues TENA-complaint software architecture and development, where applicable. See https://www.tena-sda.org for more information. Project submissions shall support TENA compliance unless identified in the submission as not applicable nor value-added in doing so.

Enclosure 5 – Administrative and National Policy Requirements and the associated attachments that address Disclosure of Information and Compliance with Safeguarding Covered Defense Information Controls, Organizational Conflict of Interest, and Intellectual Property should be clearly understood prior to developing white paper and proposal submissions.

WHITE PAPER SUBMISSION PROCESS

1. Submission Method and Guidance The offeror shall submit white paper and requested proposals only via email. Submissions shall not exceed email size of 10MB for white paper submission documents including digital signature. Submissions that DO NOT contain any CUI, including CTI, shall be sent via UNCLASSIFIED email to usarmy.orlando.peo-stri.list.trmc-te-st-baa@army.mil. The subject line of the email shall include:

1) The TTA abbreviation (for the submission’s topic), then (dash)

2) Proposed project acronym/initialism , then (underscore) For the offeror’s proposed project title, create a project acronym/initialism (preferably four to five characters, but no longer than six)

3) Offeror’s organization identifier, then underscore) Organization identifier shall be created as follows: ‘Company or Academia acronym’(1), then (hyphen), ‘Business Unit Designation’(2), and using these conventions:

- (1) one word name (or acronym/initialism) with no more than 8 characters included

- (2) acronym or abbreviation of business unit or location with no more than 5 characters - omit if none.

4) “BAA # (insert correct designation with associated Opportunity Noticenumber after an underscore) White Paper submission”.

*example subject line* “HSST-SPEEDY_BDC-HS_W900-22-R-0012_1.3 White Paper Submission” This is based on the response to a High Speed Systems Test TTA topic that was submitted by Big Defense Contractor's Hypersonics Solutions business unit and where the project submission’s initialism is “SPEEDY”. The submission was made under the BAA’s Opportunity Notice 1.3.

NOTE: If sending updates to any submissions, add “_r(#)” onto the encoded project submission name, as follows:

*example subject line* “HSST-SPEEDY_BDC-HS_W900-22-R-0012_1.3_r1 White Paper Submission” for the first revision/update to the submission.

All attached files associated with the white paper submission shall use a file name convention as described in paragraph B.

Submissions that DO contain any CUI, including CTI, must be transmitted via DoD SAFE (https://safe.apps.mil). If an offeror is a ‘guest’ per the DoD SAFE guidelines, a drop-off request must be submitted per the BAA document, and after receipt of an email with the drop-off code, a submission shall be made for the ENTIRE white paper package to ensure it remains intact vs. only CUI documents. Follow other guidelines provided in the DoD SAFE email sent. Place the email subject line described above in the drop-off field labeled “Short Note to the Recipient.” Also identify which files contain CUI in this field.

The offeror should mitigate the impact of any possible transmission interruptions by submitting well in advance of any deadline. The offeror shall ensure that the data sheet, title page, and all forms are signed by an authorized official for the offeror. The offeror shall ensure the submission is sent to the correct email address as listed above. Submissions sent to an incorrect email address will not be evaluated. The offeror may not submit by fax or in person, as any submission not received via the approved method will not be evaluated. Other guidance includes

· Submissions are expected to be UNCLASSIFIED. If submission of CLASSIFIED information is approved, follow the instructions provided by ACC Orlando Contracting Officer. Note that requests should be made well before the submission due date to allow for the request’s review and approval in time.

White paper and proposal submission documents shall be letter size (8.5 x 11 inches), have one-inch margins on all sides, and use a 12-point font. Any figures, schematics, drawings, diagrams, schedule charts, and tables may also include single-spaced text that shall use a font not smaller than 8 point. Any pages beyond these limitations will not be evaluated. The responses shall address the entire proposed period of performance, including all options or phases and/or milestone events. If applicable, each page must reference any proprietary data disclosure statements and CUI in the one-inch bottom margin as a footer with appropriate markings discussed previously.

DO NOT SEND – Hardcopies of white papers (including facsimiles), ZIP files, and/or password-protected files. Oral presentations are not permitted.

White Paper And Related Document Instructions Separate White Paper package submissions are required for each topic submission the offeror is interested in pursuing. In all circumstances a white paper submission shall consist of the following items as separate files, also using a specified file naming convention.

The same convention for the submission name that is used for the email subject line is also used for the first element of the file name.

The second element of the file name is a suffix abbreviation as indicated under each required document description below.

*example file name* “HSST-SPEEDY_BDC-HS_WP” This is based on the prior example as the first element and by using the “WP” abbreviation for the white paper document, as delineated per below.

If the document was submitted as a revision to a prior submission, include the revision/update number per the below example:

*example file name* “HSST-SPEEDY_BDC-HS_WP_r1” Required document submissions:

1) White Paper (WP) (limited to ten pages of submission content, as specified)

· Format: Office Open XML Document (.docx) or Portable Document Format (.pdf)

· Naming convention suffix abbreviation: WP

· NOTE: if the file contains controlled unclassified information, add “_CUI” at the end of the file name

2) Attachment 1 - White Paper Data Sheet (DSX) (completed but unsigned)

· Format: Office Open XML Workbook (.xlsx)

· Naming convention suffix abbreviation: DSX

3) White Paper Data Sheet (DSS) (signed)

· Format: Portable Document Format (.pdf)

· Naming convention suffix abbreviation: DSS

4) Attachment 2 - Related Work History/Experience (WH)_

· NOTE: This shall be submitted for work related in support of a single TTA’s area of responsibility, as it is defined in the Annex-TTA Descriptions document. If an offeror is submitting multiple white papers for multiple topics within a TTA, this form may be completed for all work supporting that TTA and submitted for each white paper submission for compliance. Format: Office Open XML Workbook (.xlsx)

· Naming convention suffix abbreviation: WH

· NOTE: if the file contains controlled unclassified information, add “_CUI” at the end of the file name (and follow any other amplifying related instructions in the workbook)

5) Attachment 3 - Government Data Rights Acknowledgement (DRK) (signed)

· Format: .pdf

· Naming convention suffix abbreviation: (DRK)

6) Attachment 4 - Intellectual Property/Data Rights Assertions (DRA) (signed)

· Format: .pdf

· Naming convention suffix abbreviation: DRA

7) Attachment 5 - Administrative and National Policy Requirements (ANP) (signed)

· Format: .pdf

· Naming convention suffix abbreviation: ANP The forms to be submitted with the white paper (items #2 – #7) are provided as separate attachments in the BAA posting. If the offeror revises or modifies the narrative of any form, the white paper submission will be rendered as non-compliant. These forms and attachments do not count against the White Paper page limits noted in Section C.

White Paper Document Content The white paper content should provide a clear and concise description of the effort proposed. Extraneous information, such as a table of contents, indices, offeror appendices, and past performance references, is NOT desired and shall not be included. If the white paper exceeds the page limitation (10 pages) set forth herein, excess pages will be removed from the back of the white paper and will not be evaluated. Page limitations also apply to any CLASSIFIED information submitted.

The white paper shall contain numbered sections and an appendix that addresses the following items in the order listed:

TITLE PAGE

· Labeled “WHITE PAPER, BAA NUMBER (insert the complete BAA number)”

· TTA abbreviation (e.g. AAIT, DET, SET, etc.): T&E/S&T Topic Domain Number and Name, Topic Number and Title

· Responsible organization and business type (large, small, non-traditional, non-profit, university, FFRDC, other)

· Offeror’s reference number

· Submission date

· Proposed title and acronym

· Award instrument proposed (procurement contract (specify type; e.g., Cost Plus Fixed Fee completion), Cooperative Agreement, Other Transaction)

· Any CUI/CTI required markings

· Any company proprietary information required markings The title page is NOT included in the white paper page count. The offeror shall propose a project title and a project acronym/initialism (preferably no longer four to five characters, but no more than six characters).

SECTION 1: T&E Need/Benefit Each listed topic of interest describes a specific high priority test technology need. The offeror shall provide a short description of the proposed test technology development and summarize how it satisfies the T&E need identified in the topic. The offer is not eligible for consideration if a T&E need is not addressed. If the offeror is only addressing a limited portion of the performance objectives for the topic of interest, the offeror shall clearly distinguish what aspect of the topic is being addressed.

The offeror shall address the following concerns:

a. To what extent is the technology development providing a benefit or impact over the current DoD test capabilities?

b. What utility does the end-item deliverables from this effort provide for DoD testing?

The following content supports addressing these questions:

The offeror shall provide a description or visualization of how this technology would be used in T&E (specific examples, use cases, a concept of operations, etc.) to more clearly convey how the DoD would benefit from this technology in conducting developmental, operational, and/or live-fire T&E. The offeror shall identify what will be delivered from the proposed development and articulate any benefits or usefulness those deliverables could provide DoD T&E, as well as discuss how the technology supports DoD T&E after it is matured beyond TRL 6 and incorporated into a test capability. The offeror shall describe the variety of applications for which the technology could be used to improve testing, which can include but are not limited to the following categories and examples:

· Supporting different aspects of testing Some generic DoD T&E examples include: 1) a sensor that could be used in a ground test facility and during flight testing, 2) a stimulator that could work inside a chamber and outside on an open-air range, 3) an analysis tool that can equally process data from simulations, hardware-in-the-loop laboratories, and open-air ranges.

· Supporting testing different types of systems Some generic DoD T&E examples include: 1) a sensor that could support high powered microwave testing and counter improvised explosive device (IED) testing, 2) an antenna that could be installed on aircraft and on missiles, 3) instrumentation that could track airplanes, helicopters, missiles, and ground vehicles.

· Supporting different DoD test organizations Some generic DoD T&E examples include: technology that could support testing for Army, Navy, Air Force, Marines, etc.

The offeror shall describe the potential significance or degree of enhancement the technology could provide the DoD test community. If the offeror does not intend for the solution to be TENA-compliant, then appropriate rationale shall be provided. The Government uses the aforementioned, among other content, in considering the offer's level of importance to agency programs.

SECTION 2: S&T Proposed The offeror shall clearly delineate the technology advancement this effort is addressing and undertaking. The offeror shall also include an assessment of the current state-of-the-art and how the proposed work will advance it, that is, “push the envelope” beyond what can be done today. In addition, the offeror shall assess the starting TRL for the proposed work and provide a basis for the assessment, as well as identify the ending TRL for the technology after the proposed test technology development. The technology must be developed within the specified TRLs of this BAA. If not, the offer is not eligible for consideration.

SECTION 3: Technology Maturity Approach The offeror shall address the following concerns:

a. How feasible, reasonable, logical is Technology Maturity Approach?

b. What scientific principles are used to achieve the result? How does the phased approach for TRL progression adequately address risk identification and mitigation?

c. What organizational talent and experience and what facilities enable creation of a successful prototype?

The following content supports addressing these questions:

The offeror is strongly encouraged to consider the content in Enclosure 2 – Project Structure Guidelines when developing project technology maturation plans. This information identifies frequently recurring activities that have enabled historic project execution success.

The offeror shall provide an overall development strategy that demonstrates the project’s technical feasibility for maturing technology with a successive progression of TRL from start to end. The solution described shall be innovative, achievable, and complete. Include describing any discernment of requirements, use case analysis, tradeoff assessments, or any early use of models and simulations. The offeror shall highlight the advantages of the proposed development strategy over other potential alternatives. If the proposed solution is predominantly hardware, the offeror shall identify plans to develop breadboards, brass boards, prototypes, or any other risk reducing demonstration items. If the proposed solution is predominantly software, the offeror shall identify the development methodology along with any intended configuration management schema, scrums, code reviews, and software test strategies.

Additionally, software development discussions shall consider the alignment with data rights assertions per your Section 5 response, alignment with DoD security or Information Assurance policies (e.g. potential CUI/CTI, ITAR, and classified work, and needed Risk Management Framework (RMF) compliance), and any dependencies on commercial items, whether they are a component project deliverable or not.

The offeror shall provide a high-level summary of the major tasks to be performed – organized in phases (with each phase in a separate paragraph) that have defined objectives, deliverables, and a period of performance that is of reasonable duration. The offeror shall clearly delineate the deliverables for each phase, including technical reports, analysis results, design artifacts (drawings, schemas, etc.), hardware items, and software products (as defined elsewhere in this document).

The offeror shall briefly describe how technical risk will be mitigated, including identifying the major technical risks along with the likelihood and consequence of each. The offeror shall also communicate why it is capable of performing the aforementioned development. The offeror should complete Attachment 2 - Related Work History/Experience to identify recent related work experience and contract/agreement types (and identification numbers, if awarded by DoD) corresponding particularly to the technology development discussed in the white paper (with an opportunity to also address experience/capabilities that may satisfy other TTA needs identified in the Annex – TTA Descriptions document. The Government uses the aforementioned, among other content, in considering technical merit.

SECTION 4: Programmatic Execution The offeror shall address the following concerns:

a. Does the programmatic execution graphic depiction effectively highlight the activities and events concerning potential interdependencies, project milestones?

b. Do phase durations to convey a cohesive and reasonable and timely plan of execution?

c. Are external programmatic dependencies adequately identified?

The following content supports addressing these questions:

The offeror shall provide a schedule showing, for each phase proposed in the development approach: all major tasks, milestones, tests/demonstration events, and significant meetings. In addition, the offeror shall identify phase decision meetings (also referred to as decision points) to be conducted (typically 30-45 days) before the end of a phase period of performance. This time will enable the Government to evaluate project status and determine contractual decisions, such as exercising the next contract phase (or subordinate milestones). The offeror shall provide the schedule following the example below. The offer shall provide commentary as necessary for schedule and duration logic. The offeror shall identify and explain any external dependencies that could impact the execution of the proposed work resulting in a schedule delay.

Examples of external dependencies include: 1) the offeror may propose using a Government facility to demonstrate the technology, which would be dependent on the availability of the facility; 2) the offeror may propose using data from a test event of an acquisition program, which would be dependent on the schedule and availability of that test event: 3) the offeror may need specific Government Furnished Property (GFP) as a component element of development or to conduct the development; 4) the offeror may propose leveraging technology from another development which would make that task dependent on the success of that external effort; or 5) the offeror may propose a dependency for project success based upon pending work to be performed under other funding sources. If applicable, explain the related funding sharing structures (as a percentage of proposed costs for TRMC BAA efforts vs. needed funds required for all required development. The Government uses the aforementioned, among other content, in considering technical merit.

SECTION 5: Data Rights The offeror shall address the following concerns:

How do data rights assertions impact future use of the Government’s implementation of the technology (as a return on investment consideration)?

The following content supports addressing this question:

The offeror shall address the Government’s anticipated unlimited data rights, and if applicable, state whether there are any potential assertions to restrict use as discussed in the Intellectual Property Representations subsection under the Intellectual Property part of this BAA by completing Attachment 4 Intellectual Property/Data Rights Assertions to address the assertions for both non-commercial and commercial items, including those of offeror’s subcontractors or suppliers.

Assuming that Attachment 4 is properly completed, the comments in this section can be a short generalized summary providing contextual rationale.

The Government uses the aforementioned, among other content, in considering the offer’s level of importance to agency programs.

SECTION 6: Total Cost/Price Rough Order of Magnitude (ROM) The offeror shall include a ROM for each phase - rolling up cost/price/PoP of any subordinate milestones, if used, into their respective phase - (in thousands of dollars) along with the POP (in months) as defined in the technology maturity approach and depicted in the schedule. The offeror shall provide the estimated ROM following the example below. The offeror shall ensure that all phases are included in the ROM, as the Government will not consider any unpriced phases. Failure to provide a complete ROM will render the white paper as non-compliant. The Government considers cost/price reasonableness and affordability.

APPENDIX: Table of Abbreviations, Acronyms, and Initialisms The offeror shall provide an appendix containing a table defining all abbreviations, acronyms, and initialisms used in the white paper, with the list in alphabetical order. While the table is appended to the white paper content, the Appendix table does not count towards the ten (10) page limitation.

Tabular Summary of Page Count Limitation Requirements:

(includes any separately submitted classified information, if approved) Title Page and Appendix table

END OF SUBMISSION REQUIREMENTS

A-8: 1 TRMC T&E/S&T BAA Enclosure 3: page 10 image1.png