Sending and receiving events over the 'Event Horizon'

Open

Almost all Digital Twins or Virtual Prototypes are build up using multiple ‘layers’. Each Layer tends to have their own their own timeline and time progression - in fact, its in cross-layer communication that issues tend to occur.

As an example consider the 2D buttons in your Unity3D inspector, or on the Game view HUD and your material handling simulation. Pressing the 2D buttons will create an event, but its up to the material handling simulation to process them at a given moment in time. If the event is handled too late, or too early your simulation may falter.

Between these ‘Layers’ (and their timelines) exists a virtual barrier. This barrier is what we call the Event Horizon; but depending on your background you may have encountered it under a different name*.

Regardless of name there are some application design issues you must consider when crossing an Event Horizon:

• Since the timelines on both sides of the horizon are out-of-sync data will need to buffer as it crosses the horizon - this will create non-deterministic latency - as such all data processing that uses data that crosses the event horizon will BREAK simulation determinism!

• In development, an Event Horizon is a good place to place a functional split for Unit-testing - instead of the live data you can use a recording to statically test both sides of the horizon. Obviously it is important to note that recording or dataset is actually representative of your application (see fidelity model). Helpful for testing; such static testing can (albeit temporarily) bring back determinism.

• Time Dilation or Time Scaling will exacerbate data latency. So when using time scaling, be sure to be aware of event horizons.