1 / 27

Java Real-Time RTI

Java Real-Time RTI. Michael D. Myjak. Vice President Research and Development. P.O. Box 98 Titusville, FL 32781 <mmyjak@virtualworkshop.com>. 17 September, 1998. P. O. Box 98  Titusville, FL 32781  407.264.0440. Motivation.

javen
Télécharger la présentation

Java Real-Time RTI

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. Java Real-Time RTI Michael D. Myjak Vice President Research and Development P.O. Box 98 Titusville, FL 32781 <mmyjak@virtualworkshop.com> 17 September, 1998 P. O. Box 98  Titusville, FL 32781  407.264.0440

  2. Motivation • To meet the needs of the compile-once, run-anywhere, real-time RTI user.

  3. Outline • A Bit of Simulation Darwinism • Description of the features and support services incorporated into the Java Real-Time RTI. • Architectural tradeoffs we’ve selected in order to implement a real-time infrastructure in Java.

  4. Simulation History in a Nutshell • The early days were simple: • Continuous simulations • Discrete simulations • and little later... • Monte Carlo simulations • Employed first analytical representations based on repetitive statistical trials.

  5. Simulation Darwinism • Natural evolution saw that various combinations were also interesting - • Discrete event + continuous simulations Discrete event Continuous Monte Carlo

  6. Simulation Darwinism • Natural evolution saw that various combinations were also interesting - • Discrete event + continuous simulations • Discrete event + analytical modeling Discrete event Continuous Monte Carlo

  7. Simulation Darwinism • Natural evolution saw that various combinations were also interesting - • Discrete event + continuous simulations • Discrete event + analytical modeling • Continuous + Monte Carlo => Gamblers Anonymous

  8. Internet Gaming Continuous + DES Discrete event Continuous Continuous + Analytical DES + Analytical Monte Carlo

  9. Architectural Extensions (1 of 3) • Later, various extensiontypes evolved (based on the underlying architecture). • parallel simulations • parallel platform • one multi-threaded processor • distributed simulations • several physically autonomous platforms • Then of course, when you add a human-in-the-loop to the equation… • interactive simulations

  10. Architectural Extensions (2 of 3) • Distributed Simulations... • ARE Applications that involve a network of processors • Share a common communication architecture or infrastructure • (e.g., the Internet, WWW, etc.). • Distributed Interactive Simulation applications are often characterized as being real-time or quasi-real-time.

  11. Architectural Extensions (3 of 3) • So, integrating dissimilar simulation systems is really nothing new... • Different Component/Extension Combinations have often been generated independently • Bringing them all together under a common architectural framework in order to interoperate… well, that is something new... • federated simulations.

  12. Evolving Federated Simulations • From ALSP we gained experience • Time management • simulation time must be a coordinated event • causality can be maintained • Data management • application (or application process) uses its own database, so a common method of sharing information was required. • Architecture • simulations used their existing architectures, and would also be enable to exist in an ALSP Confederation.

  13. Bringing HLA into the Mix • A federation has no central node • (i.e., no server). • Geographically Distribution • (i.e., they can reside in different locations). • Information is distributed • between federate applications • uses a pre-defined interface resembling message passing in object-oriented design.

  14. Interoperability Issue • Like C++, Ada, & IDL, Java is aptly suited to perform in the capacity of the RTI. • A transportable RTI that is platform independent is quintessential to supporting federation interoperability and reuse.

  15. We’re Not Quite There… Yet! • True, complete Interoperability (i.e., system independent functionality) is not likely • end-to-end, in a heterogeneous environment • Java lets us break through most of that • Well-defined, homogeneous, and often monolithic environments where vendor and platform dependencies exist. • Still, the Java Real-Time RTI isn’t the complete answer... • A standardized communication protocol between RTI is a necessary underlayment

  16. Federated Simulations • So where do real-time, distributed, interactive simulation applications fit within this framework?

  17. Federated Simulations • So where do real-time, distributed, interactive simulation applications fit within this framework? • Why… On the Desktop, of course!

  18. Federated Simulations • So where do real-time, distributed, interactive simulation applications fit within this framework? • Why… On the Desktop, of course! • And lugged into the World Wide Web!!!

  19. Development Goals • Broad platform and network independence. • Maximum throughput with absolutely minimal latency. • Support for streaming data types. • Embedded Management Services • Federate and federation "cut-through" functionality. • Integration w/ the Web!

  20. Development Components • Conforms to existing and emerging standards and Protocols • High Level Architecture • Run-Time Infrastructure • Virtual Reality Transfer Protocol • Real-Time Protocol • Simple Network Management Protocol • Native Java Application • Embedded Network Management • Streaming Audio/Video • Virtual Teleconference • Internet Collaboration

  21. Our Principal Goal • To provide a broad spectrum of platform and network independence • Typically guaranteed by employing standard (and de facto standard) network communication approaches, as outlined in the OSI or Internet protocol stacks. • And Java uses these...

  22. Maximum Throughput, Minimal Latency • Our second MOST important design objective! • The Real-Time Java RTI infrastructure is streamlined for the most-often used RTI service calls • Attribute updates and Interactions • Multi-threaded design • Optimized Scheduler/Time Manager • Result: maximum throughput with absolutely minimal latency

  23. Secondary Achievements • Built-in Support for streaming data types • Functional “URL references” provide “out-of-band” communications or “Cut Through” functionality • With RTP we get some nice extras... • Embedded Time Stamps • Sequence numbers • (used to improve reliability!)

  24. Real-Time Protocol • With the Real-time Protocol, we get some other interesting components like RTCP and RTSP... • 1) We can tell how long the data took to arrive at its intended destination • 2) We can reconstruct the original message in sequence order, and • 3) We have a simple mechanism available in which to implement time-stamp ordering upon receipt.

  25. Virtual Reality Transfer Protocol • Originally proposed by Don Brutzman at the last DIS workshop (96f-DIS) • Incorporates built-in network management to “throttle” communications • Incorporates Area of Interest Management, originally proposed by Mike Macedonia (IEEE Spectrum Jan/99)

  26. “Cut-Through" Functional • Web-based Simulation will require the ability to read and process URLs • This would require additional functionality within the RTI … • By including support for basic HTTP, we can interface with Federates or read FOMs anywhere on the Internet!

  27. Conclusion • Early performance results encouraging! • Embedded management is great! • Alpha release planned for 1Q99 • DDM and full Time Management to follow • More features to come!

More Related