Home

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

Get the RTI up and running (see README)
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.
Implement client behavior as necessary
Define a data exchange model, i.e. messages specific to your project
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.