Edge Console — User Guide

The Edge Console is your window onto a site. It watches every EdgeCommons component over the Unified Namespace, shows health, live data, events and configuration, and lets you send commands — all from one browser tab, with no per-component setup. This guide walks each screen, captured live from the Dallas bottling-plant test site (3 devices, 12 components).

Getting started & the app shell

Opening the console. The console serves its own UI, so you just browse to its address — in the Dallas test site that is http://127.0.0.1:8080. On a real edge it is the console component’s host and port. There is nothing to install; it streams everything live over one WebSocket and reconnects on its own if the link drops.

The frame. Every screen shares the same shell: the left rail is the primary navigation (the seven screens below). The top bar holds a global search (jump to any component, device, or signal), a theme toggle (light/dark), a notifications bell that shows the active-alarm count, and your account & role (here, operator). Your role decides which commands you may send — see Settings.

Live, not polled

Every number, sparkline, and row updates as data arrives on the bus — the “WS Live” and “Bus connected” markers in the header confirm the stream is healthy. You never refresh the page.

Overview — Edge health

The landing screen and your at-a-glance answer to “is the site healthy right now?” Four summary tiles over a fleet table grouped by device.

1 2 3 4 5 6 7 8

Overview, live against the Dallas plant — 12/12 components healthy across 3 devices.

1. Navigation rail — the seven screens; the current one is highlighted.
2. Site summary + link state — device/component counts, plus WS Live and Bus connected confirming the stream.
3. Site health — the ring shows healthy vs total; green means every component is reporting on time.
4. Active alerts — count of open alarms (0 here). Click through to Events & Alarms.
5. Edge bus msgs/s — the console’s own live bus throughput with a sparkline.
6. Console self — the console’s own CPU, memory and uptime (it is a component too).
7. Fleet table — every component grouped by device/line, with health, heartbeat age, and live CPU + memory sparklines.
8. Controls — per-component command menu (gated by your role).

Devices roll up: the DEVICE and LINE group headers carry a health chip and component count, so a red line stands out before you read a single row. The Heartbeat column is how long ago each component last proved it was alive — the console derives freshness from each component’s own configured cadence.

Components — inventory & drill-in

The full site inventory as the Unified Namespace tree, with a drill-in table for whatever node you select.

1 2 3 4

The enterprise → site → line → device → component hierarchy, straight from each component's identity.

1. UNS tree — enterprise ▸ site ▸ line ▸ device ▸ component, built from the identity each component stamps on the wire. Counts show components beneath each node.
2. Filter tree — type to narrow a large fleet to matching nodes.
3. Inventory table — every component beneath the selected node, with health, device, and heartbeat age.
4. Open — jump into that component’s detail view.

Use this screen when you know where in the plant you’re looking. Select a line to scope the table to it; select the site root to see everything.

Component detail

Everything one component is doing — its health, configuration, events, metrics, logs, and the commands you can send it — behind a row of tabs.

1 2 3 4 5 6

The Health tab for a southbound OPC UA adapter — liveness, connection state, process vitals, and operational checks.

1. Header — name, live health, its line/device/instance, keepalive cadence, and last-state age.
2. Command bar — one-click verbs the component exposes (here Ping, Get config, Signals); what you may run depends on your role.
3. Tabs — Health, Panel (descriptor-driven views), Instances, Configuration, Events, Metrics, Logs.
4. Liveness & connection — is it reporting on time, and (for adapters) is the field link up.
5. Process vitals — CPU and memory carry a Live chit and a sparkline while fresh; disk, threads/files/FDs and uptime alongside.
6. Operational checks — heartbeat freshness, messaging readiness, connection state, read errors, and open alarms in one table.

Config review

The Configuration tab shows the component’s effective, secret-redacted config exactly as it announced it — the fastest way to confirm what a component is actually running without SSHing to the device.

Instances

The Instances tab lists every connection the component is configured with — one OPC UA server, one Modbus slave, one replication source directory each — with its current state: online, connecting, backoff (down, retrying), or paused. A paused instance is marked expected quiet: an operator stopped it on purpose, so its silence is not a fault and it is left out of the Health tab’s connected-instance count. A component that reports no state per instance shows connected / disconnected instead.

Panel

The Panel tab renders the views the component itself advertises. Where those views act on one connection, an Instance selector sits above them and every command you run there targets the instance you picked. Views whose commands act on the whole component show no selector, and a view whose commands accept either addressing adds a Whole component choice to the selector.

Signals — the live data plane

Every telemetry and business signal flowing on the site bus, live. This is where you watch actual process values — tank levels, temperatures, counts — as they change.

At fleet scale a site can carry hundreds or thousands of signals, so the screen opens as a grouped index: signals fold by their path, each group header showing a count, quality rollups, and a live msg/s rate. The quality triage strip across the top counts Good / Uncertain / Bad / No-quality and doubles as a one-click filter.

1 2 3 4

Collapsed view — a whole plant reads as a handful of group headers.

1. Quality triage strip — live counts per bucket; click a bucket to filter to just those signals.
2. Group-by & scope — group by signal path, component, source, or none; narrow by device then component (the lists cascade).
3. Group rollups — per-group signal count, bad/uncertain pills, live msg/s, and freshest update.
4. Collapse all — toggle the whole index open or shut.

Expand a group and each signal becomes a rich row — and here is where the console earns its keep:

1 2 3 4 5

Expanded — real values, quality, trend sparklines, and per-signal publish lag, all live.

1. Name-led rows — the signal’s friendly name, with its canonical id, channel, and owning device / adapter / instance beneath.
2. Latest value — the current reading (numbers, booleans, strings — the class is open).
3. Quality — GOOD / UNCERTAIN / BAD; hover for the protocol-native status code.
4. Trend — a live sparkline from the retained recent window (Sine1’s wave, LiveRandom’s noise); non-numeric signals show a dash.
5. Updated + lag — receipt freshness plus lag = time from the field measurement to publish. A large lag means the source is stale even while messages still flow.

Reading lag

Lag is measured in the adapter’s own clock domain (measurement time vs publish time), so it is a true field-freshness signal — not network jitter. A dash (lag —) means the publisher sent no source/server timestamp. Click any row to open a detail panel with the full timestamp chain (source · server · published · received).

Scope

Signals shows what is on the bus. A value routed only to a durable stream target (a historian) never passes here — that’s by design, and the subtitle says so.

Site topology

A live connectivity graph — every component and the external field and cloud systems it talks to, with the link state on every edge.

1 2 3 4 5

The Dallas plant: console (site observer) → site bus → two lines → their field endpoints.

1. Filters — show/hide Southbound, Northbound, Bus edges, or focus on alarms only.
2. Site observer — the console itself and its site config component.
3. Site bus — the shared UNS broker every component publishes to.
4. Components by line — grouped by device; hover a node for detail, click to open it.
5. Field endpoints — the southbound systems (Modbus units, OPC UA servers) each adapter connects to; edge color = link state.

Structure comes from component identity; the endpoint arrows come from each component’s config. Green edges are connected, amber degraded, red disconnected — so a broken field link is visible without opening anything. Scroll to zoom, drag to pan, Fit to reset.

Events & alarms

The rolling event feed and the active-alarm surface — what happened, and what still needs attention. Reach it from the nav, or from the notifications bell in the top bar, which always shows the current active-alarm count from any screen. The screen has two halves.

The event feed is a live, newest-first log of component events, split by severity, with component and severity filters and a per-row expander for the full detail (channel, publisher timestamp, tags, and the pretty-printed body). It streams as events arrive.

Alarms are a first-class, derived surface. The console raises an alarm from the evt severity stream, re-raises bump its count, and a matching lower-severity event clears it into history. You can acknowledge an active alarm (console-side state), and when a whole device goes unreachable its component alarms are contained — held but taken out of the active counts, so “the road is down” doesn’t drown out “the houses.”

The console watches itself, too

If the gateway’s own clock steps backward (a misbehaving VM or NTP glitch), it publishes a clock-step warning that lands here like any other alarm — an observability tool reporting an infrastructure fault instead of hiding it.

Settings

The console’s own effective policy and configuration — read-only, so you can confirm exactly how it is running and what your role may do.

1 2 3 4

Read-only policy & configuration, sourced from the console's own component.global.console.

1. Access policy (RBAC) — which command verbs each role may run; deny wins, * is all-verbs. Gates the command write-path.
2. Your role — the role this connection resolved to (here operator, full control).
3. Connection — the console’s node, deployment platform, site-bus transport & broker, its WS gateway address, heartbeat cadence, and whether it serves the UI.
4. Miss-detection thresholds — the staleness ladder (warn 2× / stale 2.5× / offline 5×), the default keepalive interval, and the sweep period.

Auth posture

The command write-path is RBAC-enforced. The read surface (health, live streams) is currently unauthenticated — keep the console on a trusted network or terminate authentication in front of it.

Common tasks

I want to…	Go to	How
See if the site is healthy	Overview	Read the Site-health ring and the fleet table; red group headers surface trouble first.
Find one component fast	Top-bar search	Type a component, device, or signal name and jump straight to it.
Inspect a component in depth	Components → Open	Drill into Health, Configuration, Events, Metrics, and Logs tabs.
Watch a live process value	Signals	Expand its group; read Latest, Quality, Trend, and lag. Filter by quality to isolate problems.
Confirm what a component is running	Detail → Configuration	The effective, redacted config exactly as announced — no SSH needed.
Check a field link is up	Site Topology	Edge color shows connected / degraded / disconnected to each Modbus / OPC UA endpoint.
See what needs attention	Events & Alarms	The bell badge shows the count from anywhere; acknowledge active alarms here.
Send a command	Detail → command bar	Click a verb (e.g. Ping, Get config). Availability follows your role — check Settings.