LVC Architecture Interoperability Study Group

1. LVC Architecture Interoperability Study Group SIW Spring 2007

2. Agenda • Administrative • Review TOR (Terms of Reference) and goals • Elect new Vice Chair • Review proposed framework for discussion • Discuss!

3. Administrative • Email Reflector • SIW-SG-LVC@discussions.sisostds.org • History • Kickoff was at I/ITSEC ‘06

4. Terms of Reference TOR Document:

5. Relationship to US DoD’s LVCAR • US DoD performing an LVC Architecture Review • One purpose of this SISO LVC SG is to serve as an input to the DoD Study • What does the SISO/ M&S community think? • Put ourselves in the shoes of a consumer/user of LVC simulations (such as the US DoD, and those of other countries) • Amy Henninger’s presentation:

6. LVC Study Group Officers • Chair: Len Granowetter • Taking over from Randy Saunders • Vice-Chair: OPEN • Secretary: Michael O’Connor • Technical Area Directors (TAD): Paul Gustavson and Chris Rouget

7. Framework for discussion

8. Our goal • To produce an intellectually honest report, based on our expertise • Our hope is that this report will help policy makers make better decisions • Within the US DoD, as well as those of other countries

9. Scope • Communication architecture is just one element of LVC interoperability • Object model • Real-time/event-based/time-managed • Terrain representation • Scenario definition • Graphical representation • Others?? • Let’s explicitly acknowledge which pieces this group will focus on

10. Scope • Questions to consider: • Is it possible (easy?) to integrate Live, Virtual and Constructive assets into a single federation • Is it possible (easy?) to reuse intellectual property (object models, algorithms, code, etc.) across the various LVC domains • I.e. there may be reasons to share a common infrastructure, even if you don’t ever need to play together

11. Define Functional Requirements • Do different user communities have different requirements? • Are there good reasons why different communities should have different communication architectures?

12. Compare Existing Architectures • HLA, TENA, DIS, CTIA, others?? • Functionality • Performance • Business Model • Standards Management Process • System engineering process

13. Compare Functionality • Capabilities and limitations • E.g. Is there something about TENA that makes it particularly valuable to the live range community? • E.g. Is there something about HLA that makes it particularly valuable to the virtual and constructive communities?

14. The Performance Question • Do different communities have different requirements? • Are there characteristics of the various architectures that inherently make one the best choice for particular use cases? • Important to distinguish between architecture, and specific implementations! • Given a “good” implementation of each particular architecture, is it possible to achieve desired performance? • Is the architecture the limiting factor?

15. Compare Business Models • Costs and benefits to different approaches • Standardize API, but allow multiple, competing middleware implementations • At what level? • Standardize on a single implementation • Who owns and maintains it?

16. Compare Standards Management • How quickly can/should a standard evolve? • Tradeoff between rapid-evolution, and consensus-building • Who “owns” the standard? • Standards organization like SISO/IEEE, or a particular user community (e.g. US DoD?) • Can we plan for backwards compatibility in the face of change?

17. Possible Ways Forward • Retain several parallel architectures, with bridges and gateways for LVC events • Start with one of the existing architectures, and extend to support missing functionality if necessary • Start fresh, and try to build a new “best of all worlds” architecture • We need a roadmap – not just a desired end-state, but a workable plan for how to get there • Keep “switching costs” in mind