UPDATE: Effective immediately, the Family of Maintenance Trainers (FMT) Common Core (CC) Architecture and Software Baseline RFS posted on 04 January 2019 is on HOLD. The Government anticipates amending the current RFS and reposting in February. Any questions related to this notice should be submitted in writing to firstname.lastname@example.org, with "FMT CC" in the subject line.
Request for Solutions:
Family of Maintenance Trainers (FMT) Common Core (CC) Architecture and Software Baseline
03 January 2018
This Request for Solutions (RFS) is issued to locate capable vendors with the ability to develop a prototype FMT - CC architecture and software baseline to support the existing FMT Product Line (PL) and future Virtual Training Systems (VTS). The purpose of this effort is to analyze existing systems, develop a prototype CC PL Architecture and software baseline, and validate the CC Architecture by developing prototype maintenance trainers for multiple vehicle platforms. The RFS scope is limited to the development of the prototype Diagnostic and Troubleshooting Trainer (DTT) which is part of the FMT PL. Information related to the Hands-on-Trainer (HOT) and Part Task Trainer (PTT) variants of maintenance training systems is provided for reference only. The Government will evaluate the solutions with the intent of awarding an Other Transaction Agreement (OTA) in accordance with 10 U.S. Code § 2371b.
2. BACKGROUND AND SUMMARY
2.1 Training and Readiness Accelerator (TReX)
Vendors interested in responding to this RFS must be members of the TReX consortium. This project will be managed by the U.S. Army Program Executive Office for Simulation, Training, and Instrumentation (PEO STRI), Project Manager Training Devices (PM TRADE), Product Manager Virtual Training Systems (PdM VTS).
The FMT-CC Product Line includes, but is not limited to the Stryker, Abrams, Bradley, Armored Multi-Purpose Vehicle (AMPV), Joint Light Tactical Vehicle (JLTV), and Mobile Protected Firepower (MPF) maintenance trainers. As the AMPV is a new vehicle, the Government will require demonstration of the utility of the trainer prototype in a classroom environment. The maintenance trainers henceforth will be referred to as “the trainer.” The trainer is comprised of three classes of devices: the Diagnostic/Troubleshooting Trainers (DTTs), the Part Task Trainers (PTTs), and Hands-On-Trainers (HOTs). These systems provide Military Occupational Specialty (MOS) skill level development for system operation, fault diagnosis, troubleshooting, adjustments, component removal/replacement, and other servicing and repair tasks for the respective vehicles. Each of these variants targets specific training goals but share common training elements.
The DTTs are computer based system simulations: no actual physical vehicle hardware is employed. Navigation and interaction with the DTTs is handled via keyboard, mouse, and touchscreen inputs. The PTT and HOT trainers integrate virtual training with physical hardware. In the case of the PTT, a specific subsystem, such as the brakes, is targeted, and realistic components of that system are instrumented to be an active part of the simulation. The HOT expands upon the PTT concept. The hardware in a HOT is part of a more completely integrated environment that may contain more than one subsystem. The HOT is instrumented in the same manner as the PTT and the hardware interacts with the virtual software simulation. In all classes, the trainer is comprised of an Instructor Operators Station (IOS) and one or more student workstations (SWS). In addition, a Training Management System (TMS) provides record storage and classroom management utilities. The IOS, SWSs, and TMS are connected by an Ethernet or wireless network and high-speed switches. In the case of the PTTs and HOTs, the SWSs are connected by hardware linkage to additional Input/Outputs (I/O) used to instrument the physical representations of the specific device trainers.
The IOS controls the simulation state and the behavior of the simulation. The SWS run the actual models that provide the virtual trainer capabilities. The HOT and PTT IOS has a similar software package as the DTT but the lessons are focused on interaction with actual vehicle components or components that approximate the real vehicle with high fidelity.
Real-Time software includes the software models that simulate the vehicle systems and the executive software which controls the iteration rate of the simulation and schedules the models to run at the appropriate frequencies. The IOS software provides control of the simulation including freeze, lockstep, lesson plan control, and communication control. The TMS software provides support for classroom management functions, student record archiving, and lesson plan maintenance. The Display and Control (D&C) software is the interface between the student’s or instructor’s actions at a display and the effect it has on the simulation.
In addition to the simulation software, a Software Support Environment (SSE) provides the resources for performing post deployment software support activities, including identifying, documenting, and correcting system software faults, implementing system software upgrades, managing databases, and providing configuration management of the training system software baseline.
In addition to the common software capabilities of all of the trainers, each classification of trainer has unique features. These are addressed in the following sections.
2.2.2 Unique Features
126.96.36.199 Diagnostic/Troubleshooting Trainers (DTT)
The DTTs are a completely virtual simulation. This makes it possible to provide a record/playback capability. Since there is no hardware in the loop, the system can record all of the student’s actions. The instructor can initiate a recording session which can be played back, demonstrating the student’s interaction with the simulation. The test equipment on the DTT is all simulated. Students are able to retrieve fault codes and other diagnostic information in a manner analogous to using the actual equipment. Since the DTT classroom has many students assigned to one instructor, the instructor is supplied a handheld device that provides many of the controls that are normally present on the IOS. This allows the instructor to move around the classroom and use controls that target specific students. The IOS station has multiple displays that the instructor can use for control, replicating a student’s screen, and displaying the Interactive Electronic Technical Manuals (IETM). Similarly, the student stations have multiple displays that allow the student to interact with the simulation, view the Technical Manual, or view auxiliary instructional material.
188.8.131.52 Part Task Trainers (PTTs) and Hands-On-Trainers (HOTs)
Since the PTTs and HOTs interface through linkage to physical hardware, the Real-Time software must be configured differently than the DTTs. The models for the system represented by the trainer must take into account the linkage inputs and outputs to the physical portion of the trainer. For example, on the Brake System PTT, if the student physically disconnects the hydraulic line, which is instrumented with I/O, the model must read the linkage to determine that the line is no longer able to supply pressure. Unlike the DTT, the PTT and HOT simulations include actual or replicated physical vehicle components.
2.3 Common Software Baseline
Although the current trainers have common classifications of software within a variant (i.e., within vehicle types for both DTTs and PTTs), there is no commonality between variants. Each variant’s software architecture and source code is unique and stove-piped. With this prototype effort, the Army desires to establish a CC software baseline to replace the current stove-piped software architecture with a common product line architecture which completely supports the entire FMT PL. The FMT-CC will produce a set of plug-and-play applications in the product line architecture that are applicable across the FMT product portfolio of legacy and future combat/tactical vehicle training systems without a loss of current functionality.
The FMT-CC, vehicle specific software, assets, digital information, and documentation will reside on the Live Training Transformation (LT2) portal. The LT2 portal is an Army repository for data and standards for the live training community created under the CPMNext contract. Information uploaded by the vendor onto the LT2 portal may be available to other contractors on a need to know basis to perform work for the Army. The vendor shall provide a plan that documents a path to conformance to the LT2 Product Line Operations and CM Guide. The LT2 portal and guides are located at www.lt2portal.mil. A Common Access Card (CAC) is required to access this portal. For potential vendors without CACs, the LT2 Product Line Operations and CM Guide will be provided upon request.
2.4 Applicability of Attached Technical Supplements to this Request
The characteristics of this prototype system and the Government concept for its development are included in the attached technical supplements. The technical supplements are based upon the current training product baselines. Vendors are encouraged to tailor the technical supplements in individual solutions and should articulate any suggested additions or major discrepancies between the below technical supplements and their technical solution. The technical supplements are:
• Technical Supplement 1 – Common Core
• Technical Supplement 2 – M2A3 Bradley DTT
• Technical Supplement 3 – Abrams SEP v2 DTT
• Technical Supplement 4 – Stryker DTT
• Technical Supplement 5 – AMPV DTT
The vendor’s response shall include the tailored technical supplements delivered with tracked changes to reflect the solution and approach proposed.
3. TECHNICAL OBJECTIVES
The FMT PL prototype approach includes the following three phases as well as potential follow-on activities outlined in Section 8: Follow-on and Sustainment Activities. The varying completion criteria established for each phase may be considered a Decision Point (DP) for entry into subsequent phases and/or follow-on OT production efforts. The technical objectives for each phase will be separately priced.
Phase 1: Architecture Analysis and Common Core Development
Phase 1 may be ready for a DP upon the successful completion of Technical Objective #1, Technical Objective #2, and Technical Objective #3. The phase is considered complete upon the successful demonstration of Technical Objective #1, Technical Objective #2, and the acceptance of the Phase 1 deliverable outcomes.
Technical Objective #1: Analyze existing Abrams, Bradley, and Stryker Maintenance Training System software architectures and develop a Family of Maintenance Trainers Product Line prototype system architecture that will:
a) Satisfy the functional and performance requirements of the FMT-CC
b) Leverage legacy software components to the maximum extent possible
c) Minimize the life cycle cost to establish and sustain the Family of Maintenance Trainers Product Line
d) Support the integration of new training technologies
e) Be compatible with the LT2 constructs and guidelines. Information regarding the LT2 constructs and guidelines can be found in Section 2.3 of this RFS.
f) Allow each vehicle variant to be trained asynchronously while utilizing the same hardware.
In preparation for Technical Objective #2, develop and obtain approval from the Government for the Software Integration Lab (SIL) hardware specification requirements and purchase the SIL hardware. The SIL is further discussed in Technical Objective #2.
Technical Objective #2: Develop a FMT-CC software baseline based on the approved FMT-CC architecture from the Technical Objective #1 effort and the CC Technical Supplement #1. Develop a DTT Software Integration Lab (SIL) which consists of an IOS, two SWSs, and a TMS. Install and validate the FMT-CC software baseline on the SIL. Five (5) existing lessons from the Stryker platform will be provided by the Government, which will be used to validate compliance with the Common Core architecture and Technical Supplement #1. The lessons shall be compliant with the approved FMT-CC architecture, satisfy the FMT-CC requirements, and satisfy the vehicle specific requirements as defined in the Stryker Technical Supplement #4. The vehicle specific lessons shall be demonstrated on the SIL.
Technical Objective #3: Using the SIL and CC baseline developed in Technical Objectives #1 and #2, develop five (5) Abrams M1A2 SEP v2 troubleshooting lessons to validate the Common Core architecture. The lessons shall be compliant with the approved FMT-CC architecture, satisfy the FMT-CC requirements, and satisfy the vehicle specific requirements as defined in the Abrams Technical Supplement #3. The vehicle specific lessons shall be demonstrated on the SIL.
Phase 1 Deliverable Outcomes:
1. System Architecture Description
2. FMT-CC System Specification with a Requirements Traceability Verification Matrix
3. Software Design Description
4. Source Code
5. Verification/Validation Documentation
6. Draft Interface Capability and Interface Design Documents (ICD/IDD)
Phase 1 Technical DP #1 – Common Core Baseline Demonstration
DP 1 may be used to determine entry into Phase 2. DP 1 may occur after successful demonstration of the Phase 1 Objectives and may be prior to the Government acceptance of all Phase 1 deliverable outcomes. Early entry into Phase 2 activities may be determined by Technical DP #1 and does not constitute completion of Phase 1.
Estimated Timeline: The Government anticipates that this phase will not exceed four months.
Phase 2: Initial Prototype Development
The prototype SIL will be used to validate the product line architecture and the suitability of the prototype by developing lessons for the Bradley and AMPV vehicle types. Phase 2 Technical Objective #1 may be considered a DP for entry into follow-on activities.
The Phase 2 prototype effort will be considered complete upon the successful demonstration of all Phase 2 Objectives and the acceptance of the Phase 2 Deliverable Outcomes.
Technical Objective #1: Using the SIL and CC baseline developed in Phase 1, develop five (5) Bradley troubleshooting lessons. The lessons shall be compliant with the approved FMT-CC architecture, satisfy the FMT-CC requirements, and satisfy the vehicle specific requirements as defined in the Bradley Technical Supplement #2. The vehicle specific lessons shall be demonstrated on the SIL.
Technical Objective #2: Using the SIL and CC baseline developed in Phase 1, develop 3-D software models for the AMPV and five (5) AMPV troubleshooting lessons. The lessons shall be compliant with the approved FMT-CC architecture, satisfy the FMT-CC requirements, and satisfy the vehicle specific requirements as defined in the AMPV Technical Supplement #5. The vehicle specific lessons shall be demonstrated on the SIL.
Phase 2 Deliverable Outcomes:
1. Lesson Source Code
2. Updated draft of the Design and Interface documentation
3. Updated draft of the Verification/Validation document
Phase 2 Technical DP #2 – Follow-on Activity
DP 2 may be used to determine entrance into follow-on activities. At the Government’s discretion, DP #2 may occur when either the AMPV or Bradley vehicle specific DTT prototype with the five (5) troubleshooting lessons is satisfactorily demonstrated. DP 2 may occur prior to the Government acceptance of all Phase #2 deliverable outcomes.
Phase 2 Technical DP #3 – Proof of Concept
DP #3 may be used to determine entry into Phase 3 and/or follow-on activities. DP #3 may occur after successful demonstration of the Phase 2 Objectives and may be prior to the Government acceptance of all Phase 2 deliverable outcomes. Early entry into Phase 3 activities may be determined by Technical DP #3 and does not constitute completion of Phase 2.
Estimated Timeline: The Government anticipates that this phase will not exceed six months from the successful completion of Phase 1. At the Government’s discretion,
Phase 3 may begin prior to full completion of Phase 2.
Phase 3: Extensibility Demonstration
Phase 3 will validate that the prototype can support asynchronous training on multiple vehicles on the same classroom hardware. An extensibility demonstration is required to validate that the prototype is capable of accommodating the additional complexity of the AMPV 3-D software models and used to assess the feasibility of the prototype in an operational environment. This will be accomplished by developing 75 additional AMPV maintenance lessons for a total of 80 maintenance lessons (including the five AMPV lessons developed in Phase 2) on the SIL to validate that the functionality and fidelity of the 3-D software models developed in Phase 2. This phase will also demonstrate the suitability of the prototype to satisfy the training throughput in a classroom networked environment.
Phase 3 may be considered a DP for entry into follow-on activities. The OTA prototype effort will be considered complete upon the successful demonstration of all Phase 3 Objectives and the acceptance of the Phase 3 prototype(s) and Deliverable Outcomes.
Technical Objective #1: Demonstrate the extensibility of the Phase 1 baseline by developing two AMPV DTT classroom prototypes. Each classroom prototype will consist of an IOS, 20 SWSs, and 75 additional lessons for a total of 80 maintenance lessons (including the five AMPV lessons developed in Phase 2). Two classroom prototypes are required to validate that the TMS developed in Phase 1 can support multiple classrooms containing multiple SWSs. The prototypes will be demonstrated at Ft. Benning, GA, and will be compliant with the approved baseline developed in Phase 1, Phase 2, and the AMPV Technical Supplement #5. The classroom prototype shall include the total set of 80 total troubleshooting and maintenance lessons. The prototypes shall meet all applicable logistics, safety, and Cybersecurity requirements.
Phase 3 Deliverable Outcomes:
1. All Product Definition Data (PDD)
2. Source Code for each objective (vehicle type)
3. Updated Interface Capability and Interface Design Documents (ICD/IDD)
4. System Specifications
5. Operator and Maintenance manuals
6. Two DTT classroom prototypes
7. Updated Design Documentation (including Software Design Description)
8. Prototype Verification/Validation Document
9. Risk Management Framework (RMF) documentation
Phase 3 Technical DP #4 – Final Prototype Acceptance
DP 4 may occur at the completion of phase 3. Phase 3 may be considered complete upon the successful demonstration of all phase 3 objectives and the government acceptance of the deliverable outcomes from all phases.
Estimated Timeline: Approximately 10-12 months following the completion of Phase 2, dependent on vendor proposed solutions and schedule. The Government anticipates that this phase will not exceed 12 months.
The Government will provide Government Furnished Information (GFI) for Phase 1 and Phase 2 within 15 days after award of agreement. The GFI will include SSE from the legacy Stryker DTT, drawings, technical manuals and supplements, operator user manuals, software architecture/design/version descriptions, and software product specifications and related source code.
Government Furnished Property (GFP) for Phase 3 will be provided after successful completion of a mutually agreed upon milestone.
For Operations Security (OPSEC) requirements, see the attached OPSEC requirements document.
4. EVALUATION PROCESS AND RESPONSES
This RFS will be issued to industry through the TReX website. Interested parties will be requested to provide Technical and Pricing solutions outlining the following:
• The vendor’s technical analysis and design approach for all phases and objectives as described in sections 3 and 5
• Experience with establishing product lines
• Experience with vehicle maintenance trainers
• Team composition and sub-vendor involvement
• An Integrated Master Schedule (IMS) for the entire effort
• Level 4 Contractor Work Breakdown Structure (CWBS)
• Capability to handle simultaneous development and production efforts for multiple programs/platforms
• Approach for handling follow-on activities as referenced in Section 8
• Redlines of the Technical Supplements per Section 2.4
Your technical response should clearly outline the appropriate assertion right in technical data, computer software and software documentation that will be delivered with your solutions, as well as understanding that the US Army has release authority on any publications related to this prototype project.
• Pricing data should not be found in the Technical Section and should be provided in a separate document separated by individual phases, objectives, and pricing milestones.
• Basis of Estimates (BOEs) for the entire effort
Responses should clearly address planned documentation deliverables (including format and content) and any planned demonstrations, design reviews, and management reviews. Responses shall be submitted in an executable (not scanned) Adobe PDF format and limited to no more than 35 pages for the technical volume only, using standard 12-point Arial font. Any charts or figures are not bound by the 12-point font requirement but shall be clearly legible. A proposed Integrated Master Schedule (IMS) shall be provided in a Microsoft Project format. The Government will provide a Level 1 Work Breakdown Structure (WBS) for the DTT system. The vendor shall include a Level 4 Contractor Work Breakdown Structure (CWBS) along with a Basis of Estimate (BOE) for each element of the WBS that identifies all proposed labor hours and labor categories per month in a Microsoft Excel format. Cover pages, company historical dataIMS, CWBS, BOEs, and Redlines to the Technical Supplements are not included in the 35 page total.
Evaluations will be conducted by Government personnel. Systems Engineering and Technical Assistant (SETA) personnel will serve as advisors which are employees of ECS Federal, LLC and OST, Inc. The Government may down select the number of vendors to those with the most technically feasible proposed solutions in order to hold expanded conversation on the proposed solution and/or potential demonstrations.
The response cover page shall include the nontraditional* business status or a statement of ability to meet the eligibility requirements in 10 U.S. Code § 2371b. Within the response, please check the following box which applies – with appropriate justification if applicable.
• There is at least one nontraditional defense contractor participating to a significant extent in the project.
• All significant participants in the transaction other than the Federal Government are small businesses or nontraditional defense contractors.
• At least one third of the total cost of the project is to be paid out of funds provided by parties to the transaction other than the Federal Government.
*Nontraditional – an entity that is not currently performing and has not performed, for at least the one-year period preceding the solicitation of sources by the Department of Defense (DoD) for the procurement or transaction, any contract or subcontract for the DoD that is subject to full coverage under the cost accounting standards prescribed pursuant to section 1502 of title 41 and the regulations implementing such section.
The cover page of the response shall also include the company name, Commercial and Government Entity (CAGE) Code (if available), address, and primary point of contact including phone number and email address.
All questions related to this RFS should be submitted in writing to INITIATIVES@NSTXL.ORG, with “FMT CC” used in the subject line. Questions must be submitted no later than 1:00 PM EST on 16 January 2018. Questions received after the deadline may not be answered. Questions shall not include proprietary data. Note: the Government reserves the right to post submitted questions and answers to facilitate vendor solution responses.
Responses shall be submitted no later than 1:00 PM EST on 19 February, 2019. The response should be submitted electronically to INITIATIVES@NSTXL.ORG with “FMT CC” used in the subject line. Any submissions received after this time on this date may be rejected as late and not considered.
5. TECHNICAL SOLUTION, SCHEDULE, AND PRICING MILESTONES
The vendor’s proposed technical solution shall describe its approach to providing the solution with the system characteristics described in the attached technical supplements. The solution shall describe how the vendor plans to provide all of the major capabilities as well as a description of:
1) A design approach that demonstrates a thorough understanding of desired product line system architecture, prototype objectives, and modular approach to key subsystems.
2) A design solution that can be configured to support varied classroom configurations, sizes, and where key component functionality can be consolidated when required.
3) Team composition, subcontractor involvement and teaming arrangements.
4) Recent (within the past 5 years) and demonstrable expertise in configuration management relevant to product line development.
5) A detailed approach to demonstrate the required capabilities and manage the follow-on activities described in Section 8: Sustainment and Follow-on Activities and capability to manage simultaneous development and production efforts for multiple programs/platforms.
The above capabilities are not listed in any specific order of priority and are provided to help focus vendor responses. In addition to describing the approach to delivering these capabilities, the technical solution shall also include a full discussion of:
a) Anticipated development risks.
b) A description of the lifecycle support concept and management costs for a fully delivered FMT-CC product including Interim Contractor Support (ICS) for a period of one year.
c) Proposed timelines tied to milestone activities. The estimated period of performance for completion of phases one through three is 20 months.
The vendor shall include the anticipated delivery dates with their solution that includes all FMT-CC capabilities and completion dates for all tasks and task stages as described in the RFS.
Vendors should submit fixed amount pricing Proposed Pricing Milestones with its Pricing Solution. The Government is not dictating a specific price mechanism. However, proposed payments should be linked to clearly definable, detailed milestones in each phase. It should be clear, with sufficient detail, what is being delivered at each milestone. The vendor’s pricing milestones may vary from the defined decision points, depending on the proposed solution.
6. DATA RIGHTS, INTELLECTUAL PROPERTY, AND PLANNED TERMS AND CONDITIONS
The Government will seek Government purpose rights to all development and deliverables of technical data and computer software funded under the transaction agreement, for at least a five-year period. Government purpose rights means the right to use, modify, reproduce, release, perform, display, or disclose technical data within the Government without restriction; and release or disclose technical data outside the Government and authorize persons to whom release or disclosure has been made to use, modify, reproduce, release, perform, display, or disclose technical data for United States Government purposes. The five-year period, or such other period as may be negotiated, would commence upon execution of the Other Transaction Agreement that required development of the items, components, or processes or creation of data. The vendor will have the exclusive right, including the right to license others, to use technical data in which the Government has obtained Government purpose rights under this contract for any commercial purpose during this five-year period. Upon expiration of the five-year or other negotiated period, the Government would receive unlimited rights in the technical data and computer software. All data and information developed under this effort should be marked with Distribution D Statements.
The vendor shall describe the intellectual property rights being provided to the Government in terms of technical data, both in software and hardware, clearly outlining any rights restrictions. It is the Government’s intent to plan for the maintenance and modification of the system(s) using Government personnel and third party contractors. If additional pages are needed, data rights assertions may be submitted as an appendix, which has no page limit and does not count against the proposed technical solution page limitation.
The vendor shall make a willful attempt to analyze feasible non-proprietary solutions and incorporate them when applicable to the effort. This includes, but is not limited to, software rights, data, source code, drawings, manuals, warranties, and integration efforts. The vendor shall clearly state all assumptions made during development of responses.
7. SELECTION PROCESS
Individual responses will be evaluated on technical merit of the response, feasibility of implementation, schedule, and total project risk. The evaluation will include consideration of the following, listed in no particular order of importance:
• Maturity and technical merit of proposed approach
• Relevant Experience
• Team composition and subvendor involvement
• Prototype and production capability (for example: facility, manpower, teaming arrangements)
• Data rights assertion
The Government is planning a site visit to Ft. Benning to provide information to vendors during the solution preparation process. The dates for the site visit will be determined by the availability of Ft. Benning personnel. The Government reserves the right to request demonstrations of commercially proposed solution sets as part of the negotiation and risk assessment portion of the evaluation. The Government will award this project, via TReX, to the respondent(s) whose proposed solution will be most advantageous to the Government: price, schedule, technical risks and other factors considered. The Government reserves the right to award to a respondent that does not meet all of the requirements, but provides attributes or partial solutions of value to the RFS.
If sufficient validation of the proposed solution is not provided, the Government may reject the submission. Assessment of risks is subjective. If the risk is obvious or the schedule seems overly aggressive, the Government will consider that in their total risk assessment.
8. SUSTAINMENT AND FOLLOW-ON ACTIVITIES
It is anticipated that potential follow-on production OTAs or contracts will be awarded which use the FMT-CC architecture and software, developed under this prototyping effort. Potential follow-on production OTAs or contracts may be either sole source, based on successful completion of the prototype project within the scope of this document, or competed at the discretion of the Government. The maintenance training systems and capabilities include DTTs for multiple vehicles and variants including (but not limited to) Abrams, Bradley, Stryker, JLTV, MPF, and AMPV. Follow-on production activities could include system and software updates to address obsolescence, concurrency, evolving training requirements, and technology insertion.
The fielded prototypes and/or follow-on production may be supported using Interim Contractor Support (ICS) provided by the system developer. The ICS will provide all or part of a material support by contract for a specified interim period after initial deployment to allow the existing PEO STRI sustainment contract to be phased in. At the completion of ICS, the systems may be supported using the existing Life Cycle Contractor Support (LCCS) concept for the maintenance and sustainment of the systems.
Anticipated follow-on activities include, but are not limited to the following:
1) Produce additional models and lessons for the Bradley A3, A4, and other variants which are compliant with the approved FMT-CC architecture and the vehicle specific training requirements.
2) Produce additional models and lessons for the Abrams SEP v2, SEP v3, and other variants which are compliant with the approved FMT-CC architecture and the vehicle specific training requirements.
3) Produce additional models and lessons for the Stryker A1 and other variants which are compliant with the approved FMT-CC architecture and the vehicle specific training requirements.
4) Produce an exportable DTT which is compliant with the approved FMT-CC architecture, the vehicle specific training requirements, and in accordance with the Common Core standalone DTT objective requirement.
5) Produce DTT systems for other vehicle types not included in 1-4 above.
Follow-on Products: Follow-on products will include software design description, source code, interface capability and interface design documents (ICD/IDD), production level technical data package, system specifications.
Estimated Timeline: FY20-FY25
The estimated value of all potential follow-on activities is $21 million dollars.
9. ADDITIONAL INFORMATION
The costs of preparing and submitting a response is not considered an allowable direct charge to any contract or agreement.
Export controls: research findings and technology developments arising from the efforts may constitute a significant enhancement to the national defense and to the economic vitality of the United States. As such, in the conduct of all work related to this effort, the recipient will comply strictly with the International Traffic in Arms Regulation (22 C.F.R. §§ 120-130), the National Industrial Security Program Operating Manual (DoD 5220.22-M) and the Department of Commerce Export Regulation (15 C.F.R. §§ 730-774).
Interaction and/or Disclosure with Foreign Country/Foreign National Personnel. The Vendor should comply with foreign disclosure processes IAW US Army Regulation (AR) 380‐10, Foreign Disclosure and Contacts with Foreign Representatives; Department of Defense Directive (DoDD) 5230.11, Disclosure of Classified Military Information to Foreign Governments and International Organizations; and DoDD 5230.20, Visits and Assignments of Foreign Nationals.
All submissions shall be unclassified. Submissions containing data that is not to be disclosed to the public for any purpose or used by the Government except for evaluation purposes shall include the following sentences on the cover page:
“This submission includes data that shall not be disclosed outside the Government, except to non-Government personnel for evaluation purposes, and shall not be duplicated, used, or disclosed -- in whole or in part -- for any purpose other than to evaluate this submission. If, however, an agreement is awarded to this Company as a result of -- or in connection with – the submission of this data, the Government shall have the right to duplicate, use, or disclose the data to the extent agreed upon by both parties in the resulting agreement. This restriction does not limit the Government's right to use information contained in this data if it is obtained from another source without restriction. The data subject to this restriction are contained in sheets [insert numbers or other identification of sheets]”
Each restricted data sheet should be marked as follows:
“Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this submission.”
To view and download the RFS or any other applicable document, click the hyperlinked text below.
Active TReX Membership will be required to submit a solution for this RFS. To start your TReX Membership application and registration, please visit TReX Membership.
Any questions regarding the opportunity should be directed to email@example.com.