slide1
Download
Skip this Video
Download Presentation
Java Real-Time RTI

Loading in 2 Seconds...

play fullscreen
1 / 27

Java Real-Time RTI - PowerPoint PPT Presentation


  • 81 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Java Real-Time RTI' - javen


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
slide1

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