Abrams_EDTT__SOW_rev3.1_final.pdf

SOW-2016-011

21 November 2016

Statement of Work

For

Engine Diagnostic and Troubleshooting Trainer (ED/TT)

U.S. Army Program Executive Office for

Simulation, Training, and Instrumentation (PEO STRI)

12350 Research Parkway

Orlando, FL 32826-3276

Engineering

Prepared By: ____________________ Concurrence: ____________________

Dave Voor Jeff Meister

Lead System Engineer, ED/TT Chief Engineer, PdM GCTT

Date: _________ Date: __________

Acquisition Logistics

Prepared By: ____________________ Concurrence: __________________

Juanita Caraballo Robert Capote

Lead Acquisition Logistician, ED/TT Lifecycle Acquisition Mgr., PM TRADE

Date: ___________ Date: ___________

Program Management

Submitted By: ____________________ Approved By: ____________________

Derek Karten LTC Douglas Twitty

Project Director, ED/TT Product Manager, GCTT Date: _________ Date: _________

DISTRIBUTION STATEMENT A: APPROVED FOR PUBLIC RELEASE; DISTRIBUTION IS UNLIMITED.

david.voor Typewritten Text 22 Nov 16

RyanT Typewritten Text

RyanT Typewritten Text 22 Nov 16

RyanT Typewritten Text

CarabalJ Typewritten Text 22 Nov 16 shaun.p.schneider Typewritten Text 21 Nov 16 shaun.p.schneider Typewritten Text shaun.p.schneider Typewritten Text 23 Nov 16 shaun.p.schneider Typewritten Text 30 Nov 16

Revision History

Revision Date Pages Description

Original

Contents

1. SCOPE

Background

2. APPLICABLE DOCUMENTS

Department of Defense and Military Standards, Instructions and Handbooks

Other government documents, drawings and publications

PEO STRI and program documents

Non-Government documents

3. REQUIREMENTS

Program management

3.1.1 Integrated master schedule

3.1.2 Integrated project team

3.1.3 Meetings and reviews

Post award conference/Start of Work meeting

Program management reviews

IPT meetings

Visitor support

3.1.4 Risk management

3.1.5 Contract invoice and payment report

3.1.6 Contractor manpower reporting application

3.1.7 Government Furnished Equipment (GFE)/ Government Furnished Information (GFI)

GFE Hardware Drawings

GFE Software Baseline

3.1.8 Antiterrorism level 1 training

3.1.9 Operational security

3.1.10 AT awareness for overseas travel

3.1.11 Common access cards

Systems engineering

3.2.1 System design

Integration of Government furnished information

Hardware engineering

3.2.2 Software engineering

Software requirements and architecture development

Software design constraints

Software design and implementation

Disaster recovery media

3.2.3 Hardware and software integration

3.2.4 Cybersecurity hardware and software purchases

3.2.4.1 Cybersecurity artifacts

3.2.4.2 Cybersecurity process and controls

3.2.4.3 CS Control Review/RMF Implementation Plan Review

3.2.4.4 Security control assessment

3.2.4.5 SCA event

3.2.4.6 CS training and certification

3.2.5 Supportability engineering

3.2.6 Reliability and maintainability engineering

R&M predictions

3.2.7 Safety engineering

3.2.8 Quality management system requirements

3.2.9 Manpower and personnel integration

3.2.10 Contaminate and corrosion control

3.2.11 Standardization

3.2.12 Product definition data

3.2.13 System definition stage

Data collection

System requirements review

3.2.13.2.1 SRR entry criteria

3.2.13.2.2 SRR completion/exit criteria

3.2.13.2.3 SRR products

3.2.14 Preliminary design stage

Preliminary design review

3.2.14.1.1 PDR Entry Criteria

3.2.14.1.2 PDR completion/exit criteria

3.2.14.1.3 PDR products

3.2.15 Detailed design stage

Critical design review

3.2.15.1.1 Subsystem design

3.2.15.1.2 CDR entry criteria

3.2.15.1.3 CDR completion/exit criteria

3.2.16 Configuration management

Configuration control board

Configuration identification

Configuration change management

Configuration verification and audit

3.2.16.4.1 Physical configuration audit

3.2.16.4.2 PCA entry criteria

3.2.16.4.3 PCA exit criteria

3.2.16.4.4 Deviations

3.2.17 System integration

3.2.18 System tests

Responsibility for tests

Test authority

Test methods

Test criteria

Test logs

Changes during and after testing

Software changes during government testing

T&E deficiency reporting

DR documentation

T&E stoppage

Contractor verification testing

Test readiness review

3.2.18.12.1 TRR entry criteria

3.2.18.12.2 TRR exit criteria

First article testing

3.2.18.13.1 FAT entry criteria

3.2.18.13.2 FAT exit criteria

3.2.18.13.3 Software baseline recovery

In plan acceptance test

On site acceptance test

Integrated logistics support program

3.3.1 Maintenance planning

3.3.2 Maintenance concept and skills

3.3.3 Lifecycle costs

3.3.4 Government/industry data exchange program

3.3.5 Supportability Analysis and Logistics Product Data

Tools and test equipment

Spares selection review

3.3.6 Facilities

Site Survey

Training system installations

3.3.7 Technical publications

Instructor/operator manual

System maintenance manual

COTS manuals and associated lists

3.3.8 Logistics demonstration

Technical publications in process reviews

3.3.8.1.1 30% Technical publications in process reviews

3.3.8.1.1.1 30% IPR entry criteria

3.3.8.1.1.2 30% IPR exit criteria

3.3.8.1.1.3 70% Technical Publications IPR

3.3.8.1.1.4 70% IPR entry criteria

3.3.8.1.1.5 70% IPR exit criteria

Technical publications validation

Technical publications verification certification

3.3.9 Training courses and products

Operator course

System maintenance course

3.3.10 Item unique identification

4. Notes

Definitions

4.1.1 Integrated project team

4.1.2 Acronyms and abbreviations

Statement of Work for the

U.S. Army Abrams Engine Diagnostics and Troubleshooting Trainer (ED/TT)

1. SCOPE.

This Statement of Work (SOW) describes the work to be performed by the contractor in providing the M1A2 System Enhancement Package (SEP) version 2 (v2) Abrams Tank Engine

Diagnostics and Troubleshooting Trainer (ED/TT) that complies with the ED/TT System

Requirements Document (SRD) PRF-PT-00665. This SOW defines the effort to develop, integrate, manage, deliver, install, test and document this procurement.

Background.

The Engine Trainer has been a part of the United States Army Ordnance Center and School

(USAOC&S) for the last 30 years, early 1980s. The trainer was developed to support their

Program of Instruction (POI) and Training Support Packages (TSP) and to improve Soldiers proficiency to maintain the Full-Up Power Pack (FUPP), engine and transmission, and engine management system. The Engine Trainer has become a major part of training for the M1

Abrams series tank. The Engine Trainer consists of three-pieces: FUPP, Engine Stand, and

Driver’s Compartment. The trainer is located in a fixed site facility with all safety aspects such as external exhaust plenum and carbon monoxide sensors and other features for safe operation.

This gives the student easy access to the ED/TT subsystems, LRUs and Cables during diagnostics and troubleshooting tasks.

2. APPLICABLE DOCUMENTS.

The following documents are applicable to this SOW to the extent specified herein. In the event of a conflict between documents referenced herein and the contents of this SOW, the contents of this SOW shall be the governing requirement. The issues of these documents are those cited in the solicitation or contract Document Summary List. Nothing in this document supersedes applicable laws and regulations unless a specific exemption has been obtained.

Department of Defense and Military Standards, Instructions and Handbooks.

MIL-STD-130 Identification Marking of U.S. Military Property

MIL-STD-40051-

2C

Preparation of Digital Technical Information for Page-Based

Technical Manuals

MIL-STD-3046

(ARMY)

Department of Defense (DoD) Interim Standard Practice, Configuration Management

MIL-STD-31000 Technical Data Packages

MIL-PRF-29612 Training Data Product Specification

MIL-PRF-32216 Evaluation of Commercial Off-the-Shelf (COTS) Manuals and

Preparation of Supplemental Data

DoDI 8320.04 Item Unique Identification (IUID) Standards for Tangible

Personal Property

DoDI 8500.01 Cybersecurity (CS)

DoDI 8510.01

DoD 8570.01- M

Risk Management Framework for DoD Information

Technology, March 12, 2014

Information Assurance Workforce Improvement Program

(Copies of these documents are available online at http://assist.daps.dla.mil/quicksearch/ or from the Standardization Document Order Desk, 700 Robbins Avenue, Building 4D, Philadelphia, PA

19111-5094.)

Other government documents, drawings and publications.

The following other Government documents, drawings, and publications form a part of this

SOW to the extent specified herein.

29CFR1910.1200 Occupational Safety and Health Standards Toxic and Hazardous

Substances

Antiterrorism (AT) Anti-Terrorism training (https://atlevel1.dtic.mil/at)

AR 525-13 Antiterrorism

Operations Security

(OPSEC)

Army iWATCH Program, (http://www.myarmyonesource.com/familyprogramsandservices/i watchprogram/default.aspx)

Army Policy Notice

09-44A

Computer Hardware, Enterprise Software and Solutions (CHESS)

Program (https://chess.army.mil)

Contractor

Manpower

Reporting

Application https://cmra.army.mil

PEO STRI and program documents.

PRF-PT-00665 Systems Requirements Document (SRD) for ED/TT

TM 9-2350-388-10 Technical Manual, Operator’s Manual for Abrams

M1A2 SEP v2 Tank

(Copies of the above documents are available from the Procurement Contracting Officer at PEO

STRI, ATTN: SFAE-STRI-K, 12350 Research Parkway, Orlando, FL 32826-3276. DoD

Instructions are available on the internet at URL: http://www.dtic.mil/whs/directives/.)

Non-Government documents.

ANSI/ISO/ASQ Q9001 Quality management systems requirements

ANSI/ISO/ASQ Q9000 Quality management systems fundamentals

ANSI/ISO/ASQ Q9004 Managing for sustainment

(Applications for copies should be addressed to the American National Standards Institute, 11

W. 42nd Street; 13th Floor, New York, NY 10036 or National Electrical Manufacturers

Association, 1300 North 17th Street, Rosslyn, VA 22209.)

3. REQUIREMENTS.

Program management.

The Contractor shall establish and maintain a project management program and schedule during performance of the contract to include provisions for technical and administrative planning, organization, coordination, resource allocation, risk management, cost management, and other efforts as appropriate to accomplish the contractual objectives of the Abrams ED/TT program.

(DI-MGMT-80227) Contractors Progress, Status and Management Report

3.1.1 Integrated master schedule.

The contractor shall develop, implement, manage to, update, and maintain the contract Integrated

Master Schedule (IMS). The IMS shall present a finalized tiered scheduling system showing all critical milestones and prerequisite events. The lower tiered schedules shall display increasing levels of detail down to the work package level. All contract schedule information delivered and presented at program reviews shall originate from the IMS and shall contain all critical events, accomplishments, predecessors and successors’ events and their dependencies. The IMS shall address all program activities including activities performed by subcontractors and key supplier activities. The contractor shall develop the logic resource loaded network that accurately portrays the sequence and relationship of activities defining the development and production program. The network shall be implemented on a computer based program management control system which utilizes critical path method network analysis, accepts parametric data input, and can be utilized to determine a probabilistic estimate of the program schedules and cost for reporting project progress. The network activities duration data shall be updated to reflect accomplished activities and any changes in activity duration estimates. The Contractor shall conduct critical path analysis of the tasks and identify problem areas and corrective actions required to eliminate or reduce schedule impacts. The Contractor shall include and integrate into the IMS system network outside dependencies/events pertaining to the total program. These dependencies/events will be provided by the Government or gathered by the Contractor during participation in other Integrated Project Team (IPT) meetings.

(DI-MGMT-81861) Integrated Program Management Report

3.1.2 Integrated project team.

The Contractor shall define, document, implement, and maintain an Integrated Project Team

(IPT) structure for the duration of the contract. The purpose of an IPT is to bring together all the functions and stakeholders, including other contractors and Government personnel, in the performance of a product or process and concurrently make integrated decisions affecting that product or process. Each IPT shall prepare the required planning documents for the system element to which it is assigned; shall be responsible for developing and satisfying the specifications and baselines associated with the element; and shall complete the work outlined in tasking statements related to the element, including the technical reviews.

3.1.3 Meetings and reviews.

The contractor shall conduct, attend, and participate in meetings and reviews to be held at contractor and Government facilities, including equipment fielding locations. The contractor shall make key personnel and support available to carry out the meetings and reviews. The contractor shall establish the capability to communicate via teleconferencing with data sharing.

Meetings and reviews will be co-chaired by a Government and contractor representative. The contractor shall be prepared to explain the reasoning, assumptions, and methodologies in arriving at particular conclusions, recommendations, and alternatives in the accomplishment of the tasks required by the SOW. The contractor shall prepare media to aid in the presentations. All media presented during the meetings shall be included in the meeting minutes. The contractor shall make available facilities for Government only discussions that may be required, during all meetings and reviews at the contractor’s facility. Subcontractors shall attend meetings and reviews when required. The contractor shall prepare the agenda, record a list of all attendees, and record meeting minutes for all meetings and reviews.

The following meetings and reviews are envisioned:

a. Start of Work and Post Award Meeting

b. Program Management Reviews

c. IPT meetings

d. Design reviews (preliminary and critical)

e. System Requirements Review

f. Test Readiness Reviews

g. Technical Publications In-Process Reviews

h. Other meetings and reviews as directed by the Procurement Contracting Officer (PCO)

i. Other meetings and reviews as agreed to by the contractor and the Government

j. Security Control Assessment Test Readiness Review

Meetings and reviews shall be considered completed when all of the following items are completed:

a. A formal meeting/review has been conducted

b. All topics required for discussion and presentation have been covered

c. All action items have been addressed

d. The Government has approved the meeting minutes

(DI-ADMN-81249) Conference Agenda

(DI-ADMIN-81250) Conference Minutes

Post award conference/Start of Work meeting.

The Post Award Conference (PAC)/start of work meeting shall be held within 30 days after contract award at a mutually agreed to location. The PAC shall establish the framework for the contractor and Government interaction during the performance period of the contract. At the

PAC, the contractor shall present an IMS showing critical milestones and supporting events, including logistics. PAC shall include the presentation and discussion of information and data relating to:

a. Introduction and contract overview

b. Team contact list (names, IPT memberships, phone numbers and email address)

c. Discussion of specifications, data, and SOW requirements

d. Presentation of the draft IMS

e. Identification of critical paths within the IMS

f. IPT structure, membership, and charters (roles and responsibilities)

g. Action item management process

k. Metrics to be used as management indicators during the program

Program management reviews.

The contractor shall conduct formal program management reviews on an average of one every three months, starting after the PAC. The location of the reviews shall be at the contractor’s facility and via teleconferencing. The program management review shall provide a program overview, IMS status review and update, and a detailed discussion of pre-selected topics. Status and information at the review shall reflect updates and changes since the previous review.

IPT meetings.

The Contractor shall host IPT meetings to address program’s concerns. IPT meetings shall be held regularly as agreed by the IPT and may be conducted in person (at the contractor’s facilities), teleconference, and video teleconference. Participation by key suppliers and subcontractors may be required, based on the agenda and a specific topic of discussion.

The following IPTs are envisioned other IPTs may be convened on an as needed basis:

a. Management IPT

b. Systems Engineering, Integration, Test and Evaluation IPT (SEIT IPT)

c. System Safety Working Group

d. Software IPT

e. Integrated Logistics Support IPT

f. Data resolution IPT (fidelity)

g. Site deliveries IPT

Visitor support.

When requested by the Procurement Contracting Officer (PCO), the Contractor shall host arrange, and demonstrate the training system.

3.1.4 Risk management.

The contractor shall apply a risk management process that includes identification, analysis, mitigation planning, mitigation plan implementation, and tracking. The contractor’s risk management process shall measure future uncertainties in achieving program goals within defined cost, schedule, and performance constraints. The contractor shall:

a. Identify and document moderate and high-risk items for each risk assessment area.

b. Identify and implement risk handling approaches, and track over time each moderate and high-risk item.

c. Develop mitigation plans to identify the recommended critical path for contract completion and the appropriate risk handling approach to lower the level of uncertainty.

(DI-MGMT-81808) Contractor Risk Management Plan

3.1.5 Contract invoice and payment report.

The contractor shall collect and report financial and accounting information associated with contract line item numbers within the awarded contract, which will be used to manage obligations, disbursements, un-liquidated obligations, and canceling accounts associated with appropriated funds.

(DI-MGMT-81651) Contractor Invoicing and Payment Report

3.1.6 Contractor manpower reporting application.

The contractor shall report all contractor labor hours (including subcontractor labor hours) required for performance of services under this contract for the training system via a secure data collection site. The contractor shall fill in all required data fields using the following web address: http://www.ecmra.mil/. Reporting inputs will be for labor executed during the period of performance during each Government Fiscal Year (FY). While inputs may be reported any time during the FY, all data shall be reported no later than October 31 of each calendar year.

Contractors can find User Guides, Frequently Asked Questions, and may direct questions to the help desk at http://www.ecmra.mil/.

3.1.7 Government Furnished Equipment (GFE)/ Government Furnished Information (GFI).

The existing Engine Trainers with stands currently located at Fort Benning, GA, Fort Lee, VA and associated LRUs, cables and components will be provided as GFE. An itemization of all

GFE / GFI will be included as an attachment to the contract.

GFE Hardware Drawings.

The Government will provide Tank LRU drawings in Portable Document Format (PDF) format.

The Government will also provide Tank cable drawings in PDF format. These drawing may be used as the basis for creating Trainer Unique Drawings or modification drawing may be created to document the trainer design. The Government is unable to provide drawings of the current

M1A1 ED/TT. The contractor shall create product definition data as required by 3.2.12 for all reuse of current M1A1 ED/TT designs. The ED/TT Technical Data Package shall represent the complete design.

GFE Software Baseline.

The Government will provide the existing Diagnostic and Troubleshooting (D/T) software baseline for reused of the instructor station functionality. The Government will provide the latest

ACSL software to operate the iCDU and iDID menus. The Government will provide the Engine

Control software which allows the Digital Electronics Control Unit (DECU) to control start up, operation and shutdown of the tactical tank engine.

3.1.8 Antiterrorism level 1 training.

All contractor employees, to include sub-contractor employees, requiring access to Army installations, facilities, and controlled access areas shall complete Antiterrorism (AT) Level I awareness training within 90 calendar days after contract start date. The contractor shall submit certificates of completion for each affected contractor employees and sub-contractor employees.

http://www.ecmra.mil/ http://www.ecmra.mil/

AT level I awareness training is available at the following website: https://atlevel1.dtic.mil/at.

This training shall be renewed annually.

3.1.9 Operational security.

Contractor’s employees shall take the OPSEC training, as required, in the performance of tasks bounded by OPSEC requirements. Certifications of completion shall be attached to the

Contractor Status Report. The contractor shall identify a list of required personnel and their required training to be reviewed and approved by the Government. A status of this list and the required training shall be included in the Contractor’s status report.

3.1.10 AT awareness for overseas travel.

Additional training shall apply in the event of overseas travel required in the performance of this effort.

3.1.11 Common access cards.

The contractor shall apply for Common access cards (CACs) for all personnel planned to be involved with site visits to Government facilities. Instructions on how to apply for a Common

Access Card (CAC) will be provided by the PCO during the PAC.

Systems engineering.

The contractor shall implement a system engineering process that transforms all system requirements into a set of lower level performance requirements defining the system. Systems engineering shall integrate all elements of multifunctional engineering efforts to meet system requirements. The contractor shall integrate the systems engineering disciplines, such as reliability, maintainability, security, logistics, human factors, safety, value engineering, and standardization into the training system design and development effort.

3.2.1 System design.

The contractor shall design, develop, produce, and deliver the training systems in accordance with (IAW) PRF-PT-00665. The contractor shall use PRF-PT-00665 as the basis for development of all lower level specifications. The contractor shall use a common architecture for the design and production of the training system to reduce the hardware and logistics support footprint and maximize the reuse of common components. The design concept shall incorporate an open systems approach to choose specifications and standards widely adopted by industry standards bodies or de facto standards (set by the market place) for system interfaces, products, practices, and tools. Selected designs and specifications shall be based on performance, cost, industry acceptance, long term availability, supportability, and upgrade potential. The contractor shall maximize the open architecture design to support system upgrades, concurrency/technology insertions, ease of software/configuration changes and the ability to reprogram interfaces to support future changes.

https://atlevel1.dtic.mil/at

Integration of Government furnished information.

The contractor shall re-use and integrate the Government Furnished Information (GFI) software into the training system. The contractor shall load and install the Abrams M1A2 Engine

Technical Manuals. The technical manuals shall be available to the instructor during a lesson.

Hardware engineering.

The contractor shall integrate and assemble the system hardware that satisfies the performance requirements in the specification. The contractor shall apply the systems engineering process during each level of system development (system, subsystem, and component) to add value

(additional detail) to the products defined in the prior application of the process. Through each of the following design stages, information generated shall be documented in an integrated database.

3.2.2 Software engineering.

The contractor shall develop the system software and firmware in accordance with recognized industry standards and internal documented processes. The design shall incorporate features that promote ease of operation, ease of software maintenance, ease of future updates and modifications and smart designs that can justify a reduction in the amount of documentation.

Computer programs and computer data systems shall be fully integrated in accordance with the performance specification. The contractor shall conduct market surveillance and market investigations, in order to maximize the procurement of COTS software. The contractor shall employ the following: well-defined security policy models; structured, disciplined, rigorous hardware and software development techniques; and sound system/security engineering principles.

Software requirements and architecture development.

The contractor shall develop software requirements and architecture. All analysis and results shall be documented in an integrated database. The contractor shall define and record the operational concept for the system, the architectural design of the system (identifying the components of the system, their interfaces and a concept of execution among them) and the traceability between the system components and system requirements. The contractor shall define and record the software requirements to be met by each software item, the methods to be used to ensure that each requirement has been met, and the traceability between the software item requirements and system requirements. The contractor shall define, document, and follow an open systems approach for using modular design, standards-based interfaces, and widely-supported consensus-based standards. The contractor shall develop an architecture that is layered and modular and uses standards-based COTS hardware, operating systems, and middleware that all utilize either non-proprietary or non-vendor-unique key module or component interfaces. The contractor shall use Government software, provided as GFI, in the architecture and design of the training system.

Software design constraints.

Commercial Information Assurance (IA) and IA-enabled IT products, which have been evaluated and validated, as appropriate, in accordance with the National Information Assurance Partnership

(NIAP) (http://www.niap-ccevs.org/cc-scheme/vpl/) or Common Criteria (CC) Evaluation and

Validation Scheme (http://www.commoncriteriaportal.org/public/consumer/) shall be used to enter, process, store, display, or transmit information, to the maximum extent practicable.

Software design and implementation.

The contractor shall design software, develop executable code, perform unit testing and integrate software components (with each other and with hardware components) to meet system requirements.

(DI-IPSC-81441) Software Product Specification

(DI-IPSC-81435) Software Design Description

(DI-IPSC-81442) Software Version Description

Disaster recovery media.

The contractor shall develop a software recovery media. In the case of software corruption or a hardware failure of the computer, the media shall be utilized to restore the originally delivered software/hardware baseline. Using the disaster recovery procedures, the trainer shall be restored to the original operational state.

(DI-AVCS-80700) Computer Software Product End Items

3.2.3 Hardware and software integration.

The contractor shall perform all activities to integrate and assemble the hardware and software to achieve a fully functional and accredited system, with all support systems, that perform and operate in accordance with the PRF-PT-00665. Verification shall be in accordance with PRF-

PT-00665 and the approved tests procedures.

3.2.4 Cybersecurity hardware and software purchases.

The contractor shall purchase all Commercial Off-the-shelf desktop, notebook, computers and video teleconferencing equipment, by using Computer Hardware, Enterprise Software and

Solutions (CHESS) website (https://chess.army.mil) in compliance with Army Policy Notice 09-

44A; The contractor shall use CHESS as the Primary Source for Procuring Commercial

Information Technology (IT) Hardware and Software. The Army has mandated the use of

Secure Host Baseline - Army (SHB-A) as the Windows-based standard operating system. A licensed copy of SHB-A can be obtained from CHESS or Softmart (http://www.softmart.com).

If SHB-A cannot be used, (The contractor shall provide written explanation as to why SHB-A cannot be used.) a CS approved operating system shall be configured IAW the latest DISA

Security Technical Implementation Guides (STIG), written for that operating system.

For hardware and software products not available through CHESS or Softmart, The contractor shall select the CS validated products IAW CNSS Policy No.11. There will be no wavier issued by the Government for unapproved CS products.

3.2.4.1 Cybersecurity artifacts.

The contractor shall apply all applicable STIGs (e.g., manual and/or automated) to the DoD approved Operating systems, COTS Hardware and Software, and contractor developed software.

http://www.niap-ccevs.org/cc-scheme/vpl/ http://www.commoncriteriaportal.org/public/consumer/

The contractor shall supply the Government with vulnerabilities assessment documentation (e.g.

STIG Deviation Report) required for the completion of the Plan of Action and Milestones

(POA&M) document to ensuring adherence to the accreditation guidelines. The Government is responsible for CS accreditation with the assistance from the contractors.

(DI-MISC-80711) Scientific and Technical Reports (CS Scan Report)

3.2.4.2 Cybersecurity process and controls.

The contractor shall develop and maintain a robust Cybersecurity process to guide the system’s design, document CS decisions, and identify and implement CS requirements IAW DODI

8500.01 and DODI 8510.01. The contractor shall assist the Government in the preparation of CS system documentation. The contractor shall establish configuration management of the product baseline, implement operational system security control measures and support CS certification testing. The contractor shall identify and use CS approved solutions to include CS approved operating systems, CS approved network devices, and CS approved software. Your CS workforce shall be trained and certified IAW DoDD 8570.01 or Industry equivalent process.

The contractor shall implement CS controls IAW CNSSI 1253 and take action to address inherent system vulnerabilities and weaknesses. The contractor shall plan and implement CS e.g.

using Security Technical Implementation Guides (STIG), and Government approved CS scanning tools, as required for Standalone, Potential Impact, Confidentiality, Integrity, and

Availability, along with the corresponding CS Controls as identified in the Standalone Risk

Management Framework Implementation Plan (RIP).

3.2.4.3 CS Control Review/RMF Implementation Plan Review.

The contractor shall support a CS Control Review / RMF Implementation Plan Review (RIPR) held as part of the Preliminary Design Review (PDR). The CS Control Review/RIPR shall address at a minimum:

Update on RMF Implementation Plan (RIP)

Update Preliminary Data Flow and Accreditation Boundary Diagram

Update on the hardware/software lists and procurement action

Update on contractor CS training as applicable and the use of CS Scanning tools

Update on design and system integration schedule

3.2.4.4 Security control assessment.

The contractor shall support a Security Control Assessment (SCA) Readiness Review held no more than 7-14 working days prior to the SCA Event. The SCA Readiness Review and Scan

Report shall address at a minimum:

Final CS Scans Report of the system

Corrective actions taken and written analysis of any open deficiencies

Update of CS system documents

Finalization of travel arrangement in support of the SCA event

3.2.4.5 SCA event.

The contractor shall support the SCA event. The SCA event is conducted by the CS independent certifier to assess the overall security posture of the system prior to System Test. The status of the results for all assigned CS controls and security requirements are compiled and discussed with the Contractor. The contractor shall provide support to address the findings from the SCA events to the Government’s satisfaction after the scorecard is tabulated, and assist the

Government in the preparation of the Plan of Action and Milestone (POA&M) documentation.

3.2.4.6 CS training and certification.

The contractor shall have trained and certified CS personnel that will be performing CS functions in accordance with DoD 8570.01-M.

3.2.5 Supportability engineering.

The contractor shall ensure the supportability of the system through planning, implementation, and verification of materials, services, and resources required to satisfy the operational requirements. Supportability and Life Cycle Cost shall be primary design factors. The contractor shall evaluate reliability and maintainability factors in the design process. Design for supportability shall include the use of common fasteners and connectors, common COTS standards and proven technology. The system design shall minimize life-cycle costs and maximize life-cycle supportability by avoiding the use of proprietary items; components with limited sources for spare parts, support, or maintenance; recurring usage or service fees; and the need for special tools or test equipment.

3.2.6 Reliability and maintainability engineering.

The contractor shall establish and maintain active and effective Reliability and Maintainability

(R&M) processes, for the trainer unique hardware design, that are integrated within the systems engineering process and satisfy R&M objectives. Logistics support information shall be derived from early analysis such that R&M engineering can be applied to influence the design effort.

The contractor shall include the R&M status as topics of discussion during scheduled program reviews. The R&M process shall support economical achievement of overall program objectives and ensure sustained product integrity and safety. The process shall:

a. Optimize availability and mission success of the system.

b. Minimize system demand for maintenance manpower and logistic support.

c. Provide essential management information.

d. Minimize R&M process impact on overall program cost and schedule.

Quantitative reliability requirements for the system, all major subsystems, and equipment shall be in the system/subsystem specifications. All reliability data and information used for logistics support analysis and engineering activities shall be based upon, and traceable to, the outputs of the R&M process. The maintainability effort shall measure complexity, accessibility and testability to enhance servicing, preventive maintenance, corrective maintenance, and diagnostic capabilities. Specific design and verification criteria shall be established through performance specifications of qualitative and quantitative factors to be expressed as measures of maintainability achievement for the system, segment, subsystem, and equipment levels.

R&M predictions.

The contractor shall develop R&M predictions for the training system equipment to examine early in the program the probability that the R&M requirements of PRF-PT-00665 will be met with the proposed design. Manufacturer’s data, documented engineering analysis, and verifiable field data may be used as sources of failure rate, Mean-Time-Between-Failures, and Mean-Time-

To-Repair data. The contractor shall update the R&M predictions throughout the duration of the contract and shall present the prediction results at the scheduled program design reviews.

3.2.7 Safety engineering.

The contractor shall develop and implement tasks and activities to identify, evaluate and eliminate or control hazards throughout the system’s life cycle. The contractor shall design the training system ensuring the system is safe during operation, transportation, maintenance, support, and disposal. The contractor shall ensure their facility provides a safe environment to develop and test the ED/TT. Some of the hazards that require mitigation and are associated with the Tank engine include, but not limited to, exhaust, fuel, noise, heat. The contractor shall conduct safety analysis, hazard identification and classification and hazards tracking integral to the system design effort. The contractor shall develop a hazard risk index, hazard severity, and hazard probability levels for all hazards. The contractor shall establish and support a System

Safety Working Group as an IPT.

(DI-SAFT-80101) System Safety Hazard Analysis Report

(DI-SAFT-80102) Safety Assessment Report

(DI-SAFT-80106) Health Hazard Assessment Report

3.2.8 Quality management system requirements.

The contractor shall provide and maintain a Quality Management System (QMS) that satisfies program objectives and meets the requirements of ANSI/ASQ Q9001 or an equivalent QMS.

ANSI/ASQ Q9000 and ANSI/ASQ Q9004 may be used for guidance. The QMS procedures, planning, and all other documentation and data that comprise the QMS, shall be made available to the Government for review. Existing quality documents that meet the requirements of the contract may continue to be used. The Government may perform the inspections, verifications, and evaluations necessary to ascertain conformance to requirements and the adequacy of the implementing procedures. Third-party certification of the contractor’s QMS is not required. The contractor shall require subcontractors to maintain a QMS that achieves control of the quality of the services and supplies provided.

3.2.9 Manpower and personnel integration.

The contractor shall integrate activities of the seven domains of Manpower and Personnel

Integration (MANPRINT) to influence design decisions beginning at program conception and continuing through the development and fielding phases. These MANPRINT domains include

Manpower, Personnel, Training, Human Factors, System Safety, Health Hazards, and

Survivability. The program shall be coordinated width the training, test, and supportability engineering activities to achieve an integrated effort without duplication. The contractor shall conduct MANPRINT reviews as an integral part of scheduled program and design reviews.

3.2.10 Contaminate and corrosion control.

The contractor shall incorporate corrosion control measures, as determined by logistic support analysis, into the system design process, the manufacturing process and all levels of maintenance to include supply, and storage processes. Design concepts shall reflect realistic environments and resource availability as determined by logistic support analysis.

3.2.11 Standardization.

The contractor shall design the system to achieve maximum subsystem, component, and repair parts commonality. The contractor shall minimize equipment and parts proliferation through a standardization effort. The standardization effort shall include coordination with PEO STRI

Integrated Logistics Support Manager to maximize use of parts already in the inventory or to determine that the existing logistics support resources will benefit from the items chosen for the system.

3.2.12 Product definition data.

During the systems engineering and design, and in accordance with MIL-STD-31000, the contractor shall develop, produce, and maintain Product Definition Data (PDD) that accurately depicts the final product. The PDD is the technical description of items adequate for supporting the acquisition strategy, production, engineering, and life-cycle asset management. The PDD shall disclose complete design, logistics, manufacturing requirements, and the means of measuring compliance with the requirements. The PDD shall provide the Government the ability to operate, support and maintain the training system Piece part information (drawings, computer aided design files and meta data) and associated lists shall provide the necessary design, engineering, manufacturing and quality assurance requirements information necessary to enable the procurement or manufacture of an interchangeable item that duplicates the physical, and performance characteristics of the original product without additional design engineering effort or recourse to the original design activity. The contractor shall produce and maintain documentation for all electrical assemblies and subassemblies in such a manner to ensure their functional integration without recourse to special test equipment or installation of the assemblies or subassemblies into a next higher assembly. The contractor shall identify the components and assemblies by system analysis to be repetitively procured as spare parts for major components and identify any assemblies that may be procured independently. For each higher level component or assembly, the contractor shall determine and document the functional requirements for the item, the environment in which it must operate, the interface, the interchangeability characteristics and the criteria for verifying Logistics Support. The contractor shall identify the following data elements to assist in the procurement of spare parts and repair parts: Commercial and Government Entity code, National Stock Number, manufacturer’s part number and R&M data. The contractor shall obtain document numbers from PEO STRI for the

PDD elements. The contractor shall not add prefixes or suffixes to the numbers. All unused numbers shall be returned upon completion of PDD preparation.

(DI-SESS-81000) Product Drawing/Models and Associated Lists

(DI-SESS-81003) Commercial Drawing/Models and Associated Lists

(DI-SESS-81011) Drawing/Model Number Assignment Report

3.2.13 System definition stage.

The contractor shall establish the system definition with a focus on products required to satisfy in the performance requirements of PRF-PT-00665. The requirements and initial design documentation generated during the system definition stage shall be used to guide subsystem development. The system definition shall ensure that:

a. The system definition meets systems engineering criteria.

b. System requirements are identified.

c. System-level risks have been addressed.

d. Trade study data is adequate to substantiate that system requirements are achievable.

e. Interface requirements between human and products or subsystems have been identified and includes performance, workloads, design constraints, and usability.

f. Decisions made in arriving at the system definition configuration are well supported by analysis, and technical data.

(DI-MISC-81283) Specification Requirement Verification Matrix

(DI-IPSC-81431) System/ Subsystem Specification

Data collection.

The contractor shall collect data from the Abrams M1A2 SEPv2 tank to define the characteristics to be replicated during the simulation. The contractor shall define the physical, mechanical, dynamic and aural characteristics of the Abrams M1A2 SEPv2 components with a high degree of fidelity. The contractor shall supplement the recorded data with analysis and inputs from the

Government Subject Matter Expert (SME) when a complete set of data cannot be recorded in the field. The M1A2 SEPv2 characteristics shall form the basis for the design of the simulator when operated on the different modes and considering the conditions of operator input. The

Government will provide contractor access to an Abrams M1A2 SEP V2 Tank. The contractor shall provide and operate all the measuring equipment. The contractor shall record all the data

(written notes, sound clips, video clips, electronic sensor data, graphs, etc.). The contractor shall produce a plan detailing what data they need to collect and when where and how they plan to collect it. After the data collection effort is complete the contractor shall report their success in collecting adequate data, any data voids and any additional data collection efforts required.

(DI-MISC-80711) Scientific and Technical Reports

System requirements review.

The contractor shall conduct the System Requirement Review (SRR) as a product and process assessment to ensure the system definition is complete and the contractor is authorized to proceed into the preliminary design phase. The purpose of this review is to ensure all system requirements have been completely and properly identified and performance requirements derived from the requirements are defined/testable and consistent with schedule, risk, technology readiness and other system constraints. The System Requirements Review (SRR) shall be conducted at the completion of the systems definition stage for the purpose of determining whether the system definition is sufficiently mature to progress to preliminary design stage. The review shall include the presentation and discussion of information and data relating to:

a. System performance specification,

b. System software functionality description,

c. Preferred system solution definition,

d. Hardware/software allocation,

e. Human interfaces,

f. Data collection,

g. Database and scenario development,

h. And simulation fidelity descriptions.

3.2.13.2.1 SRR entry criteria.

Entry criteria for the SRR shall consist of:

a. Government review of the SRR (preliminary) presentation material indicates it is sufficient to support the SRR.

b. Documented results of the data collection tasks are complete.

c. Draft Requirements Traceability Matrix (RTM) document submitted for review.

3.2.13.2.2 SRR completion/exit criteria.

The SRR is considered complete when:

a. Government concurrence that all required SRR topics have been satisfactorily presented, discussed, and documented.

b. The system requirements, as disclosed, satisfy the requirements of PRF-PT-00665.

c. The system requirements are sufficiently detailed and understood to enable system functional definition, functional decomposition, test, and evaluation.

d. The program risks are identified.

e. The minutes and presentation materials have been submitted and agreed to.

f. All action items have been assigned with suspense date for closure.

3.2.13.2.3 SRR products.

Completion of the SRR should provide the following:

a. A preliminary allocation of system requirements to hardware, software, and human subsystems.

b. Risk identification, including risks mitigation options.

c. A preliminary allocation of system requirements to hardware, human, and software subsystems,

d. RTM reviewed.

e. Recommendation to the Government Team as to the technical readiness of the program to enter the next phase of development.

3.2.14 Preliminary design stage.

The contractor shall initiate subsystem design and create subsystem-level definition and design-to baselines to guide component development. The contractor shall ensure that the design considerations include system functional requirements, systems non-functional requirements

(e.g., performance, design goals, Modular Open System Approach (MOSA) and Human System

Interfaces). The contractor shall ensure that functional design considerations integrate CS functional requirements and that these requirements are included throughout the development process. The contractor shall decompose identified subsystem functions into lower-level functions and allocate functional and performance requirements to component-level functional and physical architectures. The contractor shall define the preliminary component requirements and verification methods, and the build-to baselines for all the components and subsystems.

Final subsystem definition shall include identification of recommended components and interfaces; resolution of subsystem-level risks; assessment of component risks; and design for quality factors to include producibility, verifiability, usability, CS, supportability, trainability, and disposability for each subsystem. Subsystem reviews shall be completed for each subsystem at the completion of its preliminary design stage.

Preliminary design review.

The contractor shall conduct a Preliminary Design Review (PDR) as a review and assessment to ensure the preliminary design meets the performance requirements within schedule, risk, and other system constraints. The PDR shall demonstrate the preliminary design for each configuration item (allocated baseline) and each function in the functional baseline has been allocated to system configuration items. The Government will formally review the activities and work products generated by contractor and verify the approach for the system design is ready to proceed into the detailed design phase. The contractor shall present and describe the training system design and program status. The PDR shall accomplish the following:

a. System requirements and allocations shall be complete, feasible, verifiable, and traceable to top-level system requirements.

b. The design shall be mature based on the technical development goals, events and accomplishments, and empirical analysis and test data supporting progress to date.

c. The risks associated with a continued development effort are manageable.

d. Justify proceeding to the next application of the systems engineering phase.

At the PDR, the contractor shall present the system security design, initial security risk assessment, security test approach, security training approach, and any other security relevant information. During the PDR, the contractor shall include the presentation and discussion of information and data relating to:

a. The subsystem definition is sufficiently mature to meet systems engineering criteria.

b. The subsystem functional requirements and non-functional requirements (e.g., performance, design goals, MOSA) are identified in the subsystem design and are traceable to the system functional and non-functional requirements.

c. Component allocations and preliminary component specifications are reasonable and provide a sound subsystem concept.

d. Software architecture is described using three views: software module view showing the

Computer Software Configuration Item (CSCI), Computer…