training support management tool (tsmt) performance ... · web view2020/10/14 · performance work...
TRANSCRIPT
DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
Performance Work Statement (PWS)For
Synthetic Training Environment – Information System (STE-IS)
TRAINING SIMULATION AND MANAGEMENT TOOL (TSMT)
20 October 2020Version 2.0
Prepared byU.S. Army PEO Simulation, Training, and Instrumentation
(PEO STRI)12211 Science Drive
Orlando, FL 32826-3276
DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
1
23
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Revision Level Document Date Summary of Change Pages Affected
1.0 16 October 2020 Initial release of document
All
2.0 20 October 2020 Update Paragraph 3.13.1, Industrial Security
69
iDISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
23
24
Table of Contents
1 Overview..................................................................................................................1.1 Problem Statement.............................................................................................1.2 Synthetic Training Environment Overview..........................................................1.3 Training Support Management Tool Overview...................................................
1.3.1 TSMT Scope.................................................................................................1.3.2 Capability Overview.......................................................................................
1.3.2.1 TSMT......................................................................................................1.3.2.1 TMT........................................................................................................
1.3.2.1.1 Planning Phase.................................................................................1.3.2.1.2 Prepare Phase..................................................................................1.3.2.1.3 Execute Phase..................................................................................1.3.2.1.4 Assess Phase...................................................................................
1.3.2.2 TSS.........................................................................................................2 Acquisition Pathway and Objectives.....................................................................
2.1 Software Acquisition Pathway............................................................................2.2 Objective.............................................................................................................
3 Requirements...........................................................................................................3.1 Program Management........................................................................................3.2 Associate Vendor Agreements...........................................................................3.3 Communication...................................................................................................3.4 Reviews............................................................................................................3.5 System Engineering..........................................................................................3.6 Configuration Management..............................................................................
3.6.1 Configuration Identification..........................................................................3.6.2 Configuration Control...................................................................................3.6.3 Configuration Status Accounting.................................................................
3.7 Integration.........................................................................................................3.8 Deliverables......................................................................................................
3.8.1 Management Deliverables...........................................................................3.8.2 Engineering Deliverables.............................................................................3.8.3 Product Support Deliverables......................................................................
iiDISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
3.8.4 TSMT Hardware Deliverables.....................................................................3.8.5 Cost Deliverables........................................................................................
3.9 System Requirements......................................................................................3.9.1 General........................................................................................................3.9.2 Architecture.................................................................................................3.9.3 Point of Need...............................................................................................
3.9.3.1 Point of Need Conditions......................................................................3.9.3.2 Network................................................................................................3.9.3.3 Cloud....................................................................................................3.9.3.4 Multi-level Security...............................................................................
3.9.4 TSMT Hardware..........................................................................................3.10 Agile Process....................................................................................................
3.10.1 General........................................................................................................3.10.2 Agile Ceremonies........................................................................................3.10.3 Agile Metrics................................................................................................3.10.4 Roadmap.....................................................................................................3.10.5 DevSecOps.................................................................................................
3.11 Testing..............................................................................................................3.11.1 Incremental Government Testing................................................................3.11.2 Integration Environment..............................................................................3.11.3 Development Testing...................................................................................3.11.4 Cybersecurity Tests and Events..................................................................
3.12 Product Support................................................................................................3.12.1 General........................................................................................................3.12.2 Interim Contractor Support..........................................................................3.12.3 Maintenance Planning/Concept...................................................................3.12.4 Warranty......................................................................................................3.12.5 Configuration Audits....................................................................................3.12.6 Diminishing Manufacturing Sources and Material Shortages......................3.12.7 Technical Support Documentation..............................................................3.12.8 Training.......................................................................................................3.12.9 Item Unique Identification............................................................................3.12.10.......................................................................................................System Delivery
60iii
DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
8990
3.13 Security.............................................................................................................3.13.1 Industrial Security........................................................................................3.13.2 Cybersecurity..............................................................................................
3.13.2.1 Cyber Survivability................................................................................3.13.2.2 Risk Management Framework..............................................................3.13.2.3 Cross Domain Solution Authorization (CDSA)......................................3.13.2.5 Cybersecurity Training..........................................................................
3.14 Safety and Health.............................................................................................3.14.1 Safety..........................................................................................................3.14.2 Health..........................................................................................................
4 References.............................................................................................................Appendix A Capability Descriptions........................................................................
A.1 One World Terrain...........................................................................................A.2 Reconfigurable Virtual Collective Trainer........................................................A.3 Live Virtual Constructive Integrating Architecture...........................................A.4 Mission Command Information Systems.........................................................A.5 Avionics Software Emulation...........................................................................A.6 Common Software Library..............................................................................A.7 Army Training Information System..................................................................A.8 Soldier Virtual Trainer.....................................................................................A.9 Integrated Visual Augmentation System / Soldier Immersive Virtual
Trainer.............................................................................................................A.10 STE Live Training System...............................................................................
Appendix B Objective Values...................................................................................Appendix C Capability Roadmap.............................................................................Appendix D Notional MVP/MVCR/Release Plan......................................................Appendix E IMS Template.........................................................................................Appendix F Cost Deliverables..................................................................................
F.1 CSDR DD 2794...............................................................................................F.2 Software Resources Data Report....................................................................F.3 Cost and Hour Report (FlexFile) Contractor Format IAW File Format
Specification (FFS) and Data Exchange Item (DEI)........................................F.4 Quantity Data Report (-Q) Contractor format IAW FFS and DEI.....................
Appendix G Cybersecurity........................................................................................iv
DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111112
113
114
115
116
117
118
119
120
121122
123
124
G.1 DoD CDS Connection Process Diagram........................................................Appendix H Acronyms and Glossary.......................................................................
H.1 Acronyms........................................................................................................H.2 Glossary..........................................................................................................
vDISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
125
126
127
128
129
List of Figures
Figure 1-1. STE OV-1...................................................................................................................
Figure 1-2. Synthetic Training Environment.............................................................................
Figure 1-3. TMT Interaction.........................................................................................................
Figure G-1. DoD CDS Connection Process Diagram.........................................................
List of Tables
Table 3-1. Recurring Government Meetings............................................................................
Table 3-2. Development / User Feedback Locations............................................................
Table 3-3. Fielding Locations....................................................................................................
Table B-1. Objective Values.........................................................................................
Table H-1. Acronyms....................................................................................................
Table H-2. Glossary.....................................................................................................
viDISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
This page intentionally left blank.
viiDISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
146
147
148
149
150
151
152
153
154
155
1 Overview1.1 Problem StatementThe Army currently employs a collection of outdated, cyber-vulnerable, and inefficient live, virtual, constructive, gaming (LVCG) collective training systems that form the Integrated Training Environment (ITE) which is not available at the Point of Need (PoN). These systems do not replicate the complex challenges of the current and future Operational Environment (OE) nor are they agile enough to allow Warfighters to train multiple iterations prior to mastering training in the live training environment. As we set the foundation for a Multi-Domain Operations (MDO) capable force in 2028, these critical capability gaps degrade Warfighter training readiness and performance placing our Nation’s defense at risk.
1.2 Synthetic Training Environment OverviewThe Army’s future training capability is the Synthetic Training Environment (STE). The STE will be a single, interconnected training system that provides a training environment, in which units from Soldier/Squad through Army Service Component Command (ASCC) conduct collective training, see Figure 1-1 below.
Figure 1-1. STE OV-1.
1DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
156
157158159160161162163164165166
167
168169170171
172
173
The STE is deliberately envisioned to converge the LVCG environments as one complete training capability. This training capability will enable Army units and leaders to conduct realistic multi-echelon / multi-domain combined arms maneuver and mission command training, increasing proficiency through repetition. This allows units to enter collective level training in the live environment at a much higher level of proficiency. The STE will deliver collective training, accessible at the PoN in the operational, self-development and institutional training domains. The STE is an essential component for the Army to fully realize the Standard of Training Proficiency (STP) required and levels of proficiency.
The STE must have the ability to change with technology, allowing for the replication/representation of current and future force structure, weapons effects, warfighting functions, Joint, Interagency, and Multinational (JIM) capabilities, human interaction, dense urban environment and near-peer threat capabilities. The STE will be capable of training units across the full range of Unified Land Operations (ULO) in multiple domains (Air, Land, Maritime, Cyber, and Space).
The STE provides a synthetic environment to represent and enable rapid generation of the OE. Scalable immersive collective trainers provide the commander with multiple training capability options to train operational tasks at the PoN with around-the-clock accessibility. The STE operates in connected and disconnected modes (for training under limited or degraded network conditions) and is embedded within the Common Operating Environment (COE). The STE leverages the Army Network (enterprise and tactical) to either host or deliver capabilities and provides intuitive, composable applications and services that enable embedded training with mission command workstations and select platforms. Future Live training systems will interface with the STE to incorporate instrumentation, ranges, targets, and ammunition into the synthetic environment. Next Generation Constructive will expand training of large-scale Brigade Combat Team (BCT) through ASCC. The integrated STE system consists of three foundational capabilities that are each a separate other transaction authority (OTA) effort:
Training Support Management Tool (TSMT) that consists of the Training Simulation Software (TSS), Training Management Tool (TMT), and hardware
Reconfigurable Virtual Collective Trainers (RVCT) One World Terrain (OWT)
The STE delivers software, application(s) and services that will enable the RVCT and other training capabilities. The STE will enable multi-level security through a cross domain solution (CDS). The STE architecture and design enables and supports interoperability with existing training systems (Live, Virtual, Constructive Integrating Architecture [LVC-IA], Joint Land Component Constructive Training Capability
2DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
174175176177178179180181182
183184185186187188
189190191192193194195196197198199200201202
203204205206
207208209210211
[JLCCTC], Homestation Instrumentation Training System [HITS]); and future training systems Soldier Virtual Trainer (SVT), the embedded Integrated Visual Augmentation System (IVAS) with Soldier Immersive Virtual Trainer (SiVT), future Next Generation Constructive (NGC), Synthetic Training Environment - Live Training System (STE-LTS) and operational capabilities.
TSMT is planning to utilize the Department of Defense (DoD) Software Acquisition Pathway (SAP) as defined by DoDI 5000.02 Operation of the Adaptive Acquisition Framework. In accordance with this pathway the delivery of TSMT capability is defined in terms of Minimum Viable Products (MVP), an initial Minimum Viable Capability Release (MVCR), and annual software releases after initial MVCR.
1.3 Training Support Management Tool Overview1.3.1 TSMT ScopeThis Performance Work Statement (PWS) defines the scope for providing the integrated TSMT solution identified in Figure 1-2 by the red outlined box. The scope is a Brigade and Below collective training capability. This capability includes Soldier/Squad to BCT virtual and a Brigade and below constructive staff training capability. The vendor shall design and build the TSS and TMT software, and provide TSMT Hardware.
Figure 1-2. Synthetic Training Environment.
The TSMT solution will use OWT products and integrate with RVCT as a cohesive STE system. The vendor will need to monitor, collaborate, and integrate with OWT, RVCT, SVT, IVAS-SiVT, and interfaces to Mission Command Information Systems (MCIS) (see
3DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
212213214215216
217218219220221
222
223
224225226227228
229
230
231232233
full list of MCIS in the Technical Data Package [TDP] Appendix E Systems Requirements Document [SRD]), Avionics Software Emulation [AvSE], Common Software Library [CSL], authoritative data sources (see TDP Appendix A, Authoritative Data Sources for additional information), and LVC-IA. This PWS will refer to the set of vendors in the preceding sentence as the STE system capability and interface vendors. Descriptions of these capabilities (e.g., OWT, RVCT) are in Appendix A Capability Descriptions.
The Brigade and Above capability is outside the scope of this OTA however, it and other objective values are identified in Appendix B Objective Values to provide a holistic STE vision. The MVP, MVCR, and subsequent software releases must not preclude achieving the Objective Values and scalability up to ASCC in the future.
The TSMT system bi-directionally communicates with MCIS. The TSMT system interfaces with LVC-IA to incorporate HITS, JLCCTC and Intelligence Electronic Warfare Tactical Proficiency Trainer (IEWTPT) into an exercise.
1.3.2 Capability Overview1.3.2.1 TSMT
The TSMT is the “core” simulation software and hardware that provides a common synthetic environment, the exercise design and control tool, and data manager for STE collective training.
Figure 1-3. TMT Interaction.
4DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
234235236237238239240
241242243244
245246247
248
249
250251252
253
254
1.3.2.1 TMT
TMT is the single Army user interface for exercise design, and execution control used at all echelons to plan, prepare, execute, and assess multi-echelon collective training. Figure 1-3 depicts TMT, the data manager for TSMT.
1.3.2.1.1 Planning Phase
TMT enables Commanders and Leaders at all echelons to design exercises and scenarios to meet training objectives. TMT uses authoritative sources to ensure realism by representing force structure and the OE as closely possible.
1.3.2.1.2 Prepare Phase
TMT performs the orchestration, provisioning, scheduling, and deployment of infrastructure, training, and simulation resources identified in the plan phase. TMT provides OWT terrain, parametric data, force structure and equipment, 3D moving models, behaviors, OE information, and other data required for simulator/simulation initialization.
1.3.2.1.3 Execute Phase
TMT exercise control (EXCON) monitors, collects, facilitates runtime assessments and interventions, and stores all simulation data while providing Commanders and Training Managers near real-time information. The TMT EXCON enables in progress scenario changes to achieve training objectives and to tailor the experience to the training audience level of proficiency.
1.3.2.1.4 Assess Phase
TMT automates nomination of significant activities (SIGACTs) and development of multi-media After-Action Review (AAR) as an initial baseline for training managers and commanders review so they can provide feedback to the training units. TMT supports Force Readiness measures and reporting across the collective training spectrum within the Sustainable Readiness Model and Standards for Training Proficiency goals.
1.3.2.2 TSS
The TSS is the STE ‘core’ simulation engine that provides a synthetic environment to enable collective training from Soldier/Squad through BCT across the Fires, Movement and Maneuver, and Mission Command Warfighting Functions (WfF) and supporting the Sustainment, Protection, and Intelligence WfFs. TSS ensures fair fight adjudication for interactions in the STE system. The TSS synthetic environment is delivered over the network to RVCT, MCIS, and other interfaces.
5DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
255
256257258
259
260261262
263
264265266267268
269
270271272273274
275
276277278279280
281
282283284285286287
The TSS provides computer generated forces (CGF) of BLUEFOR, OPFOR, civilians, ground vehicles, and air platforms. The TSS provides a functional virtual representation of RVCT platforms and provides the simulation software core for RVCT platforms. For example, the TSS renders the inside view of an Apache helicopter, visually displaying the interior of the cockpit with all the functional displays and switches/interfaces needed for collective training. TSS also renders the out-the-window views that the pilot and copilot see when flying through the synthetic environment as well as models or represents all RVCT platform performance, weapons, sensors, targeting, communications, and mission command subsystems.
2 Acquisition Pathway and Objectives2.1 Software Acquisition PathwayThe TSMT will use the SAP. This pathway facilitates rapid and iterative delivery of software capability to the user. The SAP employs a modern, agile and, Development Security Operations (DevSecOps) software development practices. This allows delivery of secured working software rapidly and iteratively to meet the highest priority user needs. SAP uses automated tools for development, integration, testing, deployment/delivery, and certification to iteratively update software capabilities.
Appendix C Capability Roadmap contains the Government’s initial product roadmap. Appendix D Notional MVP/MVCR/Release Plan provides a notional MVP/MVCR/Release plan. The Government’s expectation is that the vendor will utilize the initial capability roadmap,the notional release plan and the vendor’s technical approach to develop a revised capability roadmap, an MVP/MVCR/Release plan and an Integrated Master Schedule (IMS) that meets or exceeds the requirements of the initial backlog as defined by the SRD. The Government’s expectation for initial MVCR is defined as:
Delivery of the highest echelon (Company, Battalion, Brigade) multi-level security collective training capability focused on identified Combine Arms Training Strategy (CATS) tasks.
Enables the training audience to plan, prepare, execute, and assess (PPEA) collective training.
MVCR verification, validation, and accreditation process complete. Meets Cybersecurity requirements. Fielding to Fort Hood is complete. New Equipment Training (NET) at Fort Hood is complete. All contractor requirements for TSMT operations and support are in place and
ready to support unit training at Fort Hood.
6DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
288289290291292293294295296
297
298
299300301302303304
305306307308309310311312
313314315316317318319320321322323
2.2 ObjectiveThe TSMT objective is to provide a Soldier/Squad through Brigade collective training capability with increased capability for Commanders / Soldiers to train and closes the ITE limitations without creating new gaps. (i.e., Close Combat Tactical Trainer [CCTT]; Aviation Combined Arms Tactical Trainer [AVCATT]; and Games for Training [GFT] and a Brigade and below constructive staff and Commander training capability). The STE system enables the Unit/Staff to train offense, defense, and stability support operations realized through the CATS to set the foundation for an MDO capable force. Some of the collective training task sets are provided in the TDP Appendix B Collective Training Task Sets and training tasks in the TDP Appendix C Collective Training Tasks for additional collective task information.
TSMT is integrated with the OWT and RVCT to achieve a holistic STE capability. The intent of the integrated STE system is to provide value to the end user with each MVP and MVCR that enables units to conduct their doctrinal collective training. Subsequent STE system releases continue to improve the collective training capability (higher echelon, new functionality, etc.). Program Increments, MVP/MVCR/subsequent software releases continue to build on the capabilities in the previous gate.
A successful TSMT system provides the features identified in the TSMT product roadmap. The product roadmap is a series of incremental capability deliveries that provide a working / functional training capability for the user to provide feedback. In addition, Solider Touchpoints will be conducted on an integrated solution (RVCT with TSMT and OWT software). Soldier Touchpoints will be conducted with an operational unit (Forces Command [FORSCOM], Army National Guard [ARNG], and Office of the Chief Army Reserve [OCAR] coupled with the Army Capability Manager [ACM], Cross Functional Team [CFT] and Center of Excellence [CoE] Subject Matter Experts [SMEs]). A successful TSMT system provides an entity level simulation that provides virtual and constructive collective training, training to soldiers, squads, platoons, companies, battalions, and brigades. It is also interoperable with LVC-IA to enable interoperability with HITS, JLCCTC and IEWTPT (IEWTPT interoperability is through JLCCTC and LVC-IA); and bi-directionally communicates with RVCT, SVT, IVAS-SiVT, and operational capabilities (e.g., MCIS, AvSE, CSL, air, and ground platforms) enabling Commanders and units to achieve their collective training objectives at the PoN.
The Government will evaluate the technical feasibility and military utility of the TSMT solution as the foundation for the STE. The end-state of the TSMT system is the creation and successful implementation of a modular open system approach that delivers the foundational capabilities in support of the holistic STE vision.
7DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
324
325326327328329330331332333334
335336337338339340
341342343344345346347348349350351352353354355
356357358359
3 RequirementsThe requirements defined herein shall form the basis for all work that the vendor shall perform as part of the agreement the Government will issue under the TSMT OTA award for the design, development, integration, testing, delivery, and product support of TSMT.
3.1 Program ManagementThe vendor shall accomplish all planning, execution, risk management, reporting and related program management activities to ensure that the technical, schedule, and financial requirements of this PWS are accomplished in accordance with (IAW) the Government approved product roadmap. Program Management documentation shall include an integrated master plan and monthly program management metrics, technical, financial, and schedule status.
3.1.1 The vendor shall provide a set of program management metrics for the Government to approve.
3.1.2 The vendor shall provide and brief monthly program management metrics to the Government and when requested by the Government.
3.2 Associate Vendor AgreementsAssociate Vendor Agreements (AVA) are the basis for sharing information, data, technical knowledge, expertise, and/or resources essential to the integration of TSMT. AVAs ensure the greatest degree of cooperation for the development of the program to meet the terms of the efforts.
The vendor shall establish associate vendor agreements and collaborate with STE vendors.
The vendor AVA shall identify potential conflicts between relevant Government contracts, agreements, and the AVA; the agreement shall also include agreements on protection of proprietary data and restrictions on employees.
The vendor shall not be relieved of any requirements or entitled to any adjustments to the agreements terms because of a failure to resolve a disagreement with an associate vendor.
The vendor shall collaborate with STE vendors to develop the data model. The vendor shall collaborate with STE vendors to develop Application.
Programming Interfaces (APIs) and Interface Control Documents (ICDs).
8DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
360
361362363364
365
366367368369370371
372373
374375
376
377378379380
381382383384385386387388389390391
3.3 CommunicationThe STE requires the coordination of multiple OTA vendors. The core effort of STE is the TSMT OTA. The TSMT OTA vendor is in the best position to understand the interdependencies between the supporting OWT and RVCT OTAs.
3.3.1 The vendor shall establish and maintain regular communication with the Government team (both formal and informal) so that the Government can identify, assess, and resolve deviations in a timely manner.
3.3.2 The vendor shall provide technical and programmatic project status to the Government during status meetings.
3.3.3 The vendor shall participate in recurring meetings as directed by the Government (see Table 3-1).
Table 3-1. Recurring Government Meetings.
Meeting Location Host FrequencyArchitecture Synchronization TBD Government WeeklyAvSE IPT TBD Government WeeklyCost Working IPT TBD Government TBDCyber IPT TBD Government WeeklyIntegration IPT TBD Government WeeklyNetwork/Cloud WG TBD Government WeeklyOWT Coordination TBD Government WeeklyPre-Program Increment Planning Meeting TBD Government TBD
Product Support IPT TBD Government WeeklyProduct/Requirement Manager Synchronization TBD Government Weekly
RVCT Coordination TBD Government WeeklyScience and Technology IPT TBD Government MonthlyScrum of Scrums TBD Government WeeklySiVT IPT TBD Government MonthlySystem Safety Working Group TBD Government TBDTesting WIPT TBD Government WeeklyTMT IPT TBD Government WeeklyTSMT IPT TBD Government WeeklyTSS IPT TBD Government WeeklyOthers as directed by the Government TBD Government TBD
9DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
392
393394395
396397398
399400
401402
403
3.4 Reviews3.4.1 The vendor shall host and conduct technical interchange meetings (TIM) and test and
assessment reviews to inform Government approval of the product design at least once prior to each program increment, MVP, the MVCR, and subsequent software releases and as requested by the Government.
3.4.2 The vendor shall summarize the TIM and test and assessment reviews discussions, action items, risks, dependencies, and issues and submit to the Government not later than (NLT) 5 calendar days after the event and manage the action items list until all items are accepted by the Government in accordance with the deliverables (3.8.1.1 and 3.8.1.4).
3.5 System EngineeringThe vendor shall use the agreed upon Agile systems engineering process and DevSecOps environment to plan, design, develop, incorporate, test, and deliver STE system of systems capabilities.
3.5.1 The vendor shall identify risks, issues, and mitigating actions.
3.5.2 The vendor shall deliver a requirements traceability/verification matrix that traces requirements from the STE Information System Abbreviated – Capability Development Document (A-CDD) through the PWS, System Requirements Document (SRD), System/Sub System Specification (SSS), Software Requirements Specification (SRS) and test cases to the delivered products in accordance with deliverables ().
3.5.3 The vendor shall support Government coordination across efforts performing the managerial and technical systems engineering processes.
3.6 Configuration ManagementThis section references the traditional functional, allocated and product baselines. These terms equate to the following Agile elements:
Functional Baseline: The entire set of all the prioritized features in all the program increments, MVPs, MVCR, and Subsequent Software releases. This is documented in the Product Roadmap and Product Backlog.
Allocated Baseline: The planned set of prioritized features to be developed in a specific program increment, MVP, MVCR, and subsequent software releases. This is specific segment in the Product Roadmap and Product Backlog.
10DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
404
405406407408
409410411412413
414
415416417
418
419420421422423
424425
426
427428
429430431432433434435
Product Baseline: The features delivered in the working software for the specific program increment, MVP, MVCR, and subsequent software releases.
3.6.1 Configuration Identification3.6.1.1 The vendor shall ensure configuration identification, control, and status accounting of all
TSMT system hardware, software, and documentation including Government-furnished information and vendor-supplied items for the period of performance of this effort.
3.6.1.2 The vendor shall identify the TSMT hardware and software configuration in the Functional, Allocated and Product Baselines.
3.6.1.2.1 The vendor shall document the Functional Baseline as defined by the SRD and incremental Contractor Data Requirements List (CDRL) deliveries.
3.6.1.2.2 The vendor shall document Allocated Baseline as defined by the incremental CDRL deliveries, approved requirements, MVP, MVCR and subsequent software releases.
3.6.1.2.3 The vendor shall document the Product Baseline as defined by CDRL deliveries, MVCR, and subsequent software releases.
3.6.1.2.4 The vendor shall, in consonance with the Government, select the Configuration Items (CIs) to be identified and assign hierarchical identifiers to each CI, select the configuration documentation to be used to identify each CI, define and document interfaces between CIs, and establish a release system for the control of configuration documentation and computer software source code.
3.6.1.3 The vendor shall ensure that hardware and software data and equipment audits are the same.
3.6.1.4 The vendor shall seek approval for the initial system configuration and for subsequent system configuration changes during the Government hosted Product/Requirement Manager Synchronization meeting.
3.6.1.5 The vendor shall document the Product/Requirement Manager Synchronization meeting process in a Configuration Management Plan (CMP), to be delivered via Enterprise Mission Assurance Support Service (eMASS).
3.6.1.6 The vendor shall provide Product/Requirement Manager Synchronization meeting minutes and all applicable artifacts for review to the government via eMASS in accordance with deliverable 3.8.1.2.
3.6.1.7 The vendor shall deliver an updated hardware and software list and functional architecture diagram artifact prior to each test and functional validation event via eMASS in accordance with deliverable 3.8.1.2.
3.6.2 Configuration Control
11DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
436437
438
439440441
442443
444445
446447
448449
450451452453454
455456
457458459
460461462
463464465
466467468
469
3.6.2.1 The vendor shall control CI for all baselines by form, fit, function, interchangeability, and interoperability.
3.6.2.1.1 The vendor shall control and change all baselines using contractor change and engineering release process.
3.6.2.1.2 The vendor shall request Government approval for all proposed changes that affect the form, fit, function, interchangeability, or interoperability of the current system configuration.
3.6.2.1.3 The vendor shall ensure that all changes to the baselines result in a common configuration for Government operational use and maintenance activities that provides interchangeability and interoperability.
3.6.2.1.4 The vendor shall ensure that proposed engineering changes to CIs are fully coordinated and documented in accordance with the deliverables (3.8.1.4, 3.8.2.10, and 3.8.2.11).
3.6.3 Configuration Status Accounting
3.6.3.1 The TSMT vendor shall identify and document all items incorporated into or deleted from the TSMT during development.
3.6.3.1.1 The contractor shall prepare the information Baseline Description Document IAW the deliverable (3.8.2.11) for each baseline.
3.7 IntegrationThe vendor shall be responsible for the full range of integration activities associated with planning, coordination, and documentation of the STE system capability and interfaces to include STE system capability and interface vendors. These duties shall include the following integration responsibilities to assist Government oversight and decision making.
3.7.1 The vendor shall work with the STE system capability and interfaces vendors and the Government to identify and document integration risks and issues associated with vendor scope, delivery schedule, and design misalignments.
3.7.2 The vendor shall document the integrated STE plan to include action items, software management baselines and Configuration Management.
3.7.3 The vendor shall plan and coordinate STE system capability and interface vendors participation in routine vendor integration events and touchpoints in the Technology Integration Facility (TIF) located in Partnership IV supported by vendor labs and other USG infrastructure.
12DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
470471
472473
474475476
477478479
480481482
483
484485
486487
488
489490491492493
494495496
497498
499500501502
3.7.4 The vendor shall evaluate Government provided Science and Technology (S&T) handovers to assess reuse potential to meet TSMT requirements and develop plans for integration with TSMT baseline. If a handover is not suitable for reuse, the vendor shall provide supporting rational.
3.8 DeliverablesThe vendor shall provide the following list of deliverables to the Government throughout the performance of this effort. These deliverables serve to provide the performance data and product support data to the Government to allow for the appropriate planning and oversight for the TSMT.
3.8.1 Management DeliverablesVendor format is acceptable and shall be delivered electronically in MS Office compatible formats unless otherwise noted. The Government provides the Data Item Descriptions (DID) for vendor consideration.
3.8.1.1 Name: Contractor's Progress, Status and Management Report (CPSMR)
Purpose: Documents and tracks program performance, agile metrics, DevSecOps metrics, tasks, agreements and existing or potential problem areas.
Initial Submission Due: 30 days after Contract Award
Recurring Submissions Due: Monthly
DID: DI-MGMT-81928 (§10.3 A-F; H; and J only) The Government reserves the right to modify the CPMSR management deliverable content during execution.
3.8.1.2 Name: DoD Risk Management Framework (RMF) Package Deliverables
Purpose: Contains the artifacts necessary to successfully achieve the Initial Authorization to Test (IATT) and Authority to Operate (ATO).
Initial Submission Due: Initial submission required 30 days after award to support Government IATT development.
Recurring Submissions Due: Subsequent submissions required 60 days before MVCR and follow-on releases to support Government ATO development.
DID: DI-MGMT-82001
Format: As specified in the DID.
13DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
503504505506
507
508509510511
512
513514515
516
517518
519
520
521522
523
524525
526527
528529
530
531
3.8.1.3 Name: Integrated Master Schedule (IMS)
Purpose: Contains data required to measure schedule performance on DoD acquisition contracts.
Instructions: The contractor shall provide a Microsoft Project schedule depicting their work for software development, internal integration activities, dependencies, system level integration with legacy programs, all other STE vendors, major milestones, fielding at the MVCR sites and post fielding logistics support. The contractor shall submit the schedule at the end of each month and shall accurately depict progress made on tasks, an initial baseline of all tasks and milestones, highlight new tasks after the first submission, highlight tasks that have exceeded the baseline, tasks that are at risk of exceeding baseline, schedule risks, and critical path tasks that have pushed major milestones past the baselined date.
Initial Submission Due: 30 days after Contract Award
Recurring Submissions Due: Monthly
Format: Use sample format in Appendix E IMS Template.
3.8.1.4 Name: Conference MinutesPurpose: Provides executive summary, documentation of technical information provided, decisions and agreements reached, and action items captured at meetings.Initial Submission Due: As required and NLT 5 days after the meetingRecurring Submissions Due: As required and NLT 5 days after the meetingDID: DI-ADMN-81250B
3.8.1.5 Name: Product RoadmapPurpose: Aligns prioritized functional and architecture features to a high-level calendar for each program increment, MVPs, MVCR, and subsequent software releases. Includes the sequence and timing of development, integration, test, and delivery. The product roadmap is a series of incremental capability deliveries that provide a working / functional training capability for the user to provide feedback.Initial Submission Due: NLT 5 calendar days after the initial program increment planning session.Recurring Submissions Due: NLT 5 calendar days after the increment, MVP, MVCR, and subsequent software releases program increment planning sessions.
14DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
532
533534
535536537538539540541542543544
545
546
547
548
549550551
552
553
554
555
556557558559560
561562
563564
3.8.2 Engineering DeliverablesVendor format is acceptable, except as noted and shall be delivered electronically in MS Office compatible formats unless otherwise noted.
3.8.2.1 Name: Computer Software Product End Items
Purpose: Contains the format, content (including source code), and intended use information of the software deliverable
Initial Submission Due: Initial submission with first MVP
Recurring Submissions Due: Recurring submissions with all MVP, MVCR, and releases
DID: DI-AVCS-80700A
3.8.2.2 Name: DoD Architecture Framework Documentation (DoDAF)
Purpose: Used to provide architecture framework product documentation that describes characteristics pertinent to the purpose of the architecture.
Models Based System Engineering (MBSE) Approach Addendum: The Government has provided the MagicDraw tool to share engineering information. The Government will provide access to the initial set of DoDAF views and other SysML diagrams in the MagicDraw tool. The vendor shall use the existing DoDAF views and SysML diagrams as a starting place and will expound on these views and create others as needed and agreed to by the Government. The vendor shall create and share digital DoDAF views in and through the MagicDraw tool.
Agile Approach Addendum: The vendor shall continuously reference and evolve DoDAF views and SysML diagrams as required during development sprints. The vendor shall revise existing and create new views and diagrams as necessary and agreed-upon by the Government. Initial Submission Due: The vendor shall make initial revisions to existing models and begin adding new views at the completion of the first development sprint.
Recurring Submissions Due: The vendor shall continuously update and evolve DoDAF views and SysML diagrams throughout the life of the project. The vendor shall conduct reviews during sprint planning, program increment planning, and MVP/MVCR/subsequent software release completion. The vendor shall conduct additional, issue specific reviews when directed by the Government. Report snapshots may be drawn from the MagicDraw tool by any person who has
15DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
565
566567
568
569570
571
572573
574
575
576577
578579580581582583584585
586587588589590591592
593594595596597598
access to the tool(s) at any time. DID: DI-MGMT-81644B; the vendor shall provide the: AV-1, AV-2, OV-1, OV-2, OV-3, OV-4, OV-5a, CV-2, CV-3, CV-6, DIV 1, DIV 2, DIV 3, SV-1, SV-2, SV-4, SV-5a, SV-6, SV-7, SV-8, and StdV-1, and StdV-2. The vendor shall provide other views as directed by the Government.
Format: As specified in DoDAF 2.02 using the MagicDraw tool.
3.8.2.3 Name: Interface Design Description (IDD)
Purpose: Describes the interface characteristics of one or more systems, subsystems, hardware configuration items, computer software configuration items, manuals, or other system components.
MBSE Approach Addendum: The Government will provide several architectural and design products of the desired system in DoDAF views and Systems Modeling Language (SysML) diagrams to the vendor at contract award in the MagicDraw tool. The vendor shall use and build on these products to further define system and component interface specifications in the digital models created in and shared through the MagicDraw tool. The vendor shall use appropriate DoDAF views and/or SysML diagrams to capture the interface descriptions.
Agile Approach Addendum: The vendor shall continuously reference and evolve interface description models during development sprints. The vendor shall add new interfaces and interface descriptions as necessary and agreed-upon with the Government.
Initial Submission Due: The vendor shall provide models in the MagicDraw tool at the completion of the first development sprint.
Recurring Submissions Due: The vendor shall continuously update and evolve models throughout the life of the project. The vendor shall conduct reviews during sprint planning, program increment planning, and MVP/MVCR/subsequent software release completion. The vendor shall conduct additional, issue specific reviews when directed by the Government. Report snapshots may be drawn from the MagicDraw tool by any person who has access to the tool(s) at any time.
Sample Data Item Description: DoDAF 2.02; SysML 1.6
3.8.2.4 Name: Software Version Description (SVD)
Purpose: Identifies and describes a software version consisting of one or more Computer Software Configuration Items (CSCIs). It is used to release, track, and control software versions.
16DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
599600601602603
604
605
606607608
609610611612613614615616
617618619620
621622
623624625626627628
629
630
631632633
Initial Submission Due: Initial submission with the first MVP.
Recurring Submissions Due: Recurring submissions with all MVP, MVCR, and subsequent software releases.
DID: DI-IPSC-81442
3.8.2.5 Name: System/Subsystem Design Description (SSDD) or Software Product Specification (SPS)
Purpose: Describes the system or subsystem-wide design and the architectural design of the system and/or subsystem.
MBSE Approach Addendum: The Government will provide several architectural and design products of the desired system in DoDAF views and SysML diagrams to the vendor at contract award in the MagicDraw tool. The vendor shall use and build on these products to further define system and component design specifications in digital models created in and shared through the MagicDraw tool. The vendor shall use appropriate DoDAF views and/or SysML diagrams to capture the design descriptions. The vendor shall create/use SysML diagrams and DoDAF views to the extent that they are relevant to producing or managing the overall system as agreed to with the Government.
Agile Approach Addendum: The vendor shall continuously reference and evolve design models as required during development sprints. The vendor shall add new design models and their descriptions as necessary and agreed-upon with the Government.
Initial Submission Due: The vendor shall provide models in the MagicDraw tool at the completion of the first development sprint.
Recurring Submissions Due: The vendor shall continuously update and evolve models throughout the life of the project. The vendor shall conduct reviews during sprint planning, program increment planning, and MVP/MVCR/subsequent software release completion. The vendor shall conduct additional, issue specific reviews when directed by the Government. Report snapshots may be drawn from the MagicDraw tool by any person who has access to the tool(s) at any time.
Sample Data Item Description: DoDAF 2.02; SysML 1.6
3.8.2.6 Name: System/Subsystem Specification
Purpose: Specifies the requirements for a system or subsystem and the methods to be used to ensure that each requirement has been met.
17DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
634
635636
637
638639
640641
642643644645646647648649650
651652653654
655656
657658659660661662
663
664
665666
Digital Engineering Approach Addendum: The Government will provide the vendor access to an initial Dynamic Object-Oriented Requirements System (DOORS) requirements repository at agreement award. The Government will also provide Cameo Data Hub to link the requirements in DOORS and the MagicDraw tool so requirements information can be efficiently included in the MBSE model diagrams/views. The vendor shall use the Government provided system requirements in the DOORS tool and shall update/annotate the requirements repository to indicate system model parts that satisfy requirements.
MBSE Approach Addendum: The vendor shall annotate and/or trace relations to system requirements in the digital models created in and shared through the MagicDraw tool. Tracing the relation to the requirements (e.g., Requirements Traceability Matrix [RTM]/Verification Matrix) depends on which DoDAF views and/or SysML diagrams the model uses and not all SysML diagrams or DoDAF views require tracing back to requirements. The vendor shall use requirement ID numbers consistently throughout the system model diagrams/views.
Agile Approach Addendum: The vendor shall use the requirements repository to form the Program, Iteration, and Sprint Backlogs. The vendor shall develop user stories that encapsulate the requirements into manageable sets. The vendor shall use requirement ID numbers consistently throughout the agile development process.
Initial Submission Due: The vendor shall begin agile planning with requirements and include requirements tracing to/from system model diagrams/views starting with the first development sprint.
Recurring Submissions Due: The vendor shall continuously update and evolve the requirements repository and the system model(s) throughout the life of the project. The vendor shall conduct reviews during sprint planning, program increment planning, and MVP/MVCR/subsequent software release completion. Report snapshots may be drawn from the requirements and MBSE tool(s) by any person who has access to the tools at any time.
Sample Data Item Description: DoDAF 2.02; SysML 1.6
3.8.2.7 Name: Test Plan
Purpose: Provides an overview of the DevSecOps, Incremental Government, and Cybersecurity Tests and Events test strategies to include scope and objectives.
Initial Submission Due: 30 days after contract award.
18DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
667668669670671672673674
675676677678679680681
682683684685686
687688689
690691692693694695
696
697
698699700
701
Recurring Submissions Due: 30 days after program increment planning.
DID: DI-SESS-80688
3.8.2.8 Name: Test Procedure
Purpose: Identifies the step-by-step testing operations to be performed on items undergoing developmental, qualification, or acceptance testing. Includes objectives and definitions of success.
Initial Submission Due: Initial procedure 45 days and final 10 days prior to Technical Assessments (TA).
Recurring Submissions Due: Every TA.
DID: DI-NDTI-80603A
3.8.2.9 Name: Test/Inspection ReportPurpose: The test/inspection report is used to document test/inspection results, findings and analyses that will enable the Government or contracting agency to evaluate compliance with system requirements, performance objectives, specifications, and test/inspection plans.Initial Submission Due: As required Recurring Submissions Due: As requiredDID: DI-NDTI-80809B
3.8.2.10 Name: Engineering Change Proposal (ECP)Purpose: Provides the documentation in which the engineering change is described and specifies how the proposed change will be implemented.Initial Submission Due: As required Recurring Submissions Due: As requiredDID: DI-SESS-80639E
3.8.2.11 Name: Request for Variance (RFV)Purpose: Describes a proposed departure from (a nonconformance with) approved product definition information for a limited amount of time/specified effectivity or a product found to be nonconforming with product definition information after the product has been produced by the production process.
When the RFV describes a proposed departure from approved product definition information (i.e., pre-production), the variance shall result in a reduction in cost; indicated by enclosing the value in parentheses.
19DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
702
703
704
705706707
708709
710
711
712
713714715716
717
718
719
720
721722
723
724
725
726
727728729730
731732733
When the RFV describes a product found to be nonconforming after the product has been produced (i.e., post-production), the variance shall result in a reduction in cost; indicated by enclosing the value in parentheses.
When the nonconformance is induced or caused by the Acquirer, a reduction in cost is not required when submitting the RFV.
Initial Submission Due: As required Recurring Submissions Due: As requiredDID: DI-SESS-80640E
3.8.2.12 Name: Baseline Description DocumentPurpose: Provide a list of unique identifiers for all requirement documents plus approved changes and physical hardware and software items in which the specifications, drawings, interface control documents, strategy, design and version description documents define the functional and physical characteristics. The principal use of this list is to designate configuration control of identified configuration items.Initial Submission Due: 30 days prior to the first MVPRecurring Submissions Due: 30 days prior to MVCR and each subsequent software releaseDID: DI-SESS-81121A
3.8.2.13 Name: Safety Assessment Report
Purpose: Comprehensive evaluation of the safety risks being assumed prior to test or operation of the system or at contract completion. It identifies all safety features of the system, design, and procedural hazards that may be present in the system being acquired, and specific procedural controls and precautions that should be followed.
Initial Submission Due: 30 days prior to the first MVP
Recurring Submissions Due: 30 days prior to MVCR and each subsequent software release
DID: DI-NDTI-80603A
3.8.3 Product Support DeliverablesDeliverables shall conform to the format identified in the Data Item Description and shall be delivered electronically in MS Office compatible formats unless otherwise noted.
20DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
734735736
737738
739
740
741
742
743744745746747748
749
750751
752
753
754755756757758
759
760761
762
763
764765
3.8.3.1 Name: Commercial Off-The-Shelf (COTS) Manuals & Associated Supplemental Data
Purpose: Documentation provided with COTS products that may be used “as is” or with supplemental data, if required.
Initial Submission Due: Draft 30 days prior to MVCR
Recurring Submissions Due: 30 days after MVCR and each subsequent software release (updates as required)
DID: DI-TMSS-80527C
3.8.3.2 Name: Interim Contractor Support (ICS) Parts Usage and Maintenance Data Collection Report
Purpose: Report gathers and uses ICS parts usage and maintenance data to predict future requirements for any given part of the component and end item/system, including part failures.
Initial Submission Due: 30 days after ICS begins
Recurring Submissions Due: Monthly
DID: DI-ILSS-81226
3.8.3.3 Name: Level of Repair Analysis (LORA) Report
Purpose: Documents and supports the contractor’s conclusions, findings, and recommendations on the economic, noneconomic and operational impacts concerning repair versus discard at failure; optimum repair levels; support equipment (which includes test program sets, built-in-test equipment, and test, measurement, and diagnostic equipment requirements); maintenance and supply support life cycle costs; spare parts provisioning; and specific design recommendations for each item undergoing the LORA.
Initial Submission Due: 30 days prior to MVP
Recurring Submissions Due: 30 days after MVCR and subsequent software release (updates as required)
DID: DI-PSSS-81872A
3.8.3.4 Name: Failure Modes, Effects, and Criticality Analysis (FMECA)
Purpose: Identifies independent single item failures and the resulting potential impact on mission success, performance, safety, and maintainability. The FMECA promotes corrective actions by identifying potential failure risk and
21DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
766767
768769
770
771772
773
774775
776777778
779
780
781
782
783784785786787788789
790
791792
793
794
795796797
maintainability issues in order that appropriate corrective actions may be taken early to eliminate or control high risk items to improve operational readiness and reduce life cycle cost. The FMECA also establishes the baseline engineering information to identify and eliminate or control all failure modes throughout the systems life cycle. The FMECA analytics establish the basis for fault detection, fault isolation, operator and maintainer failure recognition, depot test parameters and lay-in repair parts.
Initial Submission Due: 30 days prior to MVP
Recurring Submissions Due: 30 days after MVCR and each subsequent software release (updates as required)
DID: DI-PSSS-81495B
3.8.3.5 Name: Logistics Product Data w/Attribute Selection Worksheet
Purpose: Consists of data required for maintenance planning, logistics design requirements, reliability and maintainability, system safety, maintenance engineering, support and test equipment, training and training devices, manpower and skills, facilities, transportation, supply support, parts packaging, initial provisioning, cataloging, item management and in-service feedback.
Initial Submission Due: Draft 30 days prior to MVP
Recurring Submissions Due: 30 days after MVCR and each subsequent software release (updates as required)
DID: DI-SESS-81758A
3.8.3.6 Name: Preparation of Digital Technical Information for Electronic Technical Manuals (TMs) – STE DevSecOps Integrated Operations Guide
Purpose: Establishes the technical content, style, and format requirements for all TMs, including operator and maintenance TMs and can be used to develop TMs as paper, page-based manuals, or electronic technical manuals.
Initial Submission Due: Draft 30 days prior to MVP
Recurring Submissions Due: 30 days after MVCR and each subsequent software release (updates as required)
DID: MIL-STD-40051-1C
22DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
798799800801802803804
805
806807
808
809
810811812813814
815
816817
818
819820
821822823
824
825826
827
3.8.3.7 Name: Preparation of Digital Technical Information for Electronic Technical Manuals (TMs) – System User Manual
Purpose: Establishes the technical content, style, and format requirements for all TMs, including operator and maintenance TMs and can be used to develop TMs as paper, page-based manuals, or electronic technical manuals.
Initial Submission Due: Draft 30 days prior to MVP
Recurring Submissions Due: 30 days after MVCR and each subsequent software release (updates as required)
DID: MIL-STD-40051-1C
3.8.3.8 Name: Preparation of Digital Technical Information for Electronic Technical Manuals (TMs) – Quick Reference Card(s)
Purpose: Contains the requirements for development of Quick Reference Guides (QRGs).
Initial Submission Due: Draft 30 days prior to MVP
Recurring Submissions Due: 30 days after MVCR and each subsequent software release (updates as required)
DID: MIL-PRF-32614
3.8.3.9 Name: Product Engineering Design Data & Associated Lists
Purpose: Provides engineering data adequate to serve as an authoritative and complete technical description of an item. This data, when authorized, is adequate to support competitive procurement and maintenance for items interchangeable with the original items. This data represents the highest level of design disclosure.
Initial Submission Due: Initial submission with first MVP
Recurring Submissions Due: Recurring submissions with all MVPs, MVCR, and each subsequent software release
DID: DI-SESS-81000F
3.8.3.10 Name: Drawing Tree
Purpose: Identifies the interrelationships of engineering design data and associated lists that comprise the total engineering TDP prepared for each system, subsystem, and component configuration. The Engineering Drawing
23DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
828829
830831832
833
834835
836
837838
839840
841
842843
844
845
846847848849850
851
852853
854
855
856857858
Tree also aids in the control and development of design data in the overall project.
Initial Submission Due: 30 days prior to the first MVP
Recurring Submissions Due: 30 days prior to MVCR and each subsequent software release
DID: DI-DRPR-81961A
3.8.3.11 Name: Software Sustainability Package
Purpose: Contains the source code, design details, models, algorithms, processes, flow charts, formulae and related materials that would allow the software to be reproduced, recreated or recompiled, as needed for sustainment by non-developer(s) or the Original Equipment Manufacturer (OEM). This includes all executable software, design models, source files, and software sustainment information, including "as built" design information and compilation, build, and modification procedures for each CSCI.
Initial Submission Due: Initial submission with first MVP
Recurring Submissions Due: Recurring submissions with all MVPs, MVCR, and each subsequent software release
DID: DI-IPSC-82134
3.8.3.12 Name: Technical Manual Verification Discrepancy/Disposition Record
Purpose: Provides the contractor’s dispositions/resolutions to documented TM verification discrepancies and findings.
Initial Submission Due: Draft 30 days after each MVP
Recurring Submissions Due: Final 30 days prior to MVCR and each subsequent software release
DID: DI-TMSS-81820
3.8.3.13 Name: Training Aids, Devices, Simulators, and Simulations (TADSS) Materiel Component List (MCL)
Purpose: The MCL is listing of all system and non-system TADSS component parts and the data required to create a Component of the End Item List, Basic Issue Item (BII) List, and Additional Authorization List (AAL). The MCL contains the TADSS end item, discrete subassemblies, and nonexpendable components in an indentured format for TADSS end item. The MCL defines the property record of TADSS items and allows gaining commands to account for an end
24DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
859860
861
862863
864
865
866867868869870871872
873
874875
876
877
878879
880
881882
883
884885
886887888889890891
item's components. The Government provided format outlines the required structure of the data that gives the Government the ability to import the MCL into DoD databases or property accountability and property transfers.
Initial Submission Due: 30 days prior to MVP
Recurring Submissions Due: 30 days after MVCR and each subsequent software release (updates as required)
DID: DI-PSSS-82310
3.8.3.14 Name: Bill of Materials (BOM) for Logistics and Supply Chain Risk Management
Purpose: The BOM will provide information that can be used to establish the production status of parts used in a system. The BOM will also provide DMSMS management essential information that enables the identification, forecasting, mitigation, and management of Hardware and Software obsolescence as a part of the DoD Program Manager’s Total System Life Cycle Management responsibilities. The data will be used in the Diminishing Manufacturing Sources and Material Shortages (DMSMS) forecasting tools to allow for standard and efficient sharing of information on common items.
Initial Submission Due: 30 days prior to first MVP
Recurring Submissions Due: 30 days after MVCR and each subsequent software release (updates as required)
DID: DI-PSSS-81656B
3.8.3.15 Name: Training Materials
Purpose: Provides the materials required to support training on the end item equipment (e.g. video applications, applets, instructor guides, student guides, presentations, etc.).
Initial Submission Due: Initial submission with first MVP
Recurring Submissions Due: Recurring submissions with all MVPs, MVCR, and each subsequent software release
DID: DI-ILSS-80872
3.8.3.16 Name: Item Unique Identification (IUID) Marking and Verification Report
Purpose: A tabular list that provides physical asset marking, registration, verification, inventory audits, quality audits, and other asset lifecycle activities.
Initial Submission Due: 30 days prior to MVP
25DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
892893894
895
896897
898
899
900901902903904905906907
908
909910
911
912
913914915
916
917918
919
920
921922
923
Recurring Submissions Due: 30 days after MVCR and each subsequent software release (updates as required)
DID: DI-MGMT-81858
3.8.3.17 Name: Training System Support Document
Purpose: Provides complete procedures for using all software utility programs, support software file generation, and system performance characteristics verification for life cycle maintenance. This document also contains information to assist users in operating and fully using the training system during the presentation of course(s) of instruction, training exercise(s), or missions.
Initial Submission Due: Initial submission with first MVP
Recurring Submissions Due: Recurring submissions with each MVP, MVCR, and each subsequent software release
DID: DI-PSSS-81527C
3.8.3.18 Name: Trainer Facilities Report (TFR)
Purpose: The report defines and identifies criteria and requirements necessary to design and construct/modify a facility in which the trainer and associated equipment will be installed, operated, and maintained. The report identifies contractor and Government responsibilities and the time frame in which the responsibilities will be completed.
Initial Submission Due: 30 days prior to first MVP
Recurring Submissions Due: As required for each delivery site
DID: DI-FACR-80966F
3.8.3.19 Name: Training Device Inventory Checklist/Record (TD ICL/R)
Purpose: Provides a checklist and record of expendable and nonexpendable equipment and support items, including tools, test equipment, Government Furnished Equipment (GFE), technical documentation, software and spare and repairable parts that are delivered as part of or with the device or system. This report will be utilized during device acceptance, inventory and transfer of the training device or system.
Initial Submission Due: 30 days prior to first MVP
Recurring Submissions Due: 30 days after MVCR and each subsequent software release (updates as required)
26DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
924925
926
927
928929930931932
933
934935
936
937
938939940941942
943
944
945
946
947948949950951952
953
954955
DID: DI-MISC-81191B
3.8.3.20 Name: Data Accession List (DAL)
Purpose: Provides a medium for identifying contractor internal data which has been generated by the contractor in compliance with the work effort described in the PWS. The DAL shall also identify subcontractor/vendor data which has been generated per the Supplier Data Requirements List (SDRL) and the PWS. The DAL is an index of the generated data that is made available upon request for the period of performance of the contract as well as any additional period of time negotiated between the Government and the contractor and cited in the contract. The DAL is not a requirement to deliver all the data listed. The Government can use the list to order data from the list as cited in the contract.
Initial Submission Due: 30 days prior to the first MVP
Recurring Submissions Due: 30 days prior to MVCR and each subsequent software release
DID: DI-MGMT-81453B
3.8.3.21 Name: Training Equipment Summary
Purpose: Provides a complete condensed description of an end item of training equipment. It is made part of a training information electronic resource system (or equivalent) and is used for strategic planning, public relations, and foreign military sales.
Initial Submission Due: 30 days prior to the MVCR Recurring Submissions Due: 30 days prior to each subsequent software release DID: DI-MISC-81184A
3.8.3.22 Name: Technical Manual Verification Incorporation Certificate
Purpose: Provides the Government program manager with assurance that the contractor has resolved and/or incorporated into the final TM, corrections resulting from discrepancies/findings noted during TM verification.
Initial Submission Due: 30 days prior to the first MVP
Recurring Submissions Due: 30 days prior to MVCR and each subsequent software release
DID: DI-SESS-81821
27DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
956
957
958959960961962963964965966
967
968969
970
971
972973974975
976
977978
979
980
981982983
984
985986
987
3.8.3.23 Name: Training Conduct Support Document
Purpose: Provides specific definition and direction to the instructor and trainees on learning objectives, equipment, and instructional media for use during the conduct of training. It also provides updates to course materials for life cycle maintenance of the training course.
Initial Submission Due: 30 days prior to the first MVP
Recurring Submissions Due: 30 days prior to MVCR and each subsequent software release
DID: DI-SESS-81523D
3.8.3.24 Name: Course Conduct Information Package (completion)
Purpose: Provides data required by the Government to support outsourcing the conduct of training. This data will provide sufficient information to permit an accurate evaluation of a trainee’s capabilities to meet all learning objectives of a course. This data will also identify prerequisite skills and knowledge of trainees entering the course. The course conduct information package also provides information for trainees regarding the training syllabus, training organization, operating, scheduling, etc. It also provides information on an evaluation of the trainee’s performance, the trainee evaluation of training, and a certificate of completion of training for the trainee.
Initial Submission Due: 30 days prior to the first MVP
Recurring Submissions Due: 30 days prior to MVCR and each subsequent software release
DID: DI-SESS-81522D
3.8.3.25 Name: Instructional Media Package – Training Video
Purpose: Contains visual, textual, and audio information to be used in the development and presentation of training. It also includes the fully integrated instructional media presentation package.
Initial Submission Due: 30 days prior to the first MVP
Recurring Submissions Due: 30 days prior to MVCR and each subsequent software release
DID: DI-SESS-81526C
28DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
988
989990991992
993
994995
996
997
998999
1000100110021003100410051006
1007
10081009
1010
1011
101210131014
1015
10161017
1018
3.8.3.26 Name: Contractor Device Performance Report
Purpose: Documents time distribution, manning, work accomplished, problem areas, monthly hours to repair, and summarizes training device performance during the contract period.
Initial Submission Due: 30 days prior to the first MVP
Recurring Submissions Due: 30 days prior to MVCR and each subsequent software release
DID: DI-ILSS-80191D
3.8.3.27 Name: Warranty
Purpose: Provide information on items under warranty; contractor repair, replacement, and reimbursement; and equipment failure data associated with Reliability Improvement Warranties (RIWs). Data is used to track and assess the effectiveness and implementation of the contract warranty provisions; to apprise the government of the type, severity, and frequency of failures; to verify warranty coverage for each item delivered; and to document warranty periods and delivery schedules.
Initial Submission Due: 30 days prior to the first MVP
Recurring Submissions Due: 30 days prior to MVCR and each subsequent software release
DID: DI-SESS-81639A
3.8.3.28 Name: Configuration Audit Summary Report and CertificationPurpose: Provides a listing of text and marked-up technical documents (e.g., specifications, engineering drawings) that identify discrepancies between the materiel (including software) and the requirements delineated in the applicable technical documents. The Configuration Audit Summary Report and Certification also provides a documented certification that the audit was completed, and any discrepancies have been properly adjudicated.Initial Submission Due: 10 days after each Physical Configuration Audits (PCA) Recurring Submissions Due: As requiredDID: DI-SESS-81022E
3.8.3.29 Name: Configuration Audit PlanPurpose: Provides information required for conducting Functional Configuration Audits (FCA) and PCA.Initial Submission Due: 30 days prior to first MVP
29DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
1019
102010211022
1023
10241025
1026
1027
1028102910301031103210331034
1035
10361037
1038
1039
104010411042104310441045
1046
1047
1048
1049
10501051
1052
Recurring Submissions Due: As requiredDID: DI-SESS-81646C
3.8.4 TSMT Hardware DeliverablesThe Government based the quantity of hardware identified in the tables below on existing training systems. The vendor shall recommend a hardware set that enables Brigade and below collective training that minimizes the quantity, size, and logistics footprint for the Government to evaluate and approve. The training capability for RVCT Ground, RVCT Soldier, RVCT Air, and SVT shall be able to operate independently. For example, if a location has all training capabilities, that location shall be able to operate each training capability simultaneously and independent of each other. For additional hardware and point of need concepts see the TDP Appendix D TSMT Hardware Concept.
Table 3-2 identifies hardware quantities. The vendor shall provide all hardware, except the central node, in rugged, modular, weatherproof, and lockable storage/transit cases.
Table 3-2. Development / User Feedback Locations.
Name LocationCentral Node
CDSEdge Node
Field Server
EXCON Laptops
OC Mobile Device
Vendor Development Lab TBD As proposed by vendor
Government Orlando Labs FL 2 1 2 1 9 3
OTC TX 0 0 0 1 4 2ATEC TBD TBDPEO AVN / CCDC AV&MC AL 0 0 0 1 4 2
FT LVN KS 0 0 0 1 4 1Total 2 1 2 4 21 8
30DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
1053
1054
1055
105610571058105910601061106210631064
10651066
1067
1068
1069
Table 3-3 identifies the hardware quantities the vendor shall provide to the identified fielding sites. The Government based the hardware quantiles identified in the tables below on existing training systems.
Table 3-3. Fielding Locations.
Name Deliveries Central Node CDS Edge
NodeField
ServerEXCON Laptops
OC Mobile Device
Fort Hood, TXMVP / Operational Test
/ MVCR / Annual Releases
2 1 2 6 42 28
JBLM, WA Brigade Release 2 1 2 6 42 28 Fort Drum, NY Brigade Release 2 1 2 6 42 28Fort Benning, GA
Brigade Release 2 1 2 6 42 28
Fort Leonard Wood, MO
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 later than 75 days after contract award for the Government to approve.
3.8.4.2 The vendor shall choose hardware items that provide a reduction of total ownership costs and logistics footprint to include supply chain support and document in accordance with the deliverables (x.x.x).
3.8.4.2.1 The TSMT system shall avoid using any individual item whose unit purchase cost or spare price is greater than $25,000.
3.8.4.2.2 The TSMT system shall avoid using any individual item that has a projected removal/replacement rate greater than once per year.
3.8.4.2.3 The TSMT system shall avoid using any item that has a projected annual maintenance cost of greater than $10,000 per training device.
3.8.4.2.4 The TSMT system shall avoid using any item that requires special or extraordinary handling, disposal, usage rate, or maintenance procedures.
3.8.4.2.5 The TSMT system shall avoid using any item that will be unsupportable and out of production by the OEM within 36 months after MVCR or each subsequent annual software release.
31DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
107010711072
1073
10741075
107610771078
10791080
10811082
10831084
10851086
108710881089
3.8.4.3 The vendor shall preload the Central Node, Edge Node, Field Server, EXCON Laptop, and Observer Controller (OC) Mobile Devices with the current TSMT software release and the OWT data and models as appropriate prior to each delivery.
3.8.4.4 The vendor shall deliver all hardware in accordance with commercial best practices and applicable packaging, handling, storage, and transportation (PHS&T) standards.
3.8.4.5 The vendor shall deliver production representative hardware to development and user feedback sites no later than 30 days after the Government approves the vendor’s hardware concept, hardware quantities, and draft specifications IAW Table 3-2.
3.8.4.6 The vendor shall provide a cost option to replace production representative hardware at the development and user feedback sites with production hardware (final specification) after MVCR, release 1, and release 2.
3.8.4.7 The vendor shall update the software loads on the previously delivered hardware to the latest software baseline with each software release.
3.8.4.8 The vendor shall deliver production hardware (final specification) to fielding and operational testing sites to be available on the first day of fielding or the first day of the test event preparation window as appropriate.
3.8.4.9 The vendor shall provide cross domain solutions (software or hardware) for the development and fielding locations IAW Table 3-2 and Table 3-3.
3.8.5 Cost DeliverablesData submitters must register through the Cost Assessment Data Element (CADE) website (http://cade.osd.mil) and possess a DoD-approved External Certification Authorities (ECA) digital certificate or DoD-issued Common Access Card (CAC) to obtain a CADE Portal account and be authorized to upload CSDR content. Users can obtain access by submitting user information about themselves and their organizations to the CADE Portal and requesting a Cost and Software Data Reporting (CSDR) submitter user role. After the registration information has been verified the Defense Cost and Resource Center (DCARC) shall authorize the user account and requested roles. All CADE Portal accounts need to be renewed at least annually.
The prime vendor shall flow down CSDR requirements contained in the agreement to all sub-vendors who meet the reporting thresholds specified in DoDI 5000.02, or as required by the Cost Working Integrated Product Team (CWIPT). The prime and sub-vendors shall electronically report directly to the CADE Portal using the CSDR Submit-Review System.
In accordance with Statue 10 USC 2334 Sec. 842, DoDI 5000.02, and DFARS 252.234-7003 and 252.234-7004, “Notice of Cost and Software Reporting System”
32DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
109010911092
10931094
109510961097
109810991100
11011102
110311041105
11061107
1108
110911101111111211131114111511161117
11181119112011211122
11231124
This agreement includes the approved CSDR Plan for the agreement, DD Form 2794.
A CSDR Readiness Review Meeting will be held after agreement award to include a discussion of the CSDR process that satisfies the guidelines contained in the DoD 5000.04-M- 1, “CSDR Manual,” and the requirements in the approved CSDR Plan for the agreement, DD Form 2794, and related Resource Distribution Table.
Appendix F Cost Deliverables includes the CSDR requirements (DD Form 2794). Inclusive in the plan is the information required by CWBS for the respective Sub-vendor and Prime Vendor, schedule for report submission, and specific information as to format, address to send the information, and other pertinent facts. The WBS on Page 2 of the CSDR plan may be revised by the Government prior to agreement award. The final reporting WBS shall be determined jointly with the vendor and the CWIPT.
See Appendix F Cost Deliverables for additional information. The required form and file type for each CSDR is specified in its Data Item Description. The vendor may also submit electronically in accordance with the FlexFile Excel-Compatible Submission Guidance or the FlexFile Excel Template outlined in the FlexFile Implementation Guide located on the CADE website (http://cade.osd.mil).
3.8.5.1 The vendor shall systematically collect and report to CADE and the USG the actual contract costs and technical information based on the Office of the Secretary of Defense (OSD) Deputy Director Cost Analysis (DDCA)-approved CSDR plan IAW the CSDR Manual, DoDM 5000.04-M-1.
3.8.5.2 The vendor shall prepare the CSDRs in accordance with the instructions contained in the most recently approved versions of the DIDs (DIDs DI-MGMT-82035A, DI-FNCL-82162, DI-MGMT-82164.
3.8.5.3 The vendor shall submit electronically the Software Resources Data Report (3.8.5.3).
3.8.5.4 The vendor shall submit electronically the Cost and Hour Report (FlexFile) Contractor Format IAW File Format Specification (FFS) and Data Exchange Item (DEI) (3.8.5.4).
3.8.5.5 The vendor shall submit electronically the Quantity Data Report (-Q) Contractor format IAW FFS and DEI (3.8.5.5) using the CADE CSDR Submit-Review System.
3.8.5.6 In the performance of this contract, the vendor shall use:
1. A documented standard CSDR process that satisfies the guidelines contained in the DoD 5000.04–M–1, CSDR Manual,
2. Management procedures that provide for generation of timely and reliable information for the CCDRs and Software Resources Data Reports (SRDRs) required by the CCDR and SRDR data items of this contract,
33DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
1125
1126112711281129
113011311132113311341135
11361137113811391140
1141114211431144
114511461147
1148
11491150
11511152
1153
11541155115611571158
3. The approved CSDR Plan for this contract, DD Form 2794, and the related Resource Distribution Table as the basis for reporting according to the required CSDR DIDs,
4. The vendor shall require and flow down the requirement for CSDR reporting from sub-vendors regardless of tier with a sub-agreements that exceeds $50 million or sub-agreements valued between $20 million and $49 million that are designated by the Government as being high risk, high value, or of high technical interest. If, for sub-agreements that exceed $50 million, the vendor changes sub-vendors or makes new sub-agreement awards, the vendor shall notify the Government.
3.9 System RequirementsThe vendor shall ensure that the STE simulation represents and models units, organizations, lifeforms, and other like objects as individual entities at all times. Although aggregation is required to be applied for purposes of viewing, decluttering, or controlling large units or formations, internal simulation/game engine entity level modeling and entity level representation within network packets is always required. The STE definition of an entity is as follows: An entity is any independent object within a simulation that possesses complex behaviors and attributes. For example, personnel, vehicles, complex munitions, key communications devices might all be represented as independent entities within a simulation.
The vendor shall utilize the system requirements as described in the TSMT TDP Appendix E SRD to form the initial backlog for TSMT capability. The TDP contains materials with distribution limitations. The Government can release the TDP to vendors that successfully navigate the PEO STRI vetting process.
The first two levels of the SRD requirements schema is below.
1 Common Requirements
1.1 Played Items
1.2 PMESII-PT
1.3 METT-TC Factors
1.4 Rendering
1.5 Architecture
1.6 Technology
1.7 Interoperability / Integration
1.8 Deployment
34DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
115911601161116211631164116511661167
1168
116911701171117211731174117511761177
1178117911801181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1.9 Non-Architecture Attributes /Guidance
1.10 One World Terrain
1.11 RVCT Integration
2 Training Simulation Software
2.1 TSS/RVCT
2.2 TSS General
2.3 S/SVT
3 Training Management Tool
3.1 TMT Assess
3.2 TMT Execute
3.3 TMT Plan
3.4 TMT Prepare
3.5 TMT TMT Common
3.9.1 General3.9.1.1 The vendor shall provide an option to purchase full source code data rights for any major
commercial component in the vendor’s solution.
3.9.1.2 The vendor shall provide an option to purchase updates for full source code data rights for any major commercial component in the vendor’s solution.
3.9.1.2.1 The vendor shall provide 50 copies of any commercial software used in the TMT or TSS solution for independent Government capability verification, benchmarking, and experimentation.
3.9.1.2.2 The vendor shall establish cost, option Contact Line Item Number (CLINs) for integration of an additional 10, 20, 50, 100 and 250 new OWT models above and beyond the model baseline expected from OWT.
3.9.1.3 The vendor shall consume products provided by OWT. Refer to the TDP Appendix E SRD for additional OWT requirements.
35DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
12061207
12081209
12101211
1212
121312141215
12161217
3.9.1.3.1 The TSMT vendor shall supplement the moving model library obtained from the OWT vendor with vehicle models that already exist in their library. These models shall be used as is without further modification and without new model development. These models shall be disclosed to the government and limitations in functionality published so that the government can determine their suitability for use in the simulation.
3.9.1.3.2 The vendor shall provide a methodology that allows a third party to produce models in the open OWT format and then convert the model to the open TSMT run-time format specifications in accordance with the deliverables (3.8.2.1).
3.9.1.3.3 The TSMT vendor shall work with the OWT vendor to ensure that the Well Formed Format (WFF) provides all of the information required by the TSMT software while keeping the WFF an open specification and be able to be used by third party software (see TDP Appendix F for the OWT Specification).
3.9.1.3.4 The TSMT vendor shall provide the human and animal models and kinematics for those models as listed in the model list.
3.9.1.3.5 The TSMT vendor shall work with the OWT vendor and the government to ensure that the Filmbox (FBX) and glTF implementations contain all the information required by the TSMT software to render the model. The TSMT vendor shall provide a methodology for third party content creators to create models that can be rendered by the TSMT software.
3.9.1.4 The vendor shall ensure the TSS solution is optimized for cross platform use and must function on mobile devices, laptops, desktops, and untethered cross reality (XR) devices.
3.9.1.5 The vendor shall work with the RVCT vendor to perform analysis, trade studies and experimentation to determine the feasibility of achieving significant reduction in power consumption of the RVCT Compute Kit(s) and TSMT compute/rendering/storage capability located at the point of need. The vendor shall identify and explore novel approaches such as application of low power mobile computing technology and/or transmission of streaming video in support of significant PoN power reduction.
3.9.1.6 The vendor’s new development work shall not break current capabilities.
3.9.2 Architecture
36DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
12181219122012211222
122312241225
1226122712281229
12301231
12321233123412351236
12371238
123912401241124212431244
1245
1246
The separation in contract vehicles drives the need for the development to synchronize architecture and establish platform abstraction layers, integration services interfaces, and interface agreements between vendors. The STE architecture defines the conceptual structure and logical organization of the STE capabilities. The architecture supports real-time situational awareness across all modules / components, scalability, cybersecurity, accessibility, interoperability, and extensibility. The STE provides a secure system that meets the cybersecurity requirements outlined in Section 3.13.2 Cybersecurity.
3.9.2.1 The vendor shall implement a Modular Open Systems Approach (MOSA) that complies with MOSA Implementation Guide Version 1.0 and the MOSA Reference Frameworks in Defense Acquisition Programs.
3.9.2.2 The TSMT shall be modular, with an open architecture, such that the system interfaces share common, widely accepted standards that support interoperability across OWT, RVCT and IVAS-SiVT if available, at the Brigade and Below software release.
3.9.2.3 The vendor shall enforce modular architectures.
3.9.2.4 The vendor shall certify conformance to modularity and openness using the Program Assessment and Review Tool (PART) in accordance with the deliverables (3.8.2.1).
3.9.2.5 The vendor shall comply with the Army Data Modernization Strategy.
3.9.2.6 The vendor shall designate key interfaces.
3.9.2.7 The vendor, in collaboration with the Government, shall define and manage all ICDs in accordance with the deliverable ().
3.9.2.8 The vendor shall propose standards for Government approval in accordance with the deliverable (3.8.2.2 and ).
3.9.2.9 The vendor shall develop and deliver the solution architecture in NoMagic Magic Draw format using the Unified Profile for DoDAF/MODAF (UPDM) and SysMIL plug ins in accordance with the deliverables (3.8.2.2).
3.9.2.10 The vendor shall develop architecture using the Development and Engineering Experience Platform (DEEP), a Government collaboration space for U.S. persons that hosts the authoritative model for requirements and architecture in accordance with the deliverable (3.8.2.2).
3.9.2.11 The vendor shall develop and deliver the SSS and SRS in the Dynamic Object-Oriented Requirements System (DOORS) format in the DEEP in accordance with the deliverables (3.8.2.5 and ).
37DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
12471248124912501251125212531254
125512561257
125812591260
1261
12621263
1264
1265
12661267
12681269
127012711272
1273127412751276
127712781279
3.9.2.12 The vendor shall document major interfaces and components of the vendor solution in a briefing that identifies points of modularity and evaluates all major components and interfaces for their degree of modularity and openness in accordance with the deliverable ().
3.9.2.13 The vendor shall provide frequent architecture updates that focus on interface definition to support rapid integration.
3.9.2.13.1 The vendor shall provide the first briefing not later than 60 days after OTA award in accordance with the deliverables (3.8.2.2).
3.9.2.13.2 The vendor shall provide architecture updates at each MVPs, MVCR, and releases in accordance with the deliverables (3.8.2.2).
3.9.2.14 The vendor architecture shall be compliant with the Government’s high-level STE architecture.
3.9.2.15 The vendor shall provide the architecture for the TSMT cloud.
3.9.2.16 The vendor can request changes to the Government’s high-level STE architecture through the Government’s Architecture Synchronization agile ceremony as appropriate and the Government will evaluate and determine applicability in accordance with the deliverables (3.8.2.2).
3.9.2.17 The vendor shall develop documentation that integrates the STE system capability and interfaces to include software architecture, systems architecture, training manuals, technical and troubleshooting manuals, and test plans and procedures in accordance with the deliverables (3.8.2.1, , 3.8.2.2, 3.8.3.7, 3.8.2.7).
3.9.3 Point of NeedThe TSMT delivers training content to the PoN at Home Stations, deployed locations, and training and educational institutions. See Table 3-3 for MVCR and Operational Test locations. See the TDP Appendix D TSMT Hardware Concept for more information on the PoN.
3.9.3.1 Point of Need Conditions
The STE collective training system will be used at existing facilities at the PoN. The STE collective training system shall use existing facilities’ shelter, power, and environmental control that maintains the temperature and humidity range (see AR 70-38, Research, Development, Test, and Evaluation of Materiel for Extreme Climatic Conditions).
38DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
1280128112821283
12841285
12861287
12881289
12901291
1292
1293129412951296
1297129812991300
1301
1302130313041305
1306
1307130813091310
When the STE collective training system is transported to a PoN that does not have a facility, the unit will provide tents, generators, and environmental control units to shelter and power the training capabilities and maintain the temperature and humidity in the range needed to operate the training capabilities. This will enable the operation of the STE collective training system in austere and semi-austere environments.
3.9.3.2 Network
The STE operates in connected and disconnected modes (for training under limited or degraded network conditions). STE leverages the Army Network (enterprise and tactical) to deliver training to the PoN. STE traffic traverses the Integrated Enterprise Network (IEN), Integrated Tactical Network (ITN), and commercial networks. The IEN is the backbone wide area network that connects installations together. The Installation Campus Area Network (ICAN) connects buildings on the installation. The ITN connects the MCIS and COE. STE traffic will also traverse organizational networks (Army National Guard and United States Army Reserve) to provide a total Army training capability.
3.9.3.2.1 The vendor solution shall use DoD networks (e.g., ITN, IEN, ICAN), and commercial networks for transport.
3.9.3.2.2 At a minimum, the vendor shall use identity management, domain name service, and active directory enterprise services.
3.9.3.2.3 The vendor shall design the TMT software to be securely accessible to the user from a public network.
3.9.3.2.4 The vendor shall support network communication exercises (COMEX) prior to each network risk reduction events (NRRE).
3.9.3.2.5 The vendor shall support TIF NRREs using the Joint Mission Environment (JME) and the DoDIN utilizing Non-classified Internet Protocol (IP) Router (NIPR).
3.9.3.2.6 The vendor shall support Operational Site NRREs using the Department of Defense Information Network (DoDIN) to inform/determine the network bandwidth and latency thresholds.
3.9.3.2.7 The vendor shall support Government wireless pilot experiments in the Government lab infrastructure and at Operational Sites over the DoDIN to inform/determine the network bandwidth and latency thresholds.
3.9.3.2.8 The vendor shall support Government cellular pilot experiments in the Government lab infrastructure and at Operational Sites over the DoDIN to inform/determine the network bandwidth and latency thresholds.
39DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
13111312131313141315
1316
131713181319132013211322132313241325
13261327
13281329
13301331
13321333
13341335
133613371338
133913401341
134213431344
3.9.3.2.9 The vendor solution shall be able to use installation wireless capabilities.
3.9.3.3 Cloud
The TSMT uses elastic and scalable shared computing resources to scale the capability without excessive, idle overhead capacity. The TSMT hybrid cloud agnostic design enables the capability to transition between cloud service providers. The vendor shall use Defense Information Systems Agency (DISA) approved Cloud services and shall adhere to the Enterprise Cloud Management Office (ECMO) guidelines and standards see enterprise-cloud-management-office-ecmo for additional information. The vendor shall follow the DoD Digital Modernization Strategy and DoD Cloud Strategy and operate up to Impact Level 6 and MCIS classification of secret.
3.9.3.3.1 The vendor shall work with the Government to identify the appropriate cloud provider.
3.9.3.3.2 The vendor shall use a zero-trust cloud.
3.9.3.3.3 The vendor shall use Cloud enabled Multi-cluster and cross-data center deployments including disaster recovery, aggregation for analytics, cloud migration, mission-critical stretched deployments, and global distribution to provide the framework for storing, reading, and analyzing streaming data.
3.9.3.4 Multi-level Security
3.9.3.4.1 The vendor shall employ a bi-directional CDS that can host multiple security classifications (i.e., Unclassified, Secret, and Secret Releasable) in a single exercise.
3.9.3.4.2 The vendor shall work with the Government to determine the number and type of releasable categories the CDS will support. The TDP Appendix D TSMT Hardware Concept includes conceptual CDS courses of action.
3.9.4 TSMT Hardware
40DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
1345
1346
13471348134913501351135213531354
1355
1356
1357135813591360
1361
13621363
136413651366
1367
TSMT employs an innovative and minimalistic hardware solution that leverages breakthroughs in content delivery. TSMT hardware may include central nodes, edge nodes, field servers, EXCON laptops and OC Mobile Devices. The central node and edge node hardware provides compute, store, and local area network capabilities that reduce risk for the Army network in connected or disconnected operations at the PoN. The central nodes, unclassified and classified, reside in the Network Enterprise Center (NEC) or other suitable location that provides the physical security, network connections, power, cooling, and administration as determine by installation and army regulation. Edge nodes will be collocated with the RVCT-Air and RVCT-Ground training capabilities and expanded to provide compute at point of need for future SVT and live capabilities. The field server hardware provides a compute and store capability that enables training at the PoN. TSS, TMT and OWT software and data reside on the edge nodes and the field servers. EXCON laptops allow EXCON / HighCon / LowCon / White cell and OPFOR to monitor and control the training event. OC Mobile Devices enable observer controller trainers to monitor and interact with the training event while observing the training audience. For additional hardware and point of need concepts see the TDP Appendix D TSMT Hardware Concept.
3.9.4.1 The vendor shall recommend a hardware set that enables Brigade and Below collective training that has a minimal size, weight, and power footprint for Government evaluation and approval.
3.9.4.2 The vendor TSMT hardware configuration shall provide compute, store, and network capabilities.
3.9.4.3 The vendor shall consider trade space between network, cloud, storage, and end-device (e.g., zero/thin client, thick client, RVCT, SVT) capabilities and location.
3.9.4.4 The vendor shall identify the hardware configuration that satisfies the STE requirements (TSMT & OWT services) at the PoN.
3.9.4.5 The vendor shall use the National Information Assurance Partnership (NIAP) validated or Approved Products List (APL) components in the performance of this contract.
3.10 Agile ProcessThe Government requires that the solution be built using Agile practices that are consistent with the SAP and enables frequent user feedback. The vendor shall identify how they will produce deliverables within an incremental, fast-paced software development schedule to reduce the risk of failure.
The vendor shall identify an agile approach that addresses meetings and agile ceremonies such as: daily scrum meetings, scrum of scrums, sprint planning, sprint
41DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
13681369137013711372137313741375137613771378137913801381138213831384
138513861387
13881389
13901391
13921393
13941395
1396
1397139813991400
14011402
demonstrations, sprint retrospectives, program increment planning sessions, integration points between teams, system demonstrations, and other components of the agile methodology. The vendor agile approach shall ensure continuous user engagement and feedback mechanisms. The vendor shall identify sprint and program increment length. The vendor shall also identify a specific technique to facilitate distributed meetings with the Government, vendors, and sub-vendors using a mechanism approved for official use only (FOUO). Using the agile development process, the vendor shall work with the Government to identify the capabilities the vendor shall develop during each program increment and sprint.
The TDP Appendix E SRD provides additional requirements guidance necessary for the Government and vendor to collectively construct the initial and incremental backlog of features and / or user stories. The specifics of each backlog item shall include, but not be limited to:
A Government approved prioritized increment feature list and product roadmap. Product owner approved, prioritized increment/sprint user stories (including the
anticipated outcome). Business value of each user story toward overall objectives. Progress reporting, risk identification and dependency identification.
The Government’s preferred agile approach embraces changing requirements over time based on constant user feedback. The approach provides a common cadence for the agile teams where they plan, develop, demonstrate, and learn together as an integrated system.
3.10.1 General3.10.1.1 The vendor Agile process shall include time for technology investigation, innovation,
refactoring, and bug fixes.
3.10.1.2 The vendor shall support the Government leadership team in addressing expectations, and identifying risks, issues, opportunities, and dependencies across the development.
3.10.1.3 The vendor shall deliver the initial working software that meets the vendor’s proposed and Government approved MVCR in accordance with the deliverable (3.8.2.1).
3.10.1.4 The vendor shall elevate all cost, schedule, and performance decisions to the Government.
3.10.1.5 The vendor shall participate in the weekly Government led scrum of scrum meetings.
3.10.1.6 The vendor shall participate in the weekly Government led product manager/requirements manager synchronization meetings.
42DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
140314041405140614071408140914101411
1412141314141415
14161417141814191420
1421142214231424
1425
14261427
14281429
14301431
14321433
1434
14351436
3.10.1.7 The vendor shall participate in the weekly Government led architecture synchronization meetings.
3.10.1.8 The vendor shall provide the Government an Architecture Roadmap review at least two increments prior to a program increment, MVP, MVCR, and subsequent software release as per the mutually agreed to schedule.
3.10.1.9 The vendor in collaboration with the Government shall incrementally update and maintain the roadmap and program backlog after each program increment, MVP, MVCR, and subsequent software release in accordance with the deliverables (3.8.1.5).
3.10.1.10 The vendor shall participate in the Government led pre-program increment planning session.
3.10.2 Agile Ceremonies3.10.2.1 The vendor shall conduct a program increment planning session with the Government
prior to each increment and shall use the Government provided prioritized features to conduct the planning.
3.10.2.1.1 The vendor shall meet the following program increment planning session entry criteria:
Government provided prioritized functional features and architecture enablers.
3.10.2.1.2 The vendor shall provide the Government the following program increment planning session exit criteria NLT 5 calendar days after the planning session in accordance with the deliverables (3.8.1.4, 3.8.1.5, and 3.8.2.8):
Program increment objectives Sprint plan for each team Team risks Program Increment dependency board Updated product roadmap Update architectural runway Updated program backlog T&E Plan RTM
3.10.2.2 The vendor shall conduct team sprint planning sessions on the first day of the sprint.
43DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
14371438
143914401441
144214431444
14451446
1447
144814491450
14511452
14531454
145514561457
145814591460146114621463146414651466
1467
3.10.2.2.1 The vendor shall meet the following team sprint planning session entry criteria:
Program increment planning session exit criteria artifacts.
3.10.2.2.2 The vendor shall provide the Government the following team sprint planning session exit criteria NLT 1 calendar day after the sprint planning session in accordance with the deliverable (3.8.1.4):
Refined team sprint plan Team sprint goals
3.10.2.3 The vendor shall conduct a sprint review with the Government at the end of the sprint cycle.
3.10.2.3.1 The vendor shall meet the following sprint review entry criteria in accordance with the deliverables (3.8.1.4 and 3.8.2.9)
Refined team sprint plan Sprint test results
3.10.2.3.2 The vendor shall provide the Government the following sprint review exit criteria NLT 2 calendar days after the sprint demonstration in accordance with the deliverables (3.8.1.4, , and 3.8.2.12):
Sprint demonstration Sprint retrospective Sprint release notes Sprint backlog refinement
3.10.2.4 The vendor shall conduct a program increment demonstration with the Government at the end of the program increment cycle.
3.10.2.4.1 The vendor shall meet the following program increment demonstration entry criteria in accordance with the deliverables (3.8.2.7, 3.8.2.8, 3.8.2.1, and 3.8.2.9):
Program increment software/hardware Program increment test results
3.10.2.4.2 The vendor shall provide the Government the following program increment demonstration exit criteria NLT 2 calendar days after the demonstration in accordance with the deliverables (3.8.1.4 , and 3.8.2.12):
Program increment demonstration44
DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
1468
1469
147014711472
14731474
14751476
14771478
14791480
148114821483
1484148514861487
14881489
14901491
14921493
149414951496
1497
Program increment release notes Program increment retrospective Software release Program backlog refinement Next program increment planning session
3.10.3 Agile Metrics3.10.3.1 The vendor shall provide an automated agile metric reporting mechanism for
Government approval.
3.10.3.2 The vendor shall develop and track the following agile metrics for each sprint and program increment, MVP, MVCR, and subsequent software releases to the Government NLT 2 calendar days after the cycle in accordance with the deliverables (3.8.1.1). See the DoD Agile Metrics Guide, Strategy Considerations and Sample Metrics for Agile Development Solutions Version 1.1 dated 23 September 2019 for additional information and formulas for the metrics identified below.
Agile Process Metrics. Agile process metrics measure process performance, or how well planning, execution, and delivery activities are performing. Agile process metrics include:
Feature Points: Used for sizing features. It measures the complexity of a feature. Typically, features points utilize the Fibonacci sequence (1,2,3,5,8 etc.).
Story Points. Story points measure the complexity of a story and are explained in the next subsection. The developer assigned to a story is responsible for identifying how much effort is required to complete the work in each sprint. If a story is larger than 8, the team must go back and split the story.
Velocity. Velocity measures the amount of work (usually in story points, although other measurement units can be used as well, such as hours) that the team completes in each sprint.
Velocity Variance. Velocity variance is the standard deviation from average velocity – or the difference from the mean velocity.
Velocity Predictability. Velocity predictability is measured as the difference between planned and completed velocity, which is the difference between the total planned and completed story points for a given sprint.
Story Completion Rate. Story completion rate describes the number of stories Across Board completed in each sprint or release.
Sprint Burndown. Teams implementing sprints use a sprint burndown chart to estimate their pace of work accomplished daily. The pace is usually measured in hours of work.
45DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
14981499150015011502
1503
15041505
150615071508150915101511
151215131514
1515151615171518151915201521152215231524152515261527152815291530153115321533
Release Burnup. The release burnup metric is a planning tool that allows the Agile team to estimate whether the team is on track to complete the items in the release.
3.10.3.2.1 Agile Quality Metrics. Agile quality metrics measure the quality of work being delivered. Agile quality metrics include:
Recidivism. Recidivism describes stories that are returned to the team for various reasons. If stories are not completed as the users expect, the team will need to understand the reasons, especially if recidivism rates are relatively high or increasing.
Defect Count. Defect count measures the number of defects per sprint or release.
Number of Blockers. Number of blockers describes the number of events that prohibit the completion of an activity or work item. These blockers cannot be resolved by the individual assigned to complete the activity and the team needs assistance to remove the blocker.
3.10.3.2.2 Agile Product Metrics. Agile product metrics should measure the value that the product delivers in terms of user acceptance and alignment to desired outcomes (measured by value). Agile product metrics include:
Delivered Value Points. This metric represents the count of value points delivered to users for a given release. Value points are usually defined by the users (or user representatives) to indicate a business value assigned to a given feature, capability, epic or story.
Level of User Satisfaction. This metric represents the measure of user satisfaction based on the value delivered by the product or solution.
3.10.4 Roadmap
3.10.4.1 The vendor shall collaborate with the Government to develop and maintain an executable product roadmap that includes prioritized features aligned to a high level calendar and success metrics approved by the Government for each program increment, MVPs, MVCR, and subsequent software releases in accordance with the deliverables (3.8.1.5).
3.10.4.2 The vendor shall propose their version of the product roadmap in response to this PWS that considers the desires of the Government’s draft product roadmap and balances that with the practical sequence and timing of development, integration, test and delivery that it can support.
3.10.4.2.1 The vendor roadmap shall include test dates.
3.10.4.2.2 The vendor roadmap shall include test lead time cutoff points.
46DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
153415351536
15371538
1539154015411542154315441545154615471548
154915501551
155215531554155515561557
1558
1559156015611562
1563156415651566
1567
1568
3.10.4.2.3 The vendor roadmap shall include TMT capability progression broken out by the plan, prepare, execute, and assess elements; artificial intelligence, machine learning, and intelligent tutoring system integration; and interfaces with authoritative data sources.
3.10.4.2.4 The vendor roadmap shall include TSS computer generated forces capability progression.
3.10.4.2.5 The vendor roadmap shall include TSS entity level constructive training.
3.10.4.2.6 The vendor roadmap shall include the cross-domain solution accreditation progression.
3.10.4.2.7 The vendor roadmap shall include the cybersecurity accreditation progression.
3.10.4.2.8 The vendor roadmap shall include fires training capabilities by echelon capability progression.
3.10.4.2.9 The vendor roadmap shall include mission command training capabilities by echelon capability progression.
3.10.4.2.10 The vendor roadmap shall include movement and maneuver training capabilities by echelon capability progression.
3.10.4.2.11 The vendor roadmap shall include RVCT-Soldier software capability progression e.g., Soldier/Squad to BCT.
3.10.4.2.12 The vendor roadmap shall include platform level Mission Command representation and interoperability capability progression (includes Platform command and control [C2] capability required by certain RVCT Solider and/or EXCON roles such as Squad leader and Platoon leader and Fires handheld C2 device representation [simulation, emulation or “wrapping” of tactical software] for use by a simulation role player).
3.10.4.2.13 The vendor roadmap shall include Command Post Mission Command interoperability, mapped to all systems specified in SRD capability progression.
3.10.4.2.14 The vendor roadmap shall include scalability capability progression.
3.10.4.2.15 The vendor roadmap shall include voice communications system capability progression.
3.10.4.2.16 The vendor roadmap shall include RVCT Air Software platform software capability progression.
47DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
1569157015711572
15731574
1575
15761577
1578
15791580
15811582
15831584
15851586
158715881589159015911592
15931594
1595
15961597
15981599
3.10.4.2.17 The vendor shall provide a breakout of when each major air subsystem is integrated and delivered (e.g., Apache basic flight, AvSE integration, fire control radar, 30 mm, Rockets, Hellfire, voice comms, digital comms Link 16, Air Force Applications Program Development (AFAPD) and Joint Variable Message Format (JVMF), TMT management, Aviation Mission Planning Software (AMPS) initialization, etc.).
3.10.4.2.18 The vendor roadmap shall include RVCT Ground Software platform software capability progression.
3.10.4.2.19 The vendor shall provide a breakout of when each major ground subsystem is integrated and delivered
3.10.4.2.20 The vendor roadmap shall include Political, Military, Economic, Social, Infrastructure, Information - Physical Environment, & Time (PMESII-PT) capability aligned to Military, Information, Infrastructure, Physical Environment and Time variables capability progression.
3.10.4.2.21 The vendor roadmap shall include interoperability (e.g., LVC-IA, JLCCTC, IEWTPT) capability progression.
3.10.4.2.22 The vendor roadmap shall include RVCT Air and Ground platform integration capability progression.
3.10.4.2.23 The vendor roadmap shall include OWT capability progression (e.g., model integration, base globe, Graphics Library Transmission Format (glTF)/3D tiles import, download and stitch hi resolution areas onto base globe, terrain editing, submission of edits to OWT repository for potential integration into master OWT repository).
3.10.4.2.24 The vendor roadmap shall include Government Furnished Information (GFI) / GFE / S&T integration.
3.10.4.2.25 The vendor roadmap shall include CATS task progression.
3.10.5 DevSecOps
48DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
16001601160216031604
16051606
16071608
1609161016111612
16131614
16151616
1617161816191620
16211622
1623
1624
DevSecOps is an organizational software engineering culture and practice that aims at unifying software development (Dev), security (Sec) and operations (Ops). The main characteristic of DevSecOps is to improve outcomes and mission value by automating, monitoring, and applying security at all phases of the software lifecycle. A full DevSecOps pipeline includes Continuous Integration, Continuous Delivery, Continuous Deployment, Continuous Operation, and Continuous Monitoring. The goal for the DevSecOps environment is to facilitate planning, coordination, execution, and delivery of an integrated system in one singly managed place through agile software development processes. DevSecOps, in the context of TSMT, are users and developers working together to enable rapid and frequent delivery of capabilities to the Warfighter to receive feedback that informs the requirement.
3.10.5.1 The vendor shall implement a DevSecOps process that is consistent with the DoD Enterprise DevSecOps Reference Design.
3.10.5.2 The vendor shall conduct DevSecOps discussions with current and future OTA vendors and the Government.
3.10.5.3 The vendor shall document their DevSecOps plan and provide to the Government NLT 30 days after contract award in accordance with the deliverable (3.8.3.6).
3.10.5.4 The vendor shall employ a transparent DevSecOps / Agile process involving the Government to plan, develop, build, test, secure, deploy, operate, and scale TSMT.
3.10.5.5 The vendor shall coordinate and synchronize all phases and activities of STE system capability and interface vendors through the software factory.
3.10.5.6 The vendor shall design their DevSecOps process to employ a delivery pipeline that enables the systems to develop on cadence, release on demand, and conduct continuous integration and continuous delivery (CI/CD) with STE system capability and interface vendors to ensure an integrated STE system of systems.
3.10.5.7 The vendor shall release a fully integrated STE system that provides collective training value.
3.10.5.8 The vendor shall design their DevSecOps process to maximize automation for activities in develop, build, test, release, and deliver/field phases.
3.10.5.9 The vendor shall establish pass criteria, perform, and pass automated unit tests, regression tests, and automated interface tests as entry criteria for assessment events.
3.10.5.10 The vendor shall co-develop and/or review the automated test procedures with the Government to ensure they are accurate and complete.
49DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
16251626162716281629163016311632163316341635
16361637
16381639
16401641
16421643
16441645
1646164716481649
16501651
16521653
16541655
16561657
3.10.5.11 The vendor shall present all automated test tools to the Test and Evaluation Working Integrated Product Team (T&E WIPT) for approval.
3.10.5.12 The vendor shall use an automated security tools to ensure compliance with the continuous ATO process.
3.10.5.13 The vendor shall provide the Government source code, build scripts, and any other dependency necessary to independently build the application developed under the OTA at each MVP, MVCR, and each subsequent delivery to the Government in accordance with the deliverables (3.8.2.1).
3.10.5.14 The vendor shall deploy approved system configurations to the locations identified in Table 3-2 and Table 3-3.
3.10.5.15 The vendor shall provide the Government remote access to the system to install and access diagnostic, instrumentation, and test software to collect and view test data for each sprint, program increment, MVP, MVCR, and subsequent software releases.
3.10.5.16 The vendor shall recommend changes and improvements that increase the effectiveness of the STE DevSecOps processes and procedures.
DevSecOps metrics relate to measurements that provide insight into the organization’s delivery pipeline. They also include metrics that provide a high-level assessment of the organization’s ability to integrate, deliver, monitor, and restore products.
3.10.5.17 The vendor shall develop and track the following DevSecOps metrics and provide monthly updates to the Government in accordance with the deliverables (3.8.1.1 and 3.8.3.6):
Mean Time to Restore (MTTR). MTTR measures how quickly a system or solution can be restored to functional use after a critical failure.
Deployment Frequency. Deployment frequency provides information on the cadence of deployments in terms of time elapsed between deployments.
Lead Time. This flow metric represents how long it takes to deliver a required solution.
Change Fail Rate. Tracks defect count measures and returned stories per sprint or release.
3.10.5.18 Platform One
Platform One is the official DoD DevSecOps Enterprise service. Platform One facilitates efficient and effective coordination between development scrums and the Government. The vendor accesses Platform One using the internet. The Government will purchase services to have the STE DevSecOps pipeline hosted in Platform One. The CI/CD pipeline will use Platform One provided tools and products. Platform One may have the
50DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
16581659
16601661
1662166316641665
16661667
166816691670
16711672
167316741675
167616771678
16791680168116821683168416851686
1687
16881689169016911692
flexibility to support additional tools required for the STE DevSecOps process. Platform One hosted pipelines currently have access to:
Plan & Develop: Jira, Gitlab, Github, Git, Build: Ant, Cmake, Maven, MSBuild, Gradle, Jenkins Test: Selenium, Cucumber, Junit Secure: Sonarqube, Nessus, Twislock, Fortify, Aqua, Qualys, Nexus, Archiva,
Jfrog Deploy & Operate: Ansible, Chef, Puppet, Helm, Salt, Operator SDK Monitor: Nagios, Splunk, Sunsu, Kubernetes, Docker, and ELK Stack Scale: Azure, AWS Gov Cloud, milCloud, and Google cloud.
3.10.5.18.1 The vendor shall use the Government provided Platform One environment.
3.10.5.18.2 The vendor shall identify and propose additional or substitute tools (with rationale) required above and beyond Platform One that the vendor will procure and operate.
3.10.5.18.3 The vendor shall provide an option for 50 Government personnel access licenses for any vendor requirements, architecture or DevSecOps tools needed.
3.11 TestingIncremental Government testing occurs outside of the agile process and will typically be associated with delivery of a program increment, MVP, MVCR, and subsequent software releases. Incremental Government testing includes
TA/Functional Verifications (FV) User Assessments (UA) Operational Testing (OT) Verification, Validation, and Accreditation (VV&A) Logistics Demonstration/Maintenance Evaluations (LD/ME)
3.11.1 Incremental Government Testing3.11.1.1 The vendor shall enable, participate, and support continuous and incremental
Government testing that supplements Agile process and DevSecOps testing.
3.11.1.2 The vendor shall provide software and hardware to support incremental Government testing.
3.11.1.3 The vendor shall provide manuals and training support package for UA, OT, and VV&A in accordance with the deliverables (3.8.3.7 and 3.8.3.8).
3.11.1.4 The vendor shall develop test and evaluation plans shall include an incremental test strategy in accordance with the deliverables (3.8.2.7 and 3.8.2.8).
51DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
16931694
16951696169716981699170017011702
1703
17041705
17061707
1708
170917101711
17121713171417151716
1717
17181719
17201721
17221723
17241725
3.11.1.5 The vendor shall allow the Government to review vendor test plans and metrics and to provide input on vendor testing methods to ensure the usability of vendor test data for Government purposes.
3.11.1.6 The vendor shall provide the Government access to the vendor’s test plans, testing, and test results to reduce the government test burden in accordance with deliverables (3.8.2.7, 3.8.2.8, and 3.8.2.9).
3.11.1.7 The vendor shall support Government training effectiveness assessments during the User Assessments to inform vendor design and performance trades.
3.11.1.8 The vendor shall document test/assessment objectives and known limitations for all STE system capability and interface vendors in accordance with the deliverables (3.8.2.7, 3.8.2.8, and 3.8.2.9).
3.11.1.9 The vendor shall meet the following program increment test and assessment entry criteria:
3.11.1.9.1 The vendor shall pass automated unit tests as entry criteria for verification and integration test events at the STE TIF.
3.11.1.9.2 Configuration of system under test has been defined and agreed to. All interfaces have been placed under configuration management or have been defined in accordance with an agreed to plan and a Software Version Description Document has been made available 10 days prior to completion of the software release.
3.11.1.9.3 All applicable functional, unit level, subsystem, system, and qualification testing has been conducted successfully.
3.11.1.9.4 All test and assessment reviews specific materials such as Government approved test plans, cases, and procedures have been available to all participants prior to conducting the review.
3.11.1.9.5 All known system discrepancies have been identified and resolved in accordance with an agreed to plan.
3.11.1.9.6 All previous design review exit criteria and key issues have been satisfied in accordance with an agreed to plan.
3.11.1.9.7 All required test resources (people, facilities, test articles, test instrumentation) have been identified and are available to support required tests.
3.11.1.9.8 Roles and responsibilities of all test participants are defined and agreed to.
3.11.1.9.9 All applicable Cyber security requirements have been met (e.g., Interim Authority to Test approved).
52DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
172617271728
172917301731
17321733
173417351736
17371738
17391740
1741174217431744
17451746
174717481749
17501751
17521753
17541755
1756
17571758
3.11.1.10 The vendor shall provide the following program increment test and assessment entry criteria:
3.11.1.10.1 All Action Items to document situations and possible action where the technical approach does not appear to meet the specification requirement have been addressed, assessed, and agreed upon.
3.11.1.10.2 Were all the required independent evaluators involved and do they concur with the planned tests, expected results?
3.11.1.10.3 Adequate test plans completed and approved for the system under test.
3.11.1.10.4 Previous component, subsystem, system test results form a satisfactory basis for proceeding into planned tests.
3.11.1.10.5 Risk level identified and accepted by Program leadership as required.
3.11.2 Integration Environment3.11.2.1 The vendor shall use the Government Technology Integration Facility (TIF) for integration,
demonstrations, assessments, and test and evaluations that replicates conditions of the operational environment.
3.11.2.2 The vendor shall use the Government integration environment at the Joint Development and Integration Facility (JDIF) for classified (up to SECRET, SECRET REL, SECRET NATO) integration, demonstrations, assessments, and test and evaluations.
3.11.3 Development Testing3.11.3.1 The vendor shall develop a sprint and increment level test and evaluation plan NLT 30
days after contract award for the Government to approve in accordance with the deliverables (3.8.2.7, 3.8.2.8, and 3.8.2.9).
3.11.3.1.1 The vendor shall update the test and evaluation plan NLT 30 days into each program increment, MVP, MVCR and subsequent software releases in accordance with the deliverables (3.8.2.7, 3.8.2.8, and 3.8.2.9).
3.11.3.1.2 The test and evaluation plan shall address development testing, component testing, integration testing, sprint demonstrations, program increment demonstrations, MVP, MVCR, subsequent software release demonstrations of the integrated STE solution.
3.11.3.1.3 The vendor test and evaluation plan shall establish an integration and testing roadmap/plan with events/touchpoints and coordinate STE system capability and interface vendors dependencies through the Government.
53DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
17591760
176117621763
17641765
1766
17671768
1769
1770
177117721773
177417751776
1777
177817791780
178117821783
1784178517861787
178817891790
3.11.3.1.4 The vendor test and evaluation plan shall include the Government in sprint cycles that include other vendors.
3.11.3.1.5 The vendor shall develop a RTM that traces all system requirements and features allocated to a given sprint, program increment, MVP, MVCR or subsequent software release; vendor provided, and Government approved test procedures; and vendor provided and Government approved measures of success.
3.11.3.1.6 The vendor shall support Environmental testing by providing hardware test assets and possible onsite support as required at an approved DoD/Army test agency facility.
3.11.4 Cybersecurity Tests and Events3.11.4.1 The vendor shall support development of a multi-phased, test timeline and cyber test and
evaluation plan in accordance with the deliverables (3.8.2.7, 3.8.2.8, and 3.8.2.9).
3.11.4.2 The vendor shall adhere to the Director, Operational Test & Evaluation (DOT&E) Procedures for Operational T&E of Cybersecurity in Acquisition Programs Memorandum.
3.11.4.3 The vendor shall participate in and support Cybersecurity DT Events.
3.11.4.3.1 The vendor shall support Combat Capabilities Development Command Data and Analysis Center (CCDC-DAC) in coordination with (ICW) PM (Blue Team) and AEC Cooperative Vulnerability Identification (CVI) testing and provide the test data to the Government NLT 5 calendar days after the events in accordance with the deliverable (3.8.1.2).
3.11.4.3.2 The vendor shall support the Threat System Management Office (TSMO) ICW PM (Red Team) and AEC Adversarial Cyber Developmental Tests (ACDT) and provide the test data to the Government NLT 5 calendar days after the events in accordance with the deliverables (3.8.1.2).
3.11.4.3.3 The vendor shall provide Verification of Fixes (VoF’s) event(s) NLT 10 calendar days after the test is completed in accordance with the deliverables (3.8.1.2).
3.11.4.4 The TSMT shall undergo Cybersecurity Operational Test events.
3.11.4.4.1 The vendor shall support Cooperative Vulnerability Penetration Assessments (CVPA) and provide CVPA test data to the Government NLT 10 calendar days after the test is completed in accordance with the deliverables (3.8.1.2).
3.11.4.4.2 The vendor shall support Adversarial Assessments (AA) and provide AA data to the Government NLT 10 calendar days after the assessment is completed in accordance with the deliverables (3.8.1.2).
3.11.4.4.3 The vendor shall support ATEC/AEC evaluations IAW the DOT&E Procedures for Operational T&E of Cybersecurity in the Acquisition Programs Memorandum.
54DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
17911792
1793179417951796
17971798
1799
18001801
18021803
1804
18051806180718081809
1810181118121813
18141815
1816
181718181819
182018211822
18231824
3.12 Product SupportWhile each STE system will have their independent sustainment strategy, the STE system capability vendor’s sustainment concept shall provide interfaces to allow integration of operation and sustainment as a system of systems.
3.12.1 General3.12.1.1 The vendor shall safeguard, securely store, and track government furnished property
(GFP) (i.e., GFI and GFE). Contractor Acquired Property (CAP) shall be considered as GFP and will be added to the GFP list after presentation of the DD250. The vendor can request additional GFI/GFE and the Government will evaluate and determine applicability.
3.12.1.2 The vendor shall perform the following to ensure positive control and safety of Government furnished items:
a. Examine upon receipt, consistent with practicality, to detect damage
b. Provide storage that precludes deterioration
c. Examine prior to installation, consistent with practicality, to detect damage
d. Identify and protect from improper use or disposition
e. Verify and audit quantities every quarter with 100% inventory annually
3.12.1.3 The vendor shall provide a data library of source documentation and data used to create the TSMT system and document it in accordance with the deliverable (3.8.3.20)
3.12.1.4 The vendor shall participate in the Government led incremental logistics demonstrations/maintenance evaluations.
3.12.1.5 The vendor shall design the Product Support to support a third-party maintainer.
3.12.1.5.1 The system vendor shall provide transition of product support to another provider at the end of the contract period of performance.
3.12.1.6 The system vendor shall provide sustainment projections for the lifecycle management and affordability of the TSMT solution.
3.12.2 Interim Contractor Support
3.12.2.1 The vendor shall provide ICS starting with first hardware delivery to the Government and continue for at least 24 months after the final release of capability in accordance with contract options.
55DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
1825
182618271828
1829
18301831183218331834
18351836
1837
1838
1839
1840
1841
18421843
18441845
1846
18471848
18491850
1851
185218531854
3.12.2.2 During the ICS period, the vendor shall repair/replace, as directed by the Government, defective TSMT hardware, this includes performing warranty actions as needed.
3.12.2.3 During the ICS Period, the vendor shall process bug reports, conduct preventative and corrective maintenance, patch, and update delivered software as required.
3.12.2.4 The vendor shall document TSMT system ICS in accordance with the deliverables (3.8.3.2, 3.8.3.5, 3.8.3.11, and 3.8.3.14).
3.12.2.5 During the ICS period, the vendor shall provide sufficient data in accordance with the deliverables (3.8.3.2 and 3.8.3.11) to enable an analysis to determine core logistics capabilities and sustainment support requirements.
3.12.2.6 During the ICS period, the vendor shall document and provide to the Government technical data on systems issued to the field to inform improvements prior to making production decisions.
3.12.2.7 During the ICS period, the vendor shall provide Helpdesk support.
3.12.2.8 During the ICS period, the vendor shall track and document maintenance actions and identify system configuration issues in accordance with the deliverables (3.8.3.2 and 3.8.3.26).
3.12.3 Maintenance Planning/Concept3.12.3.1 The vendor shall develop and provide a LORA in accordance with the deliverable
(3.8.3.3).3.12.3.2 The vendor shall develop and provide a FMECA in accordance with the deliverable
(3.8.3.4)
3.12.3.3 The vendor shall provide a prognostic health monitoring system that provides for continuous prognostic and preventative maintenance.
3.12.3.4 The vendor shall provide remote diagnostic capability to allow helpdesk troubleshooting and corrective actions.
3.12.3.5 The vendor shall provide an automated built-in-test (BIT) functionality that runs at system startup and as selected by the maintainer/helpdesk.
3.12.3.6 The vendor shall develop and document a 2-level maintenance concept that considers current field maintenance capabilities, and training audience level in accordance with the deliverables (8.3.11 and 8.3.14).
3.12.3.7 The vendor shall maintain and document software using the DevSecOps process.
56DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
18551856
18571858
18591860
186118621863
186418651866
1867
186818691870
1871
18721873
18741875
18761877
18781879
18801881
188218831884
1885
3.12.3.8 The vendor shall recommend a spares package to meet operational availability and material availability for TSMT Hardware issued to the TIF, Operational Test, and the fielded locations.
3.12.3.8.1 The vendor shall procure and deliver the spares packages to the appropriate locations upon receiving Government approval.
3.12.3.1 The vendor shall document and provide failure data to inform Reliability, Availability, and Maintainability (RAM) to enable maintenance analysis in accordance with the deliverables (3.8.3.2 and 3.8.3.26).
3.12.4 Warranty3.12.4.1 The vendor shall track and document warranties in accordance with the deliverable
(3.8.3.28).
3.12.4.2 The vendor shall provide no cost warranty transfer to the Government or third-party maintainer.
3.12.4.3 The vendor shall purchase, as applicable, transferable extended warranties to coincide with the duration of the ICS period.
3.12.5 Configuration Audits3.12.5.1 Configuration Audits – Functional
3.12.5.1.1 The vendor shall satisfy FCA requirements by successfully completing Operational Testing (see Section 3.11.1)
3.12.5.2 Configuration Audits – Physical 3.12.5.2.1 The vendor shall satisfy the following PCA entry criteria prior to initiating the PCA
processesa. Training system hardware design is complete except for the shortages /
deviations / waivers and has been captured in the final released engineering data and associated lists.
b. Trainer hardware installation is complete for conduct of the auditc. The vendor shall provide the Government a compiled listing of all shortages /
deviations / waivers and status of ECPs available.d. Contractor and sub-contractor released Product Engineering Design Data and
Associated Lists are complete and available to the Government at the beginning of the joint PCA.
e. A complete trainer drawing tree depicting the parent to child relationship of all drawings (contractor and subcontractor) has been delivered to the Government.
57DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
188618871888
18891890
189118921893
1894
18951896
18971898
18991900
1901
1902
19031904
1905
19061907
190819091910
1911
19121913
191419151916
191719181919
f. Technical publications, Logistics Product Data (LPD) operator and maintenance manuals, TSSD, and provisioning list, including redlines, are complete and available to the Government at the joint PCA
g. Government / vendor IPT participation has been coordinated.3.12.5.2.2 The vendor shall conduct PCAs with the Government, on the as built TSMT
system with power off, that will consist of non-functional examinations performed IAW the Government accepted Test and Evaluation Plan to demonstrate that the TSMT as-built design and that the deliverable hardware and software documentation accurately reflect the CI.
3.12.5.2.3 The vendor shall provide non-deliverable documents in contractor format as needed to determine vendor compliance with configuration management (CM) requirements.
3.12.5.2.4 The vendor shall certify, prior to the start of PCA examinations, that all electrical power, including UPS systems, have been disconnected and de-energized.
3.12.5.2.5 The vendor shall comply with the Occupational Safety and Health Administration (OSHA) lockout-tag out requirements specified in 29 CFR 1910.147.
3.12.5.2.6 The vendor shall provide the personnel, equipment, and facilities necessary to support the Government-conducted examinations.
3.12.5.2.7 The vendor shall be responsible for the disassembly, as required, of the Line Replaceable Units (LRU) for access to TSMT equipment.
3.12.5.2.8 The vendor shall record the results of the PCA examinations in accordance with the deliverable (3.8.3.28)
3.12.5.2.9 The vendor shall satisfy the following PCA exit criteria prior to closing out the PCA:a. All contractor and subcontractor released Product Engineering Design Data
and Associated Lists were provided to the Government for audit.b. Contractor has captured and entered all Government discrepancy reports in
the tracking database.3.12.5.3 Configuration Audits – Software3.12.5.3.1 For each software item, software configuration audits shall be conducted by the
vendor for each baseline and witnessed by the Government. 3.12.5.4 The vendor shall present a detailed plan for performing configuration audits prior to
release of the baseline in accordance with the deliverable (3.8.3.29)
3.12.6 Diminishing Manufacturing Sources and Material Shortages 3.12.6.1 The vendor shall identify, document, and manage DMSMS in accordance with the
deliverable (3.8.3.14).
58DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
192019211922
1923
19241925192619271928
192919301931
19321933
19341935
19361937
19381939
19401941
1942
19431944
19451946
1947
19481949
19501951
1952
19531954
3.12.6.2 The vendor shall use an automated tool to aid in equipment selection and track and manage DMSMS.
3.12.7 Technical Support Documentation3.12.7.1 The vendor shall integrate the technical documentation (e.g. System/Software User
Manuals, Operator Manuals, COTS manuals, Maintenance Manuals, engineering data, programmatic data, etc.) from OWT, SVT, SiVT and RVCT into the TSMT system technical documentation providing a single source of integrated technical documentation.
3.12.7.2 The vendor shall host and participate in Government led in-process reviews at 40% and 80% of document completion in accordance with the entry and exit criteria.
3.12.7.3 The vendor shall conduct a validation of the Technical Documentation, participate in a Government run verification of the Technical Documentation, and report it in accordance with the deliverables (3.8.3.12 and 3.8.3.23).
3.12.7.4 The vendor shall provide the Technical Documentation in interactive electronic format in accordance with the deliverables (3.8.3.1, 3.8.3.6, 3.8.3.7, and 3.8.3.8).
3.12.7.5 The vendor shall document all COTS items and modified COTS items in accordance with deliverable (3.8.3.1).
3.12.7.6 The vendor shall document and provide a process to reboot the TSMT hardware in accordance with the deliverables (3.8.3.7, and 3.8.3.8).
3.12.7.7 The vendor shall develop and publish a STE DevSecOps Integrated Operations Guide in accordance with the deliverable (3.8.3.6).
3.12.7.8 The vendor shall provide integrated engineering data and software flow diagrams in the Technical Documentation in accordance with the deliverables (3.8.3.9, 3.8.3.10, and 3.8.3.11).
3.12.7.9 The vendor shall document common and special tools and test equipment, if applicable, in the Technical Documentation in accordance with the deliverables (3.8.3.7 and 3.8.3.11).
3.12.7.10 The vendor shall include integrated supporting documentation for the maintenance and operation training tools in the Technical Documentation in accordance with the deliverable (3.8.3.15).
3.12.8 Training3.12.8.1 The vendor shall integrate TSMT training products with training products from other STE
system vendors and document the training in accordance with the deliverables (3.8.3.15, 3.8.3.17, 3.8.3.23, 3.8.3.24, and 3.8.3.25).
3.12.8.2 The vendor shall provide sufficient perpetual licenses for any commercial products used in the TSMT training development, modification, and presentation.
59DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
19551956
1957
1958195919601961
19621963
196419651966
19671968
19691970
19711972
19731974
197519761977
197819791980
198119821983
1984
198519861987
19881989
3.12.8.3 The vendor shall provide a STE system NET “train the trainer” course for instructors/trainers and maintainers.
3.12.8.3.1 The vendor shall provide the STE NET courses at five locations as identified in the fielding locations table.
3.12.8.3.2 The vendor shall accommodate a maximum of ten students for each STE NET course including student course materials.
3.12.8.4 The vendor shall develop and document specific task videos covering critical and infrequent tasks for use as refresher and just in time training in accordance with the deliverables (3.8.3.15 and 3.8.3.25).
3.12.8.5 The vendor shall develop, document, and embed in the TSMT system applications for use by the intelligent tutoring system to provide just in time and refresher training in accordance with the deliverables (3.8.3.15 and 3.8.3.23).
3.12.9 Item Unique Identification3.12.9.1 The vendor shall apply and register Government approved Item Unique Identification
labels to all material that will be delivered to the Government in accordance with MIL-STD-130 and the deliverable (3.8.3.16).
3.12.10 System Delivery3.12.10.1 The vendor shall assist the Government with coordination of system delivery.
3.12.10.2 The vendor shall assist with the preparation of system delivery documentation.
3.12.10.3 The vendor shall prepare briefing slides documenting the system delivery process for each site.
3.12.10.4 The vendor shall conduct site surveys with the Government to determine suitability of the TSMT system delivery location and any adjustments to the TSMT system configuration that will be required prior to delivery.
3.12.10.5 The vendor shall participate in telephone Site Readiness Review meetings as determined by the Government to coordinate with the TSMT system receiving site in the months prior to delivery.
3.12.10.6 The vendor shall conduct site installation.
3.12.10.7 The vendor shall conduct site testing.
3.12.10.8 The vendor shall conduct site training.
3.12.10.9 The vendor shall conduct site daily reporting.
60DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
19901991
19921993
19941995
199619971998
199920002001
2002
200320042005
2006
2007
2008
20092010
201120122013
201420152016
2017
2018
2019
2020
3.12.10.10 The vendor shall conduct site daily briefs.
3.12.10.11 The vendor shall cleanup and remove debris left over from the installation activities prior to departing the installation site.
3.12.10.12 The vendor shall be responsible for repair of any damage caused by their personnel or equipment during the installation activities.
3.12.10.13 The vendor shall incrementally demonstrate the product support processes with the resources needed to operate and sustain the system during TAs, UAs, and Operational Tests.
3.12.10.13.1 The vendor shall incrementally demonstrate the documented TSMT setup procedures during the TAs, UAs, and Operational Tests.
3.12.10.13.2 The vendor shall incrementally demonstrate the documented procedures for execution of a mission during the TAs, UAs, and Operational Tests.
3.12.10.13.3 The vendor shall incrementally demonstrate representative field and depot maintenance (using the technical documentation) that returns the TSMT from failure to full operating status during the TAs, UAs, and Operational Tests.
3.12.10.13.4 The vendor shall incrementally demonstrate preparing the TSMT system for transportation during the TAs, UAs, and Operational Tests.
3.12.10.13.5 The vendor shall incrementally demonstrate the storage process during the TAs, UAs, and Operational Tests.
3.12.10.13.6 The vendor shall incrementally demonstrate the shipping processes during the TAs, UAs, and Operational Tests.
3.13 Security3.13.1 Industrial SecurityAny contractor (prime or sub) that is a Foreign Owned, Controlled, or Influenced (FOCI) company that does not have their FOCI mitigated by the Defense Counterintelligence and Security Agency (DCSA) and who does not possess a Facility Clearance Level (FCL) by submission of their Demonstration Plan, cannot prime this contract.
3.13.1.1 The vendor shall meet security requirements as instructed in form DD254.
3.13.1.2 The vendor shall develop a TSMT system that complies with the RMF, the cybersecurity plan, and local security policies.
61DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2021
20222023
20242025
202620272028
20292030
20312032
203320342035
20362037
20382039
20402041
2042
2043
2044204520462047
2048
20492050
3.13.1.3 The highest level of classification required for this effort is: SECRET / SECRET REL. The multiple nodes exist in a variety of security enclaves, including unclassified, SECRET, and SECRET REL.
3.13.1.4 The vendor shall meet all applicable security requirements for protecting controlled unclassified information and secret information.
3.13.2 CybersecurityTSMT complies with applicable DoD Cyber Survivability Endorsement, Volumes I-III, Cyber Survivability Endorsement Implementation Guide and establishes safeguards IAW all cybersecurity related policies, regulations, and the DoD’s best business practices to include:
DoDI 8500.01Cybersecurity DoDI 5200.44 Protection of Mission Critical Functions to Achieve Trusted
Systems and Networks (TSN) AR 25-2 DoDD 8140.01 Cyberspace Workforce Management DoD 8570.01-M Information Assurance Workforce Improvement Program DA PAM 25-2-6 Cybersecurity Training and Certification DA PAM 25-2-7, Army Information System Privileged Access NIST 800-171, Protecting Controlled Unclassified Information in Nonfederal
Systems and Organizations
See Appendix G Cybersecurity for the CDS phases flowchart.
3.13.2.1 Cyber Survivability3.13.2.1.1 The vendor shall comply with DoD Cyber Survivability Endorsement, Volumes I-
III, Cyber Survivability Endorsement.3.13.2.1.2 The vendor shall respond to cybersecurity tasking orders, as directed by the
Government, provided by organizations such as NETCOM's 7th Signal Command, DOD CIO G6 and US Cyber Command.
3.13.2.1.3 The vendor shall manage vulnerabilities to maintain cyber survivability capabilities (e.g., automated patch management, mitigation of known threats, and effects of obsolescence).
3.13.2.2 Risk Management Framework
62DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
205120522053
20542055
2056
2057205820592060
2061206220632064206520662067206820692070
2071
2072
20732074
207520762077
207820792080
2081
3.13.2.2.1 The vendor shall comply with all required DoD and Army regulations (e.g., DoDI 8510.01 RMF for DoD IT, Committee on National Security Systems Instruction (CNSSI) 1253, the National Institute of Standards and Technology (NIST) SP 800-53, and Army Regulation AR 25-2) to implement and document the cybersecurity requirements, processes, and procedures to meet the Confidentiality, Integrity, and Availability impact levels of Moderate-Moderate-Low.
3.13.2.2.2 The vendor shall mitigate or fix all category 1 (CAT1) noncompliance items within 30 days of submission to the Package Approval Chain.
3.13.2.2.3 The vendor shall be Army Endpoint Security System (AESS) compliant. 3.13.2.2.4 The vendor shall develop and maintain the functional architecture/topology
diagram, authorization boundary diagram, and data flow diagram, using the NETCOM template format in accordance with the deliverables (3.8.2.2).
3.13.2.2.5 The vendor shall review and support the system categorization.3.13.2.2.6 The vendor shall plan, resource, and document the RMF Assessment and
Authorization (A&A) for the test and development enclaves and fielding sites IAW Table 3-2 and Table 3-3.
3.13.2.2.7 The vendor shall produce all components of the required RMF packages (i.e. IATT, ATO) necessary to test, develop, deliver, and operate an authorized system in accordance with the deliverables (3.8.1.2).
3.13.2.2.8 The vendor shall evaluate and document all system, interfaces and network changes that impact security in accordance with the deliverables (3.8.1.2).
3.13.2.2.9 The vendor shall develop and maintain the system cybersecurity artifacts required by RMF, DoD, DoDI, and NIST regulations, guidelines, and controls (e.g., Security Plan (SP), Continuity of Operations Plan (COOP), Contingency Plan (CP), Incident Response Plan (IRP), CMP, Standard Operating Procedures (SOP), eMASS Control Self-Assessment test results input, Ports, PPSM document) in eMASS in accordance with the deliverables (3.8.1.2).
3.13.2.2.10 The vendor shall create and maintain the System RMF authorization documentation, processes, and assessments in eMASS to achieve the fielding and DT&I sites RMF Authorizations (i.e. IATT, ATO) in accordance with the deliverables (3.8.1.2). Note: Secure Internet Protocol Routing (SIPR) eMASS instance is required for classified systems.
3.13.2.2.11 The vendor shall complete the eMASS RMF Implementation Plan in accordance with the deliverables (3.8.1.2).
3.13.2.2.12 The vendor shall develop a Continuous Monitoring Plan and update the System-level Continuous Monitoring (SLCM) Strategy in eMASS in accordance with the deliverables (3.8.1.2).
63DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
208220832084208520862087
20882089
2090
209120922093
2094
209520962097
209820992100
21012102
210321042105210621072108
21092110211121122113
21142115
211621172118
3.13.2.2.13 The vendor shall input RMF data into eMASS; ports, protocols, and services management (PPSM) registry, Army Portfolio Management Solution (APMS) and other database repositories as required by DoD directives and instructions in accordance with the deliverables (3.8.1.2).
3.13.2.2.14 The vendor shall develop and maintain a hardware and software lists in eMASS that includes version(s), vendor(s), vendor addresses, vendor phone numbers, release dates, license(s), certifications dates, termination or authorization dates, and authorization expiration dates in accordance with the deliverables (3.8.1.2).
3.13.2.2.15 The vendor software development and integration shall comply with RMF practices and guidelines for the Enclave Test and Development (T&D) Security Technical Implementation Guide (STIG) to achieve Development, Test, and Integration (DT&I) environment RMF authorizations (i.e., IATT and ATO) for the management and storage of TSMT related data. Note: DT&I environment RMF authorization is required to host or interoperate with GFE/GFI products such as MCIS, software applications such as LVC-IA, and authoritative data sources such as ATIS. DT&I environment RMF authorization is required to establish external connections with the Federal, State, and University Network (FEDSUN) that provides access to the Defense Research Engineering Network (DREN) and NIPRNET.
3.13.2.2.16 The vendor shall coordinate with the Government to obtain the TSMT system authorization from the AO 30 days prior to deploying to test and development enclaves and fielding sites IAW Table 3-2 and Table 3-3.
3.13.2.2.17 The vendor shall employ current Army Best Practice scanning and remediation monthly.
3.13.2.2.18 The vendor shall ensure log files and audits are collected, maintained, and reviewed for all systems.
3.13.2.2.19 The vendor shall audit authentication policies (e.g., password) policies for compliance.
3.13.2.2.20 The vendor shall review Audit Logs for alarms. 3.13.2.2.21 The vendor shall ensure the Information Assurance Vulnerability Alert (IAVA) and
STIGs can be applied individually when needed without the need to re-image the system.
3.13.2.2.22 The vendor shall develop an automated patch management plan that includes IAVA implementation by due date.
3.13.2.2.23 The vendor shall implement all hardware, network, and software STIGs. 3.13.2.2.24 The vendor shall develop an automated patch management plan that implements
new DISA STIGs NLT 30 days after the STIG release. Note: DISA releases updates and new STIGS on a 90-day cycle.
64DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2119212021212122
2123212421252126
2127212821292130213121322133213421352136
213721382139
21402141
21422143
21442145
2146
214721482149
21502151
2152
215321542155
3.13.2.2.25 The vendor shall document the system's Cybersecurity Deviation Report for Government approval for all updates that cannot be applied within 30 days in accordance with the deliverable (3.8.1.2).
3.13.2.2.26 The vendor shall report all IAVA, STIGs, and Bulletins in a system Plan of Action and Milestone (POA&M) that includes a list those implemented, those not implemented, justification for items not implemented, and mitigation for those not implemented at least monthly, or more frequent if directed by the local AO.
3.13.2.2.27 The vendor shall document all IAVA, STIGs, Bulletins, and security control implemented, not implemented, justification for items not implemented, impacts, and mitigations in the POA&M in eMASS at least monthly, or more frequent as directed by the local AO.
3.13.2.2.28 The vendor shall ensure cybersecurity posture and accreditation boundaries are not impacted during support and maintenance.
3.13.2.2.29 The vendor shall ensure that security changes do not invalidate any authorized accreditation.
3.13.2.3 Cross Domain Solution Authorization (CDSA)3.13.2.3.1 The vendor shall design, use, and support the authorization of the selected CDS
in a secure, enterprise environment IAW DoDI 8540.01 and Chairman Joint Chiefs of Staff Instruction (CJCSI) 6211.02D.
3.13.2.3.2 The vendor shall define data flowing through the CDS within 60 days of OTA award to support ACDMO questionnaires for Phase 1.
3.13.2.3.3 The vendor shall support the CDSA waiver artifact development, testing, and authorization processes for each required security.
3.13.2.4 Cybersecurity Incident Reporting3.13.2.4.1 The vendor shall develop a program IRP in compliance with PEO STRI and Army
IRP procedures NLT 30 TBD days after contract.3.13.2.4.2 The vendor shall comply with the IRP when responding to a cybersecurity related
incident.3.13.2.5 Cybersecurity Training
3.13.2.5.1 The vendor shall deny access to DoD information systems when contractor personnel do not have proper and current certifications.
3.13.2.5.2 The vendor shall ensure that System Administrators and Network Administrators meet the minimum requirements for technical category Level II (IAT Level II) and workforce management category Level I (Information Assurance Manager [IAM] Level I) as defined by DoD 8570.01-M.
65DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
215621572158
2159216021612162
2163216421652166
21672168
21692170
2171
217221732174
21752176
21772178
2179
21802181
21822183
2184
21852186
2187218821892190
3.13.2.5.3 The vendor shall verify employees have at least 3 years' cybersecurity or related experience (e.g., operating systems, network devices, database) for the system being managed at the moment of hiring.
3.13.2.5.4 The vendor shall have up to six months to obtain the remaining employee certification or training qualifications for their position in accordance with DoD 8570.01-M.
3.13.2.5.5 The vendor shall verify that all TSMT vendor and sub-vendor cybersecurity personnel manage their training and certification through the Army Training and Certification Tracking System (ATCTS) found at https://atc.us.army.mil.
3.13.2.5.6 The vendor shall provide the Government verification that Cybersecurity/IT personnel meet the baseline certification requirements established in the DoD 8570.01-M and DoDD 8140.01 Cyberspace Workforce Management for the category and level functions in which they are performing by contract award and update monthly after contract. Approved baseline certifications and a list of cybersecurity workforce certification providers is available at: https://public.cyber.mil/cw/cwmp/dod-approved-8570-baseline-certifications/.
3.13.2.5.7 The vendor's Information System Security Manager (ISSM) shall appoint in writing TSMT cybersecurity personnel and provide to the Government NLT 10 days after contract award and update monthly accordance.
3.13.2.5.8 The vendor shall document information assurance certification status for TSMT personnel performing information assurance functions and provide to the Government NLT 10 days after contract award and update monthly.
3.14 Safety and HealthThe vendor complies with Federal, State, and local environmental laws and regulations, Executive Orders, treaties, and agreements required to maintain a safe and non-hazardous occupational environment. The TSMT design complies with all applicable safety and health requirements prevent any uncontrolled safety and health hazards to the operator or maintenance personnel throughout its life cycle. The TSMT design and operational characteristics minimizes the possibilities for accidents or mishaps caused by human error or system failure.
3.14.1 Safety3.14.1.1 The vendor design shall be compliant with the following standards and publications to
optimize system performance and t to prevent safety, health, environmental, ergonomic, and software/firmware (to include modifications updates and new system interfaces) hazards.
MIL-STD-1472, Human Engineering Design Criteria, Principles, and Practices:66
DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
219121922193
219421952196
219721982199
2200220122022203220422052206
220722082209
221022112212
2213
2214221522162217221822192220
2221
2222222322242225
2226
MIL-STD-882E, DoD Standard Practice, System Safety. DA PAM 385-30, Safety Risk Management Technical Bulletin (TB) 43-0134
(Battery Disposition and Disposal AR 385-10 The Army Safety Program and Army Pamphlet (DA Pam) 385-16
System Safety Management Guide
3.14.1.2 The vendor shall document all known software and hardware hazards using the US Army Risk Management process in a Hazard Tracking Log and provide to the Government.
3.14.1.3 The vendor shall provide data required for event safety releases not later than 20 calendar days prior to Soldier involved assessment events in accordance with the deliverables (3.8.2.13).
3.14.1.4 The vendor shall provide a Safety Assessment Report that quantifies all known hazards IAW MIL-STD 882E in accordance with the deliverables (3.8.2.13).
3.14.1.5 The vendor shall provide a safety lead to participate in the program System Safety Working Group.
3.14.2 Health3.14.2.1 The vendor shall provide a Health Hazard Assessment (HHA) to the Program Office and
prior to each program increment, MVP, MVCR, and subsequent software releases to identify, assess, and provide mitigation of potential health hazards as required by AR 40-10, Health Hazard Assessment Program in Support of the Army Acquisition Process.
3.14.2.2 The vendor HHA shall identify and assess health hazards associated with the life cycle management of materiel systems and provide recommendations to the Program Office to eliminate or control system hazards.
4 References# Reference Title Web Location
1 29 CFR 1910.147 “The Control of Hazardous Energy (Lockout/Tagout)” June 2011
https://www.energy.gov/sites/prod/files/2013/06/f1/29cfr-1910-147_ssm.pdf
2 ADP 5-0 “The Operations Process” 17 May 2012 https://armypubs.army.mil/ProductMaps/PubForm/ADP.aspx
3 ADRP 5-0 “The Operations Process” 17 May 2012 https://armypubs.army.mil/ProductMaps/PubForm/ADRP.aspx
4 AR 25-2 "Army Cybersecurity" 4 April 2019https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/ARN17503_AR25_2_Admin_FINAL.pdf
5 AR 40-10"Health Hazard Assessment Program in Support of the Army Acquisition Process" 27 July 2007
https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/AR%2040-10.pdf
67DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
22272228222922302231
22322233
223422352236
22372238
22392240
2241
2242224322442245
224622472248
2249
# Reference Title Web Location
6 AR 70-38“Research, Development, Test and Evaluation of Materiel for Extreme Climatic Conditions” 26 June 2020
https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN30017-AR_70-38-000-WEB-1.pdf
7 AR 385-10 "The Army Safety Program" 24 February 2017
https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/ARN16777_ARN16343_AR385_10_FINAL.pdf
8
Army Training and Certification Tracking System (ATCTS)
Army Training and Certification Tracking System (ATCTS) https://atc.us.army.mil
9 CADE Cost Assessment Data Element (CADE) website http://cade.osd.mil
10 Certifications Cybersecurity Workforce Certifications https://public.cyber.mil/cw/cwmp/dod-approved-8570-baseline-certifications/
11
Chairman Joint Chiefs of Staff Instruction (CJCSI) 6211.02D
“Defense Information Systems Network (DISN) Responsibilities” 24 January 2012 current 4 August 2015
https://www.jcs.mil/Portals/36/Documents/Library/Instructions/6211_02a.pdf?ver=2016-02-05-175050-653
12
Committee on National Security Systems Instruction (CNSSI) 1253
"Security Categorization and Control Selection for National Security Systems" 27 March 2014
https://www.dcsa.mil/portals/91/documents/ctp/nao/CNSSI_No1253.pdf
13
Cyber Survivability Endorsement Implementation Guide
Cyber Survivability Endorsement Implementation Guide
14 DA PAM 25-2-6 "Cybersecurity Training and Certification" 8 April 2019
https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/ARN16685_DAPam25_2_6_FINAL.pdf
15 DA PAM 25-2-7 Army Information System Privileged Access" 8 April 2019
https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/ARN17343_P25_2_7_Admin_FINAL.pdf
16 DA PAM 385-16 "System Safety Management Guide" 13 August 2013
https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/p385_16.pdf
17 DA PAM 385-30 "Safety Risk Management" https://armypubs.army.mil/epubs/DR_pubs/DR_a/pdf/web/p385_30.pdf
18 DoD 8570.01-M"Information Assurance Workforce Improvement Program" 19 December 2005with change 4 10 November 2015
https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodm/857001m.pdf
19 DoD Agile Metrics Guide
"DoD Agile Metrics Guide, Strategy Considerations and Sample Metrics for Agile Development Solutions Version 1.1" dated 23 September 2019
https://www.dau.edu/cop/it/DAU%20Sponsored%20Documents/Agile%20Metrics%20v1.1%2020191122.pdf
68DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
# Reference Title Web Location
20 DoD DevSecOps Reference Guide
“DoD Enterprise DevSecOps Reference Design Version 1.0” 12 August 2019
https://dodcio.defense.gov/Portals/0/Documents/DoD%20Enterprise%20DevSecOps%20Reference%20Design%20v1.0_Public%20Release.pdf?ver=2019-09-26-115824-583
21
DoD Cyber Survivability Endorsement, Volumes I-III
DoD Cyber Survivability Endorsement, Volumes I-III
22 DoDD 8140.01"Cyberspace Workforce Management" 11 August 2015 with change 1 31 July 2017
https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodd/814001p.pdf
23 DoDI 8500.01 "Cybersecurity" 14 March 2014 with change effective 7 October 2019
https://www.esd.whs.mil/portals/54/documents/dd/issuances/dodi/850001_2014.pdf
24 DoDI 8510.01 "Risk Management Framework for DoD Information Technology” 28 Jul 2017
https://www.esd.whs.mil/Directives/issuances/dodi/
25 DoDI 8540.01 "Cross Domain Policy" 8 May 2015 with change 1 28 August 2017.
https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/854001p.pdf
26 DoDI 5200.44
"Protection of Mission Critical Functions to Achieve Trusted Systems and Networks" 5 November 2012, with change 3 15 October 2018
https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/520044p.pdf
27 DOT&E Memorandum
"Procedures for Operational T&E of Cybersecurity in Acquisition Programs" 3 April 2018
https://www.dote.osd.mil/Portals/97/pub/policies/2018/20180403ProcsForOTEofCybersecurityInAcqProgs(17092).pdf
28Enterprise Cloud Management Office (ECMO)
ECMO Policies and Strategies https://www.milsuite.mil/book/groups/enterprise-cloud-management-office-ecmo/overview
29 FM 7-0 “Train to Win in a Complex World” 5 October 2016
https://armypubs.army.mil/ProductMaps/PubForm/FM.aspx
30 MIL-STD-882E "DoD Standard Practice, System Safety" 11 May 2012
http://acqnotes.com/acqnote/tasks/mil-std-882e-system-safety
31 MIL-STD-1472G Change 1
“Human Engineering Design Criteria, Principles, and Practices w Change 1 17 January 2019
http://everyspec.com/MIL-STD/MIL-STD-1400-1499/MIL-STD-1472G_CHG-1_56051/
32MOSA Implementation Guide
"Modular Open Systems Approach (MOSA) Implementation Guide Version 1.0" 10 June 2020
33 MOSA Reference Frameworks
"Modular Open Systems Approach (MOSA) Reference Frameworks in Defense Acquisition Programs" May 2020
https://ac.cto.mil/wp-content/uploads/2020/06/MOSA-Ref-Frame-May2020.pdf
69DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
# Reference Title Web Location
34 NIST SP 800-53
"National Institute of Standards and Technology (NIST) SP 800-53 Rev 5 Security and Privacy Controls for Information Systems and Organizations" September 2020
https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
35 NIST SP 800-171
"National Institute of Standards and Technology (NIST) SP 800-171 Rev 2 Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations" February 2020
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r2.pdf
36 PART Program Assessment Review Tool https://www.dau.edu/cop/mosa/lists/tools/allitems.aspx
38 TB 43-0134 "Battery Disposition, Handling and Disposal" 30 May 2018
https://liw.logsa.army.mil/etmapp/api/general/search/084893/0/pdf
70DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2250
2251
2252
This page intentionally left blank.
71DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2253
2254
2255
2256
2257
2258
2259
2260
2261
Appendix A Capability Descriptions
A.1 One World Terrain
One World Terrain delivers a 3D global terrain capability and associated information services that support virtual replication of the physical Earth and complexities of the operational environment in support of training as provisioned through the Army's Synthetic Training Environment and dynamically rendered at the point-of-need. Specifically, OWT provides a synthetic/virtual World representation that supports land, air, maritime, and space operations to facilitate multi-domain operations; a well-formed format that is consumable by standard commercial tools and technologies; automatic processing of raw terrain data into the well-formed format; and a terrain configuration management capability that incorporates approved geospatial information updates and local terrain surveys back into the OWT foundational repository.
A.2 Reconfigurable Virtual Collective Trainer
The RVCT hosts the physical platform elements (e.g., cyclic, collective pedals, steering wheels, switches). The RVCT physical controls will interface with the TSS API through the platform abstraction layer. The TSS will contain a functional virtual representation of the RVCT platforms. For example, the TSS will contain the inside of an Apache helicopter visually displaying the interior of the cockpit with all the switches needed for collective training being functional (think game console or PC game). The RVCT vendor will provide 3D interior platform models and supplement the TSS virtualized hardware components and functionality with physical hardware to create the appropriate fidelity for the RVCT end user.
RVCT Initial Operational Capability (IOC) and Full Operational Capability (FOC) Definitions for the current increment
IOC Definition and target date IOC attainment is projected to occur in Fiscal Year (FY) 2022, subject to change based on the rate of progress of development of the material solution. IOC is defined as the first fielding and acceptance of the RVCT capability by an installation. It is further defined as:
All RVCT components have completed the verification, validation and accreditation process prior to IOC.
All RVCT equipment is fielded to the first installation site and accepted.
All Information Assurance (IA) requirements are complete.
1DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2262
2263
2264226522662267226822692270227122722273
2274
227522762277227822792280228122822283
22842285
2286228722882289
22902291
2292
2293
New Equipment Training (NET) at the first site is complete.
Network Enterprise capabilities are sufficient to support the STE-IS capabilities to include RVCT.
All product support requirements for RVCT operations and support are in place and ready to support unit training at the first site.
RVCT FOC Definition and target date
FOC attainment is projected to occur in FY 2027. FOC is achieved when the Basis of Issue Plan (BOIP) for the RVCT has been fielded to all sites (post, installation, armory, and institution) scheduled for fielding and all sites have accepted their associated RVCT equipment.
FOC is further defined as:
Meets or exceeds all threshold requirements All equipment associated with the RVCT has been fielded, in accordance with the
APO and BOIP. All IA requirements are complete. Network Enterprise capabilities to support the STE-IS capabilities, including
RVCT. New Equipment Training (NET) at all sites is complete. All product support requirements for RVCT operations and support are in place
and ready to support unit training at all sites. The RVCT sustainment plan is in place and being executed.
A.3 Live Virtual Constructive Integrating Architecture
LVC-IA is a net-centric linkage that collects, retrieves, and exchanges data among TADSS and Joint and Army Mission Command Systems. LVC-IA defines “how” information is exchanged among TADSS and Mission Command Systems. It enables the live, virtual, constructive training audience to see the common operating picture and to communicate using organizational command and control equipment. LVC-IA provides the common protocols, specifications, standards, and interfaces that help standardize common LVC components and tools required for interoperability of LVC components for simulations/stimulation (SIM/STIM) of unit MCS for training.
2DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2294
22952296
22972298
2299
2300230123022303
2304
2305230623072308230923102311231223132314
2315
23162317231823192320232123222323
A.4 Mission Command Information Systems
The Army employs the Command Post Computing Environment (CPCE) in operations. It must do so also in training to help retain the knowledge and expertise in MCIS employment, contributing to the maintenance of (digital) readiness. Their inclusion in training is also consistent with the Army viewpoint of train as you fight.
The solution software system design shall seamlessly integrate and maintain concurrency with the COE, MCIS, and Operational Platforms. The software system design shall provide flexible, extensible data models and interfaces (i.e. API, Software Development Kits [SDK], Command Line Interfaces [CLI], Web Interfaces, and Graphical User Interfaces) that foster interoperability and integration while maintaining synchronization of data across all components of the STE. The solution software system design shall be loosely coupled to support the upgrade and, when necessary, the replacement of STE modules. The full list of MCIS is located within the TDP Appendix E SRD.
A.5 Avionics Software Emulation
AvSE is tactical or emulated software that provides the functionality of the Operational Flight Program (OFP) and flight model to simulate flying the aircraft. Each platform has a unique instantiation of the AvSE, and some include sensor models.
A.6 Common Software Library
The CSL is a software component for Army ground vehicle trainers which replicates vehicle functionality using vehicle source code. The process of creating a CSL removes hardware specific code to allow training devices to replicate vehicle functions and simulate vehicle performance using common PC hardware. Use of a CSL for vehicle trainers ensures high functional fidelity for the training audience and helps maintain concurrency with the current fielded platform.
A.7 Army Training Information System
The enterprise ATIS provides a common operational picture of the training environment through integrated, interoperable training development, management, scheduling, and delivery capabilities. These capabilities will enable Commanders, leaders, Soldiers, and civilians to better understand, visualize, describe, direct, lead, and assess training requirements so they can more effectively plan, prepare, execute, and assess training.
3DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2324
2325232623272328
232923302331233223332334233523362337
2338
233923402341
2342
234323442345234623472348
2349
23502351235223532354
End result is a system that enables Soldiers to train as they will fight, so they can effectively fight as they have trained. ATIS includes the following five major capabilities:
Army Training Management Capability. Provides individual and collective training managers ability to manage Training & Education information, including military individual and collective training that supports mission tasks; provides users centralized access to unit training management and their individual training records.
Training Enterprise Scheduling Capability. Provides unit leaders, installation leaders, training managers, trainers, and instructors ability to submit and manage schedule requests for Training & Education resources, including transportation, classrooms, ranges, supplies, and mandated legal and social individual and unit training usage. Scheduling enabler for Training & Education.
Training Resource Management Capability. Provides leaders, training managers, training developers, trainers, and instructors ability to manage inventory and sustainability of Training & Education enablers (i.e. ranges, classrooms, simulators). Managerial enabler for tracking availability and utilization for Training & Education.
Army Training Development Capability. Provides training developers and training managers the ability to develop and coordinate Training & Education information, including training packages, training events, courses, and exercises in support of the training development enterprise.
Army Learning Content Management Capability. Provides trainers and instructors a single source to deliver Training & Education information, including educational and professional instruction, to students anytime, anywhere; provides users centralized access to Training & Education information necessary to conduct training missions. Provides trainers and instructors a single source to deliver Training & Education information, including educational and professional instruction, to students anytime, anywhere; provides users centralized access to Training & Education information necessary to conduct training missions
A.8 Soldier Virtual Trainer
4DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
23552356
2357235823592360
23612362236323642365
2366236723682369
2370237123722373
23742375237623772378237923802381
2382
The SVT will provide individual weapons skill development; enables Joint Fires training; and exercises Use of Force decision making. The SVT is enabled by the STE and is a virtual immersive trainer that combines and integrates several individual Soldier training capabilities, Weapon Skills Development (WSD), Joint Fires Training (JFT), and Use of Force (UoF), into a single capability that can be used simultaneously or individually. The WSD provides immersive capability to meet individual/crew weapons training in support of Army integrated weapon training strategies (IWTS). The JFT provides certification and qualification of Joint Fires Observers (JFO) IAW with TC 3-09.8. This includes the training of Joint Terminal Attack Controllers (JTAC) types I, II, and III close air support IAW TC 3-09.8 and the JFO and JTAC Memorandums of Agreement. Additionally, the SVT provides UoF training that enables Soldiers to exercise cognitive functions including rapid decision making and target acquisition under stress, including the introduction/removal of verbal interactions.
A.9 Integrated Visual Augmentation System / Soldier Immersive Virtual Trainer
The IVAS is an operational capability that uses mixed reality goggles, wearable compute, and a network bubble. PEO Soldier is the IVAS materiel developer. SiVT software provides the IVAS display an augmented reality view that enables the overlay of Synthetic objects (e.g., virtual soldiers and platforms) and effects (e.g., virtual cratering) on the real-world terrain. This converges Live and Synthetic training in the local training area (LTA). SiVT software adjudicates all activities in the 200-meter box in the stand-alone mode. When part of a larger training event, SiVT will interoperate with the TSS software on the TSMT Edge Node in the NEC. Details of this interoperability must be investigated.
A.10 STE Live Training System
The STE-LTS will enable a true representation of real combat to ensure a multi domain operation ready for force. The STE-LTS will integrate Live training with the STE and ensure interoperability with Joint and Coalition partners. The STE LTS will modernize both force on force and force on target training with the development of the 12 Engagements and 5 Instrumentations. The Engagement Types are: Direct Fire, Counter-Defilade Fire, Indirect Fire, Dropped Objects, Placed Objects, Thrown Objects, Guided and Autonomous Weapons, Direct Energy and Radiant Energy Weapons, Plumes, and Connections (Information Warfare). The "Plus 5" Instrumentation enablers are: Calculations, Network, Sensors, Terrains, and Transmitters. The STE-LTS will provide representation of soldier and weapon capabilities, vulnerabilities, and battlefield
5DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2383238423852386238723882389239023912392239323942395
2396
2397
239823992400240124022403240424052406
2407
2408240924102411241224132414241524162417
effects from the individual Soldier up to the BCT level. This includes an appropriately sized and equipped OPFOR and will include Echelons above Brigade elements, as well as aviation and Special Operations Forces assets. The Twelve engagement types named above will be supported in near-real-time using the five instrumentation capabilities. Physics-based munition trajectory simulations will replace current MILES Probability of Hit (Ph)/Probability of Kill (Pk) tables. The STE-LTS will allow the simulation of all weapon systems in near-real-time; include virtual targets and player avatars in Synthetic Training Environments; and enable post-engagement AARs delivered to training units during training exercises. The STE LTS will replace the current live training capabilities to include home station and maneuver Combat Training Centers (CTC), and deployed training sites of instrumentation systems, engagement capabilities, and range systems. This future system will interface with the STE architecture in native manner; leveraging the Live Training Transformation (LT2) architecture, providing the seamless exchange of content between live and simulated virtual and constructive environments for purpose of integrated EXCON, AAR generation and delivery, Networked Targetry for training on all weaponry from Soldier to BCT echelons with EAB supporting elements and Networked Tactical Engagement Simulation System (TESS) capability collecting real-time Training Performance Data (TPD).
6DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2418241924202421242224232424242524262427242824292430243124322433243424352436
2437
2438
Appendix B Objective Values
The TSMT PWS objective is to provide a Soldier/Squad through Brigade collective training capability that performs at least as proficient as the existing ITE and collective training capabilities (i.e., CCTT, AVCATT, and GFT) and a Brigade and below constructive staff training capability. The FOC is outside the scope of this Agreement, however, it is identified in this appendix as a “objective values” to provide a holistic STE vision. Objective values scale up to ASCC.
Table B-1. Objective Values.
ID Category Objective
OBJ 1Interoperability
The TSMT shall support the Intelligence Warfighting Function by interoperating with IEWTPT via APIs and appropriate classified networks (s).
OBJ 2 OWT3D Objects correctly attributed for simulation training and mission rehearsal needs.
OBJ 3 OWTIntegrate and Base globe Complete (World Geodetic System (WGS)-84, greater than 1m) to support full global coverage and mission rehearsal needs.
OBJ 4 OWTImplement OWT Data Model (logical, physical, and conceptual) and External interfaces / API defined that enable integration and information exchanges.
OBJ 5 OWTImport training and other locations glTF 3D tiles terrain set (enhanced base globe, 20cm to 1m).
OBJ 6 OWT Integrate High Resolution insets (Exterior, Interior, 20cm or better). OBJ 7 OWT Integrate and import vegetation biome point features.
OBJ 8 OWTOWT shall produce JLCCTC and Next Generation Constructive Capability terrain within 4 days (96 hours).
OBJ 9 OWT OWT produces terrain for and HITS via LVC-IA
OBJ 10 OWT
OWT rapid terrain capture shall ingest data from a Squad-equipped UAS (fixed or rotary-wing) with RGB cameras (1in sensor, 3x optical zoom) capable of 90 min flight time, autonomous flight planning and redundant, robust return-to-home features. Range of 15km. FMV-compatible (10 km range). 3-axis gimbal (pitch, roll, yaw)
OBJ 11 OWTOWT rapid terrain capture shall enable Point-of-need photogrammetric processing capabilities - i.e. local compute.
OBJ 12 OWTOWT rapid terrain capture shall enable Classification software to detect and extract features of interest: roads, surfaces, buildings, apertures, threads, change detection, urban clutter, people, vehicles, weapon systems
OBJ 13 OWTOWT rapid terrain capture shall enable Synchronization of data back to Enterprise Grid on both low and high side.
OBJ 14 OWTOWT rapid terrain capture shall enable Data outputs: gltf/3dtiles, kmz, ortho, dsm
1DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2439
244024412442244324442445
2446
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 TMTThe TMT shall interoperate with real world mission command systems up to the ASCC (Joint/MN).
OBJ 18 TMTThe TMT shall interoperate with ATIS and other authoritative data sources to develop the training simulation.
OBJ 19 TMT
The TMT will have the ability to consume data from the other parts of the CSE, namely the RVCT - A/G/S to measure individual and unit performance measures. This data will be described in the TMT object data model (ODM) and stored in a common TMT database.
OBJ 20 TMT
For each event, a common TMT database will be the repository of data produced for that event. The data described in the extended training support package (TSP), such as Task Measures and Steps, will be analyzed to track unit training performance over time. The results from the data collected in the TSS will be stored in the TMT database and later transmitted to the ATIS for individual and collective record management.
OBJ 21 TMT
The TMT ODM will contain at a minimum all the data elements needed to create a TSP. The TMT ODM will also include all the data elements needed to support the calculation of readiness per the Standards of Training Performance in accordance with FM 7-0 and AR 350-1. This new data document will be referred to as an extended TSP.
OBJ 22 TMT
The vendor will document pedagogical guidance for how the TMT is to be used in an instructional setting. Instructional design will include guidance for scenario design, initialization and utilization of the intelligent tutoring system, and utilization of the after-action review software.
OBJ 23 TMT
The TMT shall support two operational modes. The preferred operational mode is cloud delivery know at "platform as a service", where the TMT is comprised of network-based applications that are pre-configured to work with the TSS, RVCT's, OWT, etc.
The second mode is a disconnected mode which an offline mode, where the network-based applications are hosted on local server assets but operate in an identical manner as the cloud delivery mode. In this mode of operation, all scenario and training data is housed on locally hosted storage until reconnected to Army networks or until copied manually to authoritative servers.
2DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
ID Category Objective
OBJ 24 TMTThe TMT may employ user-assistive technologies to ensure all steps are correctly completed during a phase of the PPEA workflow.
OBJ 25 TMT
TMT provisions all the software services across the PPEA workflow. These software services include those required by TSS prior to the execution of the scenario and not limited to "All static Information" network, MCIS, synthetic, LIVE systems and or STE "systems admin data collection and management".
OBJ 26 TMTTMT collects and manages all data/services during all phases of the PPEA workflow including managing all changes to the OE.
OBJ 27 TMTTMT will provide data/interoperability services and management thereof across the PPEA
OBJ 28 TMT
The STE shall provide a TMT that represents the Army Operations Process consistent with FM 7-0, FM 6.0, ADP 5-0, and ADRP 5-0 (The Operations Process) at the Point of Need to plan, prepare, execute, and assess collective training from Squad through ASCC.
OBJ 29 TMT The TMT shall update Soldier records based on completed training.
OBJ 30 TMTTMT manages OWT edits and use of terrain for a particular training event instance depending on the need of the instance scenario. TMT will maintain instance edits and modification for the life of the instance/scenario.
OBJ 31 TMTThe TMT serves as the primary user interface into the STE and must be intuitive and easy to use, requiring zero specialized or formal training to operate.
OBJ 32 TMT
Due to the large amount of information produced and consumed during training, Artificial Intelligence and Machine Learning technologies may be utilized to automate data management and analysis. This real-time and post-event analysis will improve training, readiness and individual / Unit competency. Both humans and automated decision makers will recommend training interventions, assist in collecting objective data for future training assessments, needs and remediation events.
OBJ 33 TrainingThe TSMT shall be able to support distributed exercises to twelve distinct locations.
OBJ 34 TrainingThe TSMT central node with Cross Domain Solution shall be able to support TOP SECRET classification and host multiple classifications in single exercise
OBJ 35 TrainingThe TSMT shall provide sufficient hardware to conduct ASCC staff training (Exercise control, Higher Headquarters, Lower response cells, opposing forces, Observer/Controller, and MSEL management).
OBJ 36 TrainingThe TSMT shall support constructive exercises Brigade and Above staff training up to ASCC level in disconnected semi-austere environments.
OBJ 37 TrainingThe TSMT shall support constructive exercises at the BCT/BN level and virtual and live at the Company and below level in disconnected semi-austere environments.
3DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
ID Category Objective
OBJ 38 TSMT
The TSMT shall support execution of the threshold critical mission threads identified in the system's integrated architectures and satisfy the technical requirements for Net-Centric military operations. It shall provide a single, common interface with the COE (Mission Command Systems and Networks) and Live TESS systems (platforms and Soldiers).
OBJ 39 TSMTThe TSMT shall support the Intelligence Warfighting Function by interoperating with IEWTPT via APIs and appropriate classified networks (s).
OBJ 40 TSMT The TSMT shall interoperate with the Soldier Virtual Trainer (SVT).
OBJ 41 TSMTThe TSMT shall interoperate with the Synthetic Training Environment - Live Training System (STE-LTS).
OBJ 42 TSMTThe TSMT shall interoperate with the Future Next Generation Constructive (NGC)
OBJ 43 TSMTThe TSMT shall interoperate with future training aids, devices, simulators, and simulations (TADSS) and appended TADSS.
OBJ 44 TSMT The TSMT shall interoperate with Joint and Multi-national MCIS.
OBJ 45 TSMTThe TSMT shall interoperate with Joint and Multi-national simulation systems.
OBJ 46 TSMT Build a simulation interoperability bridge using common standards.
OBJ 47 TSMT
The TSMT shall support cross domain security training events (unclassified up to TS/SCI) at any and all echelons regardless of scale and training construct (i.e., separate, and distinct events and a training event with varying echelons/levels) at any and all echelons.
OBJ 48 TSMT The TSMT shall represent the air, maritime, space, and cyber domains.
OBJ 49 TSMTTSMT central node shall be capable of hosting 100 simultaneous exercises with 100,000 entities each or 1 exercise with 10 million entities.
OBJ 50 TSS The TSS shall interoperate with JLCCTC and PCTE.
OBJ 51 TSSThe TSMT shall interoperate with the Integrated Visual Augmentation System (IVAS) Soldier Immersive Virtual Trainer (SiVT).
OBJ 52 TSSThe TSS Computer Generated Forces shall aggregate and disaggregate from Soldier to ASCC Level.
OBJ 53 TSSThe TSS shall provide Computer Generated Forces with automated behaviors that represent tactical tasks and maneuver up to the ASCC level (BLUFOR, OPFOR, Civilian and Multinational Forces).
OBJ 54 TSS The TSS shall support training up to TOP SECRET level.
OBJ 55 TSSThe vendor shall include design considerations for a field server capable of providing training for a Battalion and Brigade training event.
OBJ 56 TSSThe TSS shall provide realistic and dynamic operational environment with all factors of PMESII-PT (Political, Military, Economic, Social, Infrastructure, Information - Physical Environment, & Time).
OBJ 57 TSSThe TSS Entity Level, Virtual and Constructive Simulation shall scale to 10 million entities with 5,000 in the field of view; simultaneous virtual and constructive execution.
OBJ 58 TSS The TSS shall provide a personalized avatar capability so the user profile can be loaded on demand to provide an avatar that represents the Soldier's human performance characteristics.
4DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
ID Category Objective
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.
5DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2447
Appendix C Capability Roadmap
The TSMT Product Overview brief embedded below as an object contains the Government’s initial capability roadmap expressed as echelon-based capability sets (i.e., Squad, Platoon, Company, Battalion and Brigade). The TDP Appendix E SRD identifies the initial product backlog to be utilized in development of the capability roadmap. Please note references to the Common Synthetic Environment Statement of Work (CSE SOW) is old language from a previous effort in the April 2020 timeframe. Also included is the current high-level capability over time slide from August 2020 timeframe. Appendix D Notional MVP/MVCR/Release Plan contains Government’s notional MVP/MVCR/Release plan. The USG desires the highest echelon (Company, Battalion, Brigade) the vendor can deliver. The USG will consider vendor proposals which deliver less than company level capability.
1DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2448
24492450245124522453245424552456245724582459
2460
2461
Appendix D Notional MVP/MVCR/Release Plan
The MS Excel file embedded below as an object contains the Government’s draft Notional MVP/MVCR/Release Plan.
1DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2462
24632464
2465
Appendix E IMS Template
1DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2466
2467
2468
2469
Appendix F Cost Deliverables
F.1 CSDR DD 2794
F.2 Software Resources Data Report
F.3 Cost and Hour Report (FlexFile) Contractor Format IAW File Format Specification (FFS) and Data Exchange Item (DEI)
F.4 Quantity Data Report (-Q) Contractor format IAW FFS and DEI
1DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
Appendix G Cybersecurity
G.1 DoD CDS Connection Process Diagram
Figure G-1. DoD CDS Connection Process Diagram.
1DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2482
2483
2484
2485
2486
2487
Appendix H Acronyms and Glossary
H.1 Acronyms
Table H-2. Acronyms.
Acronym MeaningA&A Assessment and AuthorizationAA Adversarial AssessmentAAL Additional Authorization ListAAR After Action ReviewA-CDD Abbreviated Capability Development DocumentACM Army Capability ManagerAEDC Adversarial Cyber Developmental Test AESS Army Endpoint Security SystemAFAPD Air Force Applications Program Development AMPS Aviation Mission Planning SoftwareAO Authorizing OfficialAPI Application Programming InterfaceAPL Approved Products ListAPMS Army Portfolio Management SystemARNG Army National GuardASCC Army Service Component CommandATCTS Army Training and Certification Tracking SystemATIS Army Training Information SystemATO Authority to OperateAVA Associate Vendor AgreementsAVCATT Aviation Combined Arms Tactical TrainerAvSE Avionics Software EmulationBCT Brigade Combat TeamBII Basic Issue ItemBIT Built In TestBOM Bill of MaterialsC2 Command and ControlCAC Common Access CardCADE Cost Assessment Data ElementCAP Contractor Acquired PropertyCAT1 Category 1CATS Combined Arms Training StrategiesCCDC AV&MC Combat Capabilities Development Command Aviation and Missile CommandCCDC DAC Combat Capabilities Development Command Data and Analysis Center
1DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2488
2489
2490
Acronym MeaningCCTT Close Combat Tactical TrainerCDRL Contractor Data Requirements ListCDS Cross Domain SolutionCDSA Cross Domain Solution AuthorizationCFT Cross Functional TeamCGF Computer Generated ForcesCI Configuration ItemCI/CD Continuous Integration / Continuous DeliveryCJCSI Chairman Joint Chiefs of Staff Instruction CLI Command Line InterfacesCLIN Contract Line Item NumberCM Configuration ManagementCMP Configuration Management PlanCNSSI Committee on National Security Systems InstructionCOE Common Operating EnvironmentCoE Center of ExcellenceCOMEX Communication ExercisesCOOP Continuity of Operations PlanCOR Contracting Officer RepresentativeCOTS Commercial Off the ShelfCP Contingency PlanCPCE Command Post Computing EnvironmentCPSMR Contractor's Progress, Status, and Management ReportCPVA Cooperative Vulnerability Penetration AssessmentsCSCI Computer Software Configuration ItemsCSDR Cost and Software Data ReportingCSL Common Software LibraryCTC Combat Training CentersCVI Cooperative Vulnerability IdentificationCWIPT Cost Working Group Integrated Product TeamDA PAM Department of the Army PamphletDAL Data Accession ListDCARC Defense Cost and Resource CenterDCSA Defense Counterintelligence and Security AgencyDDCA Deputy Director Cost AnalysisDEEP Digital Engineering Environment PlatformDEI Data Exchange ItemDevSecOps Development Security OperationsDID Data Item DescriptionDISA Defense Information Systems AgencyDMSMS Diminishing Manufacturing Sources and Material Shortages DoD Department of Defense
2DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
Acronym MeaningDoDAF Department of Defense Architecture FrameworkDoDIN Department of Defense Information NetworkDOORS Dynamic Object-Oriented Requirements SystemDOT&E Director, Operational Test & EvaluationDREN Defense Research Engineering NetworkDT&I Development Test and IntegrationECA External Certification AuthoritiesECMO Enterprise Cloud Management OfficeECP Engineering Change ProposaleMASS Enterprise Mission Assurance Support Service EXCON Exercise ControlEXORD Execution OrderFBX FilmboxFCA Functional Configuration AuditsFCL Facility Clearance LevelFEDSUN Federal, State and University Network FFS File Format SpecificationFMECA Failure Modes, Effects, and Criticality AnalysisFOC Full Operational CapabilityFOCI Foreign Ownership, Control, or InfluenceFORSCOM Forces CommandFOUO For Official Use OnlyFV Functional VerificationGFE Government Furnished EquipmentGFI Government Furnished InformationGFP Government Furnished PropertyGFT Games for TrainingglTF Graphics Library Transmission FormatHHA Health Hazard AssessmentHITS Homestation Instrumentation SystemIAMIATIATT Interim Authorization to TestIAVA Information Assurance Vulnerability AlertIAW In Accordance WithICAN Installation Campus Area NetworkICD Interface Control DocumentICS Interim Contractor SupportICW In Coordination WithIDD Interface Design DescriptionIEN Integrated Enterprise NetworkIEWTPT Intelligence Electronic Warfare Tactical Proficiency Trainer
3DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
Acronym MeaningIMS Integrated Master ScheduleIOC Initial Operational CapabilityIPT Integrated Product TeamsIRP Incident Response PlanISSM Information System Security ManagerITE Integrated Training EnvironmentITN Integrated Tactical NetworkIUID Item Unique IdentificationIVAS Integrated Visual Augmentation SystemIWTS Integrated Weapon Training StrategiesJBLM Joint Base Lewis McChordJDIF Joint Development and Integration Facility JFO Joint Fires ObserversJFT Joint Fires TrainerJIM Joint Interagency and MultinationalJLCCTC Joint Land Component Constructive Training CapabilityJME Joint Mission EnvironmentJTAC Joint Terminal Attack ControllersJVMF Joint Variable Message FormatLD/ME Logistics Demonstration/Maintenance EvaluationLORA Level of Repair AnalysisLPD Logistics Product DataLRU Line Replaceable UnitsLT2 Live Training TransformationLTA Local Training AreaLVCG Live, Virtual, Constructive, GamingLVC-IA Live, Virtual, Constructive Integrating ArchitectureMCIS Mission Command Information SystemsMCL Materiel Component ListMDO Multi-Domain OperationsMOSA Modular Open Systems ArchitectureMTTR Mean Time to RestoreMVCR Minimum Viable Capability ReleaseMVP Minimum Viable ProductNEC Network Enterprise CenterNET New Equipment TrainingNGC Next Generation ConstructiveNIAP National Information Assurance PartnershipNIPR Non-classified Internet Protocol (IP) RouterNIST National Institute of Standards and TechnologyNLT Not Later ThanNRRE Network Risk Reduction Event
4DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
Acronym Meaningo/a On or AboutOC Observer ControllerOCAR Office of the Chief Army ReserveODM Object Data ModelOE Operational EnvironmentOEM Original Equipment ManufacturerOFP Operational Flight ProgramOSD Office of the Secretary of DefenseOSHA Occupational Safety and Health AdministrationOT Operational TestOTA Other Transaction AuthorityOTC Operational Test CommandOWT One World TerrainPART Program Assessment and Review Tool PCA Physical Configuration AuditsPEO AVN Program Executive Office AviationPEO STRI Program Executive Office for Simulations and Training InstrumentationPh Probability of HitPHS&T Packaging, Handling, Shipping, and TransportPk Probability of Kill
PMESII-PTPolitical, Military, Economic, Social, Infrastructure, Information - Physical Environment, & Time
POA&M Plan of Action and MilestonesPoN Point of NeedPPEA Plan, Prepare, Execute, and AssessPPSM Ports, Protocols, and Services ManagementPWS Performance Work StatementQRG Quick Reference GuidesRAM Reliability, Availability, MaintainabilityRFT Ready for TrainingRFV Request for VarianceRIW Reliability Improvement WarrantiesRMF Risk Management FrameworkRTM Requirements Traceability MatrixRVCT Reconfigurable Virtual Collective TrainerS&T Science and TechnologySAP Software Acquisition PathwaySDK Software Development KitSDRL Supplier Data Requirements ListSIGACTS Significant ActionsSIPR Secure Internet Protocol RoutingSiVT Soldier Immersive Virtual Trainer
5DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
Acronym MeaningSLCM System-Level Continuous MonitoringSME Subject Matter ExpertSOP Standard Operating ProceduresSP Security PlanSPS Software Product SpecificationSRD System Requirements DocumentSRDR Software Resources Data Reports SRS Software Requirements SpecificationSSDD System/Subsystem Design DescriptionSSS System/Subsystem SpecificationSTE Synthetic Training EnvironmentSTE-LTS Synthetic Training Environment - Live Training System STIG Security Technical Implementation GuideSTP Standards of Training ProficiencySVD Software Version DescriptionSVT Soldier Virtual TrainerSysMIL System Modeling LanguageT&D Test and DevelopmentT&E WIPT Test and Evaluation Working Integrated Product TeamTA Technical AssessmentsTAA Technical Assistance AgreementTADSS Training Aids, Devices, Simulators, and SimulationsTB Technical BulletinTD ICL/R Training Device Inventory Checklist/RecordTDP Technical Data PackageTESS Tactical Engagement Simulation SystemTFR Training Facilities ReportTIF Technology Integration FacilityTIM Technical Interchange MeetingTM Technical ManualsTMDE Test, Measurement, and Diagnostic EquipmentTMT Training Management ToolTPD Training Performance DataTRR Test Readiness ReviewTSMO Threat System Management OfficeTSMT Training Support Management ToolTSN Trusted Systems and NetworksTSP Training Support PackageTSS Training Simulation SoftwareTSSDUA User AssessmentsULO Unified Land Operations
6DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
Acronym MeaningUoF Use of ForceUPDM Unified Profile for DoDAF/MODAFUSAPHC US Army Public Health CommandUSG United States GovernmentVoF Verification of FixesVV&A Verification, Validation, and AccreditationWfF Warfighting FunctionWGS World Geodetic SystemWSD Weapons Skills DevelopmentWTC ARNG Warfighter Training Center Army National GuardXR Cross Reality
H.2 Glossary
Table H-3. Glossary.
Term Definition
AccessibilityThe quality of being able to be reached, easy to obtain/use, and easily understood/appreciated. The ability for a system to reach the Point of Need by traversing the appropriate communications network (e.g. DODIN-A).
After Action Review (AAR)
A professional discussion of a training event focused on performance standards, that enable the participating Soldiers to discover for themselves what happened, why it happened, and how to sustain strengths and improve on weaknesses. It is a tool that leaders, trainers, and units can use to get the maximum benefit from every mission or task. Normally prepared by the TAF Analyst and conducted by an OC/T.
Application Programming Interface (API)
A set of application programs or operating system functions that can be utilized by a program.
Architecture RunwayThe Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay.
Architecture Synchronization
Government led meeting hosted by the Systems Architect with the Tech Leads from each development team
Army Service Component Command (ASCC)
Command responsible for recommendations to the joint force commander on the allocation and employment of Army forces within a combatant command. Also called ASCC. (JP 3-31)
7DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2491
2492
2493
Term Definition
Artificial Intelligence (AI)
The capacity of a computer to perform operations analogous to learning and decision making in humans, as by an expert system, a program for CAD or CAM, or a program for the perception and recognition of shapes in computer vision systems. The STE will use AI to replicate large unit level routines to increase realism of the operational environment, to support automated adaptive behaviors and free-thinking hybrid threats, to represent culturally aware virtual humans and small units, to mimic unit behaviors when they are not present, to support communication and interfacing techniques with the environment and other entities/agents, and to ease the application for a military user base.
ATO (Authority to Operate)
The official management decision given by a senior organizational official to authorize operation of an information system and to explicitly accept the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation based on the implementation of an agreed-upon set of security controls.
BacklogThe Product or Release backlog is the holding area for upcoming Features, which are intended to address user needs and deliver business benefits. It also contains the enabler features necessary to build the Architectural Runway.
Baseline The documented configuration that is the basis of the design / development / build of the product.
Cloud
Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.
Common Operating Environment (COE)
The COE is an approved set of computing technologies and standards applied across six Computing Environments (CE): Command Post, Mounted, Mobile/Handheld, Real Time/Safety Critical/Embedded, Sensor, and Enterprise. As a strategic Army initiative, and as an integral part of the LandWarNet and the Joint Information Environment, the COE is a foundational component of the Army’s modernization strategy. It aligns development and migration of Army programs to a common software baseline and a centralized hardware procurement process across the COE and within the Computing Environments.
COMMEXA COMMEX is a network and cloud connectivity check that precedes a Network Risk Reduction Event (NRRE). The purpose of the COMEX is to ensure the capability will be network and cloud connected at the Government assessment and NRRE.
Compliance1. The act of conforming, acquiescing, or yielding.2. A tendency to yield readily to others, esp. meekly3. Conformity; accordance: in compliance with orders. 4. Cooperation or obedience
Computer Generated Force (CGF)
A generic term used to refer to computer representations of forces in models and simulations that attempts to model human behavior sufficiently so that the forces will take some actions automatically (without requiring
8DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
Term Definition
man-in-the-loop interaction). Types of CGF include automated forces - computer-generated forces that require little or no human interaction. Semi-automated forces - computer-generated forces in which the individual platform simulation is operated by computer simulation of the platform crew and command hierarchy.
Computing Environment (CE)
A logical grouping of systems with similar characteristics used to organize the COE (deployment /echelon (sic), environmental, transport dependencies, form factors, etc.). A computing environment comprises the necessary hardware, operating system, libraries, and software required to run applications within the COE.
Configuration AuditCompares the as-built / as developed product against the system documentation to identify and document any variance in the documented configuration baseline.
Constructive TrainingModels and simulations that involve simulated people operating simulated systems. Real people stimulate (make inputs) to such simulations but are not involved in determining the outcomes.
Cybersecurity
Protection against intentional subversion or forced failure. A composite of four attributes – confidentiality, integrity, availability, and accountability – plus aspects of a fifth, usability, all of which have the related issue of their assurance.
Prevention of damage to, protection of, and restoration of computers, electronic communications systems, electronic communications services, wire communication, and electronic communication, including information contained therein, to ensure its availability, integrity, authentication, confidentiality, and nonrepudiation. Defined in National Security Presidential Directive-54/Homeland Security Presidential Directive-23.
Daily Scrum Team members meet daily to report plans for the day, accomplishments from the previous day and identify any blockers
Department of Defense Information Network (DoDIN)
The globally interconnected, end-to-end set of information capabilities for collecting, processing, storing, disseminating, and managing information on demand to warfighters, policy makers, and support personnel. The DoDIN includes owned and leased communications and computing systems and services, software (including applications), data, security services, other associated services, and National Security Systems (NSS). Non-DoDIN Information Technology (IT) includes stand-alone, self-contained, or embedded IT that is not, and will not be, connected to the enterprise network.
Diminishing Manufacturing Sources and Material Shortages (DMSMS)
The loss, or impending loss, of manufacturers or suppliers of items, raw materials or software.
Distributed Exercise An event enabled by distributed simulation where the training participants are at different locations (i.e., different cities, countries, or continents).
9DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
Term Definition
Distributed Simulation
A simulation that has multiple modules, which can be run on multiple processors. The processors can be co-located in the same room or located in remote sites. Entity Perspective: The perception of the synthetic environment held by a simulation entity based on its knowledge of itself and its interactions with the other simulation entities. This includes not only its own view of the simulated physical environment, but also its own view of itself, the other entities in the synthetic environment, and of the effects of the other entities on itself and the synthetic environment. Syn: World View. (SISO-REF-020-2007)
Effect A change which is a result or consequence of an action or other cause.
ElasticIn cloud computing, elasticity is the measure of how well a system adapts to workload changes by provisioning and de-provisioning systems to match the demand as closely as possible.
EntityAn entity is any independent object within a simulation that possesses complex behaviors and attributes. For example, personnel, vehicles, complex munitions, key communications devices might all be represented as independent entities within a simulation.
EnvironmentThe texture or detail of the natural domain, that is terrain relief, weather, day, night, terrain cultural features (cities or farmland), sea states, etc.; and the external objects, conditions, and processes that influence the behavior of a system.
Experience The process of doing and seeing things and having things happen to you.
ExtensibilityThe quality of being designed to allow the addition of new capabilities or functionality. An extensible system is one which takes future growth into consideration during implementation.
Fair Fight
“Fair fight” is when the performance characteristics of two of more interoperating simulations are seamless, preventing discrepancies in simulation algorithm or environmental representations from effecting the outcome of cross environment simulation exercises (e.g., Unseen opponents, pairing mismatch, effects mismatch, location mismatch, aspect mismatch).
FidelityThe degree to which a model or simulation represents the state and behavior of a real-world object or the perception of a real world object, feature, condition, or chosen standard in a measurable or perceivable manner; a measure of the realism of a model or simulation.
Field/FieldingThe process of delivering a product to the end user, this includes providing the support elements (e.g. user manuals, maintenance manuals, operator guides, spare parts, tools, etc.) that will allow the user to successfully operate and maintain the product.
10DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
Term Definition
Full Operational Capability (FOC)
In general, attained when all units and/or organizations in the force structure scheduled to receive a system 1) have received it and 2) can employ and maintain it. The specifics for any particular system FOC are defined in that system's Capability Development Document and Capability Production Document.• All equipment associated with the STE has been fielded, IAW the BOIP.• All information assurance requirements are complete.• New operator training for all sites is complete.• All contractor requirements for STE operations and support are in place and ready to support unit training at all sites.• The STE sustainment plan is in place and being executed.
Functional Fidelity
Functional fidelity captures how well the game acts like (not replicates) the operational equipment in responding to tasks performed by the training audience. For example if there is a surrogate communications system that represents the actual operational communications system but uses different means (e.g., Voice over IP (VOIP)) to provide communications, the functional fidelity is high because the training audience can perform its normal communications function even though it does not have its actual communications system or network. Functional fidelity appears to be an important factor in increasing and maintaining interest, realism, and motivation in the training event. It also helps support attention to detail.
Gaming Commercial and Government-off-the-shelf computer generated environment for interactive, semi-immersive training and education.
IATT (Interim Authority to Test)
Temporary authorization to test an information system in a specified operational information environment within the timeframe and under the conditions or constraints enumerated in the written authorization.
ImmersedSight, sound, and touch modalities are stimulated. The quality of stimulation approximates what the Soldier experiences in the Live Environment.
Immersion The placing of a human in a synthetic environment through physical and/or emotional means.
Immersive cf., Immersed
11DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
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
12DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
Term Definition
Intelligent Tutoring System
The mechanism or technologies (tools and methods) to provide tailored training and educational experiences; adaptive tutoring systems respond to changing states in the learner and changing conditions in the training environment to optimize learning; adaptive tutoring systems anticipate and recognize teachable moments. The STE will use ITS for Team and Unit Modeling, Automated Enterprise Hot wash and After-Action Review (AAR), Affective/Cognitive Modeling Capabilities, Training Effectiveness/Human Performance Measurement, Authoring Tools to Extend Applicability Across Training Domains, Domain Modeling across a range of dynamic military tasks, and elements of the Human Dimension to drive the cognitive, social, and physical skills of Soldiers over their career (Long-term Learner Modeling). An Intelligent Tutoring system (ITS) is a computer system that aims to provide immediate and customized instruction or feedback to learners, usually without.
Interface
1. A shared boundary across which information is passed. 2. A hardware or software component that connects two or more components for the purpose of passing information from one to another3. To connect two or more components for the purpose of passing information from one to another4. To serve as a connecting or connected component as in (2)
Interim Contractor Support Temporary product support provided to the Government by a contractor.
InteroperabilityThe ability to operate in synergy in the execution of assigned tasks.The ability of a model or simulation to provide services to and accept services from other models and simulations, and to use these exchanged services to operate effectively together.
Interoperable The ability of two or more systems or components to exchange information and to use the information that has been exchanged
Item Unique Identification Method of providing unique identification for each item in a system to allow documentation, tracking, and analysis of parts usage.
Joint Fires TrainingThe training for the application of Fires delivered during the employment of forces from two or more components in coordinated action to produce desired effects in support of a common objective.
Life Cycle The life of a system from initiation, planning, procurement, development, implementation, operation, maintenance, to disposal of the system
Live, Virtual, Constructive - Integrating Architecture (LVC-IA)
The Army's program of record that provides the common software, protocols, standards, and interfaces to facilitate interoperability of currently non-linked LVCG TADSS so that they can interoperate, share information, provide common views of the battlefield, and stimulate MC systems. The LVC-IA will be developed and fielded in increments (notionally two years) and is the key technical enabler foundation of the ITE. The Live, Virtual Constructive Integrating Architecture (LVC-IA) is the Program of Record that establishes initial interoperability and over time, the integration of Live, Virtual, Constructive and Gaming Simulations and Simulators and the stimulation of Mission Command Systems.
13DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
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.
14DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
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.
15DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
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
16DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
Term Definition
Product RoadmapHigh-level visual summary that maps out the vision and direction of product offerings over time. Describes the goals and features of each software sprint and program increment.
Product Support (see also sustainment)
The processes, documentation, and actions required to field and maintain the readiness and operational capability of a system.
Product VisionThe Vision is a description of the future state of the Solution under development. It reflects customer and stakeholder needs, as well as the Feature and Capabilities proposed to meet those needs.
Program Increment
A Program Increment (PI) is a timeboxed planning interval during which an Agile Release Train plans and delivers incremental value in the form of working, tested software and systems. PIs are typically 8 – 12 weeks long. The most common pattern for a PI is four development Iterations, followed by one Innovation and Planning (IP) Iteration.
Program Increment Demonstration
Teams will demonstrate the work that they have been working on during the Program Increment
Program Increment Dependency Board
Highlighting the new feature delivery dates, feature dependencies among teams and relevant Milestones.
Program Increment Objectives
Program Increment (PI) Objectives are a summary of the business and technical goals that an Agile Team or train intends to achieve in the upcoming Program Increment (PI) that are created by each team with the business value assigned by the Business Owners.
Program Increment Planning
Key Stakeholders and the development teams create a high level plan for each sprint for the release. This activity gives the opportunity to identify dependencies and risks among the teams. The Key Stakeholders and the Development team will leave the planning session with a plan and a User Agreement
Program Increment Retrospective
Teams discuss the results of the Program Increment, review practices, and identify ways to improve
Program/Requirements Manager Synchronization
Government led meeting hosted by the Program/Requirements Manager with Product Owners from each development team
RealismFine Arts. Treatment of forms, colors, space, etc., in such a manner as to emphasize their correspondence to actuality or to ordinary visual experience.
Reconfigurable Virtual Collective Trainer (RVCT)
The Air and Ground RVCT are used to train units in collective tasks on a simulated, fully interactive, real time battlefield. RVCT provides a realistic virtual environment in which units train and perform tasks preparing themselves to successfully accomplish their collective missions.
Release Notes Release notes are documents that are distributed with software products, and can be delivered when products are still be developed.
Renderer A software or hardware process that generates a visual image from a model.
Representation Models of the entity or phenomenon associated and its effects. Representations using algorithms and data that have been developed or
17DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
Term Definition
approved by a source having accurate technical knowledge are often considered authoritative.
Resolution The degree of detail visible in a photographic or television image.
Risk Management
The process of managing risks to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the nation resulting from the operation or use of an information system, and includes: 1) the conduct of a risk assessment; 2) the implementation of a risk mitigation strategy; 3) employment of techniques and procedures for the continuous monitoring of the security state of the information system; and 4) documenting the overall risk management program
RMF (Risk Management Framework)
A disciplined and structured process that integrates information security and risk management activities into the system development life cycle.
Scalability cf., Scalable.
Scalable The capacity to be changed in size or scale. The ability of the system to adapt to increased demands.
Scrum of ScrumsScrum of Scrum Sessions that are Government led hosted by the Release Train Engineer with Scrum Masters from each development. Upcoming features are socialized and dependencies are discussed at this meeting.
Semi-ImmersedSight, sound, and touch modalities are stimulated. The quality of stimulation is a low-fidelity approximation of what the Soldier experiences in the Live Environment.
Semi-Immersive cf., Semi-Immersed
Situational Awareness
Knowledge of one’s location; the location of friendly and hostile forces; and of external factors, such as terrain, weather, etc., that may affect one’s capability to perform a mission. Commanders, staffs, units, and soldiers/weapon platforms at all echelons require the means to optimally utilize all mission command information available that affects their area of operations. SA is a state of understanding gained through decisions made from knowledge supplied by a graphical Common Picture of the battlefield consisting as a minimum of the enemy situation (location, resources, status, and possible actions), friendly situation (location, resources, and status), and the logistics situation (location and status).
Software Release Functionality developed during the Program Increment
Sprint Demonstration Teams demonstrate the work that they have been working on during that 2 week Sprint
Sprint Goals Teams develop goals for the 2 week sprint during Sprint Planning
Sprint Plan
Teams engage in mapping out each sprint with features during Program Increment Planning to highlight dependencies among teams and risks which is captured in the sprint plan. During the Sprint Planning Event, the teams revisit the sprint plan and add additional detail during the Sprint Planning Phase of the Sprint Lifecycle
Sprint Retrospective The Team discuss the results of the sprint, review the team practices, and
18DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
Term Definition
identify ways to improve
Sustainment The support required to maintain a system in an operational status throughout its life cycle.
SyntheticRepresentation or model of the characteristics of the real world. Devised, arranged, or fabricated for special situations to imitate or replace usual reality.
Synthetic Environment
The integrated set of data elements that define the environment within which a given simulation application operates. The data elements include information about the initial and subsequent states of the terrain including cultural features, and atmospheric and oceanographic environments throughout an event. The data elements include databases of externally observable information about instantiable entities and are adequately correlated for the type of event to be performed. Also known as virtual world. (IEEE Std 1278.1-2012) [10] Virtuality Continuum: “The Virtuality Continuum is a continuous scale ranging between the completely virtual, a virtuality, and the completely real, reality. The reality-virtuality continuum therefore encompasses all possible variations and compositions of real and virtual objects.” [2] Virtual: An entity or data that is derived from a modeled or simulated representation of the actual or anticipated system.
Technical Assessment/Functional Verification
The Government conducts the TA/FVs on the latest developed capabilities to ensure requirements are met per the SRD/SSS. TA/FVs shall use vendor developed test procedures (e.g., threads and vignettes) to test TSMT capabilities. The vendor shall support and participate in the TA/FVs. The vendor shall provide all required hardware and software for the events. TA/FVs shall collect Reliability, Availability, and Maintainability (RAM) data. The Government will document issues in Problem Trouble Tickets (PTRs) for the vendor to address/correct during the event or as part of the backlog. TA/FV locations are TBD and may include P4 STE Technology Integration Facility (TIF), P5 Joint Development and Integration Facility (JDIF), Cloud / data center, distributed locations, MTCs, or a combination of these locations. The test environment will approximate the infrastructure (e.g., network, cloud, security) conditions of the anticipated fielding locations. The Government will host a daily hot wash and Government only AAR.
Training Aids, Devices, Simulators, and Simulations (TADSS)
Training aids, devices, simulators, and simulations (TADSS) replicate OE complexities (training role players, IED simulators, MILES, small arms) to a low-fidelity environment (low fidelity as defined by Army training directives).
Training EffectivenessEvaluation of the impact of training and educational tools and methods on usability, learning, comprehension, performance, retention, reasoning, and transfer of knowledge and acquired skills to the operational environment.
Training Unit The unit which is trained and evaluated during the event.
Use of Force A series of actions an individual can take to resolve a situation. Use of
19DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
Term Definition
force allows the Soldier flexibility as the need for force changes as the situation develops. The level of force is not linear or consecutive; one may go up a scale, and back again in a matter of seconds. Use of force includes less lethal force (e.g., officer presence; voice commands; empty hand control; pepper spray, baton, Taser; other less lethal weapons) and deadly force.
User Agreement
Agreement between the operational and acquisition communities to gain ensure active user involvement and decisions. Ensure proper resourcing of user involvement to support development Commit to active user involvement throughout design and development during planning phaseSigned by sponsor, PMO prior to entry into Execution Phase
User Assessment (UA)
The Government conducts the UA to allow the user/soldier to operate the system and provide feedback to the developers. Users roles include but are not limited to scenario planners, dismounted Soldiers, platform operators and AAR personnel. The vendor shall support and participate in the UAs. The vendor shall assist the Government to identify proper UA Soldier staffing at least 90 days prior to the event. The vendors shall provide all required hardware and software for the events. Locations of the TAs is to be determined and may include P4 STE TIF, P5 JDIF, Cloud / data center, distributed locations, including MTCs, or a combination of these locations. The Government will host a daily hot wash and Government only AAR.
Verification, Validation, and Accreditation (VV&A)
The Government conduct VV&A on all SRD/SSS requirements. The vendor will assist in all VV&A activities as required. The National Simulation Center (NSC) Analysis and Test Branch conducts testing that informs both validation decisions, and subsequent recommendations to accrediting authorities, made by Army Capability Managers (ACM) on the use of modeling and simulation solutions for training exercises and military operations. The testing concept for informing the ACM STE involves using applicable data from the OT, and from prior assessments (TAs and UAs), and conducting, by exception, additional activities, and events with priority to validation testing. Additional activities and events include technical and functional thread testing and vignette and operational scenario testing. The validation data informs identification of capabilities and limitations of STE solutions when using those to train Soldiers.
Virtual Semi-Immersive Interfaces
Virtual Semi-Immersive interfaces are common ‘keyboard and mouse’ interfaces into a virtual 3D representation of a training environment.
Virtual TrainingA simulation involving real people operating simulated systems. Virtual simulations inject human-in-the-loop in a central role by exercising motor control skills, decision skills, or communication skills.
20DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
Term Definition
Warfighting Function
A group of tasks and systems (people, organizations, information, and processes), united by a common purpose that commanders use to accomplish missions and training objectives. (ADRP 3-0)A Warfighting Function is a group of tasks united by a common purpose that commanders use to accomplish missions.
Weapon Skill DevelopmentThe development of fire’s knowledge, skills, marksmanship, and engagement techniques involved in the effective lethal employment of the weapon system.
Zero Client A zero-client is an I/O redirector device that allows a full cluster of peripheral devices to be deployed at the desired point of service without a dedicated PC or thin client at that same location and without requiring any modifications to existing software applications.
21DISTRIBUTION A: APPROVED FOR PUBLIC RELEASE // DISTRIBUTION IS UNLIMITED
2494
2495