How HYDRA OS works

Platform · Polestar Technology · Last reviewed 2026-08-21

HYDRA OS is an AI operating system built by Polestar Technology for PEM, AWE and SOEC water electrolyzers. It runs as a physics-informed digital twin alongside the physical stack. This page is the technical account of what that means: how a recommendation is produced, what produces it, how it connects to your plant, and the two ways it gets deployed.

Every recommendation carries its own reasoning

HYDRA OS attaches a Shapley value trace to every optimization recommendation — a per-input attribution showing how much each measured variable contributed to the decision and in which direction. Shapley values come from cooperative game theory: they distribute credit across inputs additively and independent of ordering, so the individual contributions sum exactly to the gap between the recommendation and the baseline. Nothing is left in an unexplained residual.

This is the difference between a system that tells an operator to lower current density and a system that can show that the recommendation was driven 61% by a rising cell-voltage divergence in cells 12–14, 24% by inlet temperature drift, and 15% by the degradation penalty term — and that the same recommendation would not have been issued had the divergence been absent.

Illustrative Shapley attribution for a single recommendation
InputContributionDirectionWhat it means
Cell voltage divergence (cells 12–14)61%Toward reducing loadLocalised degradation the stack average does not show
Inlet water temperature drift24%Toward reducing loadThermal management drifting off its setpoint band
Degradation penalty term15%Toward reducing loadLifetime-aware control trading output for stack life
Everything else<1%Pressure, flow and ambient terms, not material here

The structure above is illustrative of the format, not a customer result. What matters is that the format exists at all: an independent technical advisor reviewing an operating record needs to be able to interrogate individual decisions, not just accept an aggregate performance claim.

An ensemble, not a model

HYDRA OS runs an ensemble of more than 20 machine learning and optimization algorithms, deliberately rather than as accumulation. Monitoring, fault diagnosis, control and design search are structurally different problems; forcing them through one architecture degrades all four. Every suggestion any component produces is constrained by thermodynamic and electrochemical physics before it reaches an operator.

MethodProblem it solvesSwarm layer
Fuzzy Reinforcement LearningLifetime-aware control: learns setpoint policies that penalize degradation, trading instantaneous efficiency for stack lifePrediction / control
Recurrent Neural NetworksDegradation trend forecasting over sequential telemetry, where the order of events carries the signalPrediction
Kalman FiltersState estimation against noisy and partially observed sensors; separates true drift from measurement noiseValidation
PCA-SVM pipelinesCell voltage fault classification — flooding, drying, cell reversal — from high-dimensional CVM signalsValidation
Bayesian OptimizationCatalyst composition screening across a high-dimensional space where each evaluation is expensivePhysics / materials
Genetic AlgorithmsFlow field and bipolar plate geometry search, where the objective surface is non-convex and discontinuousPhysics / design

These six are the named components; the balance of the ensemble is surrogate models, statistical baselines and consensus logic. The 100-agent swarm architecture is how their outputs are reconciled: no alert is issued until at least 80% of the agents that examined the evidence agree.

What it connects to

HYDRA OS integrates over Modbus, OPC-UA, MQTT or REST, reading telemetry an existing SCADA system or historian already produces. There is no modification to the stack, the catalyst layers or the bipolar plates — integration is entirely on the data side. Typical commissioning takes 2 to 4 weeks.

SignalRequirementWhy
Stack voltage and currentRequiredThe baseline for every degradation calculation
Inlet / outlet water temperatureRequiredCorrects measurements to a reference condition; drives thermal models
Water flow rateRequiredMass balance and transport-loss estimation
Gas pressures (cathode / anode)RequiredCrossover modelling and pressure correction
Cell voltage monitoring (CVM)Strongly recommendedResolves degradation to the individual cell, which the stack average hides
Periodic impedance spectra (EIS)OptionalSeparates ohmic, kinetic and mass-transport losses so a trend can be attributed to a mechanism

Deployment is on-premise. Sensor data and model inference both run locally on standard industrial compute; no plant telemetry leaves the site by default. This is why the Physics Engine database ships with the deployment rather than being queried remotely.

Two deployment models

HYDRA OS is delivered either embedded — inside an electrolyzer before it ships — or as a software overlay on stacks already running in the field. These serve different customers and produce different value, and which one applies is usually obvious within one conversation.

For electrolyzer manufacturers

Embedded

HYDRA OS ships inside the electrolyzer through an OEM partnership. The stack arrives at site with degradation forecasting and lifetime-aware control already in it, so the manufacturer can offer predictive warranty terms rather than actuarial ones. The second effect matters more over time: the OEM starts accumulating real degradation data across its own installed base, which is what compresses the next hardware design cycle.

For producers, IPPs and asset owners

Software overlay

HYDRA OS is added to electrolyzers already operating, reading the telemetry the plant already generates. No hardware is touched, no downtime is required, and it runs alongside the existing monitoring rather than replacing it. This is the path for a fleet that was commissioned before anyone was thinking about auditable operational evidence — which is most of the installed base.

What lifetime extension is worth

A stack gets replaced when its cell voltage rise crosses the point where continued operation costs more than replacement. Lifetime-aware control slows that rise, which pushes the crossing later. The 30–40% service life extension HYDRA OS targets corresponds to deferring capital replacement by roughly 2 to 4 years on a typical duty cycle — and a deferred capital cost, discounted, is a smaller capital cost.

That deferral is also the term most often missing from a project's own financial model. A constant-efficiency LCOH calculation schedules no replacement at all, which is why the degradation-adjusted LCOH tool exists: at its default 10 MW case, a 3 µV/h degradation rate moves levelized cost from $4.61/kg to $5.06/kg and inserts a stack replacement in year 12 that the naive model never sees.

These figures are engineering targets derived from physics models, not measured results from a deployed customer fleet. Field-validated numbers will be published when the Founding Pilot Cohort completes. The basis for each figure is published with its baseline so the arithmetic can be checked rather than taken on trust.

Questions

How does HYDRA OS explain its recommendations?

Every optimization recommendation carries a Shapley value trace: a per-input attribution showing how much each measured variable contributed to the decision, and in which direction. Shapley values come from cooperative game theory and distribute credit across inputs in a way that is additive and order-independent, so the contributions sum to the difference between the recommendation and the baseline. For an operator this answers "why this setpoint"; for a lender's technical advisor it turns a model output into an auditable record.

What algorithms does HYDRA OS use?

An ensemble of more than 20 machine learning and optimization algorithms rather than one model. The named components include Fuzzy Reinforcement Learning for lifetime-aware control, Recurrent Neural Networks for degradation trend forecasting, Genetic Algorithms for flow field and stack design search, Bayesian Optimization for catalyst composition screening, PCA-SVM pipelines for cell voltage fault classification, and Kalman Filters for state estimation against noisy sensor data. Every suggestion any of them produces is constrained by thermodynamic and electrochemical physics before it is issued.

Which industrial protocols does HYDRA OS integrate with?

Modbus, OPC-UA, MQTT and REST. No modification to the stack, catalyst layers or bipolar plates is required — integration is purely on the data side, against telemetry an existing SCADA or historian already produces. Typical commissioning takes 2 to 4 weeks.

Can HYDRA OS be embedded by an electrolyzer manufacturer?

Yes. There are two deployment models. Embedded: an OEM ships HYDRA OS inside the electrolyzer, so the stack arrives at site with degradation forecasting and lifetime-aware control already in it, and the manufacturer gains field degradation data across its installed base. Software overlay: HYDRA OS is added to electrolyzers already operating in the field, reading existing telemetry without touching the hardware.

How does extending stack life defer capital expenditure?

A stack is replaced when its cell voltage rise crosses the threshold at which continued operation costs more than replacement. Lifetime-aware control trades a small amount of instantaneous efficiency to slow that voltage rise, which pushes the crossing point later. The 30–40% service life extension HYDRA OS targets corresponds to deferring capital replacement by roughly 2 to 4 years on a typical duty cycle. These are engineering targets from physics models, not measured customer results.

Does HYDRA OS send plant data to the cloud?

No. Deployment is on-premise: sensor data and model inference both run locally on standard industrial compute, and no plant telemetry leaves the site by default. This is a requirement rather than a preference for most industrial operators, and it is also why the Physics Engine database ships with the deployment instead of being queried remotely.