training support management tool (tsmt) performance

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

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

1

2

3

Performance Work Statement (PWS) 4

For 5

Synthetic Training Environment – Information System 6

(STE-IS) 7

TRAINING SIMULATION AND MANAGEMENT TOOL 8

(TSMT) 9

10

11

12

13

16 October 2020 14

Version 1.0 15

16

17

Prepared by 18

U.S. Army PEO Simulation, Training, and Instrumentation 19

(PEO STRI) 20

12211 Science Drive 21 Orlando, FL 32826-3276 22

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

23

Revision Level Document Date Summary of Change

Pages Affected

1.0 16 October 2020 Initial release of document

All

24

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

Table of Contents 25

Overview .................................................................................................................. 1 26 1.1 Problem Statement ............................................................................................ 1 27 1.2 Synthetic Training Environment Overview ......................................................... 1 28 1.3 Training Support Management Tool Overview ................................................... 3 29

1.3.1 TSMT Scope ................................................................................................. 3 30 1.3.2 Capability Overview ...................................................................................... 4 31

1.3.2.1 TSMT ..................................................................................................... 4 32 1.3.2.1 TMT ....................................................................................................... 5 33

Planning Phase ................................................................................ 5 34 Prepare Phase ................................................................................. 5 35 Execute Phase ................................................................................. 5 36 Assess Phase ................................................................................... 5 37

1.3.2.2 TSS ........................................................................................................ 5 38 Acquisition Pathway and Objectives .................................................................... 6 39 2.1 Software Acquisition Pathway ............................................................................ 6 40 2.2 Objective ............................................................................................................ 7 41

Requirements .......................................................................................................... 8 42 3.1 Program Management ....................................................................................... 8 43 3.2 Associate Vendor Agreements .......................................................................... 8 44 3.3 Communication .................................................................................................. 9 45 3.4 Reviews ........................................................................................................... 10 46 3.5 System Engineering ......................................................................................... 10 47 3.6 Configuration Management .............................................................................. 10 48

3.6.1 Configuration Identification ......................................................................... 11 49 3.6.2 Configuration Control .................................................................................. 12 50 3.6.3 Configuration Status Accounting ................................................................ 12 51

3.7 Integration ........................................................................................................ 12 52 3.8 Deliverables ..................................................................................................... 13 53

3.8.1 Management Deliverables .......................................................................... 13 54 3.8.2 Engineering Deliverables ............................................................................ 15 55 3.8.3 Product Support Deliverables ..................................................................... 20 56

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

3.8.4 TSMT Hardware Deliverables ..................................................................... 30 57 3.8.5 Cost Deliverables ....................................................................................... 32 58

3.9 System Requirements ...................................................................................... 34 59 3.9.1 General ....................................................................................................... 35 60 3.9.2 Architecture ................................................................................................ 36 61 3.9.3 Point of Need .............................................................................................. 38 62

3.9.3.1 Point of Need Conditions ..................................................................... 38 63 3.9.3.2 Network ............................................................................................... 39 64 3.9.3.3 Cloud ................................................................................................... 39 65 3.9.3.4 Multi-level Security ............................................................................... 40 66

3.9.4 TSMT Hardware ......................................................................................... 40 67 3.10 Agile Process ................................................................................................... 41 68

3.10.1 General ....................................................................................................... 42 69 3.10.2 Agile Ceremonies ....................................................................................... 42 70 3.10.3 Agile Metrics ............................................................................................... 44 71 3.10.4 Roadmap .................................................................................................... 46 72 3.10.5 DevSecOps ................................................................................................ 48 73

3.11 Testing ............................................................................................................. 50 74 3.11.1 Incremental Government Testing ............................................................... 51 75 3.11.2 Integration Environment .............................................................................. 52 76 3.11.3 Development Testing .................................................................................. 52 77 3.11.4 Cybersecurity Tests and Events ................................................................. 53 78

3.12 Product Support ............................................................................................... 54 79 3.12.1 General ....................................................................................................... 54 80 3.12.2 Interim Contractor Support ......................................................................... 55 81 3.12.3 Maintenance Planning/Concept .................................................................. 55 82 3.12.4 Warranty ..................................................................................................... 56 83 3.12.5 Configuration Audits ................................................................................... 57 84 3.12.6 Diminishing Manufacturing Sources and Material Shortages ..................... 58 85 3.12.7 Technical Support Documentation .............................................................. 58 86 3.12.8 Training ....................................................................................................... 59 87 3.12.9 Item Unique Identification ........................................................................... 59 88 3.12.10 .................................................................................................................... System 89

Delivery ....................................................................................................... 60 90

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

3.13 Security ............................................................................................................ 61 91 3.13.1 Industrial Security ....................................................................................... 61 92 3.13.2 Cybersecurity .............................................................................................. 61 93

3.13.2.1 Cyber Survivability ............................................................................... 62 94 3.13.2.2 Risk Management Framework ............................................................. 62 95 3.13.2.3 Cross Domain Solution Authorization (CDSA) ..................................... 65 96 3.13.2.5 Cybersecurity Training ......................................................................... 65 97

3.14 Safety and Health ............................................................................................ 66 98 3.14.1 Safety ......................................................................................................... 66 99 3.14.2 Health ......................................................................................................... 67 100

References ............................................................................................................ 67 101 Appendix A Capability Descriptions ....................................................................... A-1 102

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

Trainer ............................................................................................................A-5 112 A.10 STE Live Training System ..............................................................................A-5 113

Appendix B Objective Values .................................................................................. B-1 114 Appendix C Capability Roadmap ............................................................................ C-1 115 Appendix D Notional MVP/MVCR/Release Plan ..................................................... D-1 116 Appendix E IMS Template ........................................................................................ E-1 117 Appendix F Cost Deliverables .................................................................................. F-1 118

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

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

Appendix G Cybersecurity ....................................................................................... G-1 124

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

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

H.1 Acronyms ....................................................................................................... H-1 127 H.2 Glossary ......................................................................................................... H-7 128

129

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

List of Figures 130

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

Figure 1-2. Synthetic Training Environment. ........................................................................... 3 132 Figure 1-3. TMT Interaction. ....................................................................................................... 4 133

134

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

136

List of Tables 137

Table 3-1. Recurring Government Meetings. .......................................................................... 9 138 Table 3-2. Development / User Feedback Locations. .......................................................... 30 139

Table 3-3. Fielding Locations. .................................................................................................. 31 140

141

Table B-1. Objective Values. ........................................................................................B-1 142 Table H-1. Acronyms. .................................................................................................. H-1 143 Table H-2. Glossary. ................................................................................................... H-7 144

145

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

146

147

148

149

150

151

152

153

This page intentionally left blank. 154

155

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

Overview 156

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

1.2 Synthetic Training Environment Overview 167

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

172 Figure 1-1. STE OV-1. 173


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

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

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

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

• Reconfigurable Virtual Collective Trainers (RVCT) 205 • One World Terrain (OWT) 206

The STE delivers software, application(s) and services that will enable the RVCT and 207 other training capabilities. The STE will enable multi-level security through a cross 208 domain solution (CDS). The STE architecture and design enables and supports 209 interoperability with existing training systems (Live, Virtual, Constructive Integrating 210


Architecture [LVC-IA], Joint Land Component Constructive Training Capability 211 [JLCCTC], Homestation Instrumentation Training System [HITS]); and future training 212 systems Soldier Virtual Trainer (SVT), the embedded Integrated Visual Augmentation 213 System (IVAS) with Soldier Immersive Virtual Trainer (SiVT), future Next Generation 214 Constructive (NGC), Synthetic Training Environment - Live Training System (STE-LTS) 215 and operational capabilities. 216

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

1.3 Training Support Management Tool Overview 222

1.3.1 TSMT Scope 223

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

229 Figure 1-2. Synthetic Training Environment. 230

The TSMT solution will use OWT products and integrate with RVCT as a cohesive STE 231 system. The vendor will need to monitor, collaborate, and integrate with OWT, RVCT, 232


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

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

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

1.3.2 Capability Overview 248

1.3.2.1 TSMT 249

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

253 Figure 1-3. TMT Interaction. 254


1.3.2.1 TMT 255

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

Planning Phase 259

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

Prepare Phase 263

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

Execute Phase 269

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

Assess Phase 275

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

1.3.2.2 TSS 281

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


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

Acquisition Pathway and Objectives 297

2.1 Software Acquisition Pathway 298

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

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

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

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

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

ready to support unit training at Fort Hood. 323


2.2 Objective 324

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

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

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

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


Requirements 360

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

3.1 Program Management 365

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

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

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

3.2 Associate Vendor Agreements 376

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

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

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

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

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

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


3.3 Communication 392

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

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

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

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

Table 3-1. Recurring Government Meetings. 403

Meeting Location Host Frequency Architecture Synchronization TBD Government Weekly AvSE IPT TBD Government Weekly Cost Working IPT TBD Government TBD Cyber IPT TBD Government Weekly Integration IPT TBD Government Weekly Network/Cloud WG TBD Government Weekly OWT Coordination TBD Government Weekly Pre-Program Increment Planning Meeting TBD Government TBD

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

RVCT Coordination TBD Government Weekly Science and Technology IPT TBD Government Monthly Scrum of Scrums TBD Government Weekly SiVT IPT TBD Government Monthly System Safety Working Group TBD Government TBD Testing WIPT TBD Government Weekly TMT IPT TBD Government Weekly TSMT IPT TBD Government Weekly TSS IPT TBD Government Weekly Others as directed by the Government TBD Government TBD


3.4 Reviews 404

3.4.1 The vendor shall host and conduct technical interchange meetings (TIM) and test and 405 assessment reviews to inform Government approval of the product design at least once 406 prior to each program increment, MVP, the MVCR, and subsequent software releases 407 and as requested by the Government. 408

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

3.5 System Engineering 414

The vendor shall use the agreed upon Agile systems engineering process and 415 DevSecOps environment to plan, design, develop, incorporate, test, and deliver STE 416 system of systems capabilities. 417

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

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

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

3.6 Configuration Management 426

This section references the traditional functional, allocated and product baselines. 427 These terms equate to the following Agile elements: 428

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

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


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

3.6.1 Configuration Identification 438

3.6.1.1 The vendor shall ensure configuration identification, control, and status accounting of all 439 TSMT system hardware, software, and documentation including Government-440 furnished information and vendor-supplied items for the period of performance of this 441 effort. 442

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

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

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

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

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

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

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

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

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

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


3.6.2 Configuration Control 470

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

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

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

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

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

3.6.3 Configuration Status Accounting 484

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

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

3.7 Integration 489

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

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

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


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

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

3.8 Deliverables 508

The vendor shall provide the following list of deliverables to the Government throughout 509 the performance of this effort. These deliverables serve to provide the performance data 510 and product support data to the Government to allow for the appropriate planning and 511 oversight for the TSMT. 512

3.8.1 Management Deliverables 513

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

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

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

Initial Submission Due: 30 days after Contract Award 520

Recurring Submissions Due: Monthly 521

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

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

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

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

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

DID: DI-MGMT-82001 531


Format: As specified in the DID. 532

3.8.1.3 Name: Integrated Master Schedule (IMS) 533

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

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

Initial Submission Due: 30 days after Contract Award 546


Format: Use sample format in Appendix E IMS Template. 548

3.8.1.4 Name: Conference Minutes 549 Purpose: Provides executive summary, documentation of technical information 550 provided, decisions and agreements reached, and action items captured at 551 meetings. 552 Initial Submission Due: As required and NLT 5 days after the meeting 553 Recurring Submissions Due: As required and NLT 5 days after the meeting 554 DID: DI-ADMN-81250B 555

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


3.8.2 Engineering Deliverables 566

Vendor format is acceptable, except as noted and shall be delivered electronically in MS 567 Office compatible formats unless otherwise noted. 568

3.8.2.1 Name: Computer Software Product End Items 569

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

Initial Submission Due: Initial submission with first MVP 572

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

DID: DI-AVCS-80700A 575

3.8.2.2 Name: DoD Architecture Framework Documentation (DoDAF) 576

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

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

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

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


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

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

3.8.2.3 Name: Interface Design Description (IDD) 606

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

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

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

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

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

Sample Data Item Description: DoDAF 2.02; SysML 1.6 630

3.8.2.4 Name: Software Version Description (SVD) 631

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


Initial Submission Due: Initial submission with the first MVP. 635

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

DID: DI-IPSC-81442 638

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

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

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

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

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

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


3.8.2.6 Name: System/Subsystem Specification 665

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


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

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

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

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

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


3.8.2.7 Name: Test Plan 698

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

Initial Submission Due: 30 days after contract award. 702


Recurring Submissions Due: 30 days after program increment planning. 703

DID: DI-SESS-80688 704

3.8.2.8 Name: Test Procedure 705

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

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

Recurring Submissions Due: Every TA. 711

DID: DI-NDTI-80603A 712

3.8.2.9 Name: Test/Inspection Report 713 Purpose: The test/inspection report is used to document test/inspection results, 714 findings and analyses that will enable the Government or contracting agency to 715 evaluate compliance with system requirements, performance objectives, 716 specifications, and test/inspection plans. 717 Initial Submission Due: As required 718 Recurring Submissions Due: As required 719 DID: DI-NDTI-80809B 720

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

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

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


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

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

Initial Submission Due: As required 740 Recurring Submissions Due: As required 741 DID: DI-SESS-80640E 742

3.8.2.12 Name: Baseline Description Document 743 Purpose: Provide a list of unique identifiers for all requirement documents plus 744 approved changes and physical hardware and software items in which the 745 specifications, drawings, interface control documents, strategy, design and 746 version description documents define the functional and physical characteristics. 747 The principal use of this list is to designate configuration control of identified 748 configuration items. 749 Initial Submission Due: 30 days prior to the first MVP 750 Recurring Submissions Due: 30 days prior to MVCR and each subsequent 751 software release 752 DID: DI-SESS-81121A 753

3.8.2.13 Name: Safety Assessment Report 754

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

Initial Submission Due: 30 days prior to the first MVP 760

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

DID: DI-NDTI-80603A 763

3.8.3 Product Support Deliverables 764

Deliverables shall conform to the format identified in the Data Item Description and shall 765 be delivered electronically in MS Office compatible formats unless otherwise noted. 766


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

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

Initial Submission Due: Draft 30 days prior to MVCR 771

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

DID: DI-TMSS-80527C 774

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

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

Initial Submission Due: 30 days after ICS begins 780


DID: DI-ILSS-81226 782

3.8.3.3 Name: Level of Repair Analysis (LORA) Report 783

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

Initial Submission Due: 30 days prior to MVP 791

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

DID: DI-PSSS-81872A 794

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

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


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



DID: DI-PSSS-81495B 809

3.8.3.5 Name: Logistics Product Data w/Attribute Selection Worksheet 810

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

Initial Submission Due: Draft 30 days prior to MVP 816


DID: DI-SESS-81758A 819

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

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



DID: MIL-STD-40051-1C 828


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

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



DID: MIL-STD-40051-1C 837

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

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



DID: MIL-PRF-32614 845

3.8.3.9 Name: Product Engineering Design Data & Associated Lists 846

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


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

DID: DI-SESS-81000F 855

3.8.3.10 Name: Drawing Tree 856

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


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



DID: DI-DRPR-81961A 865

3.8.3.11 Name: Software Sustainability Package 866

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



DID: DI-IPSC-82134 877

3.8.3.12 Name: Technical Manual Verification Discrepancy/Disposition Record 878

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

Initial Submission Due: Draft 30 days after each MVP 881

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

DID: DI-TMSS-81820 884

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

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


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



DID: DI-PSSS-82310 899

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

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

Initial Submission Due: 30 days prior to first MVP 909


DID: DI-PSSS-81656B 912

3.8.3.15 Name: Training Materials 913

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



DID: DI-ILSS-80872 920

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

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




DID: DI-MGMT-81858 927

3.8.3.17 Name: Training System Support Document 928

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


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

DID: DI-PSSS-81527C 937

3.8.3.18 Name: Trainer Facilities Report (TFR) 938

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


Recurring Submissions Due: As required for each delivery site 945

DID: DI-FACR-80966F 946

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

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




DID: DI-MISC-81191B 957

3.8.3.20 Name: Data Accession List (DAL) 958

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



DID: DI-MGMT-81453B 971

3.8.3.21 Name: Training Equipment Summary 972

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

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

3.8.3.22 Name: Technical Manual Verification Incorporation Certificate 981

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



DID: DI-SESS-81821 988


3.8.3.23 Name: Training Conduct Support Document 989

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



DID: DI-SESS-81523D 997

3.8.3.24 Name: Course Conduct Information Package (completion) 998

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



DID: DI-SESS-81522D 1011

3.8.3.25 Name: Instructional Media Package – Training Video 1012

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



DID: DI-SESS-81526C 1019


3.8.3.26 Name: Contractor Device Performance Report 1020

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



DID: DI-ILSS-80191D 1027

3.8.3.27 Name: Warranty 1028

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



DID: DI-SESS-81639A 1039

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

3.8.3.29 Name: Configuration Audit Plan 1050 Purpose: Provides information required for conducting Functional Configuration 1051 Audits (FCA) and PCA. 1052


Initial Submission Due: 30 days prior to first MVP 1053 Recurring Submissions Due: As required 1054 DID: DI-SESS-81646C 1055

3.8.4 TSMT Hardware Deliverables 1056

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

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

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

Name Location Central Node

CDS Edge 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 2 ATEC TBD TBD PEO AVN / CCDC AV&MC AL 0 0 0 1 4 2

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

1069

1070


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

Table 3-3. Fielding Locations. 1074

Name Deliveries Central Node CDS Edge

Node Field

Server EXCON Laptops

OC Mobile Device

Fort Hood, TX MVP / 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 28 Fort Benning, GA Brigade Release 2 1 2 6 42 28

Fort Leonard Wood, MO Brigade Release 2 1 2 6 42 28

WTC ARNG, GA (Fort Benning)

Brigade Release 2 1 2 6 42 28

Total 12 6 12 36 252 168

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

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

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

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

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

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

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


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

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

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

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

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

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

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

3.8.5 Cost Deliverables 1109

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

3.9 System Requirements 1169

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

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

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

1 Common Requirements 1184

1.1 Played Items 1185

1.2 PMESII-PT 1186

1.3 METT-TC Factors 1187

1.4 Rendering 1188

1.5 Architecture 1189

1.6 Technology 1190

1.7 Interoperability / Integration 1191

1.8 Deployment 1192


1.9 Non-Architecture Attributes /Guidance 1193

1.10 One World Terrain 1194

1.11 RVCT Integration 1195

2 Training Simulation Software 1196

2.1 TSS/RVCT 1197

2.2 TSS General 1198

2.3 S/SVT 1199

3 Training Management Tool 1200

3.1 TMT Assess 1201

3.2 TMT Execute 1202

3.3 TMT Plan 1203

3.4 TMT Prepare 1204

3.5 TMT TMT Common 1205

3.9.1 General 1206

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

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

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

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

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

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


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

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

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

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

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

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

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

3.9.2 Architecture 1248

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


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

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

3.9.2.3 The vendor shall enforce modular architectures. 1263

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

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

3.9.2.6 The vendor shall designate key interfaces. 1267

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

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

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

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

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

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

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


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

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

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

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

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

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

3.9.3 Point of Need 1303

The TSMT delivers training content to the PoN at Home Stations, deployed locations, 1304 and training and educational institutions. See Table 3-3 for MVCR and Operational Test 1305 locations. See the TDP Appendix D TSMT Hardware Concept for more information on 1306 the PoN. 1307

3.9.3.1 Point of Need Conditions 1308

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

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


3.9.3.2 Network 1318

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

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

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

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

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

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

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

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

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

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

3.9.3.3 Cloud 1348

The TSMT uses elastic and scalable shared computing resources to scale the capability 1349 without excessive, idle overhead capacity. The TSMT hybrid cloud agnostic design 1350 enables the capability to transition between cloud service providers. The vendor shall 1351


use Defense Information Systems Agency (DISA) approved Cloud services and shall 1352 adhere to the Enterprise Cloud Management Office (ECMO) guidelines and standards 1353 see enterprise-cloud-management-office-ecmo for additional information. The vendor 1354 shall follow the DoD Digital Modernization Strategy and DoD Cloud Strategy and 1355 operate up to Impact Level 6 and MCIS classification of secret. 1356

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

The vendor shall use a zero-trust cloud. 1358

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

3.9.3.4 Multi-level Security 1363

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

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

3.9.4 TSMT Hardware 1369

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

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


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

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

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

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

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

3.10 Agile Process 1398

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

The vendor shall identify an agile approach that addresses meetings and agile 1403 ceremonies such as: daily scrum meetings, scrum of scrums, sprint planning, sprint 1404 demonstrations, sprint retrospectives, program increment planning sessions, integration 1405 points between teams, system demonstrations, and other components of the agile 1406 methodology. The vendor agile approach shall ensure continuous user engagement and 1407 feedback mechanisms. The vendor shall identify sprint and program increment length. 1408 The vendor shall also identify a specific technique to facilitate distributed meetings with 1409 the Government, vendors, and sub-vendors using a mechanism approved for official 1410 use only (FOUO). Using the agile development process, the vendor shall work with the 1411 Government to identify the capabilities the vendor shall develop during each program 1412 increment and sprint. 1413

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

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

anticipated outcome). 1420 • Business value of each user story toward overall objectives. 1421


• Progress reporting, risk identification and dependency identification. 1422

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

3.10.1 General 1427

3.10.1.1 The vendor Agile process shall include time for technology investigation, innovation, 1428 refactoring, and bug fixes. 1429

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

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

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

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

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

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

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

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

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

3.10.2 Agile Ceremonies 1449

3.10.2.1 The vendor shall conduct a program increment planning session with the Government 1450 prior to each increment and shall use the Government provided prioritized features to 1451 conduct the planning. 1452


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

• Government provided prioritized functional features and architecture 1455 enablers. 1456

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

• Program increment objectives 1460 • Sprint plan for each team 1461 • Team risks 1462 • Program Increment dependency board 1463 • Updated product roadmap 1464 • Update architectural runway 1465 • Updated program backlog 1466 • T&E Plan 1467 • RTM 1468

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

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

• Program increment planning session exit criteria artifacts. 1471

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

• Refined team sprint plan 1475 • Team sprint goals 1476

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

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

• Refined team sprint plan 1481 • Sprint test results 1482


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

• Sprint demonstration 1486 • Sprint retrospective 1487 • Sprint release notes 1488 • Sprint backlog refinement 1489

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

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

• Program increment software/hardware 1494 • Program increment test results 1495

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

• Program increment demonstration 1499 • Program increment release notes 1500 • Program increment retrospective 1501 • Software release 1502 • Program backlog refinement 1503 • Next program increment planning session 1504

3.10.3 Agile Metrics 1505

3.10.3.1 The vendor shall provide an automated agile metric reporting mechanism for 1506 Government approval. 1507

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

3.10.4 Roadmap 1560

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

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

The vendor roadmap shall include test dates. 1570

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

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

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

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

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

The vendor roadmap shall include the cybersecurity accreditation progression. 1581

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


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

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

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

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

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

The vendor roadmap shall include scalability capability progression. 1598

The vendor roadmap shall include voice communications system capability 1599 progression. 1600

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

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

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

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

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

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


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

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

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

The vendor roadmap shall include CATS task progression. 1626

3.10.5 DevSecOps 1627

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

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

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

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

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

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

3.10.5.6 The vendor shall design their DevSecOps process to employ a delivery pipeline that 1649 enables the systems to develop on cadence, release on demand, and conduct 1650


continuous integration and continuous delivery (CI/CD) with STE system capability and 1651 interface vendors to ensure an integrated STE system of systems. 1652

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

3.10.5.18 Platform One 1690

Platform One is the official DoD DevSecOps Enterprise service. Platform One facilitates 1691 efficient and effective coordination between development scrums and the Government. 1692 The vendor accesses Platform One using the internet. The Government will purchase 1693 services to have the STE DevSecOps pipeline hosted in Platform One. The CI/CD 1694 pipeline will use Platform One provided tools and products. Platform One may have the 1695 flexibility to support additional tools required for the STE DevSecOps process. Platform 1696 One hosted pipelines currently have access to: 1697

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

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

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

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

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

3.11 Testing 1711

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

• TA/Functional Verifications (FV) 1715 • User Assessments (UA) 1716 • Operational Testing (OT) 1717


• Verification, Validation, and Accreditation (VV&A) 1718 • Logistics Demonstration/Maintenance Evaluations (LD/ME) 1719

3.11.1 Incremental Government Testing 1720

3.11.1.1 The vendor shall enable, participate, and support continuous and incremental 1721 Government testing that supplements Agile process and DevSecOps testing. 1722

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

3.11.2 Integration Environment 1773

3.11.2.1 The vendor shall use the Government Technology Integration Facility (TIF) for 1774 integration, demonstrations, assessments, and test and evaluations that replicates 1775 conditions of the operational environment. 1776

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

3.11.3 Development Testing 1781


3.11.3.1 The vendor shall develop a sprint and increment level test and evaluation plan NLT 30 1782 days after contract award for the Government to approve in accordance with the 1783 deliverables (3.8.2.7, 3.8.2.8, and 3.8.2.9). 1784

The vendor shall update the test and evaluation plan NLT 30 days into each 1785 program increment, MVP, MVCR and subsequent software releases in accordance 1786 with the deliverables (3.8.2.7, 3.8.2.8, and 3.8.2.9). 1787 The test and evaluation plan shall address development testing, component 1788 testing, integration testing, sprint demonstrations, program increment demonstrations, 1789 MVP, MVCR, subsequent software release demonstrations of the integrated STE 1790 solution. 1791

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

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

The vendor shall develop a RTM that traces all system requirements and features 1797 allocated to a given sprint, program increment, MVP, MVCR or subsequent software 1798 release; vendor provided, and Government approved test procedures; and vendor 1799 provided and Government approved measures of success. 1800 The vendor shall support Environmental testing by providing hardware test assets 1801 and possible onsite support as required at an approved DoD/Army test agency facility. 1802

3.11.4 Cybersecurity Tests and Events 1803

3.11.4.1 The vendor shall support development of a multi-phased, test timeline and cyber test 1804 and evaluation plan in accordance with the deliverables (3.8.2.7, 3.8.2.8, and 3.8.2.9). 1805

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

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

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


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

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

3.11.4.4 The TSMT shall undergo Cybersecurity Operational Test events. 1821

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

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

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

3.12 Product Support 1830

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

3.12.1 General 1834

3.12.1.1 The vendor shall safeguard, securely store, and track government furnished property 1835 (GFP) (i.e., GFI and GFE). Contractor Acquired Property (CAP) shall be considered as 1836 GFP and will be added to the GFP list after presentation of the DD250. The vendor can 1837 request additional GFI/GFE and the Government will evaluate and determine 1838 applicability. 1839

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

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

b. Provide storage that precludes deterioration 1843

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

d. Identify and protect from improper use or disposition 1845

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


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

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

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

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

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

3.12.2 Interim Contractor Support 1856

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

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

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

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

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

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

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

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

3.12.3 Maintenance Planning/Concept 1876

3.12.3.1 The vendor shall develop and provide a LORA in accordance with the deliverable 1877 (3.8.3.3). 1878


3.12.3.2 The vendor shall develop and provide a FMECA in accordance with the deliverable 1879 (3.8.3.4) 1880

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

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

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

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

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

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

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

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

3.12.4 Warranty 1899

3.12.4.1 The vendor shall track and document warranties in accordance with the deliverable 1900 (3.8.3.28). 1901

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

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


3.12.5 Configuration Audits 1906

3.12.5.1 Configuration Audits – Functional 1907

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

3.12.5.2 Configuration Audits – Physical 1910 The vendor shall satisfy the following PCA entry criteria prior to initiating the PCA 1911 processes 1912

a. Training system hardware design is complete except for the shortages / 1913 deviations / waivers and has been captured in the final released engineering 1914 data and associated lists. 1915

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

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

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

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

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

g. Government / vendor IPT participation has been coordinated. 1928 The vendor shall conduct PCAs with the Government, on the as built TSMT 1929 system with power off, that will consist of non-functional examinations performed IAW 1930 the Government accepted Test and Evaluation Plan to demonstrate that the TSMT as-1931 built design and that the deliverable hardware and software documentation accurately 1932 reflect the CI. 1933 The vendor shall provide non-deliverable documents in contractor format as 1934 needed to determine vendor compliance with configuration management (CM) 1935 requirements. 1936 The vendor shall certify, prior to the start of PCA examinations, that all electrical 1937 power, including UPS systems, have been disconnected and de-energized. 1938 The vendor shall comply with the Occupational Safety and Health Administration 1939 (OSHA) lockout-tag out requirements specified in 29 CFR 1910.147. 1940


The vendor shall provide the personnel, equipment, and facilities necessary to 1941 support the Government-conducted examinations. 1942 The vendor shall be responsible for the disassembly, as required, of the Line 1943 Replaceable Units (LRU) for access to TSMT equipment. 1944 The vendor shall record the results of the PCA examinations in accordance with 1945 the deliverable (3.8.3.28) 1946 The vendor shall satisfy the following PCA exit criteria prior to closing out the PCA: 1947

a. All contractor and subcontractor released Product Engineering Design Data 1948 and Associated Lists were provided to the Government for audit. 1949

b. Contractor has captured and entered all Government discrepancy reports in 1950 the tracking database. 1951

3.12.5.3 Configuration Audits – Software 1952 For each software item, software configuration audits shall be conducted by the 1953 vendor for each baseline and witnessed by the Government. 1954

3.12.5.4 The vendor shall present a detailed plan for performing configuration audits prior to 1955 release of the baseline in accordance with the deliverable (3.8.3.29) 1956

3.12.6 Diminishing Manufacturing Sources and Material Shortages 1957

3.12.6.1 The vendor shall identify, document, and manage DMSMS in accordance with the 1958 deliverable (3.8.3.14). 1959

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

3.12.7 Technical Support Documentation 1962

3.12.7.1 The vendor shall integrate the technical documentation (e.g. System/Software User 1963 Manuals, Operator Manuals, COTS manuals, Maintenance Manuals, engineering 1964 data, programmatic data, etc.) from OWT, SVT, SiVT and RVCT into the TSMT 1965 system technical documentation providing a single source of integrated technical 1966 documentation. 1967

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

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

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


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

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

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

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

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

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

3.12.8 Training 1990

3.12.8.1 The vendor shall integrate TSMT training products with training products from other 1991 STE system vendors and document the training in accordance with the deliverables 1992 (3.8.3.15, 3.8.3.17, 3.8.3.23, 3.8.3.24, and 3.8.3.25). 1993

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

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

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

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

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

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

3.12.9 Item Unique Identification 2008


3.12.9.1 The vendor shall apply and register Government approved Item Unique Identification 2009 labels to all material that will be delivered to the Government in accordance with MIL-2010 STD-130 and the deliverable (3.8.3.16). 2011

3.12.10 System Delivery 2012

3.12.10.1 The vendor shall assist the Government with coordination of system delivery. 2013

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

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

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

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

3.12.10.6 The vendor shall conduct site installation. 2023

3.12.10.7 The vendor shall conduct site testing. 2024

3.12.10.8 The vendor shall conduct site training. 2025

3.12.10.9 The vendor shall conduct site daily reporting. 2026

3.12.10.10 The vendor shall conduct site daily briefs. 2027

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

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

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

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

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


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

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

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

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

3.13 Security 2048

3.13.1 Industrial Security 2049

Any contractor (prime or sub) that is a Foreign Owned, Controlled, or Influenced (FOCI) 2050 company that does not have their FOCI mitigated by the Defense Counterintelligence 2051 and Security Agency (DCSA) and who does not possess a Facility Clearance Level 2052 (FCL) shall provide to the Authorizing Official (AO), Contracting Officer Representative 2053 (COR) and cognizant security office a copy of their DSP-5 and if needed Technical 2054 Assistance Agreement (TAA) prior to receiving any Unclassified Technical Data 2055 Packages marked (FOUO, Distribution B – F, or Export Controlled). Additionally, the 2056 FOCI company must comply with the provisos listed within their State Department 2057 license(s) as it pertains to the contract. 2058

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

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

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

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

3.13.2 Cybersecurity 2067

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


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

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

Systems and Organizations 2081

See Appendix G Cybersecurity for the CDS phases flowchart. 2082

3.13.2.1 Cyber Survivability 2083 The vendor shall comply with DoD Cyber Survivability Endorsement, Volumes I-2084 III, Cyber Survivability Endorsement. 2085 The vendor shall respond to cybersecurity tasking orders, as directed by the 2086 Government, provided by organizations such as NETCOM's 7th Signal Command, 2087 DOD CIO G6 and US Cyber Command. 2088 The vendor shall manage vulnerabilities to maintain cyber survivability capabilities 2089 (e.g., automated patch management, mitigation of known threats, and effects of 2090 obsolescence). 2091

3.13.2.2 Risk Management Framework 2092 The vendor shall comply with all required DoD and Army regulations (e.g., DoDI 2093 8510.01 RMF for DoD IT, Committee on National Security Systems Instruction 2094 (CNSSI) 1253, the National Institute of Standards and Technology (NIST) SP 800-53, 2095 and Army Regulation AR 25-2) to implement and document the cybersecurity 2096 requirements, processes, and procedures to meet the Confidentiality, Integrity, and 2097 Availability impact levels of Moderate-Moderate-Low. 2098 The vendor shall mitigate or fix all category 1 (CAT1) noncompliance items within 2099 30 days of submission to the Package Approval Chain. 2100 The vendor shall be Army Endpoint Security System (AESS) compliant. 2101 The vendor shall develop and maintain the functional architecture/topology 2102 diagram, authorization boundary diagram, and data flow diagram, using the NETCOM 2103 template format in accordance with the deliverables (3.8.2.2). 2104 The vendor shall review and support the system categorization. 2105


The vendor shall plan, resource, and document the RMF Assessment and 2106 Authorization (A&A) for the test and development enclaves and fielding sites IAW 2107 Table 3-2 and Table 3-3. 2108 The vendor shall produce all components of the required RMF packages (i.e. 2109 IATT, ATO) necessary to test, develop, deliver, and operate an authorized system in 2110 accordance with the deliverables (3.8.1.2). 2111 The vendor shall evaluate and document all system, interfaces and network 2112 changes that impact security in accordance with the deliverables (3.8.1.2). 2113 The vendor shall develop and maintain the system cybersecurity artifacts required 2114 by RMF, DoD, DoDI, and NIST regulations, guidelines, and controls (e.g., Security 2115 Plan (SP), Continuity of Operations Plan (COOP), Contingency Plan (CP), Incident 2116 Response Plan (IRP), CMP, Standard Operating Procedures (SOP), eMASS Control 2117 Self-Assessment test results input, Ports, PPSM document) in eMASS in accordance 2118 with the deliverables (3.8.1.2). 2119

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

3.13.2.3 Cross Domain Solution Authorization (CDSA) 2182 The vendor shall design, use, and support the authorization of the selected CDS 2183 in a secure, enterprise environment IAW DoDI 8540.01 and Chairman Joint Chiefs of 2184 Staff Instruction (CJCSI) 6211.02D. 2185 The vendor shall define data flowing through the CDS within 60 days of OTA 2186 award to support ACDMO questionnaires for Phase 1. 2187 The vendor shall support the CDSA waiver artifact development, testing, and 2188 authorization processes for each required security. 2189

3.13.2.4 Cybersecurity Incident Reporting 2190 The vendor shall develop a program IRP in compliance with PEO STRI and Army 2191 IRP procedures NLT 30 TBD days after contract. 2192 The vendor shall comply with the IRP when responding to a cybersecurity related 2193 incident. 2194

3.13.2.5 Cybersecurity Training 2195 The vendor shall deny access to DoD information systems when contractor 2196 personnel do not have proper and current certifications. 2197 The vendor shall ensure that System Administrators and Network Administrators 2198 meet the minimum requirements for technical category Level II (IAT Level II) and 2199 workforce management category Level I (Information Assurance Manager [IAM] Level 2200 I) as defined by DoD 8570.01-M. 2201 The vendor shall verify employees have at least 3 years' cybersecurity or related 2202 experience (e.g., operating systems, network devices, database) for the system being 2203 managed at the moment of hiring. 2204 The vendor shall have up to six months to obtain the remaining employee 2205 certification or training qualifications for their position in accordance with DoD 8570.01-2206 M. 2207


The vendor shall verify that all TSMT vendor and sub-vendor cybersecurity 2208 personnel manage their training and certification through the Army Training and 2209 Certification Tracking System (ATCTS) found at https://atc.us.army.mil. 2210 The vendor shall provide the Government verification that Cybersecurity/IT 2211 personnel meet the baseline certification requirements established in the DoD 2212 8570.01-M and DoDD 8140.01 Cyberspace Workforce Management for the category 2213 and level functions in which they are performing by contract award and update 2214 monthly after contract. Approved baseline certifications and a list of cybersecurity 2215 workforce certification providers is available at: https://public.cyber.mil/cw/cwmp/dod-2216 approved-8570-baseline-certifications/. 2217 The vendor's Information System Security Manager (ISSM) shall appoint in writing 2218 TSMT cybersecurity personnel and provide to the Government NLT 10 days after 2219 contract award and update monthly accordance. 2220 The vendor shall document information assurance certification status for TSMT 2221 personnel performing information assurance functions and provide to the Government 2222 NLT 10 days after contract award and update monthly. 2223

3.14 Safety and Health 2224

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

3.14.1 Safety 2232

3.14.1.1 The vendor design shall be compliant with the following standards and publications to 2233 optimize system performance and t to prevent safety, health, environmental, 2234 ergonomic, and software/firmware (to include modifications updates and new system 2235 interfaces) hazards. 2236

• MIL-STD-1472, Human Engineering Design Criteria, Principles, and Practices: 2237 • MIL-STD-882E, DoD Standard Practice, System Safety. 2238 • DA PAM 385-30, Safety Risk Management Technical Bulletin (TB) 43-0134 2239

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

System Safety Management Guide 2242

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


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

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

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

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

3.14.2 Health 2253

3.14.2.1 The vendor shall provide a Health Hazard Assessment (HHA) to the Program Office 2254 and prior to each program increment, MVP, MVCR, and subsequent software releases 2255 to identify, assess, and provide mitigation of potential health hazards as required by AR 2256 40-10, Health Hazard Assessment Program in Support of the Army Acquisition 2257 Process. 2258

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

References 2262

# 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 2019 https://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

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

https://public.cyber.mil/cw/cwmp/dod-approved-8570-baseline-certifications/

https://public.cyber.mil/cw/cwmp/dod-approved-8570-baseline-certifications/



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

28 Enterprise 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/

32 MOSA 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

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

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





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

2263

2264

2265


2266

2267

2268

2269

2270

2271

2272

2273

This page intentionally left blank. 2274

2275

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

Appendix A Capability Descriptions 2276

A.1 One World Terrain 2277

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

A.2 Reconfigurable Virtual Collective Trainer 2288

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

RVCT Initial Operational Capability (IOC) and Full Operational Capability (FOC) 2298 Definitions for the current increment 2299 IOC Definition and target date IOC attainment is projected to occur in Fiscal Year (FY) 2300 2022, subject to change based on the rate of progress of development of the material 2301 solution. IOC is defined as the first fielding and acceptance of the RVCT capability by an 2302 installation. It is further defined as: 2303

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

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

• All Information Assurance (IA) requirements are complete. 2307


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

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

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

RVCT FOC Definition and target date 2313

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

FOC is further defined as: 2318

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

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

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

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

A.3 Live Virtual Constructive Integrating Architecture 2329

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


A.4 Mission Command Information Systems 2338

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

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

A.5 Avionics Software Emulation 2352

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

A.6 Common Software Library 2356

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

A.7 Army Training Information System 2363

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


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

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

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

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

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

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

A.8 Soldier Virtual Trainer 2396


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

A.9 Integrated Visual Augmentation System / Soldier Immersive 2410

Virtual Trainer 2411

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

A.10 STE Live Training System 2421

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


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

2451

2452

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

Appendix B Objective Values 2453

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

Table B-1. Objective Values. 2460 ID Category Objective

OBJ 1 Interoperability

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

OBJ 2 OWT 3D Objects correctly attributed for simulation training and mission rehearsal needs.

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

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

OBJ 5 OWT Import 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 OWT OWT 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 OWT OWT rapid terrain capture shall enable Point-of-need photogrammetric processing capabilities - i.e. local compute.

OBJ 12 OWT OWT 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 OWT OWT rapid terrain capture shall enable Synchronization of data back to Enterprise Grid on both low and high side.

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


ID Category Objective

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 TMT The TMT shall interoperate with real world mission command systems up to the ASCC (Joint/MN).

OBJ 18 TMT The 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 TMT The 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 TMT TMT collects and manages all data/services during all phases of the PPEA workflow including managing all changes to the OE.

OBJ 27 TMT TMT 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 TMT TMT 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 TMT The 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 Training The TSMT shall be able to support distributed exercises to twelve distinct locations.

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

OBJ 35 Training The 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 Training The TSMT shall support constructive exercises Brigade and Above staff training up to ASCC level in disconnected semi-austere environments.

OBJ 37 Training The 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 TSMT The 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 TSMT The TSMT shall interoperate with the Synthetic Training Environment - Live Training System (STE-LTS).

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

OBJ 43 TSMT The 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 TSMT The 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 TSMT TSMT 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 TSS The TSMT shall interoperate with the Integrated Visual Augmentation System (IVAS) Soldier Immersive Virtual Trainer (SiVT).

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

OBJ 53 TSS The 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 TSS The vendor shall include design considerations for a field server capable of providing training for a Battalion and Brigade training event.

OBJ 56 TSS The 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 TSS The 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.

2461

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

Appendix C Capability Roadmap 2462

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

TSMT Product

Roadmap Overview 1 SPARTAN CAPSET

Oneslider 12OCT20.p 2474

2475

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

Appendix D Notional MVP/MVCR/Release Plan 2476

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

Copy of 06 OCT 2020 RFS Notional Schedule 2479

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

Appendix E IMS Template 2480

2481

2482

2483

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

Appendix F Cost Deliverables

F.1 CSDR DD 2794

STE DD2794 Training System DEV CSDR_Dr

F.2 Software Resources Data Report

Example_CDRL_SRDR_3026-1_20190614.

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

Example_CDRL_Cost and Hour Report (Flex

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

Example_CDRL_Quantity Data Report_2019

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

Appendix G Cybersecurity

G.1 DoD CDS Connection Process Diagram

CSD Process Flowchart DIST A.pdf

Figure G-1. DoD CDS Connection Process Diagram.

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

Appendix H Acronyms and Glossary

H.1 Acronyms

Table H-1. Acronyms.

Acronym Meaning A&A Assessment and Authorization AA Adversarial Assessment AAL Additional Authorization List AAR After Action Review A-CDD Abbreviated Capability Development Document ACM Army Capability Manager AEDC Adversarial Cyber Developmental Test AESS Army Endpoint Security System AFAPD Air Force Applications Program Development AMPS Aviation Mission Planning Software AO Authorizing Official API Application Programming Interface APL Approved Products List APMS Army Portfolio Management System ARNG Army National Guard ASCC Army Service Component Command ATCTS Army Training and Certification Tracking System ATIS Army Training Information System ATO Authority to Operate AVA Associate Vendor Agreements AVCATT Aviation Combined Arms Tactical Trainer AvSE Avionics Software Emulation BCT Brigade Combat Team BII Basic Issue Item BIT Built In Test BOM Bill of Materials C2 Command and Control CAC Common Access Card CADE Cost Assessment Data Element CAP Contractor Acquired Property CAT1 Category 1 CATS Combined Arms Training Strategies CCDC AV&MC Combat Capabilities Development Command Aviation and Missile Command CCDC DAC Combat Capabilities Development Command Data and Analysis Center


Acronym Meaning CCTT Close Combat Tactical Trainer CDRL Contractor Data Requirements List CDS Cross Domain Solution CDSA Cross Domain Solution Authorization CFT Cross Functional Team CGF Computer Generated Forces CI Configuration Item CI/CD Continuous Integration / Continuous Delivery CJCSI Chairman Joint Chiefs of Staff Instruction CLI Command Line Interfaces CLIN Contract Line Item Number CM Configuration Management CMP Configuration Management Plan CNSSI Committee on National Security Systems Instruction COE Common Operating Environment CoE Center of Excellence COMEX Communication Exercises COOP Continuity of Operations Plan COR Contracting Officer Representative COTS Commercial Off the Shelf CP Contingency Plan CPCE Command Post Computing Environment CPSMR Contractor's Progress, Status, and Management Report CPVA Cooperative Vulnerability Penetration Assessments CSCI Computer Software Configuration Items CSDR Cost and Software Data Reporting CSL Common Software Library CTC Combat Training Centers CVI Cooperative Vulnerability Identification CWIPT Cost Working Group Integrated Product Team DA PAM Department of the Army Pamphlet DAL Data Accession List DCARC Defense Cost and Resource Center DCSA Defense Counterintelligence and Security Agency DDCA Deputy Director Cost Analysis DEEP Digital Engineering Environment Platform DEI Data Exchange Item DevSecOps Development Security Operations DID Data Item Description DISA Defense Information Systems Agency


Acronym Meaning DMSMS Diminishing Manufacturing Sources and Material Shortages DoD Department of Defense DoDAF Department of Defense Architecture Framework DoDIN Department of Defense Information Network DOORS Dynamic Object-Oriented Requirements System DOT&E Director, Operational Test & Evaluation DREN Defense Research Engineering Network DT&I Development Test and Integration ECA External Certification Authorities ECMO Enterprise Cloud Management Office ECP Engineering Change Proposal eMASS Enterprise Mission Assurance Support Service EXCON Exercise Control EXORD Execution Order FBX Filmbox FCA Functional Configuration Audits FCL Facility Clearance Level FEDSUN Federal, State and University Network FFS File Format Specification FMECA Failure Modes, Effects, and Criticality Analysis FOC Full Operational Capability FOCI Foreign Ownership, Control, or Influence FORSCOM Forces Command FOUO For Official Use Only FV Functional Verification GFE Government Furnished Equipment GFI Government Furnished Information GFP Government Furnished Property GFT Games for Training glTF Graphics Library Transmission Format HHA Health Hazard Assessment HITS Homestation Instrumentation System IAM IAT IATT Interim Authorization to Test IAVA Information Assurance Vulnerability Alert IAW In Accordance With ICAN Installation Campus Area Network ICD Interface Control Document ICS Interim Contractor Support


Acronym Meaning ICW In Coordination With IDD Interface Design Description IEN Integrated Enterprise Network IEWTPT Intelligence Electronic Warfare Tactical Proficiency Trainer IMS Integrated Master Schedule IOC Initial Operational Capability IPT Integrated Product Teams IRP Incident Response Plan ISSM Information System Security Manager ITE Integrated Training Environment ITN Integrated Tactical Network IUID Item Unique Identification IVAS Integrated Visual Augmentation System IWTS Integrated Weapon Training Strategies JBLM Joint Base Lewis McChord JDIF Joint Development and Integration Facility JFO Joint Fires Observers JFT Joint Fires Trainer JIM Joint Interagency and Multinational JLCCTC Joint Land Component Constructive Training Capability JME Joint Mission Environment JTAC Joint Terminal Attack Controllers JVMF Joint Variable Message Format LD/ME Logistics Demonstration/Maintenance Evaluation LORA Level of Repair Analysis LPD Logistics Product Data LRU Line Replaceable Units LT2 Live Training Transformation LTA Local Training Area LVCG Live, Virtual, Constructive, Gaming LVC-IA Live, Virtual, Constructive Integrating Architecture MCIS Mission Command Information Systems MCL Materiel Component List MDO Multi-Domain Operations MOSA Modular Open Systems Architecture MTTR Mean Time to Restore MVCR Minimum Viable Capability Release MVP Minimum Viable Product NEC Network Enterprise Center NET New Equipment Training


Acronym Meaning NGC Next Generation Constructive NIAP National Information Assurance Partnership NIPR Non-classified Internet Protocol (IP) Router NIST National Institute of Standards and Technology NLT Not Later Than NRRE Network Risk Reduction Event o/a On or About OC Observer Controller OCAR Office of the Chief Army Reserve ODM Object Data Model OE Operational Environment OEM Original Equipment Manufacturer OFP Operational Flight Program OSD Office of the Secretary of Defense OSHA Occupational Safety and Health Administration OT Operational Test OTA Other Transaction Authority OTC Operational Test Command OWT One World Terrain PART Program Assessment and Review Tool PCA Physical Configuration Audits PEO AVN Program Executive Office Aviation PEO STRI Program Executive Office for Simulations and Training Instrumentation Ph Probability of Hit PHS&T Packaging, Handling, Shipping, and Transport Pk Probability of Kill

PMESII-PT Political, Military, Economic, Social, Infrastructure, Information - Physical Environment, & Time

POA&M Plan of Action and Milestones PoN Point of Need PPEA Plan, Prepare, Execute, and Assess PPSM Ports, Protocols, and Services Management PWS Performance Work Statement QRG Quick Reference Guides RAM Reliability, Availability, Maintainability RFT Ready for Training RFV Request for Variance RIW Reliability Improvement Warranties RMF Risk Management Framework RTM Requirements Traceability Matrix RVCT Reconfigurable Virtual Collective Trainer


Acronym Meaning S&T Science and Technology SAP Software Acquisition Pathway SDK Software Development Kit SDRL Supplier Data Requirements List SIGACTS Significant Actions SIPR Secure Internet Protocol Routing SiVT Soldier Immersive Virtual Trainer SLCM System-Level Continuous Monitoring SME Subject Matter Expert SOP Standard Operating Procedures SP Security Plan SPS Software Product Specification SRD System Requirements Document SRDR Software Resources Data Reports SRS Software Requirements Specification SSDD System/Subsystem Design Description SSS System/Subsystem Specification STE Synthetic Training Environment STE-LTS Synthetic Training Environment - Live Training System STIG Security Technical Implementation Guide STP Standards of Training Proficiency SVD Software Version Description SVT Soldier Virtual Trainer SysMIL System Modeling Language T&D Test and Development T&E WIPT Test and Evaluation Working Integrated Product Team TA Technical Assessments TAA Technical Assistance Agreement TADSS Training Aids, Devices, Simulators, and Simulations TB Technical Bulletin TD ICL/R Training Device Inventory Checklist/Record TDP Technical Data Package TESS Tactical Engagement Simulation System TFR Training Facilities Report TIF Technology Integration Facility TIM Technical Interchange Meeting TM Technical Manuals TMDE Test, Measurement, and Diagnostic Equipment TMT Training Management Tool TPD Training Performance Data


Acronym Meaning TRR Test Readiness Review TSMO Threat System Management Office TSMT Training Support Management Tool TSN Trusted Systems and Networks TSP Training Support Package TSS Training Simulation Software TSSD UA User Assessments ULO Unified Land Operations UoF Use of Force UPDM Unified Profile for DoDAF/MODAF USAPHC US Army Public Health Command USG United States Government VoF Verification of Fixes VV&A Verification, Validation, and Accreditation WfF Warfighting Function WGS World Geodetic System WSD Weapons Skills Development WTC ARNG Warfighter Training Center Army National Guard XR Cross Reality

H.2 Glossary

Table H-2. Glossary.

Term Definition

Accessibility The 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 Runway The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay.


Term Definition

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)

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.

Backlog The 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.

COMMEX A 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.


Term Definition

Compliance 1. The act of conforming, acquiescing, or yielding. 2. A tendency to yield readily to others, esp. meekly 3. 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 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 Audit Compares the as-built / as developed product against the system documentation to identify and document any variance in the documented configuration baseline.

Constructive Training Models 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.


Term Definition

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).

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.

Elastic In 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.

Entity 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.

Environment The 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.

Extensibility The 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).

Fidelity The 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/Fielding The 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.

Immersed Sight, 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 another 3. To connect two or more components for the purpose of passing information from one to another 4. To serve as a connecting or connected component as in (2)

Interim Contractor Support Temporary product support provided to the Government by a contractor.

Interoperability The 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 Training The 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 Roadmap High-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 Vision The 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

Realism Fine 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.


Term Definition

Representation Models of the entity or phenomenon associated and its effects. Representations using algorithms and data that have been developed or 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 Scrums Scrum 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-Immersed Sight, 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


Term Definition

Sprint Retrospective The Team discuss the results of the sprint, review the team practices, and identify ways to improve

Sustainment The support required to maintain a system in an operational status throughout its life cycle.

Synthetic Representation 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 Effectiveness Evaluation 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.


Term Definition

Use of Force

A series of actions an individual can take to resolve a situation. Use of 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 phase Signed 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 Training A 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 Development The 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.