Testing in a Joint Environment Roadmap - U.S. Army Operational ...
Testing in a Joint Environment Roadmap - U.S. Army Operational ...
Testing in a Joint Environment Roadmap - U.S. Army Operational ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
For Official Use Only<br />
<strong>Test<strong>in</strong>g</strong> <strong>in</strong> a Jo<strong>in</strong>t <strong>Environment</strong> <strong>Roadmap</strong><br />
B.2.4 SYSTEM/THREAT/ENVIRONMENT REPRESENTATIONS<br />
Program managers must be able to "plug" the warfight<strong>in</strong>g capabilities under test <strong>in</strong>to the jo<strong>in</strong>t<br />
mission <strong>in</strong>frastructure and have their respective systems be immersed well enough to meet their<br />
test objectives. Although there are many ways to categorize the various systems <strong>in</strong>teract<strong>in</strong>g <strong>in</strong><br />
the jo<strong>in</strong>t mission <strong>in</strong>frastructure, this roadmap organizes them <strong>in</strong>to three major categories: System<br />
Representations, Threat Representations, and <strong>Environment</strong> Representations.<br />
B.2.4.1 SYSTEM REPRESENTATIONS<br />
System representations are live, virtual, or constructive simulations of warfight<strong>in</strong>g systems.<br />
System representations are not only of the system under test, but also all the systems that system<br />
is expected to <strong>in</strong>teract with <strong>in</strong> the jo<strong>in</strong>t mission <strong>in</strong>frastructure (<strong>in</strong>clud<strong>in</strong>g sensor systems,<br />
communication systems, non-DoD systems (NSA, FAA, Homeland Defense systems, etc.), and<br />
allied systems. S<strong>in</strong>ce they are the actual capability with which the nation goes to war, live<br />
systems will always be the most significant elements to <strong>in</strong>tegrate <strong>in</strong>to the jo<strong>in</strong>t mission<br />
<strong>in</strong>frastructure, provid<strong>in</strong>g the most operationally realistic test events.<br />
For live systems, their <strong>in</strong>terface to the jo<strong>in</strong>t mission <strong>in</strong>frastructure will often be via tactical<br />
means, such as stimulators <strong>in</strong>ject<strong>in</strong>g <strong>in</strong>formation <strong>in</strong>to sensors for the system under test, or<br />
<strong>in</strong>strumentation publish<strong>in</strong>g/subscrib<strong>in</strong>g <strong>in</strong>formation to the C4I subsystem of the system under<br />
test, but it could also be via non-tactical methods, such as embedded <strong>in</strong>strumentation. However,<br />
live systems are expensive to use to support a test event, and traditionally are difficult to obta<strong>in</strong>.<br />
Constructive and virtual representations of acquisition systems must be developed to be<br />
compatible with the jo<strong>in</strong>t mission <strong>in</strong>frastructure architecture. These representations should be<br />
created as design and development aids for an acquisition program and used throughout its<br />
acquisition process, progress<strong>in</strong>g from a virtual prototype, to HITL laboratories, to range test<strong>in</strong>g,<br />
to ultimate field<strong>in</strong>g. Most importantly, it should be realized that a system's <strong>in</strong>terface should be<br />
consistent throughout all these acquisition phases, regardless of whether it is a live, virtual, or<br />
constructive representative. This <strong>in</strong>terface consistency enables data coherency throughout the<br />
acquisition process, so that predictions from virtual prototypes could be compared to results from<br />
live systems <strong>in</strong> a more "apples-to-apples" assessment.<br />
A virtual prototype should be available for use <strong>in</strong> the jo<strong>in</strong>t mission <strong>in</strong>frastructure and should<br />
be ma<strong>in</strong>ta<strong>in</strong>ed by the program. Rather than drop the constructive and/or virtual M&S after they<br />
create the actual hardware, program offices should acquire these capabilities as deliverables from<br />
their prime contractors and ma<strong>in</strong>ta<strong>in</strong> these simulations, even after their systems enter production.<br />
Although this process will <strong>in</strong>itially <strong>in</strong>crease the cost to a program, the benefit will be reaped<br />
many times by all systems that are on the jo<strong>in</strong>t battlefield. Furthermore, programs will be<br />
reimbursed for the use of their virtual representations to support a test <strong>in</strong> the jo<strong>in</strong>t environment<br />
B-9<br />
For Official Use Only<br />
Appendix B