SILVER RIDGE GROUPHardware Control Plane Request a briefing
Platform

The operational state layer above your hardware.

Not a monitoring tool. The authoritative record of what every device is doing, which alarms are open and in what lifecycle state, who owns what, and which commands were issued, by whom, and when.

On this page
01, Collection

Nine protocols. One telemetry pipeline. No exceptions.

Every driver writes through the same store_samples() path into a TimescaleDB hypertable. There is no protocol-specific alarm path and no protocol-specific telemetry endpoint, a GPU node, a Modbus UPS and an OpenConfig router are read the same way.

IT tier
Redfish / DMTF
IPMI 2.0 / RMCP+

Servers, blades, storage, BMCs, liquid cooling

GPU / HPC tier
DCGM / dcgm-exporter
SLURM / slurmrestd

GPU nodes, clusters, job schedulers

Network tier
gNMI / OpenConfig
SNMP v1/v2c

Routers, switches, optical transport

OT / facility tier
Modbus TCP
MQTT
BACnet/IP

UPS, PDUs, cooling, generators, HVAC

Shared telemetry pipeline store_samples() → TimescaleDB hypertable · event normalization · Z-score anomaly detection · alarm rule evaluation
Alarm engine
ISA-18.2 lifecycle, escalation
Health scoring
0–100 with A–F grade
Intelligence
Eleven analytics capabilities
Northbound
REST, Redfish, SSE, Kafka, webhooks

Read is uniform

/api/v1/assets/{slug}/telemetry returns the same shape whether the metrics came from OpenConfig paths, BMC sensors, Modbus registers, HVAC points, OID maps, DCGM fields or SLURM cluster counters.

Write is explicit

Control is protocol-specific by design, command semantics differ too much to flatten. Each protocol exposes its own discovery and execution endpoints; SNMP, DCGM and SLURM are telemetry-only and their control surfaces are hidden entirely.

02, Alarm management

Process-control alarm discipline, applied to the data center.

ISA-18.2 is the standard that industrial process control uses to keep operators effective under load. An alarm is not a notification, it is a record with a lifecycle, an owner and a history.

Alarm lifecycle
Fires
UNACKNOWLEDGED
operator ACK
Owned
ACKNOWLEDGED
condition ends
Resolved
CLEARED
time-bounded
Deferred
SHELVED
parent alarm
Cascade
SUPPRESSED

Every transition is written to the alarm's action history with a timestamp and an operator identity. Shelving is time-bounded or indefinite and always attributable. Suppression is derived from the typed asset relationship graph, so a UPS offline alarm silences the servers on that circuit rather than burying the operator in consequences.

Where alarms come from

Event rules, pattern match on event type, message ID, severity or message body, from device push or poll-detected transitions.
Threshold rules, any metric, with a hysteresis deadband so an alarm fires at one value and clears at another.
Anomaly, automatic P3 from statistical detection, on every metric from every protocol.

Noise control that is built in

Deduplication, repeats inside a window increment a counter instead of creating records.
Burst filter, a minimum occurrence count before an alarm is allowed to fire.
Auto-shelve, rules firing more than N times an hour shelve themselves and are flagged for tuning.
Storm detection, five alarms across three assets in sixty seconds broadcasts a storm and rings the account on the map.

Escalation and accountability

Ordered chains, per-step delays, per-account scope with a global fallback.
Channels, email, chat webhooks, custom HTTP endpoints, retried with exponential backoff.
Priorities, P1 critical through P4 low, weighted into the asset health score.
Workload filters, separate threshold profiles for idle and running GPU states.
03, Detection and grading

Statistical detection without an ML pipeline to operate.

Z-score anomaly detection

Baseline7-day rolling mean and standard deviation per device and metric, cached with a five-minute TTL
Candidate breachdeviation beyond three standard deviations from the mean
Confirmationtwo consecutive breaches before a P3 alarm fires, so a single spike stays silent
Auto-clearwhen the score falls back within two standard deviations
Coverageevery metric, every device, all nine protocols
Workload awaresuppressed while a scheduler reports an active GPU workload, training runs are supposed to be hot

No model training, no feature store, no external inference service. The computation runs inside the platform process against the telemetry it already holds.

Asset health score

Every asset carries a 0–100 score and a letter grade, sortable in the inventory and aggregated per account on the geographic map.

ComponentMax penalty
Active alarm burden (P1×20, P2×10, P3×5, P4×2)50
Open anomaly alarms (10 each)30
Telemetry availability gap over 24h20
Peer percentile against same-type assets15
A
90–100
Healthy
B
75–89
Monitor
C
60–74
Investigate
D
45–59
Act
F
0–44
Critical
04, Intelligence

Analytics that answer operational questions, not dashboard questions.

Predictive maintenance

Regression trend on any metric over a 1–365 day lookback, projecting time to threshold for battery degradation, bearing wear and capacitor aging.

Energy efficiency

A PUE proxy from IT power against facility power, baseline versus current, with configurable buckets.

Alarm noise analysis

Identifies over-sensitive rules, those whose firings mostly end in a rapid clear or shelve, and proposes threshold or deadband changes.

Cascade risk

Traverses the relationship graph to surface single points of failure, upstream equipment feeding many downstream assets.

Thermal correlation

A correlation matrix across temperature metrics that identifies thermally coupled assets you did not know were coupled.

Root cause groups

Temporal clustering of alarms inside sixty-second windows, surfacing the likely cause from co-occurring patterns.

Rack power / temperature

Where power changes predictably drive thermal events, so capacity decisions can be made per rack.

Cooling setpoint deviation

Supply and return variance against setpoint over a configurable window, the first sign of a plant losing ground.

Generator readiness

Fuel trending and a readiness score from last test run, fuel level and coolant temperature.

GPU and HPC intelligence

PTLA: thermal risk scored before the event, not after it.

Predicted Thermal Load Accumulation answers one question: how likely is this rack to hit a cooling-driven thermal event inside the prediction horizon? It combines what is queued, how much headroom the GPUs have left, and how slowly this rack's cooling actually responds.

PTLA = WQP × (1 − DOH) × (IRL ÷ H)
WQPWorkload queue pressure. Normalised pending job count and estimated dispatch time, demand about to land.
DOHDevice operational headroom. Current GPU temperature as a fraction of the TDP-derived thermal ceiling.
IRLInfrastructure response latency. Measured from a real load step of 500 W or more; a conservative 120 s default at steady state, badged in the UI so operators know which they are reading.
HPrediction horizon. Configurable look-ahead, five minutes by default.
Below 0.4 nominal 0.4–0.7 elevated, monitor 0.7 and above, pre-cool now
Ten cards, drag-and-drop, persisted per operator
PTLA gauge
Cluster temperature
GPU utilisation
GPU power draw
ECC error rate
Thermal efficiency ratio
DCGM health
Workload power correlation
GPU / air DOH breakdown
Workload queue depth
05, Onboarding

A fleet arrives as a spreadsheet. It should not arrive as a data-entry project.

Upload, match, review, promote. Every promoted asset satisfies the catalog integrity constraints enforced in the database, so the registry stays clean at the point of entry rather than being cleaned up later.

STEP 01
Upload

Excel or CSV. More than fifty column header aliases are recognised per field; blank rows are dropped.

STEP 02
Fuzzy match

Manufacturer, model, asset type, protocol and full location path matched against the catalog with a confidence score.

STEP 03
Triage

Rows land as ready, needs review, awaiting catalog or error. Confidence is shown per field, not per row.

STEP 04
Resolve

Override free text or pick from the catalog and location tree. A resolution propagates to every row with the same raw value.

STEP 05
Promote

Ready rows become live assets. The location's account determines ownership; unresolved catalog rows cannot pass.

Configure once, inherit everywhere

The catalog is a three-tier product hierarchy, and protocol maps inherit down it. Define a register map at the product family level and every device of that type picks it up, with per-device overrides still available for the exceptions.

Manufacturer
Product family
Asset model : 37 hardware spec columns
Asset : specs inherited on creation

Integrity enforced at the database

Check constraints require a catalog reference whenever a manufacturer, model or asset type string is stored.
Trigram indexes and an insert trigger block near-duplicate manufacturers, so "Cisco", "Ciscco" and "Cisco Systems" cannot coexist.
Auto-resolution at the API layer keeps the constraints invisible during normal operation.
Power, capacity, physical, UPS topology, GPU and environmental specs populate once in the catalog and flow to every asset of that model.
06, Integration and deployment

It has to fit the pipeline you already run.

Every state change, five ways out

ChannelTypical consumer
Kafka topicsSIEM ingestion, observability, audit archival
Server-sent eventsLive dashboards and wall displays
Signed webhooks (HMAC-SHA256)ITSM and incident tooling, chat, custom endpoints
Redfish EventServiceExisting Redfish-compliant management tools
REST pollingScheduled reporting and audit pipelines

Webhook delivery is tracked per event and per destination with retry, so an integration can be audited rather than assumed.

Deploy where your data has to live

On-premisesYour Linux host or VM, container stack included. The default posture for sovereignty requirements.
Private cloudYour cloud account, your network policy, managed database and cache tiers where you prefer them.
Scaling pathSingle node for lab and small production; split API, poller and alarm tiers as asset count grows. The Redis sorted-set scheduler is already the foundation for distributed polling.
Proof of conceptSimulators for all nine protocols mean the first thirty days need no lab hardware and no change window.
Stack
PostgreSQL 17 + TimescaleDBRedis 7Apache KafkaEclipse MosquittoApache APISIXPython 3.11 asyncReact 18 + TypeScriptGrafana · Loki

Bring your NOC leads. The alarm discipline is what they will judge.

Request a briefing
Silver Ridge Group LLC · Irvine, California
+1 714-381-7883