Call for Solutions for FogTester Software Application.pdf

CALL FOR SOLUTIONS

Fog Tester Analysis Software Application

Project Number W911QY-26-R-FOG Army Open Solicitation (AOS) Number W9128Z-25-S-A002

Call for Solution Title Fog Tester Analysis Software

Issued By Army Contracting Command – Aberdeen Proving Ground (ACC-APG) Natick Division

Submission Instructions To respond to this Call for Solution, please refer to Sections 6 and 8 of this Call for Solution

*Solution Briefs Due Date/Time (Suspense)

4 September 2026 by 1600 EST

Points of Contact (POCs) for Solution Brief Submission:

Contracting Officer: Lyndon Jagroop, lyndon.s.jagroop.civ@army.mil

Contract Specialist: Kaylie Silva, kaylie.j.silva.civ@army.mil

*Any submissions that are received by the Contracting Officer after the suspense date/time listed above will be deemed late and not evaluated. It is the sole responsibility of the company to ensure that its submission is received in the inbox listed above before the deadline specified.

This call for Solution may result in the Government awarding Federal Acquisition Regulation (FAR) contracts or non-FAR agreements in accordance with (IAW) Defense Federal Acquisition Regulation Supplement (DFARS) 212.70 – Defense Commercial Solutions Opening. Other Transaction (OT) that may be awarded from this Call for Solution are not subject to the FAR or its supplements, as applicable.

1. INTRODUCTION

U.S. Army Combat Capabilities Development Command – Soldier Center (DEVCOM-SC), Soldier Protection Directorate (SPD), Optical and Electromagnetic Materials Branch (OEMB) is seeking advancements in the development of a Fog Tester Analysis Software. The Government designed the 4th generation Fog Tester that currently utilizes a LabVIEW program, named FogTester. The system runs on a Microsoft Windows computer to operate a custom control board that provides 120VAC electrical outlet relay switching, temperature and humidity input and records, light(s), dual camera video input, and heating circuit temperature control of the video camera lenses.

A separate LabVIEW application, named BarTarget, is then used post-test to analyze the acquired video stills to generate a contrast ratio value of selected regions of interest. The contrast ratio mailto:lyndon.s.jagroop.civ@army.mil mailto:kaylie.j.silva.civ@army.mil values are then manually plotted by the user in Microsoft Excel and compared to known Haze Standard values.

This Call for Solution aims to develop an improved BarTarget application that can be designed to analyze post-test acquired video images from both cameras and generate the contrast ratio value per selected region of interest and plot the contrast ratio over the duration time of the test and output a result per designated pass/fail criteria based upon the haze calibration measurements.

2. PROBLEM STATEMENT

DEVCOM-SC OEMB is seeking innovative solutions to:

(1) Develop a post-test image analysis sub-program for use with Soldier Center-developed Fog Tester instrument control and data acquisition software. This sub-program will replace the current BarTarget program, and the data plotting performed in Microsoft Excel by the user.

(2) Deliver a sub-program which shall also be able to process calibration tests, analyze the data and deliver a calibrations file for input to the pass/fail criteria.

3. DESIRED SOLUTION OBJECTIVES

The software code shall operate on a Microsoft Windows 11 operating system for image analysis software application that will interact with the FogTester software application in a local host environment (no internet connection required), have users input test condition parameters (file save location, test duration, camera configuration), perform the test, analyze the data, and compute and output the results per designated pass/fail criteria. Saved output graph and data shall be compatible with Microsoft Word and Excel programs for user reporting purposes.

The software shall be written/developed using any of the following programming languages:

LabVIEW, .NET (C#, Visual Basic) Python. Other programming languages may be considered but require approval before use. The software shall communicate with the FogTester software via a TCP port.

4. SOFTWARE ASSURANCE (SwA) REQUIREMENTS

4.1 Software Assurance. The software developed under this effort is categorized as Non-Critical, Untethered, Government-purpose developed software intended for installation on a standalone (disconnected) laboratory information system with no internet connectivity. The Contractor shall implement Software Assurance to the maximum extent practicable in accordance with AR 25-2, the HQDA DCS G-6 Software Assurance Implementation Planning Guidance (IPG), DA PAM 25-2-5, and DoDI SwA Contract Language §2.2] [1][2][3]

4.1.1 Secure Coding Practices. The Contractor shall enforce secure coding practices throughout the Software Development Lifecycle, including input validation of all data received from the FogTester application and TCP interface, adherence to the principle of least privilege, and elimination of compiler warnings at the highest available warning level. The Contractor shall apply these practices to all custom-developed code and any reused, open-source, or generated code.

[Ref: DA PAM 25-2-5 §4-1b and §4-3a; DoD SwA Contract Language Notional SOO] [2][3]

4.1.2 Static Application Security Testing (SAST). The Contractor shall perform Static Application Security Testing (Static Code Analysis) on the complete source code (LabVIEW, .NET/C#/VB, and/or Python as applicable) using at least one automated SAST tool providing coverage for the language(s) employed, with a target of no less than 80% code coverage. SAST satisfies RMF Control SA-11(1) and is the minimum required SwA activity at the Army Readiness Level. Findings shall be reported using Common Weakness Enumeration (CWE) identifiers. [Ref: SwA IPG Annex A §1.3, Annex B §2.1; SA-11(1); DoD SwA Contract Language SA-11(1)] [1][3]

4.1.3 Software Composition Analysis (SCA) and Software Bill of Materials (SBOM). The Contractor shall perform Software Composition Analysis on all third-party libraries, frameworks, and code dependencies to identify known vulnerabilities and out-of-date components, satisfying RMF Control SI-2. The Contractor shall deliver a Software Bill of Materials (SBOM) in CycloneDX or SPDX format describing the provenance and pedigree of all delivered software, including all open-source and third-party components, as required by Executive Order 14028 and the ASA(ALT) SBOM Playbook. Known vulnerabilities shall be reported using Common Vulnerabilities and Exposures (CVE) identifiers, and the Contractor shall confirm that delivered component versions contain no publicly known unmitigated vulnerabilities. [Ref: SwA IPG Annex B §2.5, EO 14028; DoD SwA Contract Language §2.2 / §2.2.1] [1][3]

4.1.4 Application Security and Development (ASD) STIG. The Contractor shall assess the software against the current DISA Application Security and Development (ASD) STIG and deliver a completed STIG Checklist. The Contractor shall incorporate applicable ASD STIG requirements into the software design and implementation. [Ref: SwA IPG Annex B §2.6; DoD SwA Contract Language SA- 4] [1][3]

4.1.5 Flaw Remediation. The Contractor shall implement a flaw remediation process to identify, track, and remediate all software weaknesses and vulnerabilities based on risk severity (Critical, High, Medium, Low), satisfying RMF Control SI-2. All findings shall be consolidated into a single Plan of Action and Milestones (POA&M). The Contractor shall correct all Critical and High severity findings prior to final delivery, or otherwise document and obtain Government acceptance of any residual risk. [Ref: SwA IPG Annex B §3.1; DA PAM 25-2-5 §3-2; SI-2; DoD SwA Contract Language

SI-2] [1] [2][3]

4.1.6 Software Confidence Baseline. The Contractor shall provide the artifacts necessary for the Government to establish the Software Confidence Baseline, consisting at a minimum of: (a) SAST results [SA-11(1)], (b) SCA results, (c) the SBOM, and (d) the ASD STIG Checklist. Because the system is disconnected/standalone and non-critical, the baseline shall be reviewed at a minimum annually, and immediately upon any significant change or upon discovery/announcement of a relevant cyber vulnerability. [Ref: SwA IPG Annex A §1.3 and Table 2 — "Non-Critical Untethered Software: Annually" / disconnected] [1]

4.1.7 Government Data Rights for SwA Validation. Consistent with the source code deliverable required in Section 9, the Contractor shall grant the Government Government Purpose Rights to all delivered non-commercial source code and provide all source code, incorporated code, dependencies, and build/make instructions necessary for the Government to independently rebuild and assess the software. [Ref: SwA IPG §2.1.1 and Annex D §3; DoD SwA Contract Language SA- 4(2)] [1][3]

4.1.8 Software Assurance Plan (SwA Plan). The Contractor shall develop and deliver a Software Assurance Plan within thirty (30) calendar days after contract award and shall update it at each major review. The SwA Plan shall be delivered as a tailored section of the Software Development Plan (DI-IPSC-81427) or as a standalone Plan (DI MGMT-81024). Government approval of the SwA Plan is a prerequisite (entry criterion) to the mid-point technical review. [Ref: DoD SwA Contract Language §2.3.1; SwA IPG Annex A] [1][3]

5. AWARDING INSTRUMENT

In accordance with Open Solicitation Procedures detailed within W9128Z-25-S-A002, the Government intends to award FAR part 12, Firm-Fixed-Price (FFP) type contract as a result of this Call. The Government further reserves the right to reward all, some, or none of the companies who submit a proposal. Use of a CSO in accordance with DFARS Subpart 212.70 is considered to be a competitive procedure for the purposes of 10 U.S.C. chapter 221 and FAR subpart 6.102.

6. SOLICITATION INSTRUCTIONS AND NOTES

6.1 Overview of Submission Phases

The response process for this Call will generally consist of the following phase(s):

Phase 1: Solution Brief

Offerors will submit a detailed brief their proposed solution, addressing the Government’s objectives and requirements as outlined in Sections 2 and 3.

Phase 2: Demonstration (unless bypassed)

The Government MAY invite selected Offerors to present and discuss their solution in a live or virtual setting.

Offerors will submit a detailed summary of their proposed solution, addressing the Government’s objectives and requirements (Sections 2 and 3). After solution briefs are collected, the Government may choose to proceed to Phase 2 in requesting a live demonstration, if applicable.

7. GENERAL INFORMATION AND QUESTIONS

Questions are to be sent electronically via e-mail to the Points of Contact (POCs) listed in this Call for Solution. The following shall be utilized in the e-mail subject line: ‘Call for Solution – Fog Tester Software W9128Z-25-S-A002’.

Material questions and answers will be published and updated on SAM.gov.

The deadline to submit questions for Phase 1 is 26 August 2026 by 1200 EST.

8. SOLUTION SUBMISSION REQUIREMENTS

The Government will utilize up to two (2) phases for assessing solutions:

8.1 Phase 1 – Solution Brief Content

Solution Briefs should not exceed eight (8) written pages using 12-point Times New Roman font.

The Government will not consider inserted textboxes/pop-ups or internet links to additional information as part of the Solution Brief and will not consider such information in its evaluation.

Solution Briefs are intended to be clear and concise.

Solution Briefs shall include the following at a minimum:

a. Title Page (does not count against page limit) that includes the following:

1. Company Name

2. Title of Proposal

3. Date Submitted

4. Point of Contact (Name, E-mail address, Phone Number)

5. Commercial and Government Entity (CAGE) Code and Unique Entity Identification (UEI) code

6. Identify the referenced Call for which the Solution Brief is submitted against

b. Executive Summary (one page): Provide an executive summary of the technology.

c. Software Assurance Requirements. The Offeror shall submit a Software Assurance Technical Approach addressing how it will satisfy the SwA requirements outlined in Section 4:

1. Describe its secure coding practices for the proposed language(s) (LabVIEW, .NET, and/or Python), including the input validation of FogTester/TCP-sourced data [Section 4.1.1]

2. Identify the SAST tool(s) to be used, demonstrate language coverage, and state the achievable code-coverage percentage and CWE-based reporting method. [Section 4.1.2]

3. Identify the SCA tool and SBOM format (CycloneDX/SPDX), and describe how known-vulnerable/out-of-date components will be identified and reported via CVE. [Section 4.1.3]

4. Describe its approach to the ASD STIG assessment and checklist delivery. [Section 4.1.4]

5. Describe its flaw remediation/POA&M process and severity-based remediation thresholds.

[Section 4.1.5]

6. Identify the SwA artifacts it will deliver to establish the Software Confidence Baseline and confirm acceptance of the annual review cadence for disconnected systems. [Section 4.1.6]

7. Confirm provision of source code, dependencies, and build instructions sufficient for Government independent rebuild/assessment. [Section 4.1.7]

8.2 Phase 2 Live Demonstration:

a. Phase 2 submission requirements and evaluation criteria will be outlined in the invitation to this phase, unless bypassed.

9. NON-GOVERNMENT ADVISORS

Non-government advisors will not participate during the evaluation process.

10. ORGANIZATIONAL CONFLICT OF INTEREST (OCI)

The Offeror shall perform an OCI analysis and submit the results of that analysis in addition to the white paper submission. The OCI analysis does not count towards the 5-page limitation.

Specifically, the Offeror shall analyze the planned acquisition for actual or potential OCI situations associated with the Offeror or any of the Offeror’s proposed teammates or subcontractor’s performance under any contract or agreement the Offeror or the Offeror’s teammates or subcontractors has been or may be awarded by any federal agency or other entity. The Offeror shall describe in detail the methodology used to identify actual or potential OCI issues. If the Offeror identifies any actual or potential OCIs with respect to the performance of the Offeror or the Offeror’s subcontractors or teammates, the contractor shall provide an OCI Mitigation Plan to be incorporated as an attachment to any resulting contract or agreement.

Any proposed avoidance or mitigation techniques shall be consistent with FAR 9.5 and the most recent decisions of the Government Accountability Office (GAO) and the U.S. Court of Federal Claims.

11. EVALUATION CRITERIA

The Government will evaluate submission based on their potential to satisfy the needs of the Government’s Statement of Objectives (SOO). Proposals will be evaluated on their own technical merit and not against other submissions. All evaluation factors other than cost or price, when combined, are significantly more important than cost or price. The evaluation factors are listed below in descending order of importance:

1. Technical Merit and Relevance: The solution’s applicability to the Government’s SOO, its scientific and technical feasibility, and its potential to significantly enhance DEVCOM-SC’s OEMB capabilities.

2. Innovation and Uniqueness: The degree to which the proposed solution is new, underutilized, or uniquely applied to solve an Army problem.

3. Company Visibility: The Offeror’s ability to execute the proposed effort, including relevant corporate experience, personnel qualifications, and a sound business model.

4. Price and Affordability: The reasonableness of the proposed price and the overall affordability of the solution for the Government. Price will be considered to the extent appropriate to determine fairness and reasonableness.

12. ANTITERRORISM (AT), OPERATIONS SECURITY (OPSEC)

Offerors shall ensure that the following required language is included in the proposed SOW.

AT Level I Awareness training. All contractor employees, including subcontractor employees, requiring access to Army installations, facilities and controlled access areas shall complete AT Level I Awareness training within 30 calendar days after contract start date or effective date of incorporation of this requirement into the contract, whichever is applicable. The contractor shall submit certificates of completion for each affected contractor employee and subcontractor employee, to the COR or to the contracting officer, if a COR is not assigned, within 15 calendar days after completion of training by all employees and subcontractor personnel. AT level I Awareness training is available at the following website: http://jko.jten.mil.

Access and general protection/security policy and procedures. Contractor and all associated subcontractor employees shall provide all information required for background checks to meet installation access requirements to be accomplished by installation Provost Marshal Office, Director of Emergency Services or Security Office. Contractor workforce must comply with all personal identity verification requirements (FAR clause 52.204-9, Personal Identity Verification of Contractor Personnel) as directed by DOD, HQDA and/or local policy. In addition to the changes http://jko.jten.mil/ otherwise authorized by the changes clause of this contract, should the Force Protection Condition (FPCON) at any individual facility or installation change, the Government may require changes in contractor security matters or processes.

For contractors that do not require CAC but require access to a DoD facility or installation.

Contractor and all associated sub-contractors employees shall comply with adjudication standards and procedures using the National Crime Information Center Interstate Identification Index (NCIC-III) and Terrorist Screening Database (Army Directive 2014-05/AR 190-13), applicable installation, facility and area commander installation/facility access and local security policies and procedures (provided by government representative); or, at OCONUS locations, in accordance with status of forces agreements and other theater regulations.

iWATCH Training. The contractor and all associated sub-contractors shall brief all employees on the local iWATCH Army program (training standards provided by the requiring activity ATO). This local developed training will be used to inform employees of the types of behavior to watch for and instruct employees to report suspicious activity to the COR. This training shall be completed within 30 calendar days of contract award and within 30 calendar days of new employees commencing performance with the results reported to the COR NLT 30 calendar days after contract award.

For contracts that require OPSEC Training. Per AR 530-1, Operations Security, the contractor employees must complete Level I OPSEC Awareness training. New employees must be trained within 30 calendar days of their reporting for duty and annually thereafter.