1 / 39

Technical Challenges Workshop, Extensible Modeling and Simulation Framework (XMSF)

Science Applications. International Corporation. An Employee-Owned Company. Monterey California USA, 19-20 August 2002. Technical Challenges Workshop, Extensible Modeling and Simulation Framework (XMSF). Don Brutzman and Michael Zyda Naval Postgraduate School

aysel
Télécharger la présentation

Technical Challenges Workshop, Extensible Modeling and Simulation Framework (XMSF)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Science Applications International Corporation An Employee-Owned Company Monterey California USA, 19-20 August 2002 Technical Challenges Workshop,Extensible Modeling and Simulation Framework (XMSF) Don Brutzman and Michael Zyda Naval Postgraduate School Mark Pullen, George Mason University (GMU) Katherine L. Morse, SAIC

  2. XMSF Technical Workshop • XMSF executive summary • Problems, motivation, strategy • Workshop organization and details • Administrative stuff • Further technical discussion

  3. Executive summary • Web-based technologies can provide an extensible modeling and simulation architecture, to support a new generation of interoperable applications • Simulation support is needed for operational warfighting capabilities • XML-based architecture can provide a bridge between emerging rehearsal/reality/replay requirements and open/commercial Web standards • Web = best tech strategy + best business case

  4. Problems • Current approaches are not compatible with effective use of emerging Web technologies • Military modeling & simulation has little or no apparent impact on warfighters’ daily tactical operations • Diverse simulations do not scalably interoperate with warfighting systems • Global systems are not yet possible without connection to common interoperable framework • physical and logical “stovepipes” prevent this

  5. Motivation • Transformational technologies are needed to scale up defense modeling/simulation to meet real-world needs • Can we use Web technologies as common framework? • Dynamic capabilities, open standards, Web business model provide lift to support government and commercial success • Easy use and open extensibility for developers and users, fueling rapid growth of interoperable simulations • Bring defense modeling/simulation/tactical support into mainstream of enterprise-wide best-business practices

  6. Planning for change/quick start • Technical opportunities workshop • NPS, August 19-20 – welcome! • MOVES Open House, August 20-22 • Strategic opportunities symposium • George Mason University, September 6 • Immediately precedes SIW for good participation • Broader feedback: right track? what else is needed? • Exemplar demonstration • I/ITSEC demos, Orlando Florida December 2-5

  7. Project strategy • Outline large-scale framework for next-generation Web-compatible simulation interoperability • Enumerate technical components, languages, and specifications • Workshop of key researchers to refine requirements • Seek broad feedback for consensus, focus, progress • Demonstrate rapidly how these new capabilities might help • Current war effort against terrorism • Homeland defense • Science, commerce, education, etc. • Multi-year initiative for simulation using Web technologies? • Workshop and symposium produce strategy and white paper • Conceptual suite of applications demo at I/ITSEC in December • NPS, GMU and SAIC have started, shared strategies welcome • Further workshop in fall among existing programs??

  8. Workshop Details

  9. Workshop strategy 1 • How to solve big problems? Divide & conquer. • Three perspectives • Web technologies, XML • Networking and Internet • Modeling and simulation (M&S) • White paper lays out initial basic framework • please use, extend, correct, disagree

  10. Workshop strategy 2 • How to solve big problems? Divide & conquer. • Triage approach for all three technical areas: • What do we agree on: determine consensus • What do we disagree on: more work needed • What are most important directions for further work • Document workshop and symposium results • Most important outcomes may be education, direction

  11. Moderator: Don Brutzman, NPS Erik Chaum NUWC Rob Glidden Sun Jack Jackson, TRAC Monterey David Kwak, MITRE Recorders: Steve Fouskarinis SAIC, Curt Blais NPS Dr. Francisco Loaiza, IDA Dr. Edward Sims, Vcom3D Dr. Chenghui Luo, Fraunhofer CRCG Phil Zimmerman, DMSO Web/XML group: Root 200C conference room

  12. Moderator: Mark Pullen, GMU Rusty Baldwin, AFIT Scott Bradner, IESG, Harvard Suleyman Guleyupoglu, NRL Sue Numrich, DMSO Recorders: Don McGregor, NPS Dave Laflam, AMSO Denny Moen Steve Carson, GSC Assoc. Norbert Schiffner, CRCG Marcelo Zuffo, University Sao Paolo two last-minute drops: Sandeep Singhal Reefedge, Mikel Petty ODU Internet/networking group: Spanagel 254 conference room

  13. Moderator: Katherine Morse, SAIC Mike Bailey USMC TECOM Paul Diefenbach, OpenWorlds Dr. Niki Deliman Goerger, USA ERDC Alan Hudson, Yumetech Recorders: Joerg Wellbrink, NPS Simon Goerger, NPS Kalyan S. Perumalla, Georgia Inst. of Technology Dick Puk, Intelligraphics Cristina Russo dos Santos, Eurecom, University Toulon Dr. Andreas Tolk, ODU Dr. Sanjeev Trika, Intel Modeling & simulation group: Engineers’ auditorium

  14. Monday Agenda • 0830 XMSF Technical Workshop Overview • 0930 Tasks: triage consensus on XMSF challenges • 1000 Break at auditorium • 1030 Break out, present positions 10 minutes each • 1200 Lunch break on own. Thai Hut, coffee bar, Hermann Hall basement or Randy’s Sandwiches • 1300 Group breakouts, discussions, triage • 1500 Break at auditorium • 1700 Plenary progress quicklook: 15 minutes/group • 1900 Dinner El Palomar, $18 buffet, will have maps

  15. Tuesday Agenda • 0815 Working groups resume, complete contributions • 1000 Break at auditorium • 1030 Plenary results session: 20-min. group reports • 1130 Final discussion: conclusions and next steps • 1200 Workshop complete! Lunch break on own. Thai Hut, coffee bar, Hermann Hall basement or Randy’s Sandwiches • 1300 MOVES Open House (right back here)

  16. XMSF website, report • Position papers and slides available at • http://www.movesInstitute.org/xmsf • Recorders can upload during sessions, or else send mail to Don (why not, everyone else does) • Participants can improve/amend contributions • Report revision dates: September 1 and 8

  17. Position paper revisions • Feel free to reconsider points you’re making • but little need for duplication • clarity is key • lots of references and URLs, please • Do we want consistent formatting template? • Will provide position papers with final report.

  18. Administratospheria

  19. Registration • $50 needed for XMSF breaks • $150 needed for MOVES open house breaks • Rachel Davis is handling registration details. • Telephone for messages: +1.831.656.1126 • Thanks one and all for cheerful professionalism!

  20. Travel claims • Thanks to many of you for letting us make reservations, despite SATO ticket hassles. Government rates saves us a bunch of money. • Cecelia Childers will provide forms to fill out. • Please save your receipts! • Cecelia is in MOVES lab Spanagel 256, x3818 • mailto:cmchilde@nps.navy.mil

  21. Handouts • XMSF workshop folder • MOVES open-house brochure • Web3D Consortium’s X3D SDK CDs • MOVES open-house DVD • MOVES open house highlights • Tuesday afternoon: our web-based work, reception • Wednesday evening: demos in lab, hors d’oeuvres • Thursday morning: AmericasArmy.com

  22. Further technical discussion

  23. Application Domains • Discrete-event and constructive simulations • Virtual worlds and continuous simulations • Multi-agent systems • Interactive, man-in-the-loop, equipment-in-loop systems • Live and virtual entities, mixed seamlessly • Distance learning for interaction among participants • Audio and video (both needed for WAN testing anyway) • Multiformat whiteboard; recording and playback • Teaching and training compatibility via ADL SCORM • Maybe inclusion is too far a reach? Be clear what is/isn’t

  24. Top-Level Requirements 1 • Ability to interact directly and scalably over the network • Compatible with Web architecture and technologies • Highly distributed • Use by humans and software agents equally important • Support for composable, reusable model components • Root data-structure representations specified using XML schema • Representations in other languages autogenerated directly • Connection point between syntax and RDF Schema, semantics

  25. Top-Level Requirements 2 • Simple learning curve and repeatable examples • Support users and developers • Modular structure • Ability to directly interact with network layer • Plug-ins connecting into kernel plug-ins at run time • Standards-based • IEEE, ISO, W3C, IETF, Web3D • Integrate with tactical systems • Augment group shared picture of operations • Producers and consumers • System life-cycle patterns, repeatability

  26. Top-Level Requirements 3 • Support for XML and multiple programming languages • Dynamically extensible at run time: “always on” • software + hardware, diversity includes backwards compatibility • loose coupling, verification/validation, repair, graceful degradation, redundancy, etc. • Security levels consistent with current Web technology • Public library of useful reusable components • Cross-platform capabilities • Rendering support and architectural hooks for visual simulations

  27. Top-Level Requirements 4 • Expected computer performance: • Small, fast, inexpensive computers • Reconnect via GRID computing (distributed operating systems) • Expected network performance: • Modems through ADSL (0.05-1.5 Mbps) for limited participation • 10 - 1Gbps for local participation • OC3 up through gigabit wide-area networking • Backward compatibility with existing architectures and protocols, where it makes sense • e.g. DIS, HLA/RTI, ALSP, probably many others

  28. M&S Functional Requirements • Backward compatibility • Authoritative representations • Composability • Multi-resolution modeling • Tactical system integration • Simulation support services • Time management • Logging and playback

  29. M&S Issues • Discuss the shared goal of bringing working M&S applications matching real world problems into tactical use. • Discuss approaches for backwards compatibility to HLA/RTI and DIS technologies which don’t constrain emergence of new capabilities. Explore specific bridging approaches for HLA/RTI and DIS over web channels. • Discuss compatibility with the Joint Technical Architecture (JTA), http://www-jta.itsi.disa.mil. • Explore integration of C4I systems to augment joint common operational picture. • Discuss approaches for playback capture. • Identify technology availability: immediate, near-term (1-2 years), likely (3-5 years), problematic.

  30. Design Ideas 1 • Object-oriented programs + validatable structured data • Repeatable programming metaphors + XML tagsets/registries • Language and object-system independent • e.g. CORBA/IDL, SOAP, RMI/RPC, others • Design patterns unambiguously define language bindings • Map representations, component models from root XML schemas to programming languages and API bindings of interest • Wire protocols unambiguously, flexibly defined using XML • Run-time extensibility, portability, interoperability for streams • Packet description language -or- direct mappability from Schema

  31. Design Ideas 2 • Time services support wide-area routing and playback • Participating computer clocks all set correctly(!) via NTP or GPS • RTP for all stream headers • SMIL for stream synchronization • Higher-level time abstractions communicable by system • What about supercomputer batch-mode asynchronous? • Infrastructure represented as objects in system • Enable object and service discovery at runtime • Ability to monitor, test, improve systems at local and global scale

  32. Business Model 1 • Minimal architecture is open source implementation • Royalty free, usable without any fee restrictions whatsoever • Important to have two or more interoperable implementations • Commercial implementations profitably augment open source • Long-term stable infrastructure enables sustainable business models • Flexible architecture broadens market: not “just” military simulation, also full World Wide Web via open/secure Internets • Web-enabled architecture allows more sponsors to participate, which allows simulations, models, and applications to survive despite intermittent funding profiles • Transferable career-building skills and reusable experience for programmers and managers

  33. Business Model 2 • Commercial models in partnership with open-source • Support • Offer programming skill for a fee and give up rights to the source if it is infrastructure related. • Proprietary software • A vendor may write a simulator that runs on top of the free infrastructure. They can use any license they like on this and sell it as they see fit. • Consulting • Someone needs to put together the simulations. Even if all the parts are free, this is a salable service. • Maintenance • Numerous success stories exist. • Success of the overall endeavor is key to business success.

  34. DoD Business Model • Commercial technology is crucial • We can’t do it alone • Special technology requirements harmful • Translate into always spending too much for unique, outdated technology • Nothing succeeds like success • Slipstreaming standards and industry “best practices” makes best sense for industry partners too

  35. Open Issues • Source code control • Interoperability test suite and certification shows conformance • Source forking no longer divisive issue, let many flowers bloom • “Actual results” validation through use with tactical systems • Architecture • What are good driving exemplar applications? • Reality pulls teams through the big design space • Must show significant “value add” to current practices plus current excitement • Can we extend some existing systems (e.g. HLA/RTI capable), show interoperability with legacy systems via good examples? • e.g. NSS, OneSAF, ITEM • Multiple inheritance – no; multiple interfaces – yes • Do we need a specified method for distributed synchronization, or is open architecture supporting different models sufficient?

  36. Recent work: workshop on software componentization • July 2002, DMSO, DC • Consensus seemed to be: • components are a worthwhile approach to consider for improving composability and interoperability of diverse interacting simulations • component technology is sufficiently mature and well defined for building exemplars • Slidesets and conclusions available? _____

  37. Contact

  38. Contacts Don Brutzman brutzman@nps.navy.mil 831.656.2149 Michael Zyda zyda@nps.navy.mil 831.656.2305 Don McGregor mcgredo@nps.navy.mil 831.656.4090 Andrzej Kapolka akapolk@nps.navy.mil 831.656.2253 Mark Pullen mpullen@gmu.edu 703.993.1538 Katherine Morse morsek@saic.com 858.826.6728 Steve Fouskarinissteven.fouskarinis@saic.com 858-826-4407 http://www.MovesInstitute.org/xmsf

  39. Rooms • Web/XML: Root 200B (by Don’s office) • Networking: Spanagel 254 (by Mike’s office) • M + S: Right here in auditorium

More Related