27.01.2015 Views

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

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!