1 / 53

J AVELIN !

J AVELIN !. Embedded. Michael D. Myjak Vice President & CTO The Virtual Workshop, Inc. P.O. Box 98 Titusville, FL 32781 <mmyjak@virtualworkshop.com>. Keith Briggs President iMT, Inc. P.O. Box 4380 Mountain View, CA 94040 <keith@imtinc.com>. J AVELIN. Embedded.

Download Presentation

J AVELIN !

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. JAVELIN ! Embedded Michael D. Myjak Vice President & CTO The Virtual Workshop, Inc. P.O. Box 98 Titusville, FL 32781 <mmyjak@virtualworkshop.com> Keith Briggs President iMT, Inc. P.O. Box 4380 Mountain View, CA 94040 <keith@imtinc.com>

  2. JAVELIN Embedded Java Virtual Environment Layered Infrastructure & the Java Real-Time RTI

  3. JAVELIN- Product Overview Embedded • Optimized Version of the Javelin • Produced Specifically for the Embedded Marketplace • Developed in Accordance With Sun’s Embedded Java Specification • Operates With a Minimal Memory Footprint • Utilizes a Modular and Dynamic Architecture • JAVELINAllows Service Support to Be Added Across a Network Through Embedded Java’s Dynamic Class Loader Capability. • Local Instance Need Not Support the Overhead Associated With Services That Are Not Locally Required While Maintaining Full Compatibility With the HLA Interface Specification.

  4. HLA Products… Who we are • Focused on the commercialization of HLA technologies • Defense and Commercial Applications • Education, Training, Research and Development • Combines iMT and TVW teams to achieve success! • Principles in HLA, SISO, IETF, VRML and Java communities • Past and present SISO RTI&C chairs, RTI Interop Chair, SAC Vice Chair, HLA SDG AR, RPR FOM DT, RD&E Forum Vice Chair and Chair of the IETF Large Scale Multicast Application (LSMA) Working Group • Strong community participation provides insight into requirements and solutions • Founders have over 70 years of combined experience! • Obtained significant investment to build JAVELIN

  5. JAVELIN - Overview • Requirements driven • Performance in Real-Time Environments • Platform Independence • Open Architecture • JAVELIN supports • streaming protocols, real-time communications and embedded network management for embedded systems and web-based applications • Technology enabled • Java Native Application • Embraces OSI Initiative of the ISO and IETF Standards • Hierarchical Design Approach

  6. Background - • Its Been Nearly Two Years Since the First RTI Prototypes Became Available From DMSO • Still No RTI for the Embedded Marketplace. • The Simple Truth About Embedded Applications • Unique Requirements for Embedded Simulation • Relative Difficulty of Addressing Those Requirements Within the DMSO RTI. • Embedded Marketplace Is a Fractured Community… • Applications Run on a Wide Range of Processors • Equally Wide Range of Operating System Environments. • Processor Speeds, Memory Capabilities, Disk Access (If Any), and Above All, the Connectivity of the Host Platforms Define a Truly Broad Range of Operating Capabilities.

  7. Other Challenges... • The DMSO RTI Requires Application Be Within a Relatively Standard Desktop Environment. • A Precise and Current Set of Operating System Patches Must Be Installed • Correct Environment Variables Need to Be Set • Is It Any Wonder That the Product Isn’t Available for the Embedded Marketplace? • NO Vendor Is Capable of Providing an RTI That Will Meet ALL of the Requirements of the Embedded Systems Marketplace. • The Range and Breadth of the Market Is Too Extreme to Provide for a Complete Solution.

  8. A Solution... • Can Be Achieved by Developing an RTI Framework That That Is Easily Customizable • (!) By the End Users • The Users Implementational Knowledge can assist in Customizing the Environment (as Required) • Baseline Capability Needs to Be Flexible • As Part of a Hardware-in-the-loop Simulator • Or Within Next Generation MILES Gear. • The Embedded Javelin Framework Is Designed to Provide That Level of Flexibility

  9. Javelin Embedded Was • Designed From the Ground up to Accommodate: • Extensible Networks • Widest Breath of Platform Capabilities • User Customization • Through Source Code Licensing • Real-time Performance • And Multi-platform Transportability • Through 100% Pure Java

  10. Embedded Requirements • Unique Processor / Operating System Requirements • Unique Connectivity Needs in Terms of • Performance (Low Latency) • Throughput (Low Bandwidth) • Limited (I.E., Console) or No Direct User Interface • Wide Variety of Platforms and Configurations

  11. Unique Processor O/S requirements(1 of 2) • Two Features of Importance for RTI Developers to Consider - • Porting Code Can Be Difficult, Time Consuming and CO$TLY! • Especially for Real-time Applications. • Different O/S Process Control Mechanisms • OS-9, Vx-works, VRTX, Real-time Unix and Windows CE for Example(s) • It Is Even Difficult to Move Between Different Platforms Even Using the Same OS

  12. Unique Processor O/S requirements(2 of 2) • There Is No Comparable Standard for Embedded Systems • As There Is for the PC Desktop Environment. • This Limitation Represents the Single Biggest Hurdle to the Delivery of an RTI for Embedded Systems Use.

  13. An Embedded Solution contains... • Any RTI Solution Must Be Configurable to Work on Both Large and Small Embedded Processors • It Must Maintain the Ability to Interoperate. • Constrain the Performance in High Performance Installations • At the Same Time, One Cannot Require Too Many Processor Resources From Smaller Installations.

  14. Connectivity & Requirements(1 of 3) • Hardware-in-the-loop • Often Tested Within the Context of a Sophisticated Laboratory Environment • One Would Expect Support for Standard or High Performance Commercial Networking Equipment • Low Latency Is of Key Importance • Allows for More Dynamic Distributed Interactions to Be Modeled Within the Simulation. • JADS Tests • Connected Via a Long Haul Network to Other Simulation Components Some 2000 Miles Away.

  15. Connectivity & Requirements(2 of 3) • Range Based Simulation • Simulation Components May Be Embedded on Every Platform in a Live Exercise... • Example: MILES Equipment • Low Bandwidth Communications Link • The Requirements Are Much Different (Than Those of the Hardware in the Loop) • Communications and Processor Limitations Are the Key Drivers in This Environment • It Is Unreasonable to Expect a Single Link to Support Several Hundred Individual Players.

  16. Connectivity & Requirements(3 of 3) • Embedded Vehicle Components • RTI Components Incorporated Into Vehicles Subsystems for Supporting Embedded Test and Training Applications • Ex: RTI operating over available 1553 bus connections without impacting the other on-board systems. • May have to interoperate/integrate with legacy processor platforms • Logical Conclusion: Operate in a Hierarchical Federation • Lowest level the federation is composed of vehicle subsystems • higher levels (i.e., the composite vehicles) are also interconnected • The RTI must be able to support these types of extended federations without impacting the performance of the intravehicular simulation.

  17. User Environments • Many Embedded Applications Support Minimal or Absent User Interface • Console Control Has Only a Minimal Impact on the RTI (Either Interface or Operations) • However, Current HLA Evolution Raises Several Questions and Concerns From the Systems Administration Perspective • Ex: Current Versions of the RTI Boot From Local Copies of the RTI Executable • How Does One Automagically Specify the Federation Execution Data (FED) File, and RTI Initialization Data (RID) Files?

  18. User Environments • Local Environment Variables Define the Interface Port to Address the Federation Executive • This Must Be Started Prior to the Local RTI. • Different RTI Implementations Don’t Interoperate • Whether Produced by Different Vendors or Different Versions Produced by the Same Vendor • Therefore… • To Be Accepted, a Homogeneous RTI Must Be Supportable in an Embedded Systems Environment As Well As in Other “Easily Accessible” User Environments

  19. JAVELIN is a Framework... • It includes • the Java Real-Time RTI • The Virtual Reality Transfer Protocol • The Real-Time Protocol • From the onset, we recognized the need to support extended hierarchical federations • So JAVELIN was designed to be Scaleable and Extensible • We have constructed • The Javelin framework accommodates those requirements.

  20. Hierarchical Design • From the onset, JAVELIN was designed to be Scaleable and Extensible • JAVELIN’s Architecture draws on years of experience dealing with scaling issues on the level of the Internet • Hierarchical Design and Implementation • Planned Inter and Intra Federation support • Embedded JAVELIN moves this technology down into the Firmware

  21. SUN SGI IBM Linux Linux Simple Network • A local net example with a few federates Simulation nodes PC NT RTI Manager Token also manages Local Net

  22. Short Distance Peers • Two locally connected network segments Distributed JAVELIN Broker Simulation nodes 1-5 Segment 2 Segment 1 RTI Manager Token Local Net Manager Token JAVELIN Broker

  23. Long Distance Peers • Three local network segments connected via Interconnecting Hub Segment 3 Local Routers Simulation nodes 1-5 Interconnecting Hub Segment 2 Segment 1 RTI Manager Token Local Net Manager Token JAVELINBroker

  24. Wireless Network • Example using a generic Wireless Internet or Private Intranet, etc. LAN 3 WAN Border Router/Gateway Wireless | Embedded Simulation nodes 1-5 RTI Manager Token Local Net Manager Token JAVELIN Broker LAN 1

  25. Heterogeneous Architecture • JAVELIN supports multiple, non-congruent architecture systems, end-to-end! LAN 3 Massively Parallel Architectures Shared Memory Systems LAN 1 LAN 2 RTI Manager Token Local Net Manager Token JAVELIN Broker

  26. JAVELIN Architecture Networking Approach

  27. JAVELIN Networking • Platform and Network Independence • Maximum throughput with absolutely minimal latency (<5ms). • Special Support for Streaming Data • Embedded Management Services • Federate and federation "cut-through" functionality • Integration with the Web!

  28. Application Virtual Reality Transfer Protocol AOIM Network Manager Presentation Real-Time Control Protocol Real-Time Protocol Real-Time Streaming Protocol Session Transport Network Data Link Hardware JAVELIN Organization Embedded JVM AVE Java Real-Time RTI irtual nvironment JAVELIN ayered nfrastruvture UDP, TCP, SNMP, RSVP, etc. Internet Protocol (IP) Ethernet, ATM, FDDI, etc... Cards, Cables, Computers …

  29. JAVELIN Application Layer • We placed HLA RTI at the Application Layer... • This approach provides a clear, concise and unambiguous Interface to HLA Federates from the Java Virtual Machine • HLA RTI-Federate Interface Specification • Application Layer Protocols define two interfaces: • To the “User Application” Above • To the Next Layer Protocol Below

  30. Transport and Network Layers • Conforms to existing and emerging standards • Open Systems Interconnect (OSI) • High Level Architecture (HLA) • Virtual Reality Transfer Protocol (VRTP) • Real-Time Protocol (RTP) Including: • Real-Time control protocol (RTCP) • Multi Stream Support • Simple Network Management Protocol (SNMP) • Network Time Protocol (NTP) • Bandwidth Reservation Protocol (RSVP) • and the Internet Suite of Protocols • (e.g., IP, UDP, TCP, IPmc, etc.)

  31. JAVELIN Architecture Low Latency Low Overhead High Throughput

  32. Low Latency Requirements • Real-time applications require minimal overall (i.e., End-to-End) system latency • JAVELIN’s component infrastructure minimizes overall system latency • Time Stamp and Sequence Number • Bi-level Ordering on every datum and across streams • Scaleable O(LogN) Performance • improves consistency • Promotes deterministic results

  33. Single Lookup Design • At the lowest level • the JAVA Real-Time RTI state data is reflected to every RTI instance • Improves Performance • Lowers End-to-End Latency • Through JAVELIN’s hierarchical design • RTI state data is segmented and controlled efficiently! • Single lookups are all that is required to resolve data distribution

  34. State Reliable Protocol • RTI state data (e.g., control, data) is transmitted reliably • Low latency best effort transmission • Capitalizes on high reliability, low latency in local subnets • Currently prototyping several state reliable approaches • Forward Error Correcting • Selective Retransmission • Reliable Multicast • NACK-based) • w/ Congestion control

  35. Consistent Multi-threaded Architecture • Low latency requires multi-threaded design • Platform independent multi-threaded design is not feasible with current “C” based environments • Java provides a consistent multi-threaded supportable architecture • Update/Reflect implemented in separate high priority threads to minimize latency

  36. Java Performance • Contrary to popular myth, JAVA is Not a bottleneck • Java Hot Spot Virtual Machine (VM) performance promises to match C++ efficiency in many areas • Java v2 JVM (SUN native) Excels! • RTI does not require graphics support • the current bottleneck with Java • JAVELIN prototypes have performed well using currently available JRE (v1.1.b)

  37. Interoperability • Consider how current RTIs boot from local copies of the RTI Executable, Federation Execution Data (FED) file, and RTI Initialization Data (RID) file. • Local environment variables are used to define which port contains the Federation Executive • Must be started prior to the local RTI • Different versions of the RTI, produced by different or in many cases the same vendor, don’t interoperate. • Recognize that HLA is an immature specification • (unlike TCP/IP) • As such it can be expected that both implementations and specifications will continue to fluidly evolve over the next period of time. • Result: • Heterogeneous Interoperability is difficult to achieve

  38. Cross Platform Capabilities • Commercial support of Embedded JAVELIN across disparate platforms would not be possible without JAVA • Porting costs are greatly reduced • Replaces “One-of” Solutions • Similarly, maintenance costs are lower • Big Win • - Reduced development time • No more Big/Little “endian” problems • No word size inconsistency

  39. Programming Efficiency • Substantial increase in programming efficiency • Improved syntax / readability • Yields Improved Coding Efficiency! • Standard support for arrays, hash tables • Established documentation standards • Pure object language • This is “THE” Programmer’s Language! • High level language support for system operations (networking, etc.)

  40. Embedded Solutions • Java is rapidly becoming the standard for embedded solutions • Java is supported by all of the major embedded operating systems • Embedded Java and Personal Java provide optimized environments for embedded applications • Pico Java is already on a chip! • Porting to the embedded real-time OS is simply easier to accomplish!

  41. A Living Language • Java is a “living language” • Java is evolving with the web and with new commercial solutions • New enhancements are being developed to support: • Improved distributed programming • And new graphics standards - • Web3D (VRML), Java 3-D, etc • The standardization process for “C” and “C++” limits their market responsiveness

  42. A Natural for Web Programming • The features required for web programming are native in Java • Networking support • HTML processing • Web based applets • Portability • Java IS the standard for web programming today • With GOOD REASON!

  43. JAVELIN An Open Architecture Solution

  44. Source Code Availability • HLA Products will license the source code for JAVELIN • Source code availability is required to meet specialized market requirements • Source code availability makes sense • Reduced development time • Users benefit from all JAVELIN partners • Its simply the right thing to do! • LINUX, Netscape, GNU, etc.

  45. Web-JAVELIN The Future Learning Solution

  46. Web-JAVELIN • JAVELIN - has MASS ! • Modeling And Simulation Solution • JAVELIN - has VELOCITY ! • Virtual Environment Layered on a Commercial, Integrated Toolset (Yeah!) • HLA provides the Acceleration!

  47. JAVELIN Browser Plug-in • Core JAVELIN will be ported to operate as a plug-in to Netscape • Allows for full HLA networking capability within browser environment • Accessible to the application through Java Applets • Seamlessly merges commercial web and HLA solutions • HTML, Video Conferencing

  48. JAVELIN Applets • Provides for web based custom HLA applications • Links FED and RID data • Supports federate functionality • Automates startup process • Combined with Browser Plug-in • JAVELIN applets support HLA networking despite security restrictions

  49. Distance Learning • JAVELIN can provide new and exciting distance learning solutions • Combines the best of commercial and simulation technologies • Web-based video streaming applications will become the next frontier in Education • JAVELIN expands current commercial solutions • Supports multiple native video and audio streams

  50. Web Based Simulation • Current web based learning environments are limited to static, conversational media • JAVELIN opens up a whole new frontier • Low-cost web-based simulation • Command and control consoles • Data Fusion • Analysis and after action review • Web-based simulation plus distance learning equals the future for training!

More Related