APIC – CoreEngine Reflector

Bring a remote CoreEngine's shared memory to your local machine

Overview

Reflector is a standalone desktop application that lets you monitor and interact with a remote CoreEngine simulation as if it were running on your own machine. It removes the need for direct access to the remote system when all you need is to observe or drive the running simulation.

1. How It Works

  1. Reflector starts up and broadcasts on the network, then waits for a remote CoreEngine to connect.
  2. Once a remote CoreEngine connects, Reflector reflects its shared memory locally — the remote ICD database (LRUs, blocks, elements) is mirrored into a local shared memory instance.
  3. From that point on, the remote simulation appears to local tools as if it were running locally: no direct network access to the remote machine is required by those tools.
Reflector is the listener/host side of the connection — it waits and advertises itself; the remote CoreEngine is the one that connects to it (see the CoreEngine-side Reflector thread in config.json).
The broadcast identifies the remote engine by its application product name and version, so Reflector can tell which running CoreEngine it's looking at.

2. Data Flow

Remote CoreEngine Reflector local shared memory DIPanel SimReport OGI (graphs, images) StateHub & others network

Any local UI application that normally attaches to a CoreEngine's shared memory can attach to Reflector's mirrored shared memory instead, with no code or configuration changes on the client side.

3. Client Applications

Because Reflector mirrors the remote ICD database into a local shared memory instance, every local tool that reads or writes shared memory can use it transparently:

  • DIPanel — inject, monitor, and record data on the reflected simulation as if it were local.
  • SimReport — view live reports, warnings, errors, and state machine messages from the remote run.
  • OGI applications — graphs, images, and operator displays update live from the reflected data.
  • StateHub and other monitoring/state-machine tools — observe and control state machines on the remote engine.
None of these client applications need to know the remote machine's address or have network access to it — they only ever talk to the local shared memory that Reflector maintains.

4. Configuration

On the CoreEngine side, the connection to a Reflector instance is controlled by the Reflector thread configuration in config.json (CPU affinity and thread priority for the reflection thread). See the Runtime Configuration Guide for details.

5. Best Practices

  • Use Reflector when you need to observe or interact with a remote simulation without direct machine/network access to it.
  • Isolate the CoreEngine's Reflector thread on a dedicated core to keep reflection traffic from impacting real-time performance (see Runtime Configuration Guide).
  • Treat the reflected shared memory as read/write just like a local run — writes from local tools (e.g. DIPanel data injection) flow back to the remote CoreEngine.
  • Expect reflection to add network-dependent latency; it is not a substitute for hard real-time control loops.
← Back to Main page