training support management tool (tsmt) performance ... · web view2020/10/14 · performance work...

DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED

Performance Work Statement (PWS)For

Synthetic Training Environment – Information System (STE-IS)

TRAINING SIMULATION AND MANAGEMENT TOOL (TSMT)

20 October 2020Version 2.0

Prepared byU.S. Army PEO Simulation, Training, and Instrumentation

(PEO STRI)12211 Science Drive

Orlando, FL 32826-3276


1

23

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

Revision Level Document Date Summary of Change Pages Affected

1.0 16 October 2020 Initial release of document

All

2.0 20 October 2020 Update Paragraph 3.13.1, Industrial Security

69

iDISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED

23

24

Table of Contents

1 Overview..................................................................................................................1.1 Problem Statement.............................................................................................1.2 Synthetic Training Environment Overview..........................................................1.3 Training Support Management Tool Overview...................................................

1.3.1 TSMT Scope.................................................................................................1.3.2 Capability Overview.......................................................................................

1.3.2.1 TSMT......................................................................................................1.3.2.1 TMT........................................................................................................

1.3.2.1.1 Planning Phase.................................................................................1.3.2.1.2 Prepare Phase..................................................................................1.3.2.1.3 Execute Phase..................................................................................1.3.2.1.4 Assess Phase...................................................................................

1.3.2.2 TSS.........................................................................................................2 Acquisition Pathway and Objectives.....................................................................

2.1 Software Acquisition Pathway............................................................................2.2 Objective.............................................................................................................

3 Requirements...........................................................................................................3.1 Program Management........................................................................................3.2 Associate Vendor Agreements...........................................................................3.3 Communication...................................................................................................3.4 Reviews............................................................................................................3.5 System Engineering..........................................................................................3.6 Configuration Management..............................................................................

3.6.1 Configuration Identification..........................................................................3.6.2 Configuration Control...................................................................................3.6.3 Configuration Status Accounting.................................................................

3.7 Integration.........................................................................................................3.8 Deliverables......................................................................................................

3.8.1 Management Deliverables...........................................................................3.8.2 Engineering Deliverables.............................................................................3.8.3 Product Support Deliverables......................................................................

iiDISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

3.8.4 TSMT Hardware Deliverables.....................................................................3.8.5 Cost Deliverables........................................................................................

3.9 System Requirements......................................................................................3.9.1 General........................................................................................................3.9.2 Architecture.................................................................................................3.9.3 Point of Need...............................................................................................

3.9.3.1 Point of Need Conditions......................................................................3.9.3.2 Network................................................................................................3.9.3.3 Cloud....................................................................................................3.9.3.4 Multi-level Security...............................................................................

3.9.4 TSMT Hardware..........................................................................................3.10 Agile Process....................................................................................................

3.10.1 General........................................................................................................3.10.2 Agile Ceremonies........................................................................................3.10.3 Agile Metrics................................................................................................3.10.4 Roadmap.....................................................................................................3.10.5 DevSecOps.................................................................................................

3.11 Testing..............................................................................................................3.11.1 Incremental Government Testing................................................................3.11.2 Integration Environment..............................................................................3.11.3 Development Testing...................................................................................3.11.4 Cybersecurity Tests and Events..................................................................

3.12 Product Support................................................................................................3.12.1 General........................................................................................................3.12.2 Interim Contractor Support..........................................................................3.12.3 Maintenance Planning/Concept...................................................................3.12.4 Warranty......................................................................................................3.12.5 Configuration Audits....................................................................................3.12.6 Diminishing Manufacturing Sources and Material Shortages......................3.12.7 Technical Support Documentation..............................................................3.12.8 Training.......................................................................................................3.12.9 Item Unique Identification............................................................................3.12.10.......................................................................................................System Delivery

60iii


57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

8990

3.13 Security.............................................................................................................3.13.1 Industrial Security........................................................................................3.13.2 Cybersecurity..............................................................................................

3.13.2.1 Cyber Survivability................................................................................3.13.2.2 Risk Management Framework..............................................................3.13.2.3 Cross Domain Solution Authorization (CDSA)......................................3.13.2.5 Cybersecurity Training..........................................................................

3.14 Safety and Health.............................................................................................3.14.1 Safety..........................................................................................................3.14.2 Health..........................................................................................................

4 References.............................................................................................................Appendix A Capability Descriptions........................................................................

A.1 One World Terrain...........................................................................................A.2 Reconfigurable Virtual Collective Trainer........................................................A.3 Live Virtual Constructive Integrating Architecture...........................................A.4 Mission Command Information Systems.........................................................A.5 Avionics Software Emulation...........................................................................A.6 Common Software Library..............................................................................A.7 Army Training Information System..................................................................A.8 Soldier Virtual Trainer.....................................................................................A.9 Integrated Visual Augmentation System / Soldier Immersive Virtual

Trainer.............................................................................................................A.10 STE Live Training System...............................................................................

Appendix B Objective Values...................................................................................Appendix C Capability Roadmap.............................................................................Appendix D Notional MVP/MVCR/Release Plan......................................................Appendix E IMS Template.........................................................................................Appendix F Cost Deliverables..................................................................................

F.1 CSDR DD 2794...............................................................................................F.2 Software Resources Data Report....................................................................F.3 Cost and Hour Report (FlexFile) Contractor Format IAW File Format

Specification (FFS) and Data Exchange Item (DEI)........................................F.4 Quantity Data Report (-Q) Contractor format IAW FFS and DEI.....................

Appendix G Cybersecurity........................................................................................iv


91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111112

113

114

115

116

117

118

119

120

121122

123

124

G.1 DoD CDS Connection Process Diagram........................................................Appendix H Acronyms and Glossary.......................................................................

H.1 Acronyms........................................................................................................H.2 Glossary..........................................................................................................

vDISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED

125

126

127

128

129

List of Figures

Figure 1-1. STE OV-1...................................................................................................................

Figure 1-2. Synthetic Training Environment.............................................................................

Figure 1-3. TMT Interaction.........................................................................................................

Figure G-1. DoD CDS Connection Process Diagram.........................................................

List of Tables

Table 3-1. Recurring Government Meetings............................................................................

Table 3-2. Development / User Feedback Locations............................................................

Table 3-3. Fielding Locations....................................................................................................

Table B-1. Objective Values.........................................................................................

Table H-1. Acronyms....................................................................................................

Table H-2. Glossary.....................................................................................................

viDISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

This page intentionally left blank.

viiDISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED

146

147

148

149

150

151

152

153

154

155

1 Overview1.1 Problem StatementThe Army currently employs a collection of outdated, cyber-vulnerable, and inefficient live, virtual, constructive, gaming (LVCG) collective training systems that form the Integrated Training Environment (ITE) which is not available at the Point of Need (PoN). These systems do not replicate the complex challenges of the current and future Operational Environment (OE) nor are they agile enough to allow Warfighters to train multiple iterations prior to mastering training in the live training environment. As we set the foundation for a Multi-Domain Operations (MDO) capable force in 2028, these critical capability gaps degrade Warfighter training readiness and performance placing our Nation’s defense at risk.

1.2 Synthetic Training Environment OverviewThe Army’s future training capability is the Synthetic Training Environment (STE). The STE will be a single, interconnected training system that provides a training environment, in which units from Soldier/Squad through Army Service Component Command (ASCC) conduct collective training, see Figure 1-1 below.

Figure 1-1. STE OV-1.

1DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED

156

157158159160161162163164165166

167

168169170171

172

173

The STE is deliberately envisioned to converge the LVCG environments as one complete training capability. This training capability will enable Army units and leaders to conduct realistic multi-echelon / multi-domain combined arms maneuver and mission command training, increasing proficiency through repetition. This allows units to enter collective level training in the live environment at a much higher level of proficiency. The STE will deliver collective training, accessible at the PoN in the operational, self-development and institutional training domains. The STE is an essential component for the Army to fully realize the Standard of Training Proficiency (STP) required and levels of proficiency.

The STE must have the ability to change with technology, allowing for the replication/representation of current and future force structure, weapons effects, warfighting functions, Joint, Interagency, and Multinational (JIM) capabilities, human interaction, dense urban environment and near-peer threat capabilities. The STE will be capable of training units across the full range of Unified Land Operations (ULO) in multiple domains (Air, Land, Maritime, Cyber, and Space).

The STE provides a synthetic environment to represent and enable rapid generation of the OE. Scalable immersive collective trainers provide the commander with multiple training capability options to train operational tasks at the PoN with around-the-clock accessibility. The STE operates in connected and disconnected modes (for training under limited or degraded network conditions) and is embedded within the Common Operating Environment (COE). The STE leverages the Army Network (enterprise and tactical) to either host or deliver capabilities and provides intuitive, composable applications and services that enable embedded training with mission command workstations and select platforms. Future Live training systems will interface with the STE to incorporate instrumentation, ranges, targets, and ammunition into the synthetic environment. Next Generation Constructive will expand training of large-scale Brigade Combat Team (BCT) through ASCC. The integrated STE system consists of three foundational capabilities that are each a separate other transaction authority (OTA) effort:

Training Support Management Tool (TSMT) that consists of the Training Simulation Software (TSS), Training Management Tool (TMT), and hardware

Reconfigurable Virtual Collective Trainers (RVCT) One World Terrain (OWT)

The STE delivers software, application(s) and services that will enable the RVCT and other training capabilities. The STE will enable multi-level security through a cross domain solution (CDS). The STE architecture and design enables and supports interoperability with existing training systems (Live, Virtual, Constructive Integrating Architecture [LVC-IA], Joint Land Component Constructive Training Capability


174175176177178179180181182

183184185186187188

189190191192193194195196197198199200201202

203204205206

207208209210211

[JLCCTC], Homestation Instrumentation Training System [HITS]); and future training systems Soldier Virtual Trainer (SVT), the embedded Integrated Visual Augmentation System (IVAS) with Soldier Immersive Virtual Trainer (SiVT), future Next Generation Constructive (NGC), Synthetic Training Environment - Live Training System (STE-LTS) and operational capabilities.

TSMT is planning to utilize the Department of Defense (DoD) Software Acquisition Pathway (SAP) as defined by DoDI 5000.02 Operation of the Adaptive Acquisition Framework. In accordance with this pathway the delivery of TSMT capability is defined in terms of Minimum Viable Products (MVP), an initial Minimum Viable Capability Release (MVCR), and annual software releases after initial MVCR.

1.3 Training Support Management Tool Overview1.3.1 TSMT ScopeThis Performance Work Statement (PWS) defines the scope for providing the integrated TSMT solution identified in Figure 1-2 by the red outlined box. The scope is a Brigade and Below collective training capability. This capability includes Soldier/Squad to BCT virtual and a Brigade and below constructive staff training capability. The vendor shall design and build the TSS and TMT software, and provide TSMT Hardware.

Figure 1-2. Synthetic Training Environment.

The TSMT solution will use OWT products and integrate with RVCT as a cohesive STE system. The vendor will need to monitor, collaborate, and integrate with OWT, RVCT, SVT, IVAS-SiVT, and interfaces to Mission Command Information Systems (MCIS) (see


212213214215216

217218219220221

222

223

224225226227228

229

230

231232233

full list of MCIS in the Technical Data Package [TDP] Appendix E Systems Requirements Document [SRD]), Avionics Software Emulation [AvSE], Common Software Library [CSL], authoritative data sources (see TDP Appendix A, Authoritative Data Sources for additional information), and LVC-IA. This PWS will refer to the set of vendors in the preceding sentence as the STE system capability and interface vendors. Descriptions of these capabilities (e.g., OWT, RVCT) are in Appendix A Capability Descriptions.

The Brigade and Above capability is outside the scope of this OTA however, it and other objective values are identified in Appendix B Objective Values to provide a holistic STE vision. The MVP, MVCR, and subsequent software releases must not preclude achieving the Objective Values and scalability up to ASCC in the future.

The TSMT system bi-directionally communicates with MCIS. The TSMT system interfaces with LVC-IA to incorporate HITS, JLCCTC and Intelligence Electronic Warfare Tactical Proficiency Trainer (IEWTPT) into an exercise.

1.3.2 Capability Overview1.3.2.1 TSMT

The TSMT is the “core” simulation software and hardware that provides a common synthetic environment, the exercise design and control tool, and data manager for STE collective training.

Figure 1-3. TMT Interaction.


234235236237238239240

241242243244

245246247

248

249

250251252

253

254

1.3.2.1 TMT

TMT is the single Army user interface for exercise design, and execution control used at all echelons to plan, prepare, execute, and assess multi-echelon collective training. Figure 1-3 depicts TMT, the data manager for TSMT.

1.3.2.1.1 Planning Phase

TMT enables Commanders and Leaders at all echelons to design exercises and scenarios to meet training objectives. TMT uses authoritative sources to ensure realism by representing force structure and the OE as closely possible.

1.3.2.1.2 Prepare Phase

TMT performs the orchestration, provisioning, scheduling, and deployment of infrastructure, training, and simulation resources identified in the plan phase. TMT provides OWT terrain, parametric data, force structure and equipment, 3D moving models, behaviors, OE information, and other data required for simulator/simulation initialization.

1.3.2.1.3 Execute Phase

TMT exercise control (EXCON) monitors, collects, facilitates runtime assessments and interventions, and stores all simulation data while providing Commanders and Training Managers near real-time information. The TMT EXCON enables in progress scenario changes to achieve training objectives and to tailor the experience to the training audience level of proficiency.

1.3.2.1.4 Assess Phase

TMT automates nomination of significant activities (SIGACTs) and development of multi-media After-Action Review (AAR) as an initial baseline for training managers and commanders review so they can provide feedback to the training units. TMT supports Force Readiness measures and reporting across the collective training spectrum within the Sustainable Readiness Model and Standards for Training Proficiency goals.

1.3.2.2 TSS

The TSS is the STE ‘core’ simulation engine that provides a synthetic environment to enable collective training from Soldier/Squad through BCT across the Fires, Movement and Maneuver, and Mission Command Warfighting Functions (WfF) and supporting the Sustainment, Protection, and Intelligence WfFs. TSS ensures fair fight adjudication for interactions in the STE system. The TSS synthetic environment is delivered over the network to RVCT, MCIS, and other interfaces.


255

256257258

259

260261262

263

264265266267268

269

270271272273274

275

276277278279280

281

282283284285286287

The TSS provides computer generated forces (CGF) of BLUEFOR, OPFOR, civilians, ground vehicles, and air platforms. The TSS provides a functional virtual representation of RVCT platforms and provides the simulation software core for RVCT platforms. For example, the TSS renders the inside view of an Apache helicopter, visually displaying the interior of the cockpit with all the functional displays and switches/interfaces needed for collective training. TSS also renders the out-the-window views that the pilot and copilot see when flying through the synthetic environment as well as models or represents all RVCT platform performance, weapons, sensors, targeting, communications, and mission command subsystems.

2 Acquisition Pathway and Objectives2.1 Software Acquisition PathwayThe TSMT will use the SAP. This pathway facilitates rapid and iterative delivery of software capability to the user. The SAP employs a modern, agile and, Development Security Operations (DevSecOps) software development practices. This allows delivery of secured working software rapidly and iteratively to meet the highest priority user needs. SAP uses automated tools for development, integration, testing, deployment/delivery, and certification to iteratively update software capabilities.

Appendix C Capability Roadmap contains the Government’s initial product roadmap. Appendix D Notional MVP/MVCR/Release Plan provides a notional MVP/MVCR/Release plan. The Government’s expectation is that the vendor will utilize the initial capability roadmap,the notional release plan and the vendor’s technical approach to develop a revised capability roadmap, an MVP/MVCR/Release plan and an Integrated Master Schedule (IMS) that meets or exceeds the requirements of the initial backlog as defined by the SRD. The Government’s expectation for initial MVCR is defined as:

Delivery of the highest echelon (Company, Battalion, Brigade) multi-level security collective training capability focused on identified Combine Arms Training Strategy (CATS) tasks.

Enables the training audience to plan, prepare, execute, and assess (PPEA) collective training.

MVCR verification, validation, and accreditation process complete. Meets Cybersecurity requirements. Fielding to Fort Hood is complete. New Equipment Training (NET) at Fort Hood is complete. All contractor requirements for TSMT operations and support are in place and

ready to support unit training at Fort Hood.


288289290291292293294295296

297

298

299300301302303304

305306307308309310311312

313314315316317318319320321322323

2.2 ObjectiveThe TSMT objective is to provide a Soldier/Squad through Brigade collective training capability with increased capability for Commanders / Soldiers to train and closes the ITE limitations without creating new gaps. (i.e., Close Combat Tactical Trainer [CCTT]; Aviation Combined Arms Tactical Trainer [AVCATT]; and Games for Training [GFT] and a Brigade and below constructive staff and Commander training capability). The STE system enables the Unit/Staff to train offense, defense, and stability support operations realized through the CATS to set the foundation for an MDO capable force. Some of the collective training task sets are provided in the TDP Appendix B Collective Training Task Sets and training tasks in the TDP Appendix C Collective Training Tasks for additional collective task information.

TSMT is integrated with the OWT and RVCT to achieve a holistic STE capability. The intent of the integrated STE system is to provide value to the end user with each MVP and MVCR that enables units to conduct their doctrinal collective training. Subsequent STE system releases continue to improve the collective training capability (higher echelon, new functionality, etc.). Program Increments, MVP/MVCR/subsequent software releases continue to build on the capabilities in the previous gate.

A successful TSMT system provides the features identified in the TSMT product roadmap. The product roadmap is a series of incremental capability deliveries that provide a working / functional training capability for the user to provide feedback. In addition, Solider Touchpoints will be conducted on an integrated solution (RVCT with TSMT and OWT software). Soldier Touchpoints will be conducted with an operational unit (Forces Command [FORSCOM], Army National Guard [ARNG], and Office of the Chief Army Reserve [OCAR] coupled with the Army Capability Manager [ACM], Cross Functional Team [CFT] and Center of Excellence [CoE] Subject Matter Experts [SMEs]). A successful TSMT system provides an entity level simulation that provides virtual and constructive collective training, training to soldiers, squads, platoons, companies, battalions, and brigades. It is also interoperable with LVC-IA to enable interoperability with HITS, JLCCTC and IEWTPT (IEWTPT interoperability is through JLCCTC and LVC-IA); and bi-directionally communicates with RVCT, SVT, IVAS-SiVT, and operational capabilities (e.g., MCIS, AvSE, CSL, air, and ground platforms) enabling Commanders and units to achieve their collective training objectives at the PoN.

The Government will evaluate the technical feasibility and military utility of the TSMT solution as the foundation for the STE. The end-state of the TSMT system is the creation and successful implementation of a modular open system approach that delivers the foundational capabilities in support of the holistic STE vision.


324

325326327328329330331332333334

335336337338339340

341342343344345346347348349350351352353354355

356357358359

3 RequirementsThe requirements defined herein shall form the basis for all work that the vendor shall perform as part of the agreement the Government will issue under the TSMT OTA award for the design, development, integration, testing, delivery, and product support of TSMT.

3.1 Program ManagementThe vendor shall accomplish all planning, execution, risk management, reporting and related program management activities to ensure that the technical, schedule, and financial requirements of this PWS are accomplished in accordance with (IAW) the Government approved product roadmap. Program Management documentation shall include an integrated master plan and monthly program management metrics, technical, financial, and schedule status.

3.1.1 The vendor shall provide a set of program management metrics for the Government to approve.

3.1.2 The vendor shall provide and brief monthly program management metrics to the Government and when requested by the Government.

3.2 Associate Vendor AgreementsAssociate Vendor Agreements (AVA) are the basis for sharing information, data, technical knowledge, expertise, and/or resources essential to the integration of TSMT. AVAs ensure the greatest degree of cooperation for the development of the program to meet the terms of the efforts.

The vendor shall establish associate vendor agreements and collaborate with STE vendors.

The vendor AVA shall identify potential conflicts between relevant Government contracts, agreements, and the AVA; the agreement shall also include agreements on protection of proprietary data and restrictions on employees.

The vendor shall not be relieved of any requirements or entitled to any adjustments to the agreements terms because of a failure to resolve a disagreement with an associate vendor.

The vendor shall collaborate with STE vendors to develop the data model. The vendor shall collaborate with STE vendors to develop Application.

Programming Interfaces (APIs) and Interface Control Documents (ICDs).


360

361362363364

365

366367368369370371

372373

374375

376

377378379380

381382383384385386387388389390391

3.3 CommunicationThe STE requires the coordination of multiple OTA vendors. The core effort of STE is the TSMT OTA. The TSMT OTA vendor is in the best position to understand the interdependencies between the supporting OWT and RVCT OTAs.

3.3.1 The vendor shall establish and maintain regular communication with the Government team (both formal and informal) so that the Government can identify, assess, and resolve deviations in a timely manner.

3.3.2 The vendor shall provide technical and programmatic project status to the Government during status meetings.

3.3.3 The vendor shall participate in recurring meetings as directed by the Government (see Table 3-1).

Table 3-1. Recurring Government Meetings.

Meeting Location Host FrequencyArchitecture Synchronization TBD Government WeeklyAvSE IPT TBD Government WeeklyCost Working IPT TBD Government TBDCyber IPT TBD Government WeeklyIntegration IPT TBD Government WeeklyNetwork/Cloud WG TBD Government WeeklyOWT Coordination TBD Government WeeklyPre-Program Increment Planning Meeting TBD Government TBD

Product Support IPT TBD Government WeeklyProduct/Requirement Manager Synchronization TBD Government Weekly

RVCT Coordination TBD Government WeeklyScience and Technology IPT TBD Government MonthlyScrum of Scrums TBD Government WeeklySiVT IPT TBD Government MonthlySystem Safety Working Group TBD Government TBDTesting WIPT TBD Government WeeklyTMT IPT TBD Government WeeklyTSMT IPT TBD Government WeeklyTSS IPT TBD Government WeeklyOthers as directed by the Government TBD Government TBD


392

393394395

396397398

399400

401402

403

3.4 Reviews3.4.1 The vendor shall host and conduct technical interchange meetings (TIM) and test and

assessment reviews to inform Government approval of the product design at least once prior to each program increment, MVP, the MVCR, and subsequent software releases and as requested by the Government.

3.4.2 The vendor shall summarize the TIM and test and assessment reviews discussions, action items, risks, dependencies, and issues and submit to the Government not later than (NLT) 5 calendar days after the event and manage the action items list until all items are accepted by the Government in accordance with the deliverables (3.8.1.1 and 3.8.1.4).

3.5 System EngineeringThe vendor shall use the agreed upon Agile systems engineering process and DevSecOps environment to plan, design, develop, incorporate, test, and deliver STE system of systems capabilities.

3.5.1 The vendor shall identify risks, issues, and mitigating actions.

3.5.2 The vendor shall deliver a requirements traceability/verification matrix that traces requirements from the STE Information System Abbreviated – Capability Development Document (A-CDD) through the PWS, System Requirements Document (SRD), System/Sub System Specification (SSS), Software Requirements Specification (SRS) and test cases to the delivered products in accordance with deliverables ().

3.5.3 The vendor shall support Government coordination across efforts performing the managerial and technical systems engineering processes.

3.6 Configuration ManagementThis section references the traditional functional, allocated and product baselines. These terms equate to the following Agile elements:

Functional Baseline: The entire set of all the prioritized features in all the program increments, MVPs, MVCR, and Subsequent Software releases. This is documented in the Product Roadmap and Product Backlog.

Allocated Baseline: The planned set of prioritized features to be developed in a specific program increment, MVP, MVCR, and subsequent software releases. This is specific segment in the Product Roadmap and Product Backlog.


404

405406407408

409410411412413

414

415416417

418

419420421422423

424425

426

427428

429430431432433434435

Product Baseline: The features delivered in the working software for the specific program increment, MVP, MVCR, and subsequent software releases.

3.6.1 Configuration Identification3.6.1.1 The vendor shall ensure configuration identification, control, and status accounting of all

TSMT system hardware, software, and documentation including Government-furnished information and vendor-supplied items for the period of performance of this effort.

3.6.1.2 The vendor shall identify the TSMT hardware and software configuration in the Functional, Allocated and Product Baselines.

3.6.1.2.1 The vendor shall document the Functional Baseline as defined by the SRD and incremental Contractor Data Requirements List (CDRL) deliveries.

3.6.1.2.2 The vendor shall document Allocated Baseline as defined by the incremental CDRL deliveries, approved requirements, MVP, MVCR and subsequent software releases.

3.6.1.2.3 The vendor shall document the Product Baseline as defined by CDRL deliveries, MVCR, and subsequent software releases.

3.6.1.2.4 The vendor shall, in consonance with the Government, select the Configuration Items (CIs) to be identified and assign hierarchical identifiers to each CI, select the configuration documentation to be used to identify each CI, define and document interfaces between CIs, and establish a release system for the control of configuration documentation and computer software source code.

3.6.1.3 The vendor shall ensure that hardware and software data and equipment audits are the same.

3.6.1.4 The vendor shall seek approval for the initial system configuration and for subsequent system configuration changes during the Government hosted Product/Requirement Manager Synchronization meeting.

3.6.1.5 The vendor shall document the Product/Requirement Manager Synchronization meeting process in a Configuration Management Plan (CMP), to be delivered via Enterprise Mission Assurance Support Service (eMASS).

3.6.1.6 The vendor shall provide Product/Requirement Manager Synchronization meeting minutes and all applicable artifacts for review to the government via eMASS in accordance with deliverable 3.8.1.2.

3.6.1.7 The vendor shall deliver an updated hardware and software list and functional architecture diagram artifact prior to each test and functional validation event via eMASS in accordance with deliverable 3.8.1.2.

3.6.2 Configuration Control


436437

438

439440441

442443

444445

446447

448449

450451452453454

455456

457458459

460461462

463464465

466467468

469

3.6.2.1 The vendor shall control CI for all baselines by form, fit, function, interchangeability, and interoperability.

3.6.2.1.1 The vendor shall control and change all baselines using contractor change and engineering release process.

3.6.2.1.2 The vendor shall request Government approval for all proposed changes that affect the form, fit, function, interchangeability, or interoperability of the current system configuration.

3.6.2.1.3 The vendor shall ensure that all changes to the baselines result in a common configuration for Government operational use and maintenance activities that provides interchangeability and interoperability.

3.6.2.1.4 The vendor shall ensure that proposed engineering changes to CIs are fully coordinated and documented in accordance with the deliverables (3.8.1.4, 3.8.2.10, and 3.8.2.11).

3.6.3 Configuration Status Accounting

3.6.3.1 The TSMT vendor shall identify and document all items incorporated into or deleted from the TSMT during development.

3.6.3.1.1 The contractor shall prepare the information Baseline Description Document IAW the deliverable (3.8.2.11) for each baseline.

3.7 IntegrationThe vendor shall be responsible for the full range of integration activities associated with planning, coordination, and documentation of the STE system capability and interfaces to include STE system capability and interface vendors. These duties shall include the following integration responsibilities to assist Government oversight and decision making.

3.7.1 The vendor shall work with the STE system capability and interfaces vendors and the Government to identify and document integration risks and issues associated with vendor scope, delivery schedule, and design misalignments.

3.7.2 The vendor shall document the integrated STE plan to include action items, software management baselines and Configuration Management.

3.7.3 The vendor shall plan and coordinate STE system capability and interface vendors participation in routine vendor integration events and touchpoints in the Technology Integration Facility (TIF) located in Partnership IV supported by vendor labs and other USG infrastructure.


470471

472473

474475476

477478479

480481482

483

484485

486487

488

489490491492493

494495496

497498

499500501502

3.7.4 The vendor shall evaluate Government provided Science and Technology (S&T) handovers to assess reuse potential to meet TSMT requirements and develop plans for integration with TSMT baseline. If a handover is not suitable for reuse, the vendor shall provide supporting rational.

3.8 DeliverablesThe vendor shall provide the following list of deliverables to the Government throughout the performance of this effort. These deliverables serve to provide the performance data and product support data to the Government to allow for the appropriate planning and oversight for the TSMT.

3.8.1 Management DeliverablesVendor format is acceptable and shall be delivered electronically in MS Office compatible formats unless otherwise noted. The Government provides the Data Item Descriptions (DID) for vendor consideration.

3.8.1.1 Name: Contractor's Progress, Status and Management Report (CPSMR)

Purpose: Documents and tracks program performance, agile metrics, DevSecOps metrics, tasks, agreements and existing or potential problem areas.

Initial Submission Due: 30 days after Contract Award

Recurring Submissions Due: Monthly

DID: DI-MGMT-81928 (§10.3 A-F; H; and J only) The Government reserves the right to modify the CPMSR management deliverable content during execution.

3.8.1.2 Name: DoD Risk Management Framework (RMF) Package Deliverables

Purpose: Contains the artifacts necessary to successfully achieve the Initial Authorization to Test (IATT) and Authority to Operate (ATO).

Initial Submission Due: Initial submission required 30 days after award to support Government IATT development.

Recurring Submissions Due: Subsequent submissions required 60 days before MVCR and follow-on releases to support Government ATO development.

DID: DI-MGMT-82001

Format: As specified in the DID.


503504505506

507

508509510511

512

513514515

516

517518

519

520

521522

523

524525

526527

528529

530

531

3.8.1.3 Name: Integrated Master Schedule (IMS)

Purpose: Contains data required to measure schedule performance on DoD acquisition contracts.

Instructions: The contractor shall provide a Microsoft Project schedule depicting their work for software development, internal integration activities, dependencies, system level integration with legacy programs, all other STE vendors, major milestones, fielding at the MVCR sites and post fielding logistics support. The contractor shall submit the schedule at the end of each month and shall accurately depict progress made on tasks, an initial baseline of all tasks and milestones, highlight new tasks after the first submission, highlight tasks that have exceeded the baseline, tasks that are at risk of exceeding baseline, schedule risks, and critical path tasks that have pushed major milestones past the baselined date.

Initial Submission Due: 30 days after Contract Award


Format: Use sample format in Appendix E IMS Template.

3.8.1.4 Name: Conference MinutesPurpose: Provides executive summary, documentation of technical information provided, decisions and agreements reached, and action items captured at meetings.Initial Submission Due: As required and NLT 5 days after the meetingRecurring Submissions Due: As required and NLT 5 days after the meetingDID: DI-ADMN-81250B

3.8.1.5 Name: Product RoadmapPurpose: Aligns prioritized functional and architecture features to a high-level calendar for each program increment, MVPs, MVCR, and subsequent software releases. Includes the sequence and timing of development, integration, test, and delivery. The product roadmap is a series of incremental capability deliveries that provide a working / functional training capability for the user to provide feedback.Initial Submission Due: NLT 5 calendar days after the initial program increment planning session.Recurring Submissions Due: NLT 5 calendar days after the increment, MVP, MVCR, and subsequent software releases program increment planning sessions.


532

533534

535536537538539540541542543544

545

546

547

548

549550551

552

553

554

555

556557558559560

561562

563564

3.8.2 Engineering DeliverablesVendor format is acceptable, except as noted and shall be delivered electronically in MS Office compatible formats unless otherwise noted.

3.8.2.1 Name: Computer Software Product End Items

Purpose: Contains the format, content (including source code), and intended use information of the software deliverable

Initial Submission Due: Initial submission with first MVP

Recurring Submissions Due: Recurring submissions with all MVP, MVCR, and releases

DID: DI-AVCS-80700A

3.8.2.2 Name: DoD Architecture Framework Documentation (DoDAF)

Purpose: Used to provide architecture framework product documentation that describes characteristics pertinent to the purpose of the architecture.

Models Based System Engineering (MBSE) Approach Addendum: The Government has provided the MagicDraw tool to share engineering information. The Government will provide access to the initial set of DoDAF views and other SysML diagrams in the MagicDraw tool. The vendor shall use the existing DoDAF views and SysML diagrams as a starting place and will expound on these views and create others as needed and agreed to by the Government. The vendor shall create and share digital DoDAF views in and through the MagicDraw tool.

Agile Approach Addendum: The vendor shall continuously reference and evolve DoDAF views and SysML diagrams as required during development sprints. The vendor shall revise existing and create new views and diagrams as necessary and agreed-upon by the Government. Initial Submission Due: The vendor shall make initial revisions to existing models and begin adding new views at the completion of the first development sprint.

Recurring Submissions Due: The vendor shall continuously update and evolve DoDAF views and SysML diagrams throughout the life of the project. The vendor shall conduct reviews during sprint planning, program increment planning, and MVP/MVCR/subsequent software release completion. The vendor shall conduct additional, issue specific reviews when directed by the Government. Report snapshots may be drawn from the MagicDraw tool by any person who has


565

566567

568

569570

571

572573

574

575

576577

578579580581582583584585

586587588589590591592

593594595596597598

access to the tool(s) at any time. DID: DI-MGMT-81644B; the vendor shall provide the: AV-1, AV-2, OV-1, OV-2, OV-3, OV-4, OV-5a, CV-2, CV-3, CV-6, DIV 1, DIV 2, DIV 3, SV-1, SV-2, SV-4, SV-5a, SV-6, SV-7, SV-8, and StdV-1, and StdV-2. The vendor shall provide other views as directed by the Government.

Format: As specified in DoDAF 2.02 using the MagicDraw tool.

3.8.2.3 Name: Interface Design Description (IDD)

Purpose: Describes the interface characteristics of one or more systems, subsystems, hardware configuration items, computer software configuration items, manuals, or other system components.

MBSE Approach Addendum: The Government will provide several architectural and design products of the desired system in DoDAF views and Systems Modeling Language (SysML) diagrams to the vendor at contract award in the MagicDraw tool. The vendor shall use and build on these products to further define system and component interface specifications in the digital models created in and shared through the MagicDraw tool. The vendor shall use appropriate DoDAF views and/or SysML diagrams to capture the interface descriptions.

Agile Approach Addendum: The vendor shall continuously reference and evolve interface description models during development sprints. The vendor shall add new interfaces and interface descriptions as necessary and agreed-upon with the Government.

Initial Submission Due: The vendor shall provide models in the MagicDraw tool at the completion of the first development sprint.

Recurring Submissions Due: The vendor shall continuously update and evolve models throughout the life of the project. The vendor shall conduct reviews during sprint planning, program increment planning, and MVP/MVCR/subsequent software release completion. The vendor shall conduct additional, issue specific reviews when directed by the Government. Report snapshots may be drawn from the MagicDraw tool by any person who has access to the tool(s) at any time.

Sample Data Item Description: DoDAF 2.02; SysML 1.6

3.8.2.4 Name: Software Version Description (SVD)

Purpose: Identifies and describes a software version consisting of one or more Computer Software Configuration Items (CSCIs). It is used to release, track, and control software versions.


599600601602603

604

605

606607608

609610611612613614615616

617618619620

621622

623624625626627628

629

630

631632633

Initial Submission Due: Initial submission with the first MVP.

Recurring Submissions Due: Recurring submissions with all MVP, MVCR, and subsequent software releases.

DID: DI-IPSC-81442

3.8.2.5 Name: System/Subsystem Design Description (SSDD) or Software Product Specification (SPS)

Purpose: Describes the system or subsystem-wide design and the architectural design of the system and/or subsystem.

MBSE Approach Addendum: The Government will provide several architectural and design products of the desired system in DoDAF views and SysML diagrams to the vendor at contract award in the MagicDraw tool. The vendor shall use and build on these products to further define system and component design specifications in digital models created in and shared through the MagicDraw tool. The vendor shall use appropriate DoDAF views and/or SysML diagrams to capture the design descriptions. The vendor shall create/use SysML diagrams and DoDAF views to the extent that they are relevant to producing or managing the overall system as agreed to with the Government.

Agile Approach Addendum: The vendor shall continuously reference and evolve design models as required during development sprints. The vendor shall add new design models and their descriptions as necessary and agreed-upon with the Government.

Initial Submission Due: The vendor shall provide models in the MagicDraw tool at the completion of the first development sprint.

Recurring Submissions Due: The vendor shall continuously update and evolve models throughout the life of the project. The vendor shall conduct reviews during sprint planning, program increment planning, and MVP/MVCR/subsequent software release completion. The vendor shall conduct additional, issue specific reviews when directed by the Government. Report snapshots may be drawn from the MagicDraw tool by any person who has access to the tool(s) at any time.


3.8.2.6 Name: System/Subsystem Specification

Purpose: Specifies the requirements for a system or subsystem and the methods to be used to ensure that each requirement has been met.


634

635636

637

638639

640641

642643644645646647648649650

651652653654

655656

657658659660661662

663

664

665666

Digital Engineering Approach Addendum: The Government will provide the vendor access to an initial Dynamic Object-Oriented Requirements System (DOORS) requirements repository at agreement award. The Government will also provide Cameo Data Hub to link the requirements in DOORS and the MagicDraw tool so requirements information can be efficiently included in the MBSE model diagrams/views. The vendor shall use the Government provided system requirements in the DOORS tool and shall update/annotate the requirements repository to indicate system model parts that satisfy requirements.

MBSE Approach Addendum: The vendor shall annotate and/or trace relations to system requirements in the digital models created in and shared through the MagicDraw tool. Tracing the relation to the requirements (e.g., Requirements Traceability Matrix [RTM]/Verification Matrix) depends on which DoDAF views and/or SysML diagrams the model uses and not all SysML diagrams or DoDAF views require tracing back to requirements. The vendor shall use requirement ID numbers consistently throughout the system model diagrams/views.

Agile Approach Addendum: The vendor shall use the requirements repository to form the Program, Iteration, and Sprint Backlogs. The vendor shall develop user stories that encapsulate the requirements into manageable sets. The vendor shall use requirement ID numbers consistently throughout the agile development process.

Initial Submission Due: The vendor shall begin agile planning with requirements and include requirements tracing to/from system model diagrams/views starting with the first development sprint.

Recurring Submissions Due: The vendor shall continuously update and evolve the requirements repository and the system model(s) throughout the life of the project. The vendor shall conduct reviews during sprint planning, program increment planning, and MVP/MVCR/subsequent software release completion. Report snapshots may be drawn from the requirements and MBSE tool(s) by any person who has access to the tools at any time.


3.8.2.7 Name: Test Plan

Purpose: Provides an overview of the DevSecOps, Incremental Government, and Cybersecurity Tests and Events test strategies to include scope and objectives.

Initial Submission Due: 30 days after contract award.


667668669670671672673674

675676677678679680681

682683684685686

687688689

690691692693694695

696

697

698699700

701

Recurring Submissions Due: 30 days after program increment planning.

DID: DI-SESS-80688

3.8.2.8 Name: Test Procedure

Purpose: Identifies the step-by-step testing operations to be performed on items undergoing developmental, qualification, or acceptance testing. Includes objectives and definitions of success.

Initial Submission Due: Initial procedure 45 days and final 10 days prior to Technical Assessments (TA).

Recurring Submissions Due: Every TA.

DID: DI-NDTI-80603A

3.8.2.9 Name: Test/Inspection ReportPurpose: The test/inspection report is used to document test/inspection results, findings and analyses that will enable the Government or contracting agency to evaluate compliance with system requirements, performance objectives, specifications, and test/inspection plans.Initial Submission Due: As required Recurring Submissions Due: As requiredDID: DI-NDTI-80809B

3.8.2.10 Name: Engineering Change Proposal (ECP)Purpose: Provides the documentation in which the engineering change is described and specifies how the proposed change will be implemented.Initial Submission Due: As required Recurring Submissions Due: As requiredDID: DI-SESS-80639E

3.8.2.11 Name: Request for Variance (RFV)Purpose: Describes a proposed departure from (a nonconformance with) approved product definition information for a limited amount of time/specified effectivity or a product found to be nonconforming with product definition information after the product has been produced by the production process.

When the RFV describes a proposed departure from approved product definition information (i.e., pre-production), the variance shall result in a reduction in cost; indicated by enclosing the value in parentheses.


702

703

704

705706707

708709

710

711

712

713714715716

717

718

719

720

721722

723

724

725

726

727728729730

731732733

When the RFV describes a product found to be nonconforming after the product has been produced (i.e., post-production), the variance shall result in a reduction in cost; indicated by enclosing the value in parentheses.

When the nonconformance is induced or caused by the Acquirer, a reduction in cost is not required when submitting the RFV.

Initial Submission Due: As required Recurring Submissions Due: As requiredDID: DI-SESS-80640E

3.8.2.12 Name: Baseline Description DocumentPurpose: Provide a list of unique identifiers for all requirement documents plus approved changes and physical hardware and software items in which the specifications, drawings, interface control documents, strategy, design and version description documents define the functional and physical characteristics. The principal use of this list is to designate configuration control of identified configuration items.Initial Submission Due: 30 days prior to the first MVPRecurring Submissions Due: 30 days prior to MVCR and each subsequent software releaseDID: DI-SESS-81121A

3.8.2.13 Name: Safety Assessment Report

Purpose: Comprehensive evaluation of the safety risks being assumed prior to test or operation of the system or at contract completion. It identifies all safety features of the system, design, and procedural hazards that may be present in the system being acquired, and specific procedural controls and precautions that should be followed.

Initial Submission Due: 30 days prior to the first MVP

Recurring Submissions Due: 30 days prior to MVCR and each subsequent software release

DID: DI-NDTI-80603A

3.8.3 Product Support DeliverablesDeliverables shall conform to the format identified in the Data Item Description and shall be delivered electronically in MS Office compatible formats unless otherwise noted.


734735736

737738

739

740

741

742

743744745746747748

749

750751

752

753

754755756757758

759

760761

762

763

764765

3.8.3.1 Name: Commercial Off-The-Shelf (COTS) Manuals & Associated Supplemental Data

Purpose: Documentation provided with COTS products that may be used “as is” or with supplemental data, if required.

Initial Submission Due: Draft 30 days prior to MVCR

Recurring Submissions Due: 30 days after MVCR and each subsequent software release (updates as required)

DID: DI-TMSS-80527C

3.8.3.2 Name: Interim Contractor Support (ICS) Parts Usage and Maintenance Data Collection Report

Purpose: Report gathers and uses ICS parts usage and maintenance data to predict future requirements for any given part of the component and end item/system, including part failures.

Initial Submission Due: 30 days after ICS begins


DID: DI-ILSS-81226

3.8.3.3 Name: Level of Repair Analysis (LORA) Report

Purpose: Documents and supports the contractor’s conclusions, findings, and recommendations on the economic, noneconomic and operational impacts concerning repair versus discard at failure; optimum repair levels; support equipment (which includes test program sets, built-in-test equipment, and test, measurement, and diagnostic equipment requirements); maintenance and supply support life cycle costs; spare parts provisioning; and specific design recommendations for each item undergoing the LORA.

Initial Submission Due: 30 days prior to MVP

Recurring Submissions Due: 30 days after MVCR and subsequent software release (updates as required)

DID: DI-PSSS-81872A

3.8.3.4 Name: Failure Modes, Effects, and Criticality Analysis (FMECA)

Purpose: Identifies independent single item failures and the resulting potential impact on mission success, performance, safety, and maintainability. The FMECA promotes corrective actions by identifying potential failure risk and


766767

768769

770

771772

773

774775

776777778

779

780

781

782

783784785786787788789

790

791792

793

794

795796797

maintainability issues in order that appropriate corrective actions may be taken early to eliminate or control high risk items to improve operational readiness and reduce life cycle cost. The FMECA also establishes the baseline engineering information to identify and eliminate or control all failure modes throughout the systems life cycle. The FMECA analytics establish the basis for fault detection, fault isolation, operator and maintainer failure recognition, depot test parameters and lay-in repair parts.



DID: DI-PSSS-81495B

3.8.3.5 Name: Logistics Product Data w/Attribute Selection Worksheet

Purpose: Consists of data required for maintenance planning, logistics design requirements, reliability and maintainability, system safety, maintenance engineering, support and test equipment, training and training devices, manpower and skills, facilities, transportation, supply support, parts packaging, initial provisioning, cataloging, item management and in-service feedback.

Initial Submission Due: Draft 30 days prior to MVP


DID: DI-SESS-81758A

3.8.3.6 Name: Preparation of Digital Technical Information for Electronic Technical Manuals (TMs) – STE DevSecOps Integrated Operations Guide

Purpose: Establishes the technical content, style, and format requirements for all TMs, including operator and maintenance TMs and can be used to develop TMs as paper, page-based manuals, or electronic technical manuals.



DID: MIL-STD-40051-1C


798799800801802803804

805

806807

808

809

810811812813814

815

816817

818

819820

821822823

824

825826

827

3.8.3.7 Name: Preparation of Digital Technical Information for Electronic Technical Manuals (TMs) – System User Manual

Purpose: Establishes the technical content, style, and format requirements for all TMs, including operator and maintenance TMs and can be used to develop TMs as paper, page-based manuals, or electronic technical manuals.



DID: MIL-STD-40051-1C

3.8.3.8 Name: Preparation of Digital Technical Information for Electronic Technical Manuals (TMs) – Quick Reference Card(s)

Purpose: Contains the requirements for development of Quick Reference Guides (QRGs).



DID: MIL-PRF-32614

3.8.3.9 Name: Product Engineering Design Data & Associated Lists

Purpose: Provides engineering data adequate to serve as an authoritative and complete technical description of an item. This data, when authorized, is adequate to support competitive procurement and maintenance for items interchangeable with the original items. This data represents the highest level of design disclosure.


Recurring Submissions Due: Recurring submissions with all MVPs, MVCR, and each subsequent software release

DID: DI-SESS-81000F

3.8.3.10 Name: Drawing Tree

Purpose: Identifies the interrelationships of engineering design data and associated lists that comprise the total engineering TDP prepared for each system, subsystem, and component configuration. The Engineering Drawing


828829

830831832

833

834835

836

837838

839840

841

842843

844

845

846847848849850

851

852853

854

855

856857858

Tree also aids in the control and development of design data in the overall project.



DID: DI-DRPR-81961A

3.8.3.11 Name: Software Sustainability Package

Purpose: Contains the source code, design details, models, algorithms, processes, flow charts, formulae and related materials that would allow the software to be reproduced, recreated or recompiled, as needed for sustainment by non-developer(s) or the Original Equipment Manufacturer (OEM). This includes all executable software, design models, source files, and software sustainment information, including "as built" design information and compilation, build, and modification procedures for each CSCI.



DID: DI-IPSC-82134

3.8.3.12 Name: Technical Manual Verification Discrepancy/Disposition Record

Purpose: Provides the contractor’s dispositions/resolutions to documented TM verification discrepancies and findings.

Initial Submission Due: Draft 30 days after each MVP

Recurring Submissions Due: Final 30 days prior to MVCR and each subsequent software release

DID: DI-TMSS-81820

3.8.3.13 Name: Training Aids, Devices, Simulators, and Simulations (TADSS) Materiel Component List (MCL)

Purpose: The MCL is listing of all system and non-system TADSS component parts and the data required to create a Component of the End Item List, Basic Issue Item (BII) List, and Additional Authorization List (AAL). The MCL contains the TADSS end item, discrete subassemblies, and nonexpendable components in an indentured format for TADSS end item. The MCL defines the property record of TADSS items and allows gaining commands to account for an end


859860

861

862863

864

865

866867868869870871872

873

874875

876

877

878879

880

881882

883

884885

886887888889890891

item's components. The Government provided format outlines the required structure of the data that gives the Government the ability to import the MCL into DoD databases or property accountability and property transfers.



DID: DI-PSSS-82310

3.8.3.14 Name: Bill of Materials (BOM) for Logistics and Supply Chain Risk Management

Purpose: The BOM will provide information that can be used to establish the production status of parts used in a system. The BOM will also provide DMSMS management essential information that enables the identification, forecasting, mitigation, and management of Hardware and Software obsolescence as a part of the DoD Program Manager’s Total System Life Cycle Management responsibilities. The data will be used in the Diminishing Manufacturing Sources and Material Shortages (DMSMS) forecasting tools to allow for standard and efficient sharing of information on common items.

Initial Submission Due: 30 days prior to first MVP


DID: DI-PSSS-81656B

3.8.3.15 Name: Training Materials

Purpose: Provides the materials required to support training on the end item equipment (e.g. video applications, applets, instructor guides, student guides, presentations, etc.).



DID: DI-ILSS-80872

3.8.3.16 Name: Item Unique Identification (IUID) Marking and Verification Report

Purpose: A tabular list that provides physical asset marking, registration, verification, inventory audits, quality audits, and other asset lifecycle activities.



892893894

895

896897

898

899

900901902903904905906907

908

909910

911

912

913914915

916

917918

919

920

921922

923


DID: DI-MGMT-81858

3.8.3.17 Name: Training System Support Document

Purpose: Provides complete procedures for using all software utility programs, support software file generation, and system performance characteristics verification for life cycle maintenance. This document also contains information to assist users in operating and fully using the training system during the presentation of course(s) of instruction, training exercise(s), or missions.


Recurring Submissions Due: Recurring submissions with each MVP, MVCR, and each subsequent software release

DID: DI-PSSS-81527C

3.8.3.18 Name: Trainer Facilities Report (TFR)

Purpose: The report defines and identifies criteria and requirements necessary to design and construct/modify a facility in which the trainer and associated equipment will be installed, operated, and maintained. The report identifies contractor and Government responsibilities and the time frame in which the responsibilities will be completed.


Recurring Submissions Due: As required for each delivery site

DID: DI-FACR-80966F

3.8.3.19 Name: Training Device Inventory Checklist/Record (TD ICL/R)

Purpose: Provides a checklist and record of expendable and nonexpendable equipment and support items, including tools, test equipment, Government Furnished Equipment (GFE), technical documentation, software and spare and repairable parts that are delivered as part of or with the device or system. This report will be utilized during device acceptance, inventory and transfer of the training device or system.




924925

926

927

928929930931932

933

934935

936

937

938939940941942

943

944

945

946

947948949950951952

953

954955

DID: DI-MISC-81191B

3.8.3.20 Name: Data Accession List (DAL)

Purpose: Provides a medium for identifying contractor internal data which has been generated by the contractor in compliance with the work effort described in the PWS. The DAL shall also identify subcontractor/vendor data which has been generated per the Supplier Data Requirements List (SDRL) and the PWS. The DAL is an index of the generated data that is made available upon request for the period of performance of the contract as well as any additional period of time negotiated between the Government and the contractor and cited in the contract. The DAL is not a requirement to deliver all the data listed. The Government can use the list to order data from the list as cited in the contract.



DID: DI-MGMT-81453B

3.8.3.21 Name: Training Equipment Summary

Purpose: Provides a complete condensed description of an end item of training equipment. It is made part of a training information electronic resource system (or equivalent) and is used for strategic planning, public relations, and foreign military sales.

Initial Submission Due: 30 days prior to the MVCR Recurring Submissions Due: 30 days prior to each subsequent software release DID: DI-MISC-81184A

3.8.3.22 Name: Technical Manual Verification Incorporation Certificate

Purpose: Provides the Government program manager with assurance that the contractor has resolved and/or incorporated into the final TM, corrections resulting from discrepancies/findings noted during TM verification.



DID: DI-SESS-81821


956

957

958959960961962963964965966

967

968969

970

971

972973974975

976

977978

979

980

981982983

984

985986

987

3.8.3.23 Name: Training Conduct Support Document

Purpose: Provides specific definition and direction to the instructor and trainees on learning objectives, equipment, and instructional media for use during the conduct of training. It also provides updates to course materials for life cycle maintenance of the training course.



DID: DI-SESS-81523D

3.8.3.24 Name: Course Conduct Information Package (completion)

Purpose: Provides data required by the Government to support outsourcing the conduct of training. This data will provide sufficient information to permit an accurate evaluation of a trainee’s capabilities to meet all learning objectives of a course. This data will also identify prerequisite skills and knowledge of trainees entering the course. The course conduct information package also provides information for trainees regarding the training syllabus, training organization, operating, scheduling, etc. It also provides information on an evaluation of the trainee’s performance, the trainee evaluation of training, and a certificate of completion of training for the trainee.



DID: DI-SESS-81522D

3.8.3.25 Name: Instructional Media Package – Training Video

Purpose: Contains visual, textual, and audio information to be used in the development and presentation of training. It also includes the fully integrated instructional media presentation package.



DID: DI-SESS-81526C


988

989990991992

993

994995

996

997

998999

1000100110021003100410051006

1007

10081009

1010

1011

101210131014

1015

10161017

1018

3.8.3.26 Name: Contractor Device Performance Report

Purpose: Documents time distribution, manning, work accomplished, problem areas, monthly hours to repair, and summarizes training device performance during the contract period.



DID: DI-ILSS-80191D

3.8.3.27 Name: Warranty

Purpose: Provide information on items under warranty; contractor repair, replacement, and reimbursement; and equipment failure data associated with Reliability Improvement Warranties (RIWs). Data is used to track and assess the effectiveness and implementation of the contract warranty provisions; to apprise the government of the type, severity, and frequency of failures; to verify warranty coverage for each item delivered; and to document warranty periods and delivery schedules.



DID: DI-SESS-81639A

3.8.3.28 Name: Configuration Audit Summary Report and CertificationPurpose: Provides a listing of text and marked-up technical documents (e.g., specifications, engineering drawings) that identify discrepancies between the materiel (including software) and the requirements delineated in the applicable technical documents. The Configuration Audit Summary Report and Certification also provides a documented certification that the audit was completed, and any discrepancies have been properly adjudicated.Initial Submission Due: 10 days after each Physical Configuration Audits (PCA) Recurring Submissions Due: As requiredDID: DI-SESS-81022E

3.8.3.29 Name: Configuration Audit PlanPurpose: Provides information required for conducting Functional Configuration Audits (FCA) and PCA.Initial Submission Due: 30 days prior to first MVP


1019

102010211022

1023

10241025

1026

1027

1028102910301031103210331034

1035

10361037

1038

1039

104010411042104310441045

1046

1047

1048

1049

10501051

1052

Recurring Submissions Due: As requiredDID: DI-SESS-81646C

3.8.4 TSMT Hardware DeliverablesThe Government based the quantity of hardware identified in the tables below on existing training systems. The vendor shall recommend a hardware set that enables Brigade and below collective training that minimizes the quantity, size, and logistics footprint for the Government to evaluate and approve. The training capability for RVCT Ground, RVCT Soldier, RVCT Air, and SVT shall be able to operate independently. For example, if a location has all training capabilities, that location shall be able to operate each training capability simultaneously and independent of each other. For additional hardware and point of need concepts see the TDP Appendix D TSMT Hardware Concept.

Table 3-2 identifies hardware quantities. The vendor shall provide all hardware, except the central node, in rugged, modular, weatherproof, and lockable storage/transit cases.

Table 3-2. Development / User Feedback Locations.

Name LocationCentral Node

CDSEdge Node

Field Server

EXCON Laptops

OC Mobile Device

Vendor Development Lab TBD As proposed by vendor

Government Orlando Labs FL 2 1 2 1 9 3

OTC TX 0 0 0 1 4 2ATEC TBD TBDPEO AVN / CCDC AV&MC AL 0 0 0 1 4 2

FT LVN KS 0 0 0 1 4 1Total 2 1 2 4 21 8


1053

1054

1055

105610571058105910601061106210631064

10651066

1067

1068

1069

Table 3-3 identifies the hardware quantities the vendor shall provide to the identified fielding sites. The Government based the hardware quantiles identified in the tables below on existing training systems.

Table 3-3. Fielding Locations.

Name Deliveries Central Node CDS Edge

NodeField

ServerEXCON Laptops

OC Mobile Device

Fort Hood, TXMVP / Operational Test

/ MVCR / Annual Releases

2 1 2 6 42 28

JBLM, WA Brigade Release 2 1 2 6 42 28 Fort Drum, NY Brigade Release 2 1 2 6 42 28Fort Benning, GA

Brigade Release 2 1 2 6 42 28

Fort Leonard Wood, MO


WTC ARNG, GA (Fort Benning)


Total 12 6 12 36 252 168

3.8.4.1 The vendor shall specify the hardware concept, quantities, and draft specifications no later than 75 days after contract award for the Government to approve.

3.8.4.2 The vendor shall choose hardware items that provide a reduction of total ownership costs and logistics footprint to include supply chain support and document in accordance with the deliverables (x.x.x).

3.8.4.2.1 The TSMT system shall avoid using any individual item whose unit purchase cost or spare price is greater than $25,000.

3.8.4.2.2 The TSMT system shall avoid using any individual item that has a projected removal/replacement rate greater than once per year.

3.8.4.2.3 The TSMT system shall avoid using any item that has a projected annual maintenance cost of greater than $10,000 per training device.

3.8.4.2.4 The TSMT system shall avoid using any item that requires special or extraordinary handling, disposal, usage rate, or maintenance procedures.

3.8.4.2.5 The TSMT system shall avoid using any item that will be unsupportable and out of production by the OEM within 36 months after MVCR or each subsequent annual software release.


107010711072

1073

10741075

107610771078

10791080

10811082

10831084

10851086

108710881089

3.8.4.3 The vendor shall preload the Central Node, Edge Node, Field Server, EXCON Laptop, and Observer Controller (OC) Mobile Devices with the current TSMT software release and the OWT data and models as appropriate prior to each delivery.

3.8.4.4 The vendor shall deliver all hardware in accordance with commercial best practices and applicable packaging, handling, storage, and transportation (PHS&T) standards.

3.8.4.5 The vendor shall deliver production representative hardware to development and user feedback sites no later than 30 days after the Government approves the vendor’s hardware concept, hardware quantities, and draft specifications IAW Table 3-2.

3.8.4.6 The vendor shall provide a cost option to replace production representative hardware at the development and user feedback sites with production hardware (final specification) after MVCR, release 1, and release 2.

3.8.4.7 The vendor shall update the software loads on the previously delivered hardware to the latest software baseline with each software release.

3.8.4.8 The vendor shall deliver production hardware (final specification) to fielding and operational testing sites to be available on the first day of fielding or the first day of the test event preparation window as appropriate.

3.8.4.9 The vendor shall provide cross domain solutions (software or hardware) for the development and fielding locations IAW Table 3-2 and Table 3-3.

3.8.5 Cost DeliverablesData submitters must register through the Cost Assessment Data Element (CADE) website (http://cade.osd.mil) and possess a DoD-approved External Certification Authorities (ECA) digital certificate or DoD-issued Common Access Card (CAC) to obtain a CADE Portal account and be authorized to upload CSDR content. Users can obtain access by submitting user information about themselves and their organizations to the CADE Portal and requesting a Cost and Software Data Reporting (CSDR) submitter user role. After the registration information has been verified the Defense Cost and Resource Center (DCARC) shall authorize the user account and requested roles. All CADE Portal accounts need to be renewed at least annually.

The prime vendor shall flow down CSDR requirements contained in the agreement to all sub-vendors who meet the reporting thresholds specified in DoDI 5000.02, or as required by the Cost Working Integrated Product Team (CWIPT). The prime and sub-vendors shall electronically report directly to the CADE Portal using the CSDR Submit-Review System.

In accordance with Statue 10 USC 2334 Sec. 842, DoDI 5000.02, and DFARS 252.234-7003 and 252.234-7004, “Notice of Cost and Software Reporting System”


109010911092

10931094

109510961097

109810991100

11011102

110311041105

11061107

1108

110911101111111211131114111511161117

11181119112011211122

11231124

This agreement includes the approved CSDR Plan for the agreement, DD Form 2794.

A CSDR Readiness Review Meeting will be held after agreement award to include a discussion of the CSDR process that satisfies the guidelines contained in the DoD 5000.04-M- 1, “CSDR Manual,” and the requirements in the approved CSDR Plan for the agreement, DD Form 2794, and related Resource Distribution Table.

Appendix F Cost Deliverables includes the CSDR requirements (DD Form 2794). Inclusive in the plan is the information required by CWBS for the respective Sub-vendor and Prime Vendor, schedule for report submission, and specific information as to format, address to send the information, and other pertinent facts. The WBS on Page 2 of the CSDR plan may be revised by the Government prior to agreement award. The final reporting WBS shall be determined jointly with the vendor and the CWIPT.

See Appendix F Cost Deliverables for additional information. The required form and file type for each CSDR is specified in its Data Item Description. The vendor may also submit electronically in accordance with the FlexFile Excel-Compatible Submission Guidance or the FlexFile Excel Template outlined in the FlexFile Implementation Guide located on the CADE website (http://cade.osd.mil).

3.8.5.1 The vendor shall systematically collect and report to CADE and the USG the actual contract costs and technical information based on the Office of the Secretary of Defense (OSD) Deputy Director Cost Analysis (DDCA)-approved CSDR plan IAW the CSDR Manual, DoDM 5000.04-M-1.

3.8.5.2 The vendor shall prepare the CSDRs in accordance with the instructions contained in the most recently approved versions of the DIDs (DIDs DI-MGMT-82035A, DI-FNCL-82162, DI-MGMT-82164.

3.8.5.3 The vendor shall submit electronically the Software Resources Data Report (3.8.5.3).

3.8.5.4 The vendor shall submit electronically the Cost and Hour Report (FlexFile) Contractor Format IAW File Format Specification (FFS) and Data Exchange Item (DEI) (3.8.5.4).

3.8.5.5 The vendor shall submit electronically the Quantity Data Report (-Q) Contractor format IAW FFS and DEI (3.8.5.5) using the CADE CSDR Submit-Review System.

3.8.5.6 In the performance of this contract, the vendor shall use:

1. A documented standard CSDR process that satisfies the guidelines contained in the DoD 5000.04–M–1, CSDR Manual,

2. Management procedures that provide for generation of timely and reliable information for the CCDRs and Software Resources Data Reports (SRDRs) required by the CCDR and SRDR data items of this contract,


1125

1126112711281129

113011311132113311341135

11361137113811391140

1141114211431144

114511461147

1148

11491150

11511152

1153

11541155115611571158

3. The approved CSDR Plan for this contract, DD Form 2794, and the related Resource Distribution Table as the basis for reporting according to the required CSDR DIDs,

4. The vendor shall require and flow down the requirement for CSDR reporting from sub-vendors regardless of tier with a sub-agreements that exceeds $50 million or sub-agreements valued between $20 million and $49 million that are designated by the Government as being high risk, high value, or of high technical interest. If, for sub-agreements that exceed $50 million, the vendor changes sub-vendors or makes new sub-agreement awards, the vendor shall notify the Government.

3.9 System RequirementsThe vendor shall ensure that the STE simulation represents and models units, organizations, lifeforms, and other like objects as individual entities at all times. Although aggregation is required to be applied for purposes of viewing, decluttering, or controlling large units or formations, internal simulation/game engine entity level modeling and entity level representation within network packets is always required. The STE definition of an entity is as follows: An entity is any independent object within a simulation that possesses complex behaviors and attributes. For example, personnel, vehicles, complex munitions, key communications devices might all be represented as independent entities within a simulation.

The vendor shall utilize the system requirements as described in the TSMT TDP Appendix E SRD to form the initial backlog for TSMT capability. The TDP contains materials with distribution limitations. The Government can release the TDP to vendors that successfully navigate the PEO STRI vetting process.

The first two levels of the SRD requirements schema is below.

1 Common Requirements

1.1 Played Items

1.2 PMESII-PT

1.3 METT-TC Factors

1.4 Rendering

1.5 Architecture

1.6 Technology

1.7 Interoperability / Integration

1.8 Deployment


115911601161116211631164116511661167

1168

116911701171117211731174117511761177

1178117911801181

1182

1183

1184

1185

1186

1187

1188

1189

1190

1191

1.9 Non-Architecture Attributes /Guidance

1.10 One World Terrain

1.11 RVCT Integration

2 Training Simulation Software

2.1 TSS/RVCT

2.2 TSS General

2.3 S/SVT

3 Training Management Tool

3.1 TMT Assess

3.2 TMT Execute

3.3 TMT Plan

3.4 TMT Prepare

3.5 TMT TMT Common

3.9.1 General3.9.1.1 The vendor shall provide an option to purchase full source code data rights for any major

commercial component in the vendor’s solution.

3.9.1.2 The vendor shall provide an option to purchase updates for full source code data rights for any major commercial component in the vendor’s solution.

3.9.1.2.1 The vendor shall provide 50 copies of any commercial software used in the TMT or TSS solution for independent Government capability verification, benchmarking, and experimentation.

3.9.1.2.2 The vendor shall establish cost, option Contact Line Item Number (CLINs) for integration of an additional 10, 20, 50, 100 and 250 new OWT models above and beyond the model baseline expected from OWT.

3.9.1.3 The vendor shall consume products provided by OWT. Refer to the TDP Appendix E SRD for additional OWT requirements.


1192

1193

1194

1195

1196

1197

1198

1199

1200

1201

1202

1203

1204

1205

12061207

12081209

12101211

1212

121312141215

12161217

3.9.1.3.1 The TSMT vendor shall supplement the moving model library obtained from the OWT vendor with vehicle models that already exist in their library. These models shall be used as is without further modification and without new model development. These models shall be disclosed to the government and limitations in functionality published so that the government can determine their suitability for use in the simulation.

3.9.1.3.2 The vendor shall provide a methodology that allows a third party to produce models in the open OWT format and then convert the model to the open TSMT run-time format specifications in accordance with the deliverables (3.8.2.1).

3.9.1.3.3 The TSMT vendor shall work with the OWT vendor to ensure that the Well Formed Format (WFF) provides all of the information required by the TSMT software while keeping the WFF an open specification and be able to be used by third party software (see TDP Appendix F for the OWT Specification).

3.9.1.3.4 The TSMT vendor shall provide the human and animal models and kinematics for those models as listed in the model list.

3.9.1.3.5 The TSMT vendor shall work with the OWT vendor and the government to ensure that the Filmbox (FBX) and glTF implementations contain all the information required by the TSMT software to render the model. The TSMT vendor shall provide a methodology for third party content creators to create models that can be rendered by the TSMT software.

3.9.1.4 The vendor shall ensure the TSS solution is optimized for cross platform use and must function on mobile devices, laptops, desktops, and untethered cross reality (XR) devices.

3.9.1.5 The vendor shall work with the RVCT vendor to perform analysis, trade studies and experimentation to determine the feasibility of achieving significant reduction in power consumption of the RVCT Compute Kit(s) and TSMT compute/rendering/storage capability located at the point of need. The vendor shall identify and explore novel approaches such as application of low power mobile computing technology and/or transmission of streaming video in support of significant PoN power reduction.

3.9.1.6 The vendor’s new development work shall not break current capabilities.

3.9.2 Architecture


12181219122012211222

122312241225

1226122712281229

12301231

12321233123412351236

12371238

123912401241124212431244

1245

1246

The separation in contract vehicles drives the need for the development to synchronize architecture and establish platform abstraction layers, integration services interfaces, and interface agreements between vendors. The STE architecture defines the conceptual structure and logical organization of the STE capabilities. The architecture supports real-time situational awareness across all modules / components, scalability, cybersecurity, accessibility, interoperability, and extensibility. The STE provides a secure system that meets the cybersecurity requirements outlined in Section 3.13.2 Cybersecurity.

3.9.2.1 The vendor shall implement a Modular Open Systems Approach (MOSA) that complies with MOSA Implementation Guide Version 1.0 and the MOSA Reference Frameworks in Defense Acquisition Programs.

3.9.2.2 The TSMT shall be modular, with an open architecture, such that the system interfaces share common, widely accepted standards that support interoperability across OWT, RVCT and IVAS-SiVT if available, at the Brigade and Below software release.

3.9.2.3 The vendor shall enforce modular architectures.

3.9.2.4 The vendor shall certify conformance to modularity and openness using the Program Assessment and Review Tool (PART) in accordance with the deliverables (3.8.2.1).

3.9.2.5 The vendor shall comply with the Army Data Modernization Strategy.

3.9.2.6 The vendor shall designate key interfaces.

3.9.2.7 The vendor, in collaboration with the Government, shall define and manage all ICDs in accordance with the deliverable ().

3.9.2.8 The vendor shall propose standards for Government approval in accordance with the deliverable (3.8.2.2 and ).

3.9.2.9 The vendor shall develop and deliver the solution architecture in NoMagic Magic Draw format using the Unified Profile for DoDAF/MODAF (UPDM) and SysMIL plug ins in accordance with the deliverables (3.8.2.2).

3.9.2.10 The vendor shall develop architecture using the Development and Engineering Experience Platform (DEEP), a Government collaboration space for U.S. persons that hosts the authoritative model for requirements and architecture in accordance with the deliverable (3.8.2.2).

3.9.2.11 The vendor shall develop and deliver the SSS and SRS in the Dynamic Object-Oriented Requirements System (DOORS) format in the DEEP in accordance with the deliverables (3.8.2.5 and ).


12471248124912501251125212531254

125512561257

125812591260

1261

12621263

1264

1265

12661267

12681269

127012711272

1273127412751276

127712781279

3.9.2.12 The vendor shall document major interfaces and components of the vendor solution in a briefing that identifies points of modularity and evaluates all major components and interfaces for their degree of modularity and openness in accordance with the deliverable ().

3.9.2.13 The vendor shall provide frequent architecture updates that focus on interface definition to support rapid integration.

3.9.2.13.1 The vendor shall provide the first briefing not later than 60 days after OTA award in accordance with the deliverables (3.8.2.2).

3.9.2.13.2 The vendor shall provide architecture updates at each MVPs, MVCR, and releases in accordance with the deliverables (3.8.2.2).

3.9.2.14 The vendor architecture shall be compliant with the Government’s high-level STE architecture.

3.9.2.15 The vendor shall provide the architecture for the TSMT cloud.

3.9.2.16 The vendor can request changes to the Government’s high-level STE architecture through the Government’s Architecture Synchronization agile ceremony as appropriate and the Government will evaluate and determine applicability in accordance with the deliverables (3.8.2.2).

3.9.2.17 The vendor shall develop documentation that integrates the STE system capability and interfaces to include software architecture, systems architecture, training manuals, technical and troubleshooting manuals, and test plans and procedures in accordance with the deliverables (3.8.2.1, , 3.8.2.2, 3.8.3.7, 3.8.2.7).

3.9.3 Point of NeedThe TSMT delivers training content to the PoN at Home Stations, deployed locations, and training and educational institutions. See Table 3-3 for MVCR and Operational Test locations. See the TDP Appendix D TSMT Hardware Concept for more information on the PoN.

3.9.3.1 Point of Need Conditions

The STE collective training system will be used at existing facilities at the PoN. The STE collective training system shall use existing facilities’ shelter, power, and environmental control that maintains the temperature and humidity range (see AR 70-38, Research, Development, Test, and Evaluation of Materiel for Extreme Climatic Conditions).


1280128112821283

12841285

12861287

12881289

12901291

1292

1293129412951296

1297129812991300

1301

1302130313041305

1306

1307130813091310

When the STE collective training system is transported to a PoN that does not have a facility, the unit will provide tents, generators, and environmental control units to shelter and power the training capabilities and maintain the temperature and humidity in the range needed to operate the training capabilities. This will enable the operation of the STE collective training system in austere and semi-austere environments.

3.9.3.2 Network

The STE operates in connected and disconnected modes (for training under limited or degraded network conditions). STE leverages the Army Network (enterprise and tactical) to deliver training to the PoN. STE traffic traverses the Integrated Enterprise Network (IEN), Integrated Tactical Network (ITN), and commercial networks. The IEN is the backbone wide area network that connects installations together. The Installation Campus Area Network (ICAN) connects buildings on the installation. The ITN connects the MCIS and COE. STE traffic will also traverse organizational networks (Army National Guard and United States Army Reserve) to provide a total Army training capability.

3.9.3.2.1 The vendor solution shall use DoD networks (e.g., ITN, IEN, ICAN), and commercial networks for transport.

3.9.3.2.2 At a minimum, the vendor shall use identity management, domain name service, and active directory enterprise services.

3.9.3.2.3 The vendor shall design the TMT software to be securely accessible to the user from a public network.

3.9.3.2.4 The vendor shall support network communication exercises (COMEX) prior to each network risk reduction events (NRRE).

3.9.3.2.5 The vendor shall support TIF NRREs using the Joint Mission Environment (JME) and the DoDIN utilizing Non-classified Internet Protocol (IP) Router (NIPR).

3.9.3.2.6 The vendor shall support Operational Site NRREs using the Department of Defense Information Network (DoDIN) to inform/determine the network bandwidth and latency thresholds.

3.9.3.2.7 The vendor shall support Government wireless pilot experiments in the Government lab infrastructure and at Operational Sites over the DoDIN to inform/determine the network bandwidth and latency thresholds.

3.9.3.2.8 The vendor shall support Government cellular pilot experiments in the Government lab infrastructure and at Operational Sites over the DoDIN to inform/determine the network bandwidth and latency thresholds.


13111312131313141315

1316

131713181319132013211322132313241325

13261327

13281329

13301331

13321333

13341335

133613371338

133913401341

134213431344

3.9.3.2.9 The vendor solution shall be able to use installation wireless capabilities.

3.9.3.3 Cloud

The TSMT uses elastic and scalable shared computing resources to scale the capability without excessive, idle overhead capacity. The TSMT hybrid cloud agnostic design enables the capability to transition between cloud service providers. The vendor shall use Defense Information Systems Agency (DISA) approved Cloud services and shall adhere to the Enterprise Cloud Management Office (ECMO) guidelines and standards see enterprise-cloud-management-office-ecmo for additional information. The vendor shall follow the DoD Digital Modernization Strategy and DoD Cloud Strategy and operate up to Impact Level 6 and MCIS classification of secret.

3.9.3.3.1 The vendor shall work with the Government to identify the appropriate cloud provider.

3.9.3.3.2 The vendor shall use a zero-trust cloud.

3.9.3.3.3 The vendor shall use Cloud enabled Multi-cluster and cross-data center deployments including disaster recovery, aggregation for analytics, cloud migration, mission-critical stretched deployments, and global distribution to provide the framework for storing, reading, and analyzing streaming data.

3.9.3.4 Multi-level Security

3.9.3.4.1 The vendor shall employ a bi-directional CDS that can host multiple security classifications (i.e., Unclassified, Secret, and Secret Releasable) in a single exercise.

3.9.3.4.2 The vendor shall work with the Government to determine the number and type of releasable categories the CDS will support. The TDP Appendix D TSMT Hardware Concept includes conceptual CDS courses of action.

3.9.4 TSMT Hardware


1345

1346

13471348134913501351135213531354

1355

1356

1357135813591360

1361

13621363

136413651366

1367

https://login.milsuite.mil/?goto=https%3A%2F%2Fwww.milsuite.mil%3A443%2Fbook%2Fgroups%2Fenterprise-cloud-management-office-ecmo

TSMT employs an innovative and minimalistic hardware solution that leverages breakthroughs in content delivery. TSMT hardware may include central nodes, edge nodes, field servers, EXCON laptops and OC Mobile Devices. The central node and edge node hardware provides compute, store, and local area network capabilities that reduce risk for the Army network in connected or disconnected operations at the PoN. The central nodes, unclassified and classified, reside in the Network Enterprise Center (NEC) or other suitable location that provides the physical security, network connections, power, cooling, and administration as determine by installation and army regulation. Edge nodes will be collocated with the RVCT-Air and RVCT-Ground training capabilities and expanded to provide compute at point of need for future SVT and live capabilities. The field server hardware provides a compute and store capability that enables training at the PoN. TSS, TMT and OWT software and data reside on the edge nodes and the field servers. EXCON laptops allow EXCON / HighCon / LowCon / White cell and OPFOR to monitor and control the training event. OC Mobile Devices enable observer controller trainers to monitor and interact with the training event while observing the training audience. For additional hardware and point of need concepts see the TDP Appendix D TSMT Hardware Concept.

3.9.4.1 The vendor shall recommend a hardware set that enables Brigade and Below collective training that has a minimal size, weight, and power footprint for Government evaluation and approval.

3.9.4.2 The vendor TSMT hardware configuration shall provide compute, store, and network capabilities.

3.9.4.3 The vendor shall consider trade space between network, cloud, storage, and end-device (e.g., zero/thin client, thick client, RVCT, SVT) capabilities and location.

3.9.4.4 The vendor shall identify the hardware configuration that satisfies the STE requirements (TSMT & OWT services) at the PoN.

3.9.4.5 The vendor shall use the National Information Assurance Partnership (NIAP) validated or Approved Products List (APL) components in the performance of this contract.

3.10 Agile ProcessThe Government requires that the solution be built using Agile practices that are consistent with the SAP and enables frequent user feedback. The vendor shall identify how they will produce deliverables within an incremental, fast-paced software development schedule to reduce the risk of failure.

The vendor shall identify an agile approach that addresses meetings and agile ceremonies such as: daily scrum meetings, scrum of scrums, sprint planning, sprint


13681369137013711372137313741375137613771378137913801381138213831384

138513861387

13881389

13901391

13921393

13941395

1396

1397139813991400

14011402

demonstrations, sprint retrospectives, program increment planning sessions, integration points between teams, system demonstrations, and other components of the agile methodology. The vendor agile approach shall ensure continuous user engagement and feedback mechanisms. The vendor shall identify sprint and program increment length. The vendor shall also identify a specific technique to facilitate distributed meetings with the Government, vendors, and sub-vendors using a mechanism approved for official use only (FOUO). Using the agile development process, the vendor shall work with the Government to identify the capabilities the vendor shall develop during each program increment and sprint.

The TDP Appendix E SRD provides additional requirements guidance necessary for the Government and vendor to collectively construct the initial and incremental backlog of features and / or user stories. The specifics of each backlog item shall include, but not be limited to:

A Government approved prioritized increment feature list and product roadmap. Product owner approved, prioritized increment/sprint user stories (including the

anticipated outcome). Business value of each user story toward overall objectives. Progress reporting, risk identification and dependency identification.

The Government’s preferred agile approach embraces changing requirements over time based on constant user feedback. The approach provides a common cadence for the agile teams where they plan, develop, demonstrate, and learn together as an integrated system.

3.10.1 General3.10.1.1 The vendor Agile process shall include time for technology investigation, innovation,

refactoring, and bug fixes.

3.10.1.2 The vendor shall support the Government leadership team in addressing expectations, and identifying risks, issues, opportunities, and dependencies across the development.

3.10.1.3 The vendor shall deliver the initial working software that meets the vendor’s proposed and Government approved MVCR in accordance with the deliverable (3.8.2.1).

3.10.1.4 The vendor shall elevate all cost, schedule, and performance decisions to the Government.

3.10.1.5 The vendor shall participate in the weekly Government led scrum of scrum meetings.

3.10.1.6 The vendor shall participate in the weekly Government led product manager/requirements manager synchronization meetings.


140314041405140614071408140914101411

1412141314141415

14161417141814191420

1421142214231424

1425

14261427

14281429

14301431

14321433

1434

14351436

3.10.1.7 The vendor shall participate in the weekly Government led architecture synchronization meetings.

3.10.1.8 The vendor shall provide the Government an Architecture Roadmap review at least two increments prior to a program increment, MVP, MVCR, and subsequent software release as per the mutually agreed to schedule.

3.10.1.9 The vendor in collaboration with the Government shall incrementally update and maintain the roadmap and program backlog after each program increment, MVP, MVCR, and subsequent software release in accordance with the deliverables (3.8.1.5).

3.10.1.10 The vendor shall participate in the Government led pre-program increment planning session.

3.10.2 Agile Ceremonies3.10.2.1 The vendor shall conduct a program increment planning session with the Government

prior to each increment and shall use the Government provided prioritized features to conduct the planning.

3.10.2.1.1 The vendor shall meet the following program increment planning session entry criteria:

Government provided prioritized functional features and architecture enablers.

3.10.2.1.2 The vendor shall provide the Government the following program increment planning session exit criteria NLT 5 calendar days after the planning session in accordance with the deliverables (3.8.1.4, 3.8.1.5, and 3.8.2.8):

Program increment objectives Sprint plan for each team Team risks Program Increment dependency board Updated product roadmap Update architectural runway Updated program backlog T&E Plan RTM

3.10.2.2 The vendor shall conduct team sprint planning sessions on the first day of the sprint.


14371438

143914401441

144214431444

14451446

1447

144814491450

14511452

14531454

145514561457

145814591460146114621463146414651466

1467

3.10.2.2.1 The vendor shall meet the following team sprint planning session entry criteria:

Program increment planning session exit criteria artifacts.

3.10.2.2.2 The vendor shall provide the Government the following team sprint planning session exit criteria NLT 1 calendar day after the sprint planning session in accordance with the deliverable (3.8.1.4):

Refined team sprint plan Team sprint goals

3.10.2.3 The vendor shall conduct a sprint review with the Government at the end of the sprint cycle.

3.10.2.3.1 The vendor shall meet the following sprint review entry criteria in accordance with the deliverables (3.8.1.4 and 3.8.2.9)

Refined team sprint plan Sprint test results

3.10.2.3.2 The vendor shall provide the Government the following sprint review exit criteria NLT 2 calendar days after the sprint demonstration in accordance with the deliverables (3.8.1.4, , and 3.8.2.12):

Sprint demonstration Sprint retrospective Sprint release notes Sprint backlog refinement

3.10.2.4 The vendor shall conduct a program increment demonstration with the Government at the end of the program increment cycle.

3.10.2.4.1 The vendor shall meet the following program increment demonstration entry criteria in accordance with the deliverables (3.8.2.7, 3.8.2.8, 3.8.2.1, and 3.8.2.9):

Program increment software/hardware Program increment test results

3.10.2.4.2 The vendor shall provide the Government the following program increment demonstration exit criteria NLT 2 calendar days after the demonstration in accordance with the deliverables (3.8.1.4 , and 3.8.2.12):

Program increment demonstration44


1468

1469

147014711472

14731474

14751476

14771478

14791480

148114821483

1484148514861487

14881489

14901491

14921493

149414951496

1497

Program increment release notes Program increment retrospective Software release Program backlog refinement Next program increment planning session

3.10.3 Agile Metrics3.10.3.1 The vendor shall provide an automated agile metric reporting mechanism for

Government approval.

3.10.3.2 The vendor shall develop and track the following agile metrics for each sprint and program increment, MVP, MVCR, and subsequent software releases to the Government NLT 2 calendar days after the cycle in accordance with the deliverables (3.8.1.1). See the DoD Agile Metrics Guide, Strategy Considerations and Sample Metrics for Agile Development Solutions Version 1.1 dated 23 September 2019 for additional information and formulas for the metrics identified below.

Agile Process Metrics. Agile process metrics measure process performance, or how well planning, execution, and delivery activities are performing. Agile process metrics include:

Feature Points: Used for sizing features. It measures the complexity of a feature. Typically, features points utilize the Fibonacci sequence (1,2,3,5,8 etc.).

Story Points. Story points measure the complexity of a story and are explained in the next subsection. The developer assigned to a story is responsible for identifying how much effort is required to complete the work in each sprint. If a story is larger than 8, the team must go back and split the story.

Velocity. Velocity measures the amount of work (usually in story points, although other measurement units can be used as well, such as hours) that the team completes in each sprint.

Velocity Variance. Velocity variance is the standard deviation from average velocity – or the difference from the mean velocity.

Velocity Predictability. Velocity predictability is measured as the difference between planned and completed velocity, which is the difference between the total planned and completed story points for a given sprint.

Story Completion Rate. Story completion rate describes the number of stories Across Board completed in each sprint or release.

Sprint Burndown. Teams implementing sprints use a sprint burndown chart to estimate their pace of work accomplished daily. The pace is usually measured in hours of work.


14981499150015011502

1503

15041505

150615071508150915101511

151215131514

1515151615171518151915201521152215231524152515261527152815291530153115321533

Release Burnup. The release burnup metric is a planning tool that allows the Agile team to estimate whether the team is on track to complete the items in the release.

3.10.3.2.1 Agile Quality Metrics. Agile quality metrics measure the quality of work being delivered. Agile quality metrics include:

Recidivism. Recidivism describes stories that are returned to the team for various reasons. If stories are not completed as the users expect, the team will need to understand the reasons, especially if recidivism rates are relatively high or increasing.

Defect Count. Defect count measures the number of defects per sprint or release.

Number of Blockers. Number of blockers describes the number of events that prohibit the completion of an activity or work item. These blockers cannot be resolved by the individual assigned to complete the activity and the team needs assistance to remove the blocker.

3.10.3.2.2 Agile Product Metrics. Agile product metrics should measure the value that the product delivers in terms of user acceptance and alignment to desired outcomes (measured by value). Agile product metrics include:

Delivered Value Points. This metric represents the count of value points delivered to users for a given release. Value points are usually defined by the users (or user representatives) to indicate a business value assigned to a given feature, capability, epic or story.

Level of User Satisfaction. This metric represents the measure of user satisfaction based on the value delivered by the product or solution.

3.10.4 Roadmap

3.10.4.1 The vendor shall collaborate with the Government to develop and maintain an executable product roadmap that includes prioritized features aligned to a high level calendar and success metrics approved by the Government for each program increment, MVPs, MVCR, and subsequent software releases in accordance with the deliverables (3.8.1.5).

3.10.4.2 The vendor shall propose their version of the product roadmap in response to this PWS that considers the desires of the Government’s draft product roadmap and balances that with the practical sequence and timing of development, integration, test and delivery that it can support.

3.10.4.2.1 The vendor roadmap shall include test dates.

3.10.4.2.2 The vendor roadmap shall include test lead time cutoff points.


153415351536

15371538

1539154015411542154315441545154615471548

154915501551

155215531554155515561557

1558

1559156015611562

1563156415651566

1567

1568

3.10.4.2.3 The vendor roadmap shall include TMT capability progression broken out by the plan, prepare, execute, and assess elements; artificial intelligence, machine learning, and intelligent tutoring system integration; and interfaces with authoritative data sources.

3.10.4.2.4 The vendor roadmap shall include TSS computer generated forces capability progression.

3.10.4.2.5 The vendor roadmap shall include TSS entity level constructive training.

3.10.4.2.6 The vendor roadmap shall include the cross-domain solution accreditation progression.

3.10.4.2.7 The vendor roadmap shall include the cybersecurity accreditation progression.

3.10.4.2.8 The vendor roadmap shall include fires training capabilities by echelon capability progression.

3.10.4.2.9 The vendor roadmap shall include mission command training capabilities by echelon capability progression.

3.10.4.2.10 The vendor roadmap shall include movement and maneuver training capabilities by echelon capability progression.

3.10.4.2.11 The vendor roadmap shall include RVCT-Soldier software capability progression e.g., Soldier/Squad to BCT.

3.10.4.2.12 The vendor roadmap shall include platform level Mission Command representation and interoperability capability progression (includes Platform command and control [C2] capability required by certain RVCT Solider and/or EXCON roles such as Squad leader and Platoon leader and Fires handheld C2 device representation [simulation, emulation or “wrapping” of tactical software] for use by a simulation role player).

3.10.4.2.13 The vendor roadmap shall include Command Post Mission Command interoperability, mapped to all systems specified in SRD capability progression.

3.10.4.2.14 The vendor roadmap shall include scalability capability progression.

3.10.4.2.15 The vendor roadmap shall include voice communications system capability progression.

3.10.4.2.16 The vendor roadmap shall include RVCT Air Software platform software capability progression.


1569157015711572

15731574

1575

15761577

1578

15791580

15811582

15831584

15851586

158715881589159015911592

15931594

1595

15961597

15981599

3.10.4.2.17 The vendor shall provide a breakout of when each major air subsystem is integrated and delivered (e.g., Apache basic flight, AvSE integration, fire control radar, 30 mm, Rockets, Hellfire, voice comms, digital comms Link 16, Air Force Applications Program Development (AFAPD) and Joint Variable Message Format (JVMF), TMT management, Aviation Mission Planning Software (AMPS) initialization, etc.).

3.10.4.2.18 The vendor roadmap shall include RVCT Ground Software platform software capability progression.

3.10.4.2.19 The vendor shall provide a breakout of when each major ground subsystem is integrated and delivered

3.10.4.2.20 The vendor roadmap shall include Political, Military, Economic, Social, Infrastructure, Information - Physical Environment, & Time (PMESII-PT) capability aligned to Military, Information, Infrastructure, Physical Environment and Time variables capability progression.

3.10.4.2.21 The vendor roadmap shall include interoperability (e.g., LVC-IA, JLCCTC, IEWTPT) capability progression.

3.10.4.2.22 The vendor roadmap shall include RVCT Air and Ground platform integration capability progression.

3.10.4.2.23 The vendor roadmap shall include OWT capability progression (e.g., model integration, base globe, Graphics Library Transmission Format (glTF)/3D tiles import, download and stitch hi resolution areas onto base globe, terrain editing, submission of edits to OWT repository for potential integration into master OWT repository).

3.10.4.2.24 The vendor roadmap shall include Government Furnished Information (GFI) / GFE / S&T integration.

3.10.4.2.25 The vendor roadmap shall include CATS task progression.

3.10.5 DevSecOps


16001601160216031604

16051606

16071608

1609161016111612

16131614

16151616

1617161816191620

16211622

1623

1624

DevSecOps is an organizational software engineering culture and practice that aims at unifying software development (Dev), security (Sec) and operations (Ops). The main characteristic of DevSecOps is to improve outcomes and mission value by automating, monitoring, and applying security at all phases of the software lifecycle. A full DevSecOps pipeline includes Continuous Integration, Continuous Delivery, Continuous Deployment, Continuous Operation, and Continuous Monitoring. The goal for the DevSecOps environment is to facilitate planning, coordination, execution, and delivery of an integrated system in one singly managed place through agile software development processes. DevSecOps, in the context of TSMT, are users and developers working together to enable rapid and frequent delivery of capabilities to the Warfighter to receive feedback that informs the requirement.

3.10.5.1 The vendor shall implement a DevSecOps process that is consistent with the DoD Enterprise DevSecOps Reference Design.

3.10.5.2 The vendor shall conduct DevSecOps discussions with current and future OTA vendors and the Government.

3.10.5.3 The vendor shall document their DevSecOps plan and provide to the Government NLT 30 days after contract award in accordance with the deliverable (3.8.3.6).

3.10.5.4 The vendor shall employ a transparent DevSecOps / Agile process involving the Government to plan, develop, build, test, secure, deploy, operate, and scale TSMT.

3.10.5.5 The vendor shall coordinate and synchronize all phases and activities of STE system capability and interface vendors through the software factory.

3.10.5.6 The vendor shall design their DevSecOps process to employ a delivery pipeline that enables the systems to develop on cadence, release on demand, and conduct continuous integration and continuous delivery (CI/CD) with STE system capability and interface vendors to ensure an integrated STE system of systems.

3.10.5.7 The vendor shall release a fully integrated STE system that provides collective training value.

3.10.5.8 The vendor shall design their DevSecOps process to maximize automation for activities in develop, build, test, release, and deliver/field phases.

3.10.5.9 The vendor shall establish pass criteria, perform, and pass automated unit tests, regression tests, and automated interface tests as entry criteria for assessment events.

3.10.5.10 The vendor shall co-develop and/or review the automated test procedures with the Government to ensure they are accurate and complete.


16251626162716281629163016311632163316341635

16361637

16381639

16401641

16421643

16441645

1646164716481649

16501651

16521653

16541655

16561657

3.10.5.11 The vendor shall present all automated test tools to the Test and Evaluation Working Integrated Product Team (T&E WIPT) for approval.

3.10.5.12 The vendor shall use an automated security tools to ensure compliance with the continuous ATO process.

3.10.5.13 The vendor shall provide the Government source code, build scripts, and any other dependency necessary to independently build the application developed under the OTA at each MVP, MVCR, and each subsequent delivery to the Government in accordance with the deliverables (3.8.2.1).

3.10.5.14 The vendor shall deploy approved system configurations to the locations identified in Table 3-2 and Table 3-3.

3.10.5.15 The vendor shall provide the Government remote access to the system to install and access diagnostic, instrumentation, and test software to collect and view test data for each sprint, program increment, MVP, MVCR, and subsequent software releases.

3.10.5.16 The vendor shall recommend changes and improvements that increase the effectiveness of the STE DevSecOps processes and procedures.

DevSecOps metrics relate to measurements that provide insight into the organization’s delivery pipeline. They also include metrics that provide a high-level assessment of the organization’s ability to integrate, deliver, monitor, and restore products.

3.10.5.17 The vendor shall develop and track the following DevSecOps metrics and provide monthly updates to the Government in accordance with the deliverables (3.8.1.1 and 3.8.3.6):

Mean Time to Restore (MTTR). MTTR measures how quickly a system or solution can be restored to functional use after a critical failure.

Deployment Frequency. Deployment frequency provides information on the cadence of deployments in terms of time elapsed between deployments.

Lead Time. This flow metric represents how long it takes to deliver a required solution.

Change Fail Rate. Tracks defect count measures and returned stories per sprint or release.

3.10.5.18 Platform One

Platform One is the official DoD DevSecOps Enterprise service. Platform One facilitates efficient and effective coordination between development scrums and the Government. The vendor accesses Platform One using the internet. The Government will purchase services to have the STE DevSecOps pipeline hosted in Platform One. The CI/CD pipeline will use Platform One provided tools and products. Platform One may have the


16581659

16601661

1662166316641665

16661667

166816691670

16711672

167316741675

167616771678

16791680168116821683168416851686

1687

16881689169016911692

flexibility to support additional tools required for the STE DevSecOps process. Platform One hosted pipelines currently have access to:

Plan & Develop: Jira, Gitlab, Github, Git, Build: Ant, Cmake, Maven, MSBuild, Gradle, Jenkins Test: Selenium, Cucumber, Junit Secure: Sonarqube, Nessus, Twislock, Fortify, Aqua, Qualys, Nexus, Archiva,

Jfrog Deploy & Operate: Ansible, Chef, Puppet, Helm, Salt, Operator SDK Monitor: Nagios, Splunk, Sunsu, Kubernetes, Docker, and ELK Stack Scale: Azure, AWS Gov Cloud, milCloud, and Google cloud.

3.10.5.18.1 The vendor shall use the Government provided Platform One environment.

3.10.5.18.2 The vendor shall identify and propose additional or substitute tools (with rationale) required above and beyond Platform One that the vendor will procure and operate.

3.10.5.18.3 The vendor shall provide an option for 50 Government personnel access licenses for any vendor requirements, architecture or DevSecOps tools needed.

3.11 TestingIncremental Government testing occurs outside of the agile process and will typically be associated with delivery of a program increment, MVP, MVCR, and subsequent software releases. Incremental Government testing includes

TA/Functional Verifications (FV) User Assessments (UA) Operational Testing (OT) Verification, Validation, and Accreditation (VV&A) Logistics Demonstration/Maintenance Evaluations (LD/ME)

3.11.1 Incremental Government Testing3.11.1.1 The vendor shall enable, participate, and support continuous and incremental

Government testing that supplements Agile process and DevSecOps testing.

3.11.1.2 The vendor shall provide software and hardware to support incremental Government testing.

3.11.1.3 The vendor shall provide manuals and training support package for UA, OT, and VV&A in accordance with the deliverables (3.8.3.7 and 3.8.3.8).

3.11.1.4 The vendor shall develop test and evaluation plans shall include an incremental test strategy in accordance with the deliverables (3.8.2.7 and 3.8.2.8).


16931694

16951696169716981699170017011702

1703

17041705

17061707

1708

170917101711

17121713171417151716

1717

17181719

17201721

17221723

17241725

3.11.1.5 The vendor shall allow the Government to review vendor test plans and metrics and to provide input on vendor testing methods to ensure the usability of vendor test data for Government purposes.

3.11.1.6 The vendor shall provide the Government access to the vendor’s test plans, testing, and test results to reduce the government test burden in accordance with deliverables (3.8.2.7, 3.8.2.8, and 3.8.2.9).

3.11.1.7 The vendor shall support Government training effectiveness assessments during the User Assessments to inform vendor design and performance trades.

3.11.1.8 The vendor shall document test/assessment objectives and known limitations for all STE system capability and interface vendors in accordance with the deliverables (3.8.2.7, 3.8.2.8, and 3.8.2.9).

3.11.1.9 The vendor shall meet the following program increment test and assessment entry criteria:

3.11.1.9.1 The vendor shall pass automated unit tests as entry criteria for verification and integration test events at the STE TIF.

3.11.1.9.2 Configuration of system under test has been defined and agreed to. All interfaces have been placed under configuration management or have been defined in accordance with an agreed to plan and a Software Version Description Document has been made available 10 days prior to completion of the software release.

3.11.1.9.3 All applicable functional, unit level, subsystem, system, and qualification testing has been conducted successfully.

3.11.1.9.4 All test and assessment reviews specific materials such as Government approved test plans, cases, and procedures have been available to all participants prior to conducting the review.

3.11.1.9.5 All known system discrepancies have been identified and resolved in accordance with an agreed to plan.

3.11.1.9.6 All previous design review exit criteria and key issues have been satisfied in accordance with an agreed to plan.

3.11.1.9.7 All required test resources (people, facilities, test articles, test instrumentation) have been identified and are available to support required tests.

3.11.1.9.8 Roles and responsibilities of all test participants are defined and agreed to.

3.11.1.9.9 All applicable Cyber security requirements have been met (e.g., Interim Authority to Test approved).


172617271728

172917301731

17321733

173417351736

17371738

17391740

1741174217431744

17451746

174717481749

17501751

17521753

17541755

1756

17571758

3.11.1.10 The vendor shall provide the following program increment test and assessment entry criteria:

3.11.1.10.1 All Action Items to document situations and possible action where the technical approach does not appear to meet the specification requirement have been addressed, assessed, and agreed upon.

3.11.1.10.2 Were all the required independent evaluators involved and do they concur with the planned tests, expected results?

3.11.1.10.3 Adequate test plans completed and approved for the system under test.

3.11.1.10.4 Previous component, subsystem, system test results form a satisfactory basis for proceeding into planned tests.

3.11.1.10.5 Risk level identified and accepted by Program leadership as required.

3.11.2 Integration Environment3.11.2.1 The vendor shall use the Government Technology Integration Facility (TIF) for integration,

demonstrations, assessments, and test and evaluations that replicates conditions of the operational environment.

3.11.2.2 The vendor shall use the Government integration environment at the Joint Development and Integration Facility (JDIF) for classified (up to SECRET, SECRET REL, SECRET NATO) integration, demonstrations, assessments, and test and evaluations.

3.11.3 Development Testing3.11.3.1 The vendor shall develop a sprint and increment level test and evaluation plan NLT 30

days after contract award for the Government to approve in accordance with the deliverables (3.8.2.7, 3.8.2.8, and 3.8.2.9).

3.11.3.1.1 The vendor shall update the test and evaluation plan NLT 30 days into each program increment, MVP, MVCR and subsequent software releases in accordance with the deliverables (3.8.2.7, 3.8.2.8, and 3.8.2.9).

3.11.3.1.2 The test and evaluation plan shall address development testing, component testing, integration testing, sprint demonstrations, program increment demonstrations, MVP, MVCR, subsequent software release demonstrations of the integrated STE solution.

3.11.3.1.3 The vendor test and evaluation plan shall establish an integration and testing roadmap/plan with events/touchpoints and coordinate STE system capability and interface vendors dependencies through the Government.


17591760

176117621763

17641765

1766

17671768

1769

1770

177117721773

177417751776

1777

177817791780

178117821783

1784178517861787

178817891790

3.11.3.1.4 The vendor test and evaluation plan shall include the Government in sprint cycles that include other vendors.

3.11.3.1.5 The vendor shall develop a RTM that traces all system requirements and features allocated to a given sprint, program increment, MVP, MVCR or subsequent software release; vendor provided, and Government approved test procedures; and vendor provided and Government approved measures of success.

3.11.3.1.6 The vendor shall support Environmental testing by providing hardware test assets and possible onsite support as required at an approved DoD/Army test agency facility.

3.11.4 Cybersecurity Tests and Events3.11.4.1 The vendor shall support development of a multi-phased, test timeline and cyber test and

evaluation plan in accordance with the deliverables (3.8.2.7, 3.8.2.8, and 3.8.2.9).

3.11.4.2 The vendor shall adhere to the Director, Operational Test & Evaluation (DOT&E) Procedures for Operational T&E of Cybersecurity in Acquisition Programs Memorandum.

3.11.4.3 The vendor shall participate in and support Cybersecurity DT Events.

3.11.4.3.1 The vendor shall support Combat Capabilities Development Command Data and Analysis Center (CCDC-DAC) in coordination with (ICW) PM (Blue Team) and AEC Cooperative Vulnerability Identification (CVI) testing and provide the test data to the Government NLT 5 calendar days after the events in accordance with the deliverable (3.8.1.2).

3.11.4.3.2 The vendor shall support the Threat System Management Office (TSMO) ICW PM (Red Team) and AEC Adversarial Cyber Developmental Tests (ACDT) and provide the test data to the Government NLT 5 calendar days after the events in accordance with the deliverables (3.8.1.2).

3.11.4.3.3 The vendor shall provide Verification of Fixes (VoF’s) event(s) NLT 10 calendar days after the test is completed in accordance with the deliverables (3.8.1.2).

3.11.4.4 The TSMT shall undergo Cybersecurity Operational Test events.

3.11.4.4.1 The vendor shall support Cooperative Vulnerability Penetration Assessments (CVPA) and provide CVPA test data to the Government NLT 10 calendar days after the test is completed in accordance with the deliverables (3.8.1.2).

3.11.4.4.2 The vendor shall support Adversarial Assessments (AA) and provide AA data to the Government NLT 10 calendar days after the assessment is completed in accordance with the deliverables (3.8.1.2).

3.11.4.4.3 The vendor shall support ATEC/AEC evaluations IAW the DOT&E Procedures for Operational T&E of Cybersecurity in the Acquisition Programs Memorandum.


17911792

1793179417951796

17971798

1799

18001801

18021803

1804

18051806180718081809

1810181118121813

18141815

1816

181718181819

182018211822

18231824

3.12 Product SupportWhile each STE system will have their independent sustainment strategy, the STE system capability vendor’s sustainment concept shall provide interfaces to allow integration of operation and sustainment as a system of systems.

3.12.1 General3.12.1.1 The vendor shall safeguard, securely store, and track government furnished property

(GFP) (i.e., GFI and GFE). Contractor Acquired Property (CAP) shall be considered as GFP and will be added to the GFP list after presentation of the DD250. The vendor can request additional GFI/GFE and the Government will evaluate and determine applicability.

3.12.1.2 The vendor shall perform the following to ensure positive control and safety of Government furnished items:

a. Examine upon receipt, consistent with practicality, to detect damage

b. Provide storage that precludes deterioration

c. Examine prior to installation, consistent with practicality, to detect damage

d. Identify and protect from improper use or disposition

e. Verify and audit quantities every quarter with 100% inventory annually

3.12.1.3 The vendor shall provide a data library of source documentation and data used to create the TSMT system and document it in accordance with the deliverable (3.8.3.20)

3.12.1.4 The vendor shall participate in the Government led incremental logistics demonstrations/maintenance evaluations.

3.12.1.5 The vendor shall design the Product Support to support a third-party maintainer.

3.12.1.5.1 The system vendor shall provide transition of product support to another provider at the end of the contract period of performance.

3.12.1.6 The system vendor shall provide sustainment projections for the lifecycle management and affordability of the TSMT solution.

3.12.2 Interim Contractor Support

3.12.2.1 The vendor shall provide ICS starting with first hardware delivery to the Government and continue for at least 24 months after the final release of capability in accordance with contract options.


1825

182618271828

1829

18301831183218331834

18351836

1837

1838

1839

1840

1841

18421843

18441845

1846

18471848

18491850

1851

185218531854

3.12.2.2 During the ICS period, the vendor shall repair/replace, as directed by the Government, defective TSMT hardware, this includes performing warranty actions as needed.

3.12.2.3 During the ICS Period, the vendor shall process bug reports, conduct preventative and corrective maintenance, patch, and update delivered software as required.

3.12.2.4 The vendor shall document TSMT system ICS in accordance with the deliverables (3.8.3.2, 3.8.3.5, 3.8.3.11, and 3.8.3.14).

3.12.2.5 During the ICS period, the vendor shall provide sufficient data in accordance with the deliverables (3.8.3.2 and 3.8.3.11) to enable an analysis to determine core logistics capabilities and sustainment support requirements.

3.12.2.6 During the ICS period, the vendor shall document and provide to the Government technical data on systems issued to the field to inform improvements prior to making production decisions.

3.12.2.7 During the ICS period, the vendor shall provide Helpdesk support.

3.12.2.8 During the ICS period, the vendor shall track and document maintenance actions and identify system configuration issues in accordance with the deliverables (3.8.3.2 and 3.8.3.26).

3.12.3 Maintenance Planning/Concept3.12.3.1 The vendor shall develop and provide a LORA in accordance with the deliverable

(3.8.3.3).3.12.3.2 The vendor shall develop and provide a FMECA in accordance with the deliverable

(3.8.3.4)

3.12.3.3 The vendor shall provide a prognostic health monitoring system that provides for continuous prognostic and preventative maintenance.

3.12.3.4 The vendor shall provide remote diagnostic capability to allow helpdesk troubleshooting and corrective actions.

3.12.3.5 The vendor shall provide an automated built-in-test (BIT) functionality that runs at system startup and as selected by the maintainer/helpdesk.

3.12.3.6 The vendor shall develop and document a 2-level maintenance concept that considers current field maintenance capabilities, and training audience level in accordance with the deliverables (8.3.11 and 8.3.14).

3.12.3.7 The vendor shall maintain and document software using the DevSecOps process.


18551856

18571858

18591860

186118621863

186418651866

1867

186818691870

1871

18721873

18741875

18761877

18781879

18801881

188218831884

1885

3.12.3.8 The vendor shall recommend a spares package to meet operational availability and material availability for TSMT Hardware issued to the TIF, Operational Test, and the fielded locations.

3.12.3.8.1 The vendor shall procure and deliver the spares packages to the appropriate locations upon receiving Government approval.

3.12.3.1 The vendor shall document and provide failure data to inform Reliability, Availability, and Maintainability (RAM) to enable maintenance analysis in accordance with the deliverables (3.8.3.2 and 3.8.3.26).

3.12.4 Warranty3.12.4.1 The vendor shall track and document warranties in accordance with the deliverable

(3.8.3.28).

3.12.4.2 The vendor shall provide no cost warranty transfer to the Government or third-party maintainer.

3.12.4.3 The vendor shall purchase, as applicable, transferable extended warranties to coincide with the duration of the ICS period.

3.12.5 Configuration Audits3.12.5.1 Configuration Audits – Functional

3.12.5.1.1 The vendor shall satisfy FCA requirements by successfully completing Operational Testing (see Section 3.11.1)

3.12.5.2 Configuration Audits – Physical 3.12.5.2.1 The vendor shall satisfy the following PCA entry criteria prior to initiating the PCA

processesa. Training system hardware design is complete except for the shortages /

deviations / waivers and has been captured in the final released engineering data and associated lists.

b. Trainer hardware installation is complete for conduct of the auditc. The vendor shall provide the Government a compiled listing of all shortages /

deviations / waivers and status of ECPs available.d. Contractor and sub-contractor released Product Engineering Design Data and

Associated Lists are complete and available to the Government at the beginning of the joint PCA.

e. A complete trainer drawing tree depicting the parent to child relationship of all drawings (contractor and subcontractor) has been delivered to the Government.


188618871888

18891890

189118921893

1894

18951896

18971898

18991900

1901

1902

19031904

1905

19061907

190819091910

1911

19121913

191419151916

191719181919

f. Technical publications, Logistics Product Data (LPD) operator and maintenance manuals, TSSD, and provisioning list, including redlines, are complete and available to the Government at the joint PCA

g. Government / vendor IPT participation has been coordinated.3.12.5.2.2 The vendor shall conduct PCAs with the Government, on the as built TSMT

system with power off, that will consist of non-functional examinations performed IAW the Government accepted Test and Evaluation Plan to demonstrate that the TSMT as-built design and that the deliverable hardware and software documentation accurately reflect the CI.

3.12.5.2.3 The vendor shall provide non-deliverable documents in contractor format as needed to determine vendor compliance with configuration management (CM) requirements.

3.12.5.2.4 The vendor shall certify, prior to the start of PCA examinations, that all electrical power, including UPS systems, have been disconnected and de-energized.

3.12.5.2.5 The vendor shall comply with the Occupational Safety and Health Administration (OSHA) lockout-tag out requirements specified in 29 CFR 1910.147.

3.12.5.2.6 The vendor shall provide the personnel, equipment, and facilities necessary to support the Government-conducted examinations.

3.12.5.2.7 The vendor shall be responsible for the disassembly, as required, of the Line Replaceable Units (LRU) for access to TSMT equipment.

3.12.5.2.8 The vendor shall record the results of the PCA examinations in accordance with the deliverable (3.8.3.28)

3.12.5.2.9 The vendor shall satisfy the following PCA exit criteria prior to closing out the PCA:a. All contractor and subcontractor released Product Engineering Design Data

and Associated Lists were provided to the Government for audit.b. Contractor has captured and entered all Government discrepancy reports in

the tracking database.3.12.5.3 Configuration Audits – Software3.12.5.3.1 For each software item, software configuration audits shall be conducted by the

vendor for each baseline and witnessed by the Government. 3.12.5.4 The vendor shall present a detailed plan for performing configuration audits prior to

release of the baseline in accordance with the deliverable (3.8.3.29)

3.12.6 Diminishing Manufacturing Sources and Material Shortages 3.12.6.1 The vendor shall identify, document, and manage DMSMS in accordance with the

deliverable (3.8.3.14).


192019211922

1923

19241925192619271928

192919301931

19321933

19341935

19361937

19381939

19401941

1942

19431944

19451946

1947

19481949

19501951

1952

19531954

3.12.6.2 The vendor shall use an automated tool to aid in equipment selection and track and manage DMSMS.

3.12.7 Technical Support Documentation3.12.7.1 The vendor shall integrate the technical documentation (e.g. System/Software User

Manuals, Operator Manuals, COTS manuals, Maintenance Manuals, engineering data, programmatic data, etc.) from OWT, SVT, SiVT and RVCT into the TSMT system technical documentation providing a single source of integrated technical documentation.

3.12.7.2 The vendor shall host and participate in Government led in-process reviews at 40% and 80% of document completion in accordance with the entry and exit criteria.

3.12.7.3 The vendor shall conduct a validation of the Technical Documentation, participate in a Government run verification of the Technical Documentation, and report it in accordance with the deliverables (3.8.3.12 and 3.8.3.23).

3.12.7.4 The vendor shall provide the Technical Documentation in interactive electronic format in accordance with the deliverables (3.8.3.1, 3.8.3.6, 3.8.3.7, and 3.8.3.8).

3.12.7.5 The vendor shall document all COTS items and modified COTS items in accordance with deliverable (3.8.3.1).

3.12.7.6 The vendor shall document and provide a process to reboot the TSMT hardware in accordance with the deliverables (3.8.3.7, and 3.8.3.8).

3.12.7.7 The vendor shall develop and publish a STE DevSecOps Integrated Operations Guide in accordance with the deliverable (3.8.3.6).

3.12.7.8 The vendor shall provide integrated engineering data and software flow diagrams in the Technical Documentation in accordance with the deliverables (3.8.3.9, 3.8.3.10, and 3.8.3.11).

3.12.7.9 The vendor shall document common and special tools and test equipment, if applicable, in the Technical Documentation in accordance with the deliverables (3.8.3.7 and 3.8.3.11).

3.12.7.10 The vendor shall include integrated supporting documentation for the maintenance and operation training tools in the Technical Documentation in accordance with the deliverable (3.8.3.15).

3.12.8 Training3.12.8.1 The vendor shall integrate TSMT training products with training products from other STE

system vendors and document the training in accordance with the deliverables (3.8.3.15, 3.8.3.17, 3.8.3.23, 3.8.3.24, and 3.8.3.25).

3.12.8.2 The vendor shall provide sufficient perpetual licenses for any commercial products used in the TSMT training development, modification, and presentation.


19551956

1957

1958195919601961

19621963

196419651966

19671968

19691970

19711972

19731974

197519761977

197819791980

198119821983

1984

198519861987

19881989

3.12.8.3 The vendor shall provide a STE system NET “train the trainer” course for instructors/trainers and maintainers.

3.12.8.3.1 The vendor shall provide the STE NET courses at five locations as identified in the fielding locations table.

3.12.8.3.2 The vendor shall accommodate a maximum of ten students for each STE NET course including student course materials.

3.12.8.4 The vendor shall develop and document specific task videos covering critical and infrequent tasks for use as refresher and just in time training in accordance with the deliverables (3.8.3.15 and 3.8.3.25).

3.12.8.5 The vendor shall develop, document, and embed in the TSMT system applications for use by the intelligent tutoring system to provide just in time and refresher training in accordance with the deliverables (3.8.3.15 and 3.8.3.23).

3.12.9 Item Unique Identification3.12.9.1 The vendor shall apply and register Government approved Item Unique Identification

labels to all material that will be delivered to the Government in accordance with MIL-STD-130 and the deliverable (3.8.3.16).

3.12.10 System Delivery3.12.10.1 The vendor shall assist the Government with coordination of system delivery.

3.12.10.2 The vendor shall assist with the preparation of system delivery documentation.

3.12.10.3 The vendor shall prepare briefing slides documenting the system delivery process for each site.

3.12.10.4 The vendor shall conduct site surveys with the Government to determine suitability of the TSMT system delivery location and any adjustments to the TSMT system configuration that will be required prior to delivery.

3.12.10.5 The vendor shall participate in telephone Site Readiness Review meetings as determined by the Government to coordinate with the TSMT system receiving site in the months prior to delivery.

3.12.10.6 The vendor shall conduct site installation.

3.12.10.7 The vendor shall conduct site testing.

3.12.10.8 The vendor shall conduct site training.

3.12.10.9 The vendor shall conduct site daily reporting.


19901991

19921993

19941995

199619971998

199920002001

2002

200320042005

2006

2007

2008

20092010

201120122013

201420152016

2017

2018

2019

2020

3.12.10.10 The vendor shall conduct site daily briefs.

3.12.10.11 The vendor shall cleanup and remove debris left over from the installation activities prior to departing the installation site.

3.12.10.12 The vendor shall be responsible for repair of any damage caused by their personnel or equipment during the installation activities.

3.12.10.13 The vendor shall incrementally demonstrate the product support processes with the resources needed to operate and sustain the system during TAs, UAs, and Operational Tests.

3.12.10.13.1 The vendor shall incrementally demonstrate the documented TSMT setup procedures during the TAs, UAs, and Operational Tests.

3.12.10.13.2 The vendor shall incrementally demonstrate the documented procedures for execution of a mission during the TAs, UAs, and Operational Tests.

3.12.10.13.3 The vendor shall incrementally demonstrate representative field and depot maintenance (using the technical documentation) that returns the TSMT from failure to full operating status during the TAs, UAs, and Operational Tests.

3.12.10.13.4 The vendor shall incrementally demonstrate preparing the TSMT system for transportation during the TAs, UAs, and Operational Tests.

3.12.10.13.5 The vendor shall incrementally demonstrate the storage process during the TAs, UAs, and Operational Tests.

3.12.10.13.6 The vendor shall incrementally demonstrate the shipping processes during the TAs, UAs, and Operational Tests.

3.13 Security3.13.1 Industrial SecurityAny contractor (prime or sub) that is a Foreign Owned, Controlled, or Influenced (FOCI) company that does not have their FOCI mitigated by the Defense Counterintelligence and Security Agency (DCSA) and who does not possess a Facility Clearance Level (FCL) by submission of their Demonstration Plan, cannot prime this contract.

3.13.1.1 The vendor shall meet security requirements as instructed in form DD254.

3.13.1.2 The vendor shall develop a TSMT system that complies with the RMF, the cybersecurity plan, and local security policies.


2021

20222023

20242025

202620272028

20292030

20312032

203320342035

20362037

20382039

20402041

2042

2043

2044204520462047

2048

20492050

3.13.1.3 The highest level of classification required for this effort is: SECRET / SECRET REL. The multiple nodes exist in a variety of security enclaves, including unclassified, SECRET, and SECRET REL.

3.13.1.4 The vendor shall meet all applicable security requirements for protecting controlled unclassified information and secret information.

3.13.2 CybersecurityTSMT complies with applicable DoD Cyber Survivability Endorsement, Volumes I-III, Cyber Survivability Endorsement Implementation Guide and establishes safeguards IAW all cybersecurity related policies, regulations, and the DoD’s best business practices to include:

DoDI 8500.01Cybersecurity DoDI 5200.44 Protection of Mission Critical Functions to Achieve Trusted

Systems and Networks (TSN) AR 25-2 DoDD 8140.01 Cyberspace Workforce Management DoD 8570.01-M Information Assurance Workforce Improvement Program DA PAM 25-2-6 Cybersecurity Training and Certification DA PAM 25-2-7, Army Information System Privileged Access NIST 800-171, Protecting Controlled Unclassified Information in Nonfederal

Systems and Organizations

See Appendix G Cybersecurity for the CDS phases flowchart.

3.13.2.1 Cyber Survivability3.13.2.1.1 The vendor shall comply with DoD Cyber Survivability Endorsement, Volumes I-

III, Cyber Survivability Endorsement.3.13.2.1.2 The vendor shall respond to cybersecurity tasking orders, as directed by the

Government, provided by organizations such as NETCOM's 7th Signal Command, DOD CIO G6 and US Cyber Command.

3.13.2.1.3 The vendor shall manage vulnerabilities to maintain cyber survivability capabilities (e.g., automated patch management, mitigation of known threats, and effects of obsolescence).

3.13.2.2 Risk Management Framework


205120522053

20542055

2056

2057205820592060

2061206220632064206520662067206820692070

2071

2072

20732074

207520762077

207820792080

2081

3.13.2.2.1 The vendor shall comply with all required DoD and Army regulations (e.g., DoDI 8510.01 RMF for DoD IT, Committee on National Security Systems Instruction (CNSSI) 1253, the National Institute of Standards and Technology (NIST) SP 800-53, and Army Regulation AR 25-2) to implement and document the cybersecurity requirements, processes, and procedures to meet the Confidentiality, Integrity, and Availability impact levels of Moderate-Moderate-Low.

3.13.2.2.2 The vendor shall mitigate or fix all category 1 (CAT1) noncompliance items within 30 days of submission to the Package Approval Chain.

3.13.2.2.3 The vendor shall be Army Endpoint Security System (AESS) compliant. 3.13.2.2.4 The vendor shall develop and maintain the functional architecture/topology

diagram, authorization boundary diagram, and data flow diagram, using the NETCOM template format in accordance with the deliverables (3.8.2.2).

3.13.2.2.5 The vendor shall review and support the system categorization.3.13.2.2.6 The vendor shall plan, resource, and document the RMF Assessment and

Authorization (A&A) for the test and development enclaves and fielding sites IAW Table 3-2 and Table 3-3.

3.13.2.2.7 The vendor shall produce all components of the required RMF packages (i.e. IATT, ATO) necessary to test, develop, deliver, and operate an authorized system in accordance with the deliverables (3.8.1.2).

3.13.2.2.8 The vendor shall evaluate and document all system, interfaces and network changes that impact security in accordance with the deliverables (3.8.1.2).

3.13.2.2.9 The vendor shall develop and maintain the system cybersecurity artifacts required by RMF, DoD, DoDI, and NIST regulations, guidelines, and controls (e.g., Security Plan (SP), Continuity of Operations Plan (COOP), Contingency Plan (CP), Incident Response Plan (IRP), CMP, Standard Operating Procedures (SOP), eMASS Control Self-Assessment test results input, Ports, PPSM document) in eMASS in accordance with the deliverables (3.8.1.2).

3.13.2.2.10 The vendor shall create and maintain the System RMF authorization documentation, processes, and assessments in eMASS to achieve the fielding and DT&I sites RMF Authorizations (i.e. IATT, ATO) in accordance with the deliverables (3.8.1.2). Note: Secure Internet Protocol Routing (SIPR) eMASS instance is required for classified systems.

3.13.2.2.11 The vendor shall complete the eMASS RMF Implementation Plan in accordance with the deliverables (3.8.1.2).

3.13.2.2.12 The vendor shall develop a Continuous Monitoring Plan and update the System-level Continuous Monitoring (SLCM) Strategy in eMASS in accordance with the deliverables (3.8.1.2).


208220832084208520862087

20882089

2090

209120922093

2094

209520962097

209820992100

21012102

210321042105210621072108

21092110211121122113

21142115

211621172118

3.13.2.2.13 The vendor shall input RMF data into eMASS; ports, protocols, and services management (PPSM) registry, Army Portfolio Management Solution (APMS) and other database repositories as required by DoD directives and instructions in accordance with the deliverables (3.8.1.2).

3.13.2.2.14 The vendor shall develop and maintain a hardware and software lists in eMASS that includes version(s), vendor(s), vendor addresses, vendor phone numbers, release dates, license(s), certifications dates, termination or authorization dates, and authorization expiration dates in accordance with the deliverables (3.8.1.2).

3.13.2.2.15 The vendor software development and integration shall comply with RMF practices and guidelines for the Enclave Test and Development (T&D) Security Technical Implementation Guide (STIG) to achieve Development, Test, and Integration (DT&I) environment RMF authorizations (i.e., IATT and ATO) for the management and storage of TSMT related data. Note: DT&I environment RMF authorization is required to host or interoperate with GFE/GFI products such as MCIS, software applications such as LVC-IA, and authoritative data sources such as ATIS. DT&I environment RMF authorization is required to establish external connections with the Federal, State, and University Network (FEDSUN) that provides access to the Defense Research Engineering Network (DREN) and NIPRNET.

3.13.2.2.16 The vendor shall coordinate with the Government to obtain the TSMT system authorization from the AO 30 days prior to deploying to test and development enclaves and fielding sites IAW Table 3-2 and Table 3-3.

3.13.2.2.17 The vendor shall employ current Army Best Practice scanning and remediation monthly.

3.13.2.2.18 The vendor shall ensure log files and audits are collected, maintained, and reviewed for all systems.

3.13.2.2.19 The vendor shall audit authentication policies (e.g., password) policies for compliance.

3.13.2.2.20 The vendor shall review Audit Logs for alarms. 3.13.2.2.21 The vendor shall ensure the Information Assurance Vulnerability Alert (IAVA) and

STIGs can be applied individually when needed without the need to re-image the system.

3.13.2.2.22 The vendor shall develop an automated patch management plan that includes IAVA implementation by due date.

3.13.2.2.23 The vendor shall implement all hardware, network, and software STIGs. 3.13.2.2.24 The vendor shall develop an automated patch management plan that implements

new DISA STIGs NLT 30 days after the STIG release. Note: DISA releases updates and new STIGS on a 90-day cycle.


2119212021212122

2123212421252126

2127212821292130213121322133213421352136

213721382139

21402141

21422143

21442145

2146

214721482149

21502151

2152

215321542155

3.13.2.2.25 The vendor shall document the system's Cybersecurity Deviation Report for Government approval for all updates that cannot be applied within 30 days in accordance with the deliverable (3.8.1.2).

3.13.2.2.26 The vendor shall report all IAVA, STIGs, and Bulletins in a system Plan of Action and Milestone (POA&M) that includes a list those implemented, those not implemented, justification for items not implemented, and mitigation for those not implemented at least monthly, or more frequent if directed by the local AO.

3.13.2.2.27 The vendor shall document all IAVA, STIGs, Bulletins, and security control implemented, not implemented, justification for items not implemented, impacts, and mitigations in the POA&M in eMASS at least monthly, or more frequent as directed by the local AO.

3.13.2.2.28 The vendor shall ensure cybersecurity posture and accreditation boundaries are not impacted during support and maintenance.

3.13.2.2.29 The vendor shall ensure that security changes do not invalidate any authorized accreditation.

3.13.2.3 Cross Domain Solution Authorization (CDSA)3.13.2.3.1 The vendor shall design, use, and support the authorization of the selected CDS

in a secure, enterprise environment IAW DoDI 8540.01 and Chairman Joint Chiefs of Staff Instruction (CJCSI) 6211.02D.

3.13.2.3.2 The vendor shall define data flowing through the CDS within 60 days of OTA award to support ACDMO questionnaires for Phase 1.

3.13.2.3.3 The vendor shall support the CDSA waiver artifact development, testing, and authorization processes for each required security.

3.13.2.4 Cybersecurity Incident Reporting3.13.2.4.1 The vendor shall develop a program IRP in compliance with PEO STRI and Army

IRP procedures NLT 30 TBD days after contract.3.13.2.4.2 The vendor shall comply with the IRP when responding to a cybersecurity related

incident.3.13.2.5 Cybersecurity Training

3.13.2.5.1 The vendor shall deny access to DoD information systems when contractor personnel do not have proper and current certifications.

3.13.2.5.2 The vendor shall ensure that System Administrators and Network Administrators meet the minimum requirements for technical category Level II (IAT Level II) and workforce management category Level I (Information Assurance Manager [IAM] Level I) as defined by DoD 8570.01-M.


215621572158

2159216021612162

2163216421652166

21672168

21692170

2171

217221732174

21752176

21772178

2179

21802181

21822183

2184

21852186

2187218821892190

3.13.2.5.3 The vendor shall verify employees have at least 3 years' cybersecurity or related experience (e.g., operating systems, network devices, database) for the system being managed at the moment of hiring.

3.13.2.5.4 The vendor shall have up to six months to obtain the remaining employee certification or training qualifications for their position in accordance with DoD 8570.01-M.

3.13.2.5.5 The vendor shall verify that all TSMT vendor and sub-vendor cybersecurity personnel manage their training and certification through the Army Training and Certification Tracking System (ATCTS) found at https://atc.us.army.mil.

3.13.2.5.6 The vendor shall provide the Government verification that Cybersecurity/IT personnel meet the baseline certification requirements established in the DoD 8570.01-M and DoDD 8140.01 Cyberspace Workforce Management for the category and level functions in which they are performing by contract award and update monthly after contract. Approved baseline certifications and a list of cybersecurity workforce certification providers is available at: https://public.cyber.mil/cw/cwmp/dod-approved-8570-baseline-certifications/.

3.13.2.5.7 The vendor's Information System Security Manager (ISSM) shall appoint in writing TSMT cybersecurity personnel and provide to the Government NLT 10 days after contract award and update monthly accordance.

3.13.2.5.8 The vendor shall document information assurance certification status for TSMT personnel performing information assurance functions and provide to the Government NLT 10 days after contract award and update monthly.

3.14 Safety and HealthThe vendor complies with Federal, State, and local environmental laws and regulations, Executive Orders, treaties, and agreements required to maintain a safe and non-hazardous occupational environment. The TSMT design complies with all applicable safety and health requirements prevent any uncontrolled safety and health hazards to the operator or maintenance personnel throughout its life cycle. The TSMT design and operational characteristics minimizes the possibilities for accidents or mishaps caused by human error or system failure.

3.14.1 Safety3.14.1.1 The vendor design shall be compliant with the following standards and publications to

optimize system performance and t to prevent safety, health, environmental, ergonomic, and software/firmware (to include modifications updates and new system interfaces) hazards.

MIL-STD-1472, Human Engineering Design Criteria, Principles, and Practices:66


219121922193

219421952196

219721982199

2200220122022203220422052206

220722082209

221022112212

2213

2214221522162217221822192220

2221

2222222322242225

2226

https://atc.us.army.mil/

MIL-STD-882E, DoD Standard Practice, System Safety. DA PAM 385-30, Safety Risk Management Technical Bulletin (TB) 43-0134

(Battery Disposition and Disposal AR 385-10 The Army Safety Program and Army Pamphlet (DA Pam) 385-16

System Safety Management Guide

3.14.1.2 The vendor shall document all known software and hardware hazards using the US Army Risk Management process in a Hazard Tracking Log and provide to the Government.

3.14.1.3 The vendor shall provide data required for event safety releases not later than 20 calendar days prior to Soldier involved assessment events in accordance with the deliverables (3.8.2.13).

3.14.1.4 The vendor shall provide a Safety Assessment Report that quantifies all known hazards IAW MIL-STD 882E in accordance with the deliverables (3.8.2.13).

3.14.1.5 The vendor shall provide a safety lead to participate in the program System Safety Working Group.

3.14.2 Health3.14.2.1 The vendor shall provide a Health Hazard Assessment (HHA) to the Program Office and

prior to each program increment, MVP, MVCR, and subsequent software releases to identify, assess, and provide mitigation of potential health hazards as required by AR 40-10, Health Hazard Assessment Program in Support of the Army Acquisition Process.

3.14.2.2 The vendor HHA shall identify and assess health hazards associated with the life cycle management of materiel systems and provide recommendations to the Program Office to eliminate or control system hazards.

4 References# Reference Title Web Location

1 29 CFR 1910.147 “The Control of Hazardous Energy (Lockout/Tagout)” June 2011

https://www.energy.gov/sites/prod/files/2013/06/f1/29cfr-1910-147_ssm.pdf

2 ADP 5-0 “The Operations Process” 17 May 2012 https://armypubs.army.mil/ProductMaps/PubForm/ADP.aspx

3 ADRP 5-0 “The Operations Process” 17 May 2012 https://armypubs.army.mil/ProductMaps/PubForm/ADRP.aspx

4 AR 25-2 "Army Cybersecurity" 4 April 2019https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/ARN17503_AR25_2_Admin_FINAL.pdf

5 AR 40-10"Health Hazard Assessment Program in Support of the Army Acquisition Process" 27 July 2007

https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/AR%2040-10.pdf


22272228222922302231

22322233

223422352236

22372238

22392240

2241

2242224322442245

224622472248

2249

# Reference Title Web Location

6 AR 70-38“Research, Development, Test and Evaluation of Materiel for Extreme Climatic Conditions” 26 June 2020

https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN30017-AR_70-38-000-WEB-1.pdf

7 AR 385-10 "The Army Safety Program" 24 February 2017

https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/ARN16777_ARN16343_AR385_10_FINAL.pdf

8

Army Training and Certification Tracking System (ATCTS)

Army Training and Certification Tracking System (ATCTS) https://atc.us.army.mil

9 CADE Cost Assessment Data Element (CADE) website http://cade.osd.mil

10 Certifications Cybersecurity Workforce Certifications https://public.cyber.mil/cw/cwmp/dod-approved-8570-baseline-certifications/

11

Chairman Joint Chiefs of Staff Instruction (CJCSI) 6211.02D

“Defense Information Systems Network (DISN) Responsibilities” 24 January 2012 current 4 August 2015

https://www.jcs.mil/Portals/36/Documents/Library/Instructions/6211_02a.pdf?ver=2016-02-05-175050-653

12

Committee on National Security Systems Instruction (CNSSI) 1253

"Security Categorization and Control Selection for National Security Systems" 27 March 2014

https://www.dcsa.mil/portals/91/documents/ctp/nao/CNSSI_No1253.pdf

13

Cyber Survivability Endorsement Implementation Guide

Cyber Survivability Endorsement Implementation Guide

14 DA PAM 25-2-6 "Cybersecurity Training and Certification" 8 April 2019

https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/ARN16685_DAPam25_2_6_FINAL.pdf

15 DA PAM 25-2-7 Army Information System Privileged Access" 8 April 2019

https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/ARN17343_P25_2_7_Admin_FINAL.pdf

16 DA PAM 385-16 "System Safety Management Guide" 13 August 2013

https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/p385_16.pdf

17 DA PAM 385-30 "Safety Risk Management" https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/p385_30.pdf

18 DoD 8570.01-M"Information Assurance Workforce Improvement Program" 19 December 2005with change 4 10 November 2015

https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodm/857001m.pdf

19 DoD Agile Metrics Guide

"DoD Agile Metrics Guide, Strategy Considerations and Sample Metrics for Agile Development Solutions Version 1.1" dated 23 September 2019

https://www.dau.edu/cop/it/DAU%20Sponsored%20Documents/Agile%20Metrics%20v1.1%2020191122.pdf



20 DoD DevSecOps Reference Guide

“DoD Enterprise DevSecOps Reference Design Version 1.0” 12 August 2019

https://dodcio.defense.gov/Portals/0/Documents/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20v1.0_Public%20Release.pdf?ver=2019-09-26-115824-583

21

DoD Cyber Survivability Endorsement, Volumes I-III

DoD Cyber Survivability Endorsement, Volumes I-III

22 DoDD 8140.01"Cyberspace Workforce Management" 11 August 2015 with change 1 31 July 2017

https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodd/814001p.pdf

23 DoDI 8500.01 "Cybersecurity" 14 March 2014 with change effective 7 October 2019

https://www.esd.whs.mil/portals/54/documents/dd/issuances/dodi/850001_2014.pdf

24 DoDI 8510.01 "Risk Management Framework for DoD Information Technology” 28 Jul 2017

https://www.esd.whs.mil/Directives/issuances/dodi/

25 DoDI 8540.01 "Cross Domain Policy" 8 May 2015 with change 1 28 August 2017.

https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/854001p.pdf

26 DoDI 5200.44

"Protection of Mission Critical Functions to Achieve Trusted Systems and Networks" 5 November 2012, with change 3 15 October 2018

https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/520044p.pdf

27 DOT&E Memorandum

"Procedures for Operational T&E of Cybersecurity in Acquisition Programs" 3 April 2018

https://www.dote.osd.mil/Portals/97/pub/policies/2018/20180403ProcsForOTEofCybersecurityInAcqProgs(17092).pdf

28Enterprise Cloud Management Office (ECMO)

ECMO Policies and Strategies https://www.milsuite.mil/book/groups/enterprise-cloud-management-office-ecmo/overview

29 FM 7-0 “Train to Win in a Complex World” 5 October 2016

https://armypubs.army.mil/ProductMaps/PubForm/FM.aspx

30 MIL-STD-882E "DoD Standard Practice, System Safety" 11 May 2012

http://acqnotes.com/acqnote/tasks/mil-std-882e-system-safety

31 MIL-STD-1472G Change 1

“Human Engineering Design Criteria, Principles, and Practices w Change 1 17 January 2019

http://everyspec.com/MIL-STD/MIL-STD-1400-1499/MIL-STD-1472G_CHG-1_56051/

32MOSA Implementation Guide

"Modular Open Systems Approach (MOSA) Implementation Guide Version 1.0" 10 June 2020

33 MOSA Reference Frameworks

"Modular Open Systems Approach (MOSA) Reference Frameworks in Defense Acquisition Programs" May 2020

https://ac.cto.mil/wp-content/uploads/2020/06/MOSA-Ref-Frame-May2020.pdf


https://www.milsuite.mil/book/groups/enterprise-cloud-management-office-ecmo/overview




34 NIST SP 800-53

"National Institute of Standards and Technology (NIST) SP 800-53 Rev 5 Security and Privacy Controls for Information Systems and Organizations" September 2020

https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final

35 NIST SP 800-171

"National Institute of Standards and Technology (NIST) SP 800-171 Rev 2 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations" February 2020

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r2.pdf

36 PART Program Assessment Review Tool https://www.dau.edu/cop/mosa/lists/tools/allitems.aspx

38 TB 43-0134 "Battery Disposition, Handling and Disposal" 30 May 2018

https://liw.logsa.army.mil/etmapp/api/general/search/084893/0/pdf


2250

2251

2252

This page intentionally left blank.


2253

2254

2255

2256

2257

2258

2259

2260

2261

Appendix A Capability Descriptions

A.1 One World Terrain

One World Terrain delivers a 3D global terrain capability and associated information services that support virtual replication of the physical Earth and complexities of the operational environment in support of training as provisioned through the Army's Synthetic Training Environment and dynamically rendered at the point-of-need. Specifically, OWT provides a synthetic/virtual World representation that supports land, air, maritime, and space operations to facilitate multi-domain operations; a well-formed format that is consumable by standard commercial tools and technologies; automatic processing of raw terrain data into the well-formed format; and a terrain configuration management capability that incorporates approved geospatial information updates and local terrain surveys back into the OWT foundational repository.

A.2 Reconfigurable Virtual Collective Trainer

The RVCT hosts the physical platform elements (e.g., cyclic, collective pedals, steering wheels, switches). The RVCT physical controls will interface with the TSS API through the platform abstraction layer. The TSS will contain a functional virtual representation of the RVCT platforms. For example, the TSS will contain the inside of an Apache helicopter visually displaying the interior of the cockpit with all the switches needed for collective training being functional (think game console or PC game). The RVCT vendor will provide 3D interior platform models and supplement the TSS virtualized hardware components and functionality with physical hardware to create the appropriate fidelity for the RVCT end user.

RVCT Initial Operational Capability (IOC) and Full Operational Capability (FOC) Definitions for the current increment

IOC Definition and target date IOC attainment is projected to occur in Fiscal Year (FY) 2022, subject to change based on the rate of progress of development of the material solution. IOC is defined as the first fielding and acceptance of the RVCT capability by an installation. It is further defined as:

All RVCT components have completed the verification, validation and accreditation process prior to IOC.

All RVCT equipment is fielded to the first installation site and accepted.

All Information Assurance (IA) requirements are complete.


2262

2263

2264226522662267226822692270227122722273

2274

227522762277227822792280228122822283

22842285

2286228722882289

22902291

2292

2293

New Equipment Training (NET) at the first site is complete.

Network Enterprise capabilities are sufficient to support the STE-IS capabilities to include RVCT.

All product support requirements for RVCT operations and support are in place and ready to support unit training at the first site.

RVCT FOC Definition and target date

FOC attainment is projected to occur in FY 2027. FOC is achieved when the Basis of Issue Plan (BOIP) for the RVCT has been fielded to all sites (post, installation, armory, and institution) scheduled for fielding and all sites have accepted their associated RVCT equipment.

FOC is further defined as:

Meets or exceeds all threshold requirements All equipment associated with the RVCT has been fielded, in accordance with the

APO and BOIP. All IA requirements are complete. Network Enterprise capabilities to support the STE-IS capabilities, including

RVCT. New Equipment Training (NET) at all sites is complete. All product support requirements for RVCT operations and support are in place

and ready to support unit training at all sites. The RVCT sustainment plan is in place and being executed.

A.3 Live Virtual Constructive Integrating Architecture

LVC-IA is a net-centric linkage that collects, retrieves, and exchanges data among TADSS and Joint and Army Mission Command Systems. LVC-IA defines “how” information is exchanged among TADSS and Mission Command Systems. It enables the live, virtual, constructive training audience to see the common operating picture and to communicate using organizational command and control equipment. LVC-IA provides the common protocols, specifications, standards, and interfaces that help standardize common LVC components and tools required for interoperability of LVC components for simulations/stimulation (SIM/STIM) of unit MCS for training.


2294

22952296

22972298

2299

2300230123022303

2304

2305230623072308230923102311231223132314

2315

23162317231823192320232123222323

A.4 Mission Command Information Systems

The Army employs the Command Post Computing Environment (CPCE) in operations. It must do so also in training to help retain the knowledge and expertise in MCIS employment, contributing to the maintenance of (digital) readiness. Their inclusion in training is also consistent with the Army viewpoint of train as you fight.

The solution software system design shall seamlessly integrate and maintain concurrency with the COE, MCIS, and Operational Platforms. The software system design shall provide flexible, extensible data models and interfaces (i.e. API, Software Development Kits [SDK], Command Line Interfaces [CLI], Web Interfaces, and Graphical User Interfaces) that foster interoperability and integration while maintaining synchronization of data across all components of the STE. The solution software system design shall be loosely coupled to support the upgrade and, when necessary, the replacement of STE modules. The full list of MCIS is located within the TDP Appendix E SRD.

A.5 Avionics Software Emulation

AvSE is tactical or emulated software that provides the functionality of the Operational Flight Program (OFP) and flight model to simulate flying the aircraft. Each platform has a unique instantiation of the AvSE, and some include sensor models.

A.6 Common Software Library

The CSL is a software component for Army ground vehicle trainers which replicates vehicle functionality using vehicle source code. The process of creating a CSL removes hardware specific code to allow training devices to replicate vehicle functions and simulate vehicle performance using common PC hardware. Use of a CSL for vehicle trainers ensures high functional fidelity for the training audience and helps maintain concurrency with the current fielded platform.

A.7 Army Training Information System

The enterprise ATIS provides a common operational picture of the training environment through integrated, interoperable training development, management, scheduling, and delivery capabilities. These capabilities will enable Commanders, leaders, Soldiers, and civilians to better understand, visualize, describe, direct, lead, and assess training requirements so they can more effectively plan, prepare, execute, and assess training.


2324

2325232623272328

232923302331233223332334233523362337

2338

233923402341

2342

234323442345234623472348

2349

23502351235223532354

End result is a system that enables Soldiers to train as they will fight, so they can effectively fight as they have trained. ATIS includes the following five major capabilities:

Army Training Management Capability. Provides individual and collective training managers ability to manage Training & Education information, including military individual and collective training that supports mission tasks; provides users centralized access to unit training management and their individual training records.

Training Enterprise Scheduling Capability. Provides unit leaders, installation leaders, training managers, trainers, and instructors ability to submit and manage schedule requests for Training & Education resources, including transportation, classrooms, ranges, supplies, and mandated legal and social individual and unit training usage. Scheduling enabler for Training & Education.

Training Resource Management Capability. Provides leaders, training managers, training developers, trainers, and instructors ability to manage inventory and sustainability of Training & Education enablers (i.e. ranges, classrooms, simulators). Managerial enabler for tracking availability and utilization for Training & Education.

Army Training Development Capability. Provides training developers and training managers the ability to develop and coordinate Training & Education information, including training packages, training events, courses, and exercises in support of the training development enterprise.

Army Learning Content Management Capability. Provides trainers and instructors a single source to deliver Training & Education information, including educational and professional instruction, to students anytime, anywhere; provides users centralized access to Training & Education information necessary to conduct training missions. Provides trainers and instructors a single source to deliver Training & Education information, including educational and professional instruction, to students anytime, anywhere; provides users centralized access to Training & Education information necessary to conduct training missions

A.8 Soldier Virtual Trainer


23552356

2357235823592360

23612362236323642365

2366236723682369

2370237123722373

23742375237623772378237923802381

2382

The SVT will provide individual weapons skill development; enables Joint Fires training; and exercises Use of Force decision making. The SVT is enabled by the STE and is a virtual immersive trainer that combines and integrates several individual Soldier training capabilities, Weapon Skills Development (WSD), Joint Fires Training (JFT), and Use of Force (UoF), into a single capability that can be used simultaneously or individually. The WSD provides immersive capability to meet individual/crew weapons training in support of Army integrated weapon training strategies (IWTS). The JFT provides certification and qualification of Joint Fires Observers (JFO) IAW with TC 3-09.8. This includes the training of Joint Terminal Attack Controllers (JTAC) types I, II, and III close air support IAW TC 3-09.8 and the JFO and JTAC Memorandums of Agreement. Additionally, the SVT provides UoF training that enables Soldiers to exercise cognitive functions including rapid decision making and target acquisition under stress, including the introduction/removal of verbal interactions.

A.9 Integrated Visual Augmentation System / Soldier Immersive Virtual Trainer

The IVAS is an operational capability that uses mixed reality goggles, wearable compute, and a network bubble. PEO Soldier is the IVAS materiel developer. SiVT software provides the IVAS display an augmented reality view that enables the overlay of Synthetic objects (e.g., virtual soldiers and platforms) and effects (e.g., virtual cratering) on the real-world terrain. This converges Live and Synthetic training in the local training area (LTA). SiVT software adjudicates all activities in the 200-meter box in the stand-alone mode. When part of a larger training event, SiVT will interoperate with the TSS software on the TSMT Edge Node in the NEC. Details of this interoperability must be investigated.

A.10 STE Live Training System

The STE-LTS will enable a true representation of real combat to ensure a multi domain operation ready for force. The STE-LTS will integrate Live training with the STE and ensure interoperability with Joint and Coalition partners. The STE LTS will modernize both force on force and force on target training with the development of the 12 Engagements and 5 Instrumentations. The Engagement Types are: Direct Fire, Counter-Defilade Fire, Indirect Fire, Dropped Objects, Placed Objects, Thrown Objects, Guided and Autonomous Weapons, Direct Energy and Radiant Energy Weapons, Plumes, and Connections (Information Warfare). The "Plus 5" Instrumentation enablers are: Calculations, Network, Sensors, Terrains, and Transmitters. The STE-LTS will provide representation of soldier and weapon capabilities, vulnerabilities, and battlefield


2383238423852386238723882389239023912392239323942395

2396

2397

239823992400240124022403240424052406

2407

2408240924102411241224132414241524162417

effects from the individual Soldier up to the BCT level. This includes an appropriately sized and equipped OPFOR and will include Echelons above Brigade elements, as well as aviation and Special Operations Forces assets. The Twelve engagement types named above will be supported in near-real-time using the five instrumentation capabilities. Physics-based munition trajectory simulations will replace current MILES Probability of Hit (Ph)/Probability of Kill (Pk) tables. The STE-LTS will allow the simulation of all weapon systems in near-real-time; include virtual targets and player avatars in Synthetic Training Environments; and enable post-engagement AARs delivered to training units during training exercises. The STE LTS will replace the current live training capabilities to include home station and maneuver Combat Training Centers (CTC), and deployed training sites of instrumentation systems, engagement capabilities, and range systems. This future system will interface with the STE architecture in native manner; leveraging the Live Training Transformation (LT2) architecture, providing the seamless exchange of content between live and simulated virtual and constructive environments for purpose of integrated EXCON, AAR generation and delivery, Networked Targetry for training on all weaponry from Soldier to BCT echelons with EAB supporting elements and Networked Tactical Engagement Simulation System (TESS) capability collecting real-time Training Performance Data (TPD).


2418241924202421242224232424242524262427242824292430243124322433243424352436

2437

2438

Appendix B Objective Values

The TSMT PWS objective is to provide a Soldier/Squad through Brigade collective training capability that performs at least as proficient as the existing ITE and collective training capabilities (i.e., CCTT, AVCATT, and GFT) and a Brigade and below constructive staff training capability. The FOC is outside the scope of this Agreement, however, it is identified in this appendix as a “objective values” to provide a holistic STE vision. Objective values scale up to ASCC.

Table B-1. Objective Values.

ID Category Objective

OBJ 1Interoperability

The TSMT shall support the Intelligence Warfighting Function by interoperating with IEWTPT via APIs and appropriate classified networks (s).

OBJ 2 OWT3D Objects correctly attributed for simulation training and mission rehearsal needs.

OBJ 3 OWTIntegrate and Base globe Complete (World Geodetic System (WGS)-84, greater than 1m) to support full global coverage and mission rehearsal needs.

OBJ 4 OWTImplement OWT Data Model (logical, physical, and conceptual) and External interfaces / API defined that enable integration and information exchanges.

OBJ 5 OWTImport training and other locations glTF 3D tiles terrain set (enhanced base globe, 20cm to 1m).

OBJ 6 OWT Integrate High Resolution insets (Exterior, Interior, 20cm or better). OBJ 7 OWT Integrate and import vegetation biome point features.

OBJ 8 OWTOWT shall produce JLCCTC and Next Generation Constructive Capability terrain within 4 days (96 hours).

OBJ 9 OWT OWT produces terrain for and HITS via LVC-IA

OBJ 10 OWT

OWT rapid terrain capture shall ingest data from a Squad-equipped UAS (fixed or rotary-wing) with RGB cameras (1in sensor, 3x optical zoom) capable of 90 min flight time, autonomous flight planning and redundant, robust return-to-home features. Range of 15km. FMV-compatible (10 km range). 3-axis gimbal (pitch, roll, yaw)

OBJ 11 OWTOWT rapid terrain capture shall enable Point-of-need photogrammetric processing capabilities - i.e. local compute.

OBJ 12 OWTOWT rapid terrain capture shall enable Classification software to detect and extract features of interest: roads, surfaces, buildings, apertures, threads, change detection, urban clutter, people, vehicles, weapon systems

OBJ 13 OWTOWT rapid terrain capture shall enable Synchronization of data back to Enterprise Grid on both low and high side.

OBJ 14 OWTOWT rapid terrain capture shall enable Data outputs: gltf/3dtiles, kmz, ortho, dsm


2439

244024412442244324442445

2446


OBJ 15 TMT

The Training Management Tools are aligned with the DOD's Advanced Distributed Learning Initiative. The ADL created the Total Learning Architecture around common set of data standards, business rules, governance rules, and policies. By aligning the STE TMT to the TLA, CFT takes advantage of the background research and development needed to make a functional distributed training system at PON.

OBJ 16 TMT

TMT will use an intelligent tutoring system in support of training readiness execution and outcomes. The intelligent tutor may be initiated by a human or may be automated if the number of simultaneous trainees is too large for the available training managers to surveille effectively. The intelligent tutor will be able to assess current knowledge elements

OBJ 17 TMTThe TMT shall interoperate with real world mission command systems up to the ASCC (Joint/MN).

OBJ 18 TMTThe TMT shall interoperate with ATIS and other authoritative data sources to develop the training simulation.

OBJ 19 TMT

The TMT will have the ability to consume data from the other parts of the CSE, namely the RVCT - A/G/S to measure individual and unit performance measures. This data will be described in the TMT object data model (ODM) and stored in a common TMT database.

OBJ 20 TMT

For each event, a common TMT database will be the repository of data produced for that event. The data described in the extended training support package (TSP), such as Task Measures and Steps, will be analyzed to track unit training performance over time. The results from the data collected in the TSS will be stored in the TMT database and later transmitted to the ATIS for individual and collective record management.

OBJ 21 TMT

The TMT ODM will contain at a minimum all the data elements needed to create a TSP. The TMT ODM will also include all the data elements needed to support the calculation of readiness per the Standards of Training Performance in accordance with FM 7-0 and AR 350-1. This new data document will be referred to as an extended TSP.

OBJ 22 TMT

The vendor will document pedagogical guidance for how the TMT is to be used in an instructional setting. Instructional design will include guidance for scenario design, initialization and utilization of the intelligent tutoring system, and utilization of the after-action review software.

OBJ 23 TMT

The TMT shall support two operational modes. The preferred operational mode is cloud delivery know at "platform as a service", where the TMT is comprised of network-based applications that are pre-configured to work with the TSS, RVCT's, OWT, etc.

The second mode is a disconnected mode which an offline mode, where the network-based applications are hosted on local server assets but operate in an identical manner as the cloud delivery mode. In this mode of operation, all scenario and training data is housed on locally hosted storage until reconnected to Army networks or until copied manually to authoritative servers.



OBJ 24 TMTThe TMT may employ user-assistive technologies to ensure all steps are correctly completed during a phase of the PPEA workflow.

OBJ 25 TMT

TMT provisions all the software services across the PPEA workflow. These software services include those required by TSS prior to the execution of the scenario and not limited to "All static Information" network, MCIS, synthetic, LIVE systems and or STE "systems admin data collection and management".

OBJ 26 TMTTMT collects and manages all data/services during all phases of the PPEA workflow including managing all changes to the OE.

OBJ 27 TMTTMT will provide data/interoperability services and management thereof across the PPEA

OBJ 28 TMT

The STE shall provide a TMT that represents the Army Operations Process consistent with FM 7-0, FM 6.0, ADP 5-0, and ADRP 5-0 (The Operations Process) at the Point of Need to plan, prepare, execute, and assess collective training from Squad through ASCC.

OBJ 29 TMT The TMT shall update Soldier records based on completed training.

OBJ 30 TMTTMT manages OWT edits and use of terrain for a particular training event instance depending on the need of the instance scenario. TMT will maintain instance edits and modification for the life of the instance/scenario.

OBJ 31 TMTThe TMT serves as the primary user interface into the STE and must be intuitive and easy to use, requiring zero specialized or formal training to operate.

OBJ 32 TMT

Due to the large amount of information produced and consumed during training, Artificial Intelligence and Machine Learning technologies may be utilized to automate data management and analysis. This real-time and post-event analysis will improve training, readiness and individual / Unit competency. Both humans and automated decision makers will recommend training interventions, assist in collecting objective data for future training assessments, needs and remediation events.

OBJ 33 TrainingThe TSMT shall be able to support distributed exercises to twelve distinct locations.

OBJ 34 TrainingThe TSMT central node with Cross Domain Solution shall be able to support TOP SECRET classification and host multiple classifications in single exercise

OBJ 35 TrainingThe TSMT shall provide sufficient hardware to conduct ASCC staff training (Exercise control, Higher Headquarters, Lower response cells, opposing forces, Observer/Controller, and MSEL management).

OBJ 36 TrainingThe TSMT shall support constructive exercises Brigade and Above staff training up to ASCC level in disconnected semi-austere environments.

OBJ 37 TrainingThe TSMT shall support constructive exercises at the BCT/BN level and virtual and live at the Company and below level in disconnected semi-austere environments.



OBJ 38 TSMT

The TSMT shall support execution of the threshold critical mission threads identified in the system's integrated architectures and satisfy the technical requirements for Net-Centric military operations. It shall provide a single, common interface with the COE (Mission Command Systems and Networks) and Live TESS systems (platforms and Soldiers).

OBJ 39 TSMTThe TSMT shall support the Intelligence Warfighting Function by interoperating with IEWTPT via APIs and appropriate classified networks (s).

OBJ 40 TSMT The TSMT shall interoperate with the Soldier Virtual Trainer (SVT).

OBJ 41 TSMTThe TSMT shall interoperate with the Synthetic Training Environment - Live Training System (STE-LTS).

OBJ 42 TSMTThe TSMT shall interoperate with the Future Next Generation Constructive (NGC)

OBJ 43 TSMTThe TSMT shall interoperate with future training aids, devices, simulators, and simulations (TADSS) and appended TADSS.

OBJ 44 TSMT The TSMT shall interoperate with Joint and Multi-national MCIS.

OBJ 45 TSMTThe TSMT shall interoperate with Joint and Multi-national simulation systems.

OBJ 46 TSMT Build a simulation interoperability bridge using common standards.

OBJ 47 TSMT

The TSMT shall support cross domain security training events (unclassified up to TS/SCI) at any and all echelons regardless of scale and training construct (i.e., separate, and distinct events and a training event with varying echelons/levels) at any and all echelons.

OBJ 48 TSMT The TSMT shall represent the air, maritime, space, and cyber domains.

OBJ 49 TSMTTSMT central node shall be capable of hosting 100 simultaneous exercises with 100,000 entities each or 1 exercise with 10 million entities.

OBJ 50 TSS The TSS shall interoperate with JLCCTC and PCTE.

OBJ 51 TSSThe TSMT shall interoperate with the Integrated Visual Augmentation System (IVAS) Soldier Immersive Virtual Trainer (SiVT).

OBJ 52 TSSThe TSS Computer Generated Forces shall aggregate and disaggregate from Soldier to ASCC Level.

OBJ 53 TSSThe TSS shall provide Computer Generated Forces with automated behaviors that represent tactical tasks and maneuver up to the ASCC level (BLUFOR, OPFOR, Civilian and Multinational Forces).

OBJ 54 TSS The TSS shall support training up to TOP SECRET level.

OBJ 55 TSSThe vendor shall include design considerations for a field server capable of providing training for a Battalion and Brigade training event.

OBJ 56 TSSThe TSS shall provide realistic and dynamic operational environment with all factors of PMESII-PT (Political, Military, Economic, Social, Infrastructure, Information - Physical Environment, & Time).

OBJ 57 TSSThe TSS Entity Level, Virtual and Constructive Simulation shall scale to 10 million entities with 5,000 in the field of view; simultaneous virtual and constructive execution.

OBJ 58 TSS The TSS shall provide a personalized avatar capability so the user profile can be loaded on demand to provide an avatar that represents the Soldier's human performance characteristics.



OBJ 59 TSS TSS shall present modular models (life forms, vehicles, and equipment) found in ASCC and below formations including Cyber and EW.

OBJ 60 TSS

The TSS shall provide full replication of the Warfighting Functions in an Operational Environment.

The TSS must provide an accurate representation of the Army's six warfighting functions (movement and maneuver, intelligence, fires, sustainment, protection, and mission command) consistent with the simultaneous deployment of unit/force types (i.e., combat arms, combat support, combat service support, as well as Special Operations Forces [SOF]) associated with those functions.


2447

Appendix C Capability Roadmap

The TSMT Product Overview brief embedded below as an object contains the Government’s initial capability roadmap expressed as echelon-based capability sets (i.e., Squad, Platoon, Company, Battalion and Brigade). The TDP Appendix E SRD identifies the initial product backlog to be utilized in development of the capability roadmap. Please note references to the Common Synthetic Environment Statement of Work (CSE SOW) is old language from a previous effort in the April 2020 timeframe. Also included is the current high-level capability over time slide from August 2020 timeframe. Appendix D Notional MVP/MVCR/Release Plan contains Government’s notional MVP/MVCR/Release plan. The USG desires the highest echelon (Company, Battalion, Brigade) the vendor can deliver. The USG will consider vendor proposals which deliver less than company level capability.


2448

24492450245124522453245424552456245724582459

2460

2461

Appendix D Notional MVP/MVCR/Release Plan

The MS Excel file embedded below as an object contains the Government’s draft Notional MVP/MVCR/Release Plan.


2462

24632464

2465

Appendix E IMS Template


2466

2467

2468

2469

Appendix F Cost Deliverables

F.1 CSDR DD 2794

F.2 Software Resources Data Report

F.3 Cost and Hour Report (FlexFile) Contractor Format IAW File Format Specification (FFS) and Data Exchange Item (DEI)

F.4 Quantity Data Report (-Q) Contractor format IAW FFS and DEI


2470

2471

2472

2473

2474

2475

2476

2477

2478

2479

2480

2481

Appendix G Cybersecurity

G.1 DoD CDS Connection Process Diagram

Figure G-1. DoD CDS Connection Process Diagram.


2482

2483

2484

2485

2486

2487

Appendix H Acronyms and Glossary

H.1 Acronyms

Table H-2. Acronyms.

Acronym MeaningA&A Assessment and AuthorizationAA Adversarial AssessmentAAL Additional Authorization ListAAR After Action ReviewA-CDD Abbreviated Capability Development DocumentACM Army Capability ManagerAEDC Adversarial Cyber Developmental Test AESS Army Endpoint Security SystemAFAPD Air Force Applications Program Development AMPS Aviation Mission Planning SoftwareAO Authorizing OfficialAPI Application Programming InterfaceAPL Approved Products ListAPMS Army Portfolio Management SystemARNG Army National GuardASCC Army Service Component CommandATCTS Army Training and Certification Tracking SystemATIS Army Training Information SystemATO Authority to OperateAVA Associate Vendor AgreementsAVCATT Aviation Combined Arms Tactical TrainerAvSE Avionics Software EmulationBCT Brigade Combat TeamBII Basic Issue ItemBIT Built In TestBOM Bill of MaterialsC2 Command and ControlCAC Common Access CardCADE Cost Assessment Data ElementCAP Contractor Acquired PropertyCAT1 Category 1CATS Combined Arms Training StrategiesCCDC AV&MC Combat Capabilities Development Command Aviation and Missile CommandCCDC DAC Combat Capabilities Development Command Data and Analysis Center


2488

2489

2490

Acronym MeaningCCTT Close Combat Tactical TrainerCDRL Contractor Data Requirements ListCDS Cross Domain SolutionCDSA Cross Domain Solution AuthorizationCFT Cross Functional TeamCGF Computer Generated ForcesCI Configuration ItemCI/CD Continuous Integration / Continuous DeliveryCJCSI Chairman Joint Chiefs of Staff Instruction CLI Command Line InterfacesCLIN Contract Line Item NumberCM Configuration ManagementCMP Configuration Management PlanCNSSI Committee on National Security Systems InstructionCOE Common Operating EnvironmentCoE Center of ExcellenceCOMEX Communication ExercisesCOOP Continuity of Operations PlanCOR Contracting Officer RepresentativeCOTS Commercial Off the ShelfCP Contingency PlanCPCE Command Post Computing EnvironmentCPSMR Contractor's Progress, Status, and Management ReportCPVA Cooperative Vulnerability Penetration AssessmentsCSCI Computer Software Configuration ItemsCSDR Cost and Software Data ReportingCSL Common Software LibraryCTC Combat Training CentersCVI Cooperative Vulnerability IdentificationCWIPT Cost Working Group Integrated Product TeamDA PAM Department of the Army PamphletDAL Data Accession ListDCARC Defense Cost and Resource CenterDCSA Defense Counterintelligence and Security AgencyDDCA Deputy Director Cost AnalysisDEEP Digital Engineering Environment PlatformDEI Data Exchange ItemDevSecOps Development Security OperationsDID Data Item DescriptionDISA Defense Information Systems AgencyDMSMS Diminishing Manufacturing Sources and Material Shortages DoD Department of Defense


Acronym MeaningDoDAF Department of Defense Architecture FrameworkDoDIN Department of Defense Information NetworkDOORS Dynamic Object-Oriented Requirements SystemDOT&E Director, Operational Test & EvaluationDREN Defense Research Engineering NetworkDT&I Development Test and IntegrationECA External Certification AuthoritiesECMO Enterprise Cloud Management OfficeECP Engineering Change ProposaleMASS Enterprise Mission Assurance Support Service EXCON Exercise ControlEXORD Execution OrderFBX FilmboxFCA Functional Configuration AuditsFCL Facility Clearance LevelFEDSUN Federal, State and University Network FFS File Format SpecificationFMECA Failure Modes, Effects, and Criticality AnalysisFOC Full Operational CapabilityFOCI Foreign Ownership, Control, or InfluenceFORSCOM Forces CommandFOUO For Official Use OnlyFV Functional VerificationGFE Government Furnished EquipmentGFI Government Furnished InformationGFP Government Furnished PropertyGFT Games for TrainingglTF Graphics Library Transmission FormatHHA Health Hazard AssessmentHITS Homestation Instrumentation SystemIAMIATIATT Interim Authorization to TestIAVA Information Assurance Vulnerability AlertIAW In Accordance WithICAN Installation Campus Area NetworkICD Interface Control DocumentICS Interim Contractor SupportICW In Coordination WithIDD Interface Design DescriptionIEN Integrated Enterprise NetworkIEWTPT Intelligence Electronic Warfare Tactical Proficiency Trainer


Acronym MeaningIMS Integrated Master ScheduleIOC Initial Operational CapabilityIPT Integrated Product TeamsIRP Incident Response PlanISSM Information System Security ManagerITE Integrated Training EnvironmentITN Integrated Tactical NetworkIUID Item Unique IdentificationIVAS Integrated Visual Augmentation SystemIWTS Integrated Weapon Training StrategiesJBLM Joint Base Lewis McChordJDIF Joint Development and Integration Facility JFO Joint Fires ObserversJFT Joint Fires TrainerJIM Joint Interagency and MultinationalJLCCTC Joint Land Component Constructive Training CapabilityJME Joint Mission EnvironmentJTAC Joint Terminal Attack ControllersJVMF Joint Variable Message FormatLD/ME Logistics Demonstration/Maintenance EvaluationLORA Level of Repair AnalysisLPD Logistics Product DataLRU Line Replaceable UnitsLT2 Live Training TransformationLTA Local Training AreaLVCG Live, Virtual, Constructive, GamingLVC-IA Live, Virtual, Constructive Integrating ArchitectureMCIS Mission Command Information SystemsMCL Materiel Component ListMDO Multi-Domain OperationsMOSA Modular Open Systems ArchitectureMTTR Mean Time to RestoreMVCR Minimum Viable Capability ReleaseMVP Minimum Viable ProductNEC Network Enterprise CenterNET New Equipment TrainingNGC Next Generation ConstructiveNIAP National Information Assurance PartnershipNIPR Non-classified Internet Protocol (IP) RouterNIST National Institute of Standards and TechnologyNLT Not Later ThanNRRE Network Risk Reduction Event


Acronym Meaningo/a On or AboutOC Observer ControllerOCAR Office of the Chief Army ReserveODM Object Data ModelOE Operational EnvironmentOEM Original Equipment ManufacturerOFP Operational Flight ProgramOSD Office of the Secretary of DefenseOSHA Occupational Safety and Health AdministrationOT Operational TestOTA Other Transaction AuthorityOTC Operational Test CommandOWT One World TerrainPART Program Assessment and Review Tool PCA Physical Configuration AuditsPEO AVN Program Executive Office AviationPEO STRI Program Executive Office for Simulations and Training InstrumentationPh Probability of HitPHS&T Packaging, Handling, Shipping, and TransportPk Probability of Kill

PMESII-PTPolitical, Military, Economic, Social, Infrastructure, Information - Physical Environment, & Time

POA&M Plan of Action and MilestonesPoN Point of NeedPPEA Plan, Prepare, Execute, and AssessPPSM Ports, Protocols, and Services ManagementPWS Performance Work StatementQRG Quick Reference GuidesRAM Reliability, Availability, MaintainabilityRFT Ready for TrainingRFV Request for VarianceRIW Reliability Improvement WarrantiesRMF Risk Management FrameworkRTM Requirements Traceability MatrixRVCT Reconfigurable Virtual Collective TrainerS&T Science and TechnologySAP Software Acquisition PathwaySDK Software Development KitSDRL Supplier Data Requirements ListSIGACTS Significant ActionsSIPR Secure Internet Protocol RoutingSiVT Soldier Immersive Virtual Trainer


Acronym MeaningSLCM System-Level Continuous MonitoringSME Subject Matter ExpertSOP Standard Operating ProceduresSP Security PlanSPS Software Product SpecificationSRD System Requirements DocumentSRDR Software Resources Data Reports SRS Software Requirements SpecificationSSDD System/Subsystem Design DescriptionSSS System/Subsystem SpecificationSTE Synthetic Training EnvironmentSTE-LTS Synthetic Training Environment - Live Training System STIG Security Technical Implementation GuideSTP Standards of Training ProficiencySVD Software Version DescriptionSVT Soldier Virtual TrainerSysMIL System Modeling LanguageT&D Test and DevelopmentT&E WIPT Test and Evaluation Working Integrated Product TeamTA Technical AssessmentsTAA Technical Assistance AgreementTADSS Training Aids, Devices, Simulators, and SimulationsTB Technical BulletinTD ICL/R Training Device Inventory Checklist/RecordTDP Technical Data PackageTESS Tactical Engagement Simulation SystemTFR Training Facilities ReportTIF Technology Integration FacilityTIM Technical Interchange MeetingTM Technical ManualsTMDE Test, Measurement, and Diagnostic EquipmentTMT Training Management ToolTPD Training Performance DataTRR Test Readiness ReviewTSMO Threat System Management OfficeTSMT Training Support Management ToolTSN Trusted Systems and NetworksTSP Training Support PackageTSS Training Simulation SoftwareTSSDUA User AssessmentsULO Unified Land Operations


Acronym MeaningUoF Use of ForceUPDM Unified Profile for DoDAF/MODAFUSAPHC US Army Public Health CommandUSG United States GovernmentVoF Verification of FixesVV&A Verification, Validation, and AccreditationWfF Warfighting FunctionWGS World Geodetic SystemWSD Weapons Skills DevelopmentWTC ARNG Warfighter Training Center Army National GuardXR Cross Reality

H.2 Glossary

Table H-3. Glossary.

Term Definition

AccessibilityThe quality of being able to be reached, easy to obtain/use, and easily understood/appreciated. The ability for a system to reach the Point of Need by traversing the appropriate communications network (e.g. DODIN-A).

After Action Review (AAR)

A professional discussion of a training event focused on performance standards, that enable the participating Soldiers to discover for themselves what happened, why it happened, and how to sustain strengths and improve on weaknesses. It is a tool that leaders, trainers, and units can use to get the maximum benefit from every mission or task. Normally prepared by the TAF Analyst and conducted by an OC/T.

Application Programming Interface (API)

A set of application programs or operating system functions that can be utilized by a program.

Architecture RunwayThe Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay.

Architecture Synchronization

Government led meeting hosted by the Systems Architect with the Tech Leads from each development team

Army Service Component Command (ASCC)

Command responsible for recommendations to the joint force commander on the allocation and employment of Army forces within a combatant command. Also called ASCC. (JP 3-31)


2491

2492

2493

Term Definition

Artificial Intelligence (AI)

The capacity of a computer to perform operations analogous to learning and decision making in humans, as by an expert system, a program for CAD or CAM, or a program for the perception and recognition of shapes in computer vision systems. The STE will use AI to replicate large unit level routines to increase realism of the operational environment, to support automated adaptive behaviors and free-thinking hybrid threats, to represent culturally aware virtual humans and small units, to mimic unit behaviors when they are not present, to support communication and interfacing techniques with the environment and other entities/agents, and to ease the application for a military user base.

ATO (Authority to Operate)

The official management decision given by a senior organizational official to authorize operation of an information system and to explicitly accept the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation based on the implementation of an agreed-upon set of security controls.

BacklogThe Product or Release backlog is the holding area for upcoming Features, which are intended to address user needs and deliver business benefits. It also contains the enabler features necessary to build the Architectural Runway.

Baseline The documented configuration that is the basis of the design / development / build of the product.

Cloud

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.

Common Operating Environment (COE)

The COE is an approved set of computing technologies and standards applied across six Computing Environments (CE): Command Post, Mounted, Mobile/Handheld, Real Time/Safety Critical/Embedded, Sensor, and Enterprise. As a strategic Army initiative, and as an integral part of the LandWarNet and the Joint Information Environment, the COE is a foundational component of the Army’s modernization strategy. It aligns development and migration of Army programs to a common software baseline and a centralized hardware procurement process across the COE and within the Computing Environments.

COMMEXA COMMEX is a network and cloud connectivity check that precedes a Network Risk Reduction Event (NRRE). The purpose of the COMEX is to ensure the capability will be network and cloud connected at the Government assessment and NRRE.

Compliance1. The act of conforming, acquiescing, or yielding.2. A tendency to yield readily to others, esp. meekly3. Conformity; accordance: in compliance with orders. 4. Cooperation or obedience

Computer Generated Force (CGF)

A generic term used to refer to computer representations of forces in models and simulations that attempts to model human behavior sufficiently so that the forces will take some actions automatically (without requiring


Term Definition

man-in-the-loop interaction). Types of CGF include automated forces - computer-generated forces that require little or no human interaction. Semi-automated forces - computer-generated forces in which the individual platform simulation is operated by computer simulation of the platform crew and command hierarchy.

Computing Environment (CE)

A logical grouping of systems with similar characteristics used to organize the COE (deployment /echelon (sic), environmental, transport dependencies, form factors, etc.). A computing environment comprises the necessary hardware, operating system, libraries, and software required to run applications within the COE.

Configuration AuditCompares the as-built / as developed product against the system documentation to identify and document any variance in the documented configuration baseline.

Constructive TrainingModels and simulations that involve simulated people operating simulated systems. Real people stimulate (make inputs) to such simulations but are not involved in determining the outcomes.

Cybersecurity

Protection against intentional subversion or forced failure. A composite of four attributes – confidentiality, integrity, availability, and accountability – plus aspects of a fifth, usability, all of which have the related issue of their assurance.

Prevention of damage to, protection of, and restoration of computers, electronic communications systems, electronic communications services, wire communication, and electronic communication, including information contained therein, to ensure its availability, integrity, authentication, confidentiality, and nonrepudiation. Defined in National Security Presidential Directive-54/Homeland Security Presidential Directive-23.

Daily Scrum Team members meet daily to report plans for the day, accomplishments from the previous day and identify any blockers

Department of Defense Information Network (DoDIN)

The globally interconnected, end-to-end set of information capabilities for collecting, processing, storing, disseminating, and managing information on demand to warfighters, policy makers, and support personnel. The DoDIN includes owned and leased communications and computing systems and services, software (including applications), data, security services, other associated services, and National Security Systems (NSS). Non-DoDIN Information Technology (IT) includes stand-alone, self-contained, or embedded IT that is not, and will not be, connected to the enterprise network.

Diminishing Manufacturing Sources and Material Shortages (DMSMS)

The loss, or impending loss, of manufacturers or suppliers of items, raw materials or software.

Distributed Exercise An event enabled by distributed simulation where the training participants are at different locations (i.e., different cities, countries, or continents).


Term Definition

Distributed Simulation

A simulation that has multiple modules, which can be run on multiple processors. The processors can be co-located in the same room or located in remote sites. Entity Perspective: The perception of the synthetic environment held by a simulation entity based on its knowledge of itself and its interactions with the other simulation entities. This includes not only its own view of the simulated physical environment, but also its own view of itself, the other entities in the synthetic environment, and of the effects of the other entities on itself and the synthetic environment. Syn: World View. (SISO-REF-020-2007)

Effect A change which is a result or consequence of an action or other cause.

ElasticIn cloud computing, elasticity is the measure of how well a system adapts to workload changes by provisioning and de-provisioning systems to match the demand as closely as possible.

EntityAn entity is any independent object within a simulation that possesses complex behaviors and attributes. For example, personnel, vehicles, complex munitions, key communications devices might all be represented as independent entities within a simulation.

EnvironmentThe texture or detail of the natural domain, that is terrain relief, weather, day, night, terrain cultural features (cities or farmland), sea states, etc.; and the external objects, conditions, and processes that influence the behavior of a system.

Experience The process of doing and seeing things and having things happen to you.

ExtensibilityThe quality of being designed to allow the addition of new capabilities or functionality. An extensible system is one which takes future growth into consideration during implementation.

Fair Fight

“Fair fight” is when the performance characteristics of two of more interoperating simulations are seamless, preventing discrepancies in simulation algorithm or environmental representations from effecting the outcome of cross environment simulation exercises (e.g., Unseen opponents, pairing mismatch, effects mismatch, location mismatch, aspect mismatch).

FidelityThe degree to which a model or simulation represents the state and behavior of a real-world object or the perception of a real world object, feature, condition, or chosen standard in a measurable or perceivable manner; a measure of the realism of a model or simulation.

Field/FieldingThe process of delivering a product to the end user, this includes providing the support elements (e.g. user manuals, maintenance manuals, operator guides, spare parts, tools, etc.) that will allow the user to successfully operate and maintain the product.


Term Definition

Full Operational Capability (FOC)

In general, attained when all units and/or organizations in the force structure scheduled to receive a system 1) have received it and 2) can employ and maintain it. The specifics for any particular system FOC are defined in that system's Capability Development Document and Capability Production Document.• All equipment associated with the STE has been fielded, IAW the BOIP.• All information assurance requirements are complete.• New operator training for all sites is complete.• All contractor requirements for STE operations and support are in place and ready to support unit training at all sites.• The STE sustainment plan is in place and being executed.

Functional Fidelity

Functional fidelity captures how well the game acts like (not replicates) the operational equipment in responding to tasks performed by the training audience. For example if there is a surrogate communications system that represents the actual operational communications system but uses different means (e.g., Voice over IP (VOIP)) to provide communications, the functional fidelity is high because the training audience can perform its normal communications function even though it does not have its actual communications system or network. Functional fidelity appears to be an important factor in increasing and maintaining interest, realism, and motivation in the training event. It also helps support attention to detail.

Gaming Commercial and Government-off-the-shelf computer generated environment for interactive, semi-immersive training and education.

IATT (Interim Authority to Test)

Temporary authorization to test an information system in a specified operational information environment within the timeframe and under the conditions or constraints enumerated in the written authorization.

ImmersedSight, sound, and touch modalities are stimulated. The quality of stimulation approximates what the Soldier experiences in the Live Environment.

Immersion The placing of a human in a synthetic environment through physical and/or emotional means.

Immersive cf., Immersed


Term Definition

Initial Operational Capability (IOC)

In general, attained when selected units and/or organizations in the force structure scheduled to receive a new system have received it and can employ and maintain it. The specifics for any system IOC are defined in that system’s Capability Development Document (CDD) and Capability Production Document (CPD).IOC is defined as the first fielding and acceptance of the STE capability by an installation. It is further defined as:• All STE components have completed the verification, validation and accreditation process prior to IOC.• All STE equipment is fielded to the first installation site and accepted.• All information assurance requirements are complete.• New user operator training at the first site is complete.• All contractor requirements for STE operations and support are in place and ready to support unit training at the first site.

Instrumentation The use or application of instruments to measure the effectiveness of training systems

Integrated Training Environment (ITE)

The Army’s Integrated Training Environment (ITE) is current array of Training Aids, Devices, Simulations and Simulators (TADSS) that enable Army Collective, Non-Systems Training. The ITE is a system of systems that, by design, combines and connects key training enablers in a persistent and consistent manner to accurately train Mission Command (MC) according to the Commander’s training objectives within the appropriate Operational Environment. The ITE Implementation and Management Plan (I2MP) describes how the Army aligns ITE system of systems requirements, funding, and solutions to create incremental ITE capabilities to support Home Station Training with a focus on Brigade and below by 2020. The plan is a living document developed cooperatively by the Deputy Commanding General, Combined Arms Center – Training and the Program Executive Officer, Simulation Training, and Instrumentation. The plan covers the stakeholders; organizations; roles; responsibilities; high-level governance and systems engineering approaches; tasks; and schedules involved in developing incremental ITE capabilities.

Integration The process of combining software or hardware components or both into an overall system

Intelligent Tutoring cf., Intelligent Tutoring System


Term Definition

Intelligent Tutoring System

The mechanism or technologies (tools and methods) to provide tailored training and educational experiences; adaptive tutoring systems respond to changing states in the learner and changing conditions in the training environment to optimize learning; adaptive tutoring systems anticipate and recognize teachable moments. The STE will use ITS for Team and Unit Modeling, Automated Enterprise Hot wash and After-Action Review (AAR), Affective/Cognitive Modeling Capabilities, Training Effectiveness/Human Performance Measurement, Authoring Tools to Extend Applicability Across Training Domains, Domain Modeling across a range of dynamic military tasks, and elements of the Human Dimension to drive the cognitive, social, and physical skills of Soldiers over their career (Long-term Learner Modeling). An Intelligent Tutoring system (ITS) is a computer system that aims to provide immediate and customized instruction or feedback to learners, usually without.

Interface

1. A shared boundary across which information is passed. 2. A hardware or software component that connects two or more components for the purpose of passing information from one to another3. To connect two or more components for the purpose of passing information from one to another4. To serve as a connecting or connected component as in (2)

Interim Contractor Support Temporary product support provided to the Government by a contractor.

InteroperabilityThe ability to operate in synergy in the execution of assigned tasks.The ability of a model or simulation to provide services to and accept services from other models and simulations, and to use these exchanged services to operate effectively together.

Interoperable The ability of two or more systems or components to exchange information and to use the information that has been exchanged

Item Unique Identification Method of providing unique identification for each item in a system to allow documentation, tracking, and analysis of parts usage.

Joint Fires TrainingThe training for the application of Fires delivered during the employment of forces from two or more components in coordinated action to produce desired effects in support of a common objective.

Life Cycle The life of a system from initiation, planning, procurement, development, implementation, operation, maintenance, to disposal of the system

Live, Virtual, Constructive - Integrating Architecture (LVC-IA)

The Army's program of record that provides the common software, protocols, standards, and interfaces to facilitate interoperability of currently non-linked LVCG TADSS so that they can interoperate, share information, provide common views of the battlefield, and stimulate MC systems. The LVC-IA will be developed and fielded in increments (notionally two years) and is the key technical enabler foundation of the ITE. The Live, Virtual Constructive Integrating Architecture (LVC-IA) is the Program of Record that establishes initial interoperability and over time, the integration of Live, Virtual, Constructive and Gaming Simulations and Simulators and the stimulation of Mission Command Systems.


Term Definition

Logistics Demonstration/Maintenance Evaluations (LD/ME)

The LD/ME are used to evaluate the adequacy of the system support package and ensure the user unit has the logistical capability to achieve IOC. A logistics demonstration includes the nondestructive disassembly and reassembly of a production representative system using its related peculiar test, measurement, and diagnostic equipment (TMDE), tools, training devices, technical publications, and support equipment. It also evaluates the adequacy of trouble-shooting procedures, personnel skill requirements; the selection and allocation of spare parts, tools, test equipment, and tasks to appropriate maintenance levels; and the adequacy of maintenance time standards. LD/ME shall use vendor developed test procedures (e.g., threads and vignettes) to test the product support capabilities. The vendor shall support and participate in the LD/ME. The vendor shall provide all required hardware and software for the events. The Government will document issues in PTRs for the vendor to address/correct during the event or as part of the backlog. LD/ME locations are TBD and may include P4 STE TIF, P5 JDIF, Cloud / data center, distributed locations, MTCs, or a combination of these locations. The test environment will approximate the infrastructure (e.g., network, cloud, security) conditions of the anticipated fielding locations. The Government will host a daily hot wash and Government only AAR.

Master Scenario Event List (MSEL)

The MSEL is a chronological list that supplements the event scenario with event synopses; expected participant responses; capabilities, tasks, and objectives to be addressed; and responsible personnel. It includes specific scenario events (or injects) that prompt players to implement the plans, policies, and procedures that require testing during the event, as identified in the capabilities-based planning process. It also records the methods that will be used to provide the injects (i.e., phone call, facsimile, radio call, e-mail).

MCIS MCIS combines data and information from the Warfighting Functions to support common CP activities that contribute to the commander’s ability to understand, visualize, describe, direct, lead, and assess operations.

Mission Command

The event of authority and direction by the commander using mission orders to enable disciplined initiative within the commander's intent to empower agile and adaptive leaders in the conduct of full-spectrum operations; commander-led and blends the art of command and the science of control to integrate the Warfighting Functions to accomplish the mission. (ADP 6-0)

Model A three-dimensional representation of a person or thing or of a proposed structure, typically on a smaller scale than the original.


Term Definition

Modular Open Systems Approach (MOSA)

An integrated business and technical strategy. The DoD will use MOSA as a tool to help provide joint combat capabilities. Five (5) MOSA Principles: 1. “Establishes an enabling environment conducive to open system implementation”2. “Employs modular design tenets” 3. “Defines key interfaces where appropriate”4. “Applies widely supported, consensus-based (i.e., open) standards that are published and maintained by a recognized industry standards organization”5. “Uses certified conformant products”· Title 40 (Public Law 104-106), Subtitle III/Clinger-Cohen Act (CCA) Compliance Requirements, Modular Contracting Implementation Guidance includes the use of Modular, Open Systems Approach as part of the Systems Engineering of each DoD System.· Federal Acquisition Regulations (FAR), Part 39, Acquisition of Information Technology, paragraph 103, requires the use of Modular Contracting (and the implied use of OSA as part of the Systems Engineering of each system).· DoDI5000.02, Enclosure 2, paragraph 6.a(5) Modular Open System Architecture (MOSA) states, “Program management is responsible for evaluating and implementing a MOSA to the maximum extent feasible and cost effective. … The Acquisition Strategy for the system should identify where, why, and how a MOSA will or will not be used by the program.”

Multi-Domain

Multi-Domain Operations allows US forces to outmaneuver adversaries physically and cognitively, applying combined arms in and across all domains. It provides a flexible means to present multiple dilemmas to an enemy and create temporary windows of localized control to seize, retain and exploit the initiative. Employing Multi-Domain Operations, Army and Marine forces with cross-domain capabilities provide a credible capability to deter adversary aggression, deny enemy freedom of action, overcome enemy anti-access and area denial (A2AD), secure terrain, compel outcomes, and consolidate gains for sustainable outcomes.

MVCR Initial set of features suitable to be fielded to an operational environment that provides value to the user in a rapid timeline.

MVP An early version of the software to deliver or field basic capabilities to users to evaluate and provide feedback on. Insights from MVPs help shape scope, requirements, and design.

Network Risk Reduction Event

A NRRE is network and cloud data collection and performance assessment to assess the capability on the network. The purpose of the NRRE is to ensure the software will operate on the Government’s network and security infrastructure.

Operational Environment (OE)

(DOD) A composite of the conditions, circumstances, and influences that affect the employment of capabilities and bear on the decisions of the commander. Also called OE. See ADRP 3-0 and ADRP 6-0.


Term Definition

Operational Testing

The Government conducts the OT on production, or production representative articles, to determine whether systems are operationally effective and suitable for intended use by representative users to support the decision to proceed to fielding the software release. The vendor shall support and participate in the OTs. The OT will be a distributed exercise conducted at home station(s) and encompass all LVCG domains utilizing STE and legacy components. The OT will validate the user's ability to Plan, Prepare, Exercise, and Assess capabilities of the STE for the various echelons. The vendors shall provide all required hardware and software for the events. OT may consist of a series of distinct test events at various locations based on the functionalities being tested. The Government will host a daily hot wash and Government only AAR.

Other Transactional Authority (OTA)

Other transactions Authority (OTA) is the term commonly used to refer to the 10 U.S.C. 2371 (Prototyping) / 10 U.S.C. 2373 (Research) authority to enter transactions other than contracts, grants, or cooperative agreements.

Performance The action or process of performing a task or function.

Platform as a Service (PaaS)

The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.

Point of Need (PoN)

The STE PoN concept provides a collective training capability to training audiences of all components at home stations (e.g., installations, combat training centers [CTCs], armories, reserve centers, Regional Collective Training Centers [RCTC], etc.), while deployed, and at the institution.

The STE Point of Need functional area has five task groups: Networking and Cloud Technology, Exercise Control / Synch and Scenario Generation / Initialization, User Interface / Contextual Input and Support for Various Platforms, Single Client Install or Web Application Access Gateway to access entire training system / environment (elimination of federated training systems), and Common Risk Management Framework that links to Mission Command. PoN is further defined as the ability to provide a collective training capability during connected, standalone, and *disconnected, intermittent, and low-bandwidth (DIL) network conditions. (*Disconnected: The STE needs the capability to operate on isolated networks, without access to enterprise resources.)

Pre-Program Increment Planning

Key stakeholders identify features from the Product Backlog from the MVP feature set for the teams to plan and develop for the 8-12 release cycle


Term Definition

Product RoadmapHigh-level visual summary that maps out the vision and direction of product offerings over time. Describes the goals and features of each software sprint and program increment.

Product Support (see also sustainment)

The processes, documentation, and actions required to field and maintain the readiness and operational capability of a system.

Product VisionThe Vision is a description of the future state of the Solution under development. It reflects customer and stakeholder needs, as well as the Feature and Capabilities proposed to meet those needs.

Program Increment

A Program Increment (PI) is a timeboxed planning interval during which an Agile Release Train plans and delivers incremental value in the form of working, tested software and systems. PIs are typically 8 – 12 weeks long. The most common pattern for a PI is four development Iterations, followed by one Innovation and Planning (IP) Iteration.

Program Increment Demonstration

Teams will demonstrate the work that they have been working on during the Program Increment

Program Increment Dependency Board

Highlighting the new feature delivery dates, feature dependencies among teams and relevant Milestones.

Program Increment Objectives

Program Increment (PI) Objectives are a summary of the business and technical goals that an Agile Team or train intends to achieve in the upcoming Program Increment (PI) that are created by each team with the business value assigned by the Business Owners.

Program Increment Planning

Key Stakeholders and the development teams create a high level plan for each sprint for the release. This activity gives the opportunity to identify dependencies and risks among the teams. The Key Stakeholders and the Development team will leave the planning session with a plan and a User Agreement

Program Increment Retrospective

Teams discuss the results of the Program Increment, review practices, and identify ways to improve

Program/Requirements Manager Synchronization

Government led meeting hosted by the Program/Requirements Manager with Product Owners from each development team

RealismFine Arts. Treatment of forms, colors, space, etc., in such a manner as to emphasize their correspondence to actuality or to ordinary visual experience.

Reconfigurable Virtual Collective Trainer (RVCT)

The Air and Ground RVCT are used to train units in collective tasks on a simulated, fully interactive, real time battlefield. RVCT provides a realistic virtual environment in which units train and perform tasks preparing themselves to successfully accomplish their collective missions.

Release Notes Release notes are documents that are distributed with software products, and can be delivered when products are still be developed.

Renderer A software or hardware process that generates a visual image from a model.

Representation Models of the entity or phenomenon associated and its effects. Representations using algorithms and data that have been developed or


Term Definition

approved by a source having accurate technical knowledge are often considered authoritative.

Resolution The degree of detail visible in a photographic or television image.

Risk Management

The process of managing risks to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the nation resulting from the operation or use of an information system, and includes: 1) the conduct of a risk assessment; 2) the implementation of a risk mitigation strategy; 3) employment of techniques and procedures for the continuous monitoring of the security state of the information system; and 4) documenting the overall risk management program

RMF (Risk Management Framework)

A disciplined and structured process that integrates information security and risk management activities into the system development life cycle.

Scalability cf., Scalable.

Scalable The capacity to be changed in size or scale. The ability of the system to adapt to increased demands.

Scrum of ScrumsScrum of Scrum Sessions that are Government led hosted by the Release Train Engineer with Scrum Masters from each development. Upcoming features are socialized and dependencies are discussed at this meeting.

Semi-ImmersedSight, sound, and touch modalities are stimulated. The quality of stimulation is a low-fidelity approximation of what the Soldier experiences in the Live Environment.

Semi-Immersive cf., Semi-Immersed

Situational Awareness

Knowledge of one’s location; the location of friendly and hostile forces; and of external factors, such as terrain, weather, etc., that may affect one’s capability to perform a mission. Commanders, staffs, units, and soldiers/weapon platforms at all echelons require the means to optimally utilize all mission command information available that affects their area of operations. SA is a state of understanding gained through decisions made from knowledge supplied by a graphical Common Picture of the battlefield consisting as a minimum of the enemy situation (location, resources, status, and possible actions), friendly situation (location, resources, and status), and the logistics situation (location and status).

Software Release Functionality developed during the Program Increment

Sprint Demonstration Teams demonstrate the work that they have been working on during that 2 week Sprint

Sprint Goals Teams develop goals for the 2 week sprint during Sprint Planning

Sprint Plan

Teams engage in mapping out each sprint with features during Program Increment Planning to highlight dependencies among teams and risks which is captured in the sprint plan. During the Sprint Planning Event, the teams revisit the sprint plan and add additional detail during the Sprint Planning Phase of the Sprint Lifecycle

Sprint Retrospective The Team discuss the results of the sprint, review the team practices, and


Term Definition

identify ways to improve

Sustainment The support required to maintain a system in an operational status throughout its life cycle.

SyntheticRepresentation or model of the characteristics of the real world. Devised, arranged, or fabricated for special situations to imitate or replace usual reality.

Synthetic Environment

The integrated set of data elements that define the environment within which a given simulation application operates. The data elements include information about the initial and subsequent states of the terrain including cultural features, and atmospheric and oceanographic environments throughout an event. The data elements include databases of externally observable information about instantiable entities and are adequately correlated for the type of event to be performed. Also known as virtual world. (IEEE Std 1278.1-2012) [10] Virtuality Continuum: “The Virtuality Continuum is a continuous scale ranging between the completely virtual, a virtuality, and the completely real, reality. The reality-virtuality continuum therefore encompasses all possible variations and compositions of real and virtual objects.” [2] Virtual: An entity or data that is derived from a modeled or simulated representation of the actual or anticipated system.

Technical Assessment/Functional Verification

The Government conducts the TA/FVs on the latest developed capabilities to ensure requirements are met per the SRD/SSS. TA/FVs shall use vendor developed test procedures (e.g., threads and vignettes) to test TSMT capabilities. The vendor shall support and participate in the TA/FVs. The vendor shall provide all required hardware and software for the events. TA/FVs shall collect Reliability, Availability, and Maintainability (RAM) data. The Government will document issues in Problem Trouble Tickets (PTRs) for the vendor to address/correct during the event or as part of the backlog. TA/FV locations are TBD and may include P4 STE Technology Integration Facility (TIF), P5 Joint Development and Integration Facility (JDIF), Cloud / data center, distributed locations, MTCs, or a combination of these locations. The test environment will approximate the infrastructure (e.g., network, cloud, security) conditions of the anticipated fielding locations. The Government will host a daily hot wash and Government only AAR.

Training Aids, Devices, Simulators, and Simulations (TADSS)

Training aids, devices, simulators, and simulations (TADSS) replicate OE complexities (training role players, IED simulators, MILES, small arms) to a low-fidelity environment (low fidelity as defined by Army training directives).

Training EffectivenessEvaluation of the impact of training and educational tools and methods on usability, learning, comprehension, performance, retention, reasoning, and transfer of knowledge and acquired skills to the operational environment.

Training Unit The unit which is trained and evaluated during the event.

Use of Force A series of actions an individual can take to resolve a situation. Use of


Term Definition

force allows the Soldier flexibility as the need for force changes as the situation develops. The level of force is not linear or consecutive; one may go up a scale, and back again in a matter of seconds. Use of force includes less lethal force (e.g., officer presence; voice commands; empty hand control; pepper spray, baton, Taser; other less lethal weapons) and deadly force.

User Agreement

Agreement between the operational and acquisition communities to gain ensure active user involvement and decisions. Ensure proper resourcing of user involvement to support development Commit to active user involvement throughout design and development during planning phaseSigned by sponsor, PMO prior to entry into Execution Phase

User Assessment (UA)

The Government conducts the UA to allow the user/soldier to operate the system and provide feedback to the developers. Users roles include but are not limited to scenario planners, dismounted Soldiers, platform operators and AAR personnel. The vendor shall support and participate in the UAs. The vendor shall assist the Government to identify proper UA Soldier staffing at least 90 days prior to the event. The vendors shall provide all required hardware and software for the events. Locations of the TAs is to be determined and may include P4 STE TIF, P5 JDIF, Cloud / data center, distributed locations, including MTCs, or a combination of these locations. The Government will host a daily hot wash and Government only AAR.

Verification, Validation, and Accreditation (VV&A)

The Government conduct VV&A on all SRD/SSS requirements. The vendor will assist in all VV&A activities as required. The National Simulation Center (NSC) Analysis and Test Branch conducts testing that informs both validation decisions, and subsequent recommendations to accrediting authorities, made by Army Capability Managers (ACM) on the use of modeling and simulation solutions for training exercises and military operations. The testing concept for informing the ACM STE involves using applicable data from the OT, and from prior assessments (TAs and UAs), and conducting, by exception, additional activities, and events with priority to validation testing. Additional activities and events include technical and functional thread testing and vignette and operational scenario testing. The validation data informs identification of capabilities and limitations of STE solutions when using those to train Soldiers.

Virtual Semi-Immersive Interfaces

Virtual Semi-Immersive interfaces are common ‘keyboard and mouse’ interfaces into a virtual 3D representation of a training environment.

Virtual TrainingA simulation involving real people operating simulated systems. Virtual simulations inject human-in-the-loop in a central role by exercising motor control skills, decision skills, or communication skills.


Term Definition

Warfighting Function

A group of tasks and systems (people, organizations, information, and processes), united by a common purpose that commanders use to accomplish missions and training objectives. (ADRP 3-0)A Warfighting Function is a group of tasks united by a common purpose that commanders use to accomplish missions.

Weapon Skill DevelopmentThe development of fire’s knowledge, skills, marksmanship, and engagement techniques involved in the effective lethal employment of the weapon system.

Zero Client A zero-client is an I/O redirector device that allows a full cluster of peripheral devices to be deployed at the desired point of service without a dedicated PC or thin client at that same location and without requiring any modifications to existing software applications.


2494