GEISTT Lab RTI

Background and purpose

The idea of a Lab RTI (run-time infrastructure) arose from the repeated experience of re-inventing the same wheel in several of GEISTT simulation-based concept development projects. The overall goal is to provide the lowest common denominator of infrastructure functionality for a lot of projects, as simply as possible, so that the projects can focus on their core functionality and research questions.

The RTI is intended for projects such as:

• Simulation-based design and concept development
• Simulated operative training
• Human-machine interface (HMI) research
• User testing

The RTI, or a similar predecessor of it, has been used successfully in a number of projects, including:

• Autonomous vehicle control HMI research
• Stress-adaptive training research
• Air traffic control decision support research
• Driving simulator co-simulation

Supported languages and platforms

What you get

The Lab RTI provides:

• Client libraries with similar usage pattern for several platforms: Javascript/Typescript, Python, C++, C# .NET Core, Unity, Unreal
• Well defined, simple-to-use publish/subscribe-based communication between components, such as simulators and HMI prototypes
• Common messages for runtime control (start, stop, etc), client & channel discovery, metrics and measurements
• Common object model for high-level concepts such as simulated entities
• Web-based runtime control application
• Command-line runtime control and debugging/analysis application

What you don't get

Compared to something like HLA, DIS, DDS...

• A standard
• Entity ownership, authorization, transfer
• Sender-side filtering and other advanced bandwidth-saving techniques
• Gateways, boosters, firewalls and such networking tools for distributed simulation
• Advanced time synchronization and lag/latency compensation
• Audio/radio (pitch talk) or video streaming (pitch media streamer)

How to use it

1. Get the RTI up and running (see README)
2. Add the appropriate Lab RTI client library for your platform to your project. If using Unity or Unreal Engine see the wiki pages for setup instructions.
3. Implement client behavior as necessary
4. Define a data exchange model, i.e. messages specific to your project
5. Implement project specific data exchange message handling - application logic for publishing and receiving your project specific messages

Enabling technology

The RTI implementation is based on open-source technology.

• Protocol Buffers by Google
• SocketCluster
  • Official client libraries for TypeScript and Python
  • Not using official client library for C# / .NET because it doesn't work with .NET Core and Unity
  • Not using official client library for C because it is subjectively a weird/broken/unfinished implementation
  • Not using official client library for C++ because it has a large dependency chain (boost beast) and seems somewhat unfinished
• .NET Core for some tools
• Vue.js for web-based user interfaces

Design choices

• Why socketcluster? Because it makes integrating web-based HMI prototypes a breeze!
• Exchangeable transport mechanism. Virtually any pubsub mechanism could be used with minimal effort. Clients implement most functionality. Minimal complexity in cluster/broker.
• Why not just use JSON? Loosely defined data contract (no schema). Bandwidth efficiency (field names > data). Parsing.
• Why not just use HLA? We can't afford it. Our clients don't want to pay for it. We don't want the complexity.