Java Real-Time RTI
This presentation is the property of its rightful owner.
Sponsored Links
1 / 27

Java Real-Time RTI PowerPoint PPT Presentation


  • 45 Views
  • Uploaded on
  • Presentation posted in: General

Java Real-Time RTI. Michael D. Myjak. Vice President Research and Development. P.O. Box 98 Titusville, FL 32781 <[email protected]>. 17 September, 1998. P. O. Box 98  Titusville, FL 32781  407.264.0440. Motivation.

Download Presentation

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Java real time rti

Java Real-Time RTI

Michael D. Myjak

Vice President

Research and Development

P.O. Box 98

Titusville, FL 32781

<[email protected]>

17 September, 1998

P. O. Box 98  Titusville, FL 32781  407.264.0440


Motivation

Motivation

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


Outline

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.


Simulation history in a nutshell

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.


Simulation darwinism

Simulation Darwinism

  • Natural evolution saw that various combinations were also interesting -

    • Discrete event + continuous simulations

Discrete event

Continuous

Monte Carlo


Simulation darwinism1

Simulation Darwinism

  • Natural evolution saw that various combinations were also interesting -

    • Discrete event + continuous simulations

    • Discrete event + analytical modeling

Discrete event

Continuous

Monte Carlo


Simulation darwinism2

Simulation Darwinism

  • Natural evolution saw that various combinations were also interesting -

    • Discrete event + continuous simulations

    • Discrete event + analytical modeling

    • Continuous + Monte Carlo

      => Gamblers Anonymous


Internet gaming

Internet Gaming

Continuous

+ DES

Discrete event

Continuous

Continuous

+ Analytical

DES + Analytical

Monte Carlo


Architectural extensions

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


Architectural extensions1

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.


Architectural extensions2

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.


Evolving federated simulations

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.


Bringing hla into the mix

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.


Interoperability issue

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.


We re not quite there yet

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


Federated simulations

Federated Simulations

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


Federated simulations1

Federated Simulations

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

  • Why… On the Desktop, of course!


Federated simulations2

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


Development goals

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!


Development components

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


Our principal goal

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


Maximum throughput minimal latency

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


Secondary achievements

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!)


Real time protocol

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.


Virtual reality transfer protocol

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)


Cut through functional

“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!


Conclusion

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!


  • Login