🔒 UNCLASSIFIED / SYNTHETIC
?
Every subscription on this dashboard is served over an authenticated WebSocket connection with adapter-side, per-item and per-field entitlement filtering. A classified network segment and a commercial network segment can each run their own isolated, self-hosted Lightstreamer deployment behind this same entitlement model. All data on this specific dashboard is synthetic and unclassified: no real track data, engagement data, satellite telemetry, classified information, CUI, or production Raytheon/RTX credentials are used anywhere in this environment.
WebSocket
?
StreamSense is Lightstreamer's automatic transport selection layer. It evaluates each client's network capability and selects the optimal delivery method: WebSocket for full-bandwidth connections, HTTP Streaming for degraded networks, and Smart Polling for highly constrained environments. The badge here updates live as you switch network conditions below. This is the single most visual proof point in the whole PoC: try the RF-Contested / Jammed mode below.
CONNECTING
KURFS/COYOTE 8 Tracks · 4 Hz MERGE ENGAGEMENT QUEUE Coyote · COMMAND AN/SPY-6 6 Contacts · 8 Hz MERGE LIGHTSTREAMER Kafka Connector Ready
KURFS/COYOTE · TRACK PICTURE
?
Eight synthetic drone-swarm tracks shaped to KuRFS's 360-degree detection cadence, streaming at 4 updates per second each. The MERGE channel holds only the latest position per track and snapshots automatically on subscribe: under network pressure, an operator's tactical display always shows the current track picture, never a backlog of stale positions. In production, the Lightstreamer Kafka Connector reads directly from Raytheon's internal KuRFS track topics. This is an adapters.xml configuration change rather than a new integration to build.
NOMINAL
COYOTE · ENGAGEMENT QUEUE
?
A synchronized engagement-authorization queue delivered on Lightstreamer's COMMAND channel: the server manages an ordered list of flagged tracks, and add, update, and delete deltas push automatically as an authorization moves from pending to authorized, held, or aborted. Client state always converges correctly, including after a reconnect. Rows appear here only when a track crosses the engagement-relevant threshold in the tactical display.
LIVE
Track · Effector · Status
No tracks currently flagged for engagement
AN/SPY-6 · RADAR CONTACTS
?
Six synthetic radar contacts spanning air, surface, and subsurface domains, shaped to SPY-6's GaN-based AESA radar returns, streaming at 8 updates per second each. Only the changed bytes transmit on every update: at shipboard satellite-uplink scale, delta delivery is the difference between a usable radar picture and a saturated link. This is the surface most directly relevant as SPY-6 expands to allied navies over the same kind of constrained link.
NOMINAL
⚡ LIGHTSTREAMER DELIVERY PROOF
?
The server publishes track, contact, and sensor data at a constant rate regardless of any client's network condition. Lightstreamer's MERGE channel tracks the last value delivered to each connected display and intelligently consolidates intermediate updates when bandwidth is constrained, so each display always receives the most recent position, never a backlog. The conflation ratio shown here is server events divided by client deliveries: 1 to 1 on a classified fiber backbone, rising as network conditions degrade toward a tactical or satellite link. Engagement authorizations and detection events on the DISTINCT channel bypass conflation entirely and always deliver in full.
Data Sources to Lightstreamer
RaytheonStreamAdapter publish rate
86
updates/sec (server)
KuRFS/Coyote tracks (8)4 Hz ea.
AN/SPY-6 contacts (6)8 Hz ea.
FORGE/JPSS OPIR (3)1 Hz ea.
Command Center (2 feeds)1 Hz ea.
Engagement / detection eventsDISTINCT
MERGE Conflation
?
Conflation ratio: server publish rate divided by client receive rate. On a classified fiber backbone this is 1 to 1. As network conditions degrade toward a tactical or satellite link, Lightstreamer consolidates intermediate values so the display always shows the latest position. Engagement authorizations and detection events on the DISTINCT channel bypass conflation and always deliver in full, regardless of bandwidth.
1:1
server events per
client delivery
Only the delta is sent.
Unchanged fields transmit 0 bytes.
Lightstreamer to This Display
This browser's receive rate
86
updates/sec (client)
KuRFS/Coyote tracks (8)4 Hz ea.
AN/SPY-6 contacts (6)8 Hz ea.
FORGE/JPSS OPIR (3)1 Hz ea.
Command Center (2 feeds)1 Hz ea.
Engagement / detection eventsALL · DISTINCT
📡 NETWORK SIMULATOR
?
These buttons simulate network conditions Raytheon's own programs actually encounter: a classified fiber or SIPR-class backbone, a forward-deployed tactical field network, a shipboard or remote-site satellite uplink, and an RF-contested or jammed link severed mid-engagement. Lightstreamer adapts automatically to each condition with no configuration required. Use this simulator to observe how the delivery rate and conflation ratio change in the proof panel above, while engagement authorizations and detection events keep arriving regardless of bandwidth.
Effective bandwidth
Unthrottled
Protocol (StreamSense)
WebSocket
MERGE conflation
Off
DISTINCT events
Unaffected
Classified Fiber: WebSocket delivers all track, contact, and sensor data at full publish rate on a hardened, high-bandwidth backbone.
⚠ DISTINCT CHANNEL: ENGAGEMENT & DETECTION EVENTS
?
Engagement authorizations, threat classification changes, radar detections, and missile-warning detections use Lightstreamer's DISTINCT channel: zero consolidation, every event delivered exactly once, in sequence, regardless of network conditions. When a display loses connectivity, events queue server-side and flush the instant the connection restores. The published and received counts shown here must always converge: that is the DISTINCT guarantee. A dropped or duplicated engagement authorization is a real operational failure rather than a display glitch, which is why this channel never conflates.
Published
?
Total events published since this session started. This count advances regardless of whether any client is connected.
0
Received
?
Total events received by this browser. During a link severance, this count pauses. On reconnect, queued events flush immediately and this count catches up to Published.
0
0
events queued during last outage
Engagement authorizations and detection events bypass all MERGE consolidation. Published and received counts converge after every outage. This is the DISTINCT guarantee: zero missed events, zero duplicates, always in order.
🌐 PROGRAM COMMAND CENTER
?
Always-on cross-program status, sized to what a Raytheon program operator actually needs: active KuRFS/Coyote tracks and pending engagements, AN/SPY-6 contact counts by domain, and FORGE/JPSS OPIR sensor status. This reuses the exact same MERGE and DISTINCT channels built for the track and contact demos, applied to aggregate telemetry, and reflects the "single deployment, many isolated programs" model in Raytheon's own Integration Blueprint.
KuRFS/Coyote Counter-UAS
Active Tracks
?
Total synthetic tracks currently held in the KuRFS 360-degree detection picture.
--
tracked
Hostile Classified
?
Tracks currently classified hostile_drone, crossing the engagement-relevant threshold.
--
tracks
Engagements Pending
?
Tracks currently in the Coyote engagement queue awaiting or on hold for authorization.
--
in queue
Effectors Ready
?
Coyote effectors not currently tasked against a pending engagement.
--
standing by
AN/SPY-6 Radar Network
Air Contacts
?
SPY-6 contacts currently tracked in the air domain.
--
tracked
Surface / Subsurface
?
SPY-6 contacts currently tracked in the surface and subsurface domains combined.
--
tracked
FORGE/JPSS OPIR Sensor Network
⚙ SELF-OBSERVABILITY: THE PLATFORM WATCHING ITSELF
?
Lightstreamer streams its own connection count, per-message latency, and throughput back out over the same technology being demoed. This is a self-referential proof point: the numbers below are running live, on the product being pitched rather than slideware. The concurrent-connection figure measured during a PoC load test feeds directly into the per-program server sizing conversation, since production servers scale as connection count divided by capacity per server.
Connections
--
p50 Latency
-- ms
p99 Latency
-- ms
Throughput
-- /s
Reference point for the PoC's own concurrency and throughput load test (Metric 5.9 in DP5_PoC_Requirements_Raytheon.docx): production deployments elsewhere on this platform have measured 2M price updates/sec and 100K+ concurrent clients per cluster. This PoC server is intentionally sized for a live demo rather than a load test rig.
⚠ EVENT LOG: DISTINCT CHANNEL
?
Every engagement authorization, threat classification change, radar detection, and missile-warning detection appears here in real time. Events shown as QUEUED during a link severance will flip to DELIVERED on reconnect. The sequence number confirms no event was skipped: DISTINCT guarantees ordered, exactly-once delivery.
Awaiting first event...
🔌 LIGHTSTREAMER SESSION LOG
?
Live event stream from the Lightstreamer client library: connection status, subscription acknowledgements, and protocol transitions. WebSocket connected means lowest-latency delivery. HTTP Streaming is the fallback for networks that block WebSocket. Smart Polling is the last resort for highly constrained environments. StreamSense selects the right protocol automatically with no configuration required.
Connecting...
HOW THIS WORKS