Java Real-Time RTI

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!