01
Sense
Read the live VFD, controller, and process state.
Quality-aware signals
TwinEdge DRIVE
Physical AI for variable-speed systems—without replacing the control layer.
TwinEdge DRIVE reads signals from supported VFD, PLC, and process connections, tests candidate operating moves against a physics twin, refuses action when data or limits cannot be trusted, routes approved changes through existing interlocks, and records the real outcome.
Read-only first
Physics-tested candidates
Hard-limit gates
PLC/VFD control path
Evidence before promotion
Fail closed on bad data
The intelligence above the VFD. The existing control system stays in charge.
The DRIVE operating model
Physical AI that works through the control system—not around it.
The control loop makes the authority boundary explicit: AI proposes, TwinEdge DRIVE governs, and the PLC or DCS retains the deterministic logic and interlocks that execute an approved move.
Bounded control loop
Interlocks activeController authoritative
02
Twin
Try the candidate move against asset and process physics.
No live write required
03
Govern
Refuse moves that fail data, limit, policy, or state checks.
Hard limits enforced
04
Act
Route an approved proposal through the existing controller.
PLC / DCS / VFD path
05
Prove
Compare the measured outcome with the approved intent.
Evidence before promotion
Authority path
AI proposesDRIVE governsPLC executes
Fail closed by design
Bad data, broken limits, or a rejected command stops the move.
Workflow
Sense → Twin → Govern → Act → Prove
Every candidate move follows one inspectable path. A failed data, physics, limit, approval, or controller check stops the move and records the reason.
1. Sense the real system
Build a quality-aware operating state from supported VFD and process signals such as speed, frequency, current, power, torque, flow, pressure, load, and controller state.
2. Test the candidate in the twin
Compare the current state with a candidate speed or setpoint using the configured drive, load, process, and asset physics. No live write is required to evaluate the proposal.
3. Govern with hard limits
Check freshness, quality, operating envelope, process limits, asset limits, action class, reversibility, approval policy, and the controller state before a move is eligible.
4. Route approved action
When the deployment permits action, DRIVE sends a signed, scoped proposal through the approved PLC, DCS, or VFD interface. Existing interlocks and protections remain authoritative.
5. Prove the real outcome
Record what was proposed, approved, attempted, accepted by the controller, and measured in the physical system. Use the result to improve the next proposal or revoke authority.
Capabilities
Where variable-speed Physical AI can create value
A good DRIVE use case has a material variable-speed load, trustworthy signals, a bounded controllable variable, explicit limits, and a measurable outcome. Support is validated for each asset, driver, model, and action class.
Variable-speed pumps
Evaluate flow or pressure demand against speed, power, suction/discharge pressure, valve state, the pump operating region, and configured cavitation and motor limits. Prove value as energy per volume moved and process stability.
Fans and blowers
Match airflow, pressure, or a process target while respecting minimum ventilation, process demand, equipment limits, and rate-of-change rules. Track useful airflow or process work, energy, and variability.
Compressors
Evaluate pressure-band and loading proposals only inside an engineered OEM and process envelope, including temperature, surge, sequencing, and demand constraints. Track specific energy and pressure stability.
Conveyors
Relate speed to material load, torque/current, upstream and downstream state, accumulation, slip, jam, throughput, and approved start/stop logic. Track energy per unit moved and throughput consistency.
Mixers
Test speed against torque/current, batch state, endpoint or quality measurements, recipe, shear, temperature, and minimum mixing requirements. Track energy per accepted batch, consistency, and cycle time.
Fit requirements
Confirm the VFD and controller interface, signal quality, baseline KPI, controllable action, physics model, operating envelope, owner, approval policy, rollback condition, and evidence needed for promotion.
Physics before action
A recommendation is not eligible just because a model produced it.
DRIVE treats the physics twin as an action gate. The proposal must make physical sense in the current operating state and remain inside the configured process, asset, controller, and policy boundaries.
Current-state confidence
Freshness, completeness, units, plausibility, operating mode, and source quality determine whether the current state is trustworthy enough to evaluate.
Candidate counterfactual
The twin estimates how the process and asset should respond to a bounded change, including the intended outcome, assumptions, and relevant uncertainty.
Configured operating envelope
Process limits, OEM constraints, motor and VFD limits, controller state, minimum/maximum demand, rates of change, and customer policy define the eligible region.
Reversibility and rollback
An approved action class needs a known reversal or safe step-down path. Unexpected controller or physical response freezes the sequence and records the exception.
Explainable refusal
Bad data, an invalid model state, a limit breach, missing approval, an unsafe operating state, or a controller rejection produces a reason—not a silent retry.
Controller authority
DRIVE remains supervisory. The PLC, DCS, VFD protections, safety PLC, and SIS keep their configured roles and can reject or override a proposal.
Earned authority
Start read-only. Advance one approved action class at a time.
Authority is promoted with evidence, not elapsed time. Every step has a named owner, eligible operating states, action range, validation threshold, and revocation rule.
Observe
Read supported signals, establish data quality, characterize operating states, and build a baseline without proposing or writing a change.
Advise
Show a bounded recommendation, expected outcome, assumptions, constraints, and refusal reasons for an operator or engineer to evaluate.
Shadow
Generate time-aligned proposals without sending them to the controller. Compare predicted outcomes with what the physical system actually did.
Supervised
Allow an authorized operator to approve a certified action class within its configured range, time window, operating state, and controller path.
Bounded
Permit only the separately approved action classes and operating envelopes that have passed the customer’s evidence and governance gates.
Freeze, revoke, or step down
Failed evidence, stale data, unexpected response, limit breach, policy change, model invalidation, or controller rejection returns the action path to a safer state.
Outcome proof ledger
Separate what was observed, modeled, approved, attempted, and measured.
A DRIVE outcome should be inspectable by an operator, controls engineer, energy manager, or auditor. Modeled projections remain labeled until the physical result is measured and normalized.
Baseline and context
Record the comparison window, demand, production or batch context, operating mode, data quality, and normalization factors.
Proposal and prediction
Record the candidate action, allowed range, twin version, assumptions, expected physical response, intended KPI change, and confidence.
Guardrail decision
Record every quality, physics, limit, action-class, time-window, approval, and controller-state check with its pass, refusal, or exception reason.
Approval and command receipt
Attribute the human or policy approval, signed command scope, idempotency or replay checks, controller response, and effective setpoint.
Measured outcome
Compare the real response with the prediction using the same process and asset context. Preserve deviations, alarms, overrides, and rollbacks.
Normalized value
Express energy as useful work where possible and adjust for demand, production, weather, batch, or another approved driver before calling a change an improvement.
Deployment path
Prove fit before expanding authority or asset coverage.
The recommended first engagement is deliberately narrow: one asset class, one measurable outcome, one controller path, and one governed action class.
1. Fit and signal review
Review the asset, VFD/PLC, available signals, sample rate, process objective, operating constraints, baseline KPI, controller interface, and change-management requirements.
2. Read-only baseline
Validate signal meaning and quality, calculate physics-aware KPIs, characterize operating states, and agree on the baseline and normalization method.
3. Shadow validation
Run candidates without live action, compare predictions with observed system behavior, challenge refusals, and tune the approved envelope.
4. Supervised action class
If approved, enable a narrow reversible action through the existing control path with explicit human approval, stop conditions, and rollback.
5. Evidence review
Review prediction accuracy, controller acceptance, physical outcome, normalized value, exceptions, and operator feedback before any promotion.
6. Bounded expansion
Add authority, action classes, operating states, assets, or sites only when each addition passes its own engineering and governance gate.
Typical inputs and boundaries
Use the signals and controls the site already trusts.
The exact set is deployment-specific. DRIVE begins with a signal and control contract rather than assuming every driver, tag, or asset has the same semantics.
VFD speedFrequencyCurrentPowerTorque or loadDrive statusPLC/DCS modeFlowPressureTemperatureProcess demandProduction contextOperating envelopeOEM limitsInterlocksApproval policyCommand receiptOutcome KPI
Engineering controls
Governed controls for Physical AI in operational environments.
DRIVE is designed to make a variable-speed control opportunity safer to evaluate and easier to audit—not to bypass deterministic controls or safety functions.
Read-only first
Baseline and shadow modes establish signal quality, model behavior, refusal reasons, and prediction evidence before a live action class is considered.
Fail closed
Stale or bad data, an invalid twin state, a limit breach, missing authority, or an unexpected response freezes the proposal path and records the reason.
Existing controls stay authoritative
PLC/DCS logic, VFD protections, interlocks, safety PLCs, SIS functions, and operator overrides keep their configured authority.
Evidence before promotion
Every authority step requires approved action scope, prediction and outcome evidence, owner sign-off, and a defined rollback or revocation condition.
Outcomes
Derived value, measured in the physical system
DRIVE focuses on the operating result rather than autonomy for its own sake. Outcomes remain site- and model-dependent and are verified against an approved baseline.
Less energy per useful work
Find better bounded operating points and evaluate energy against delivered flow, airflow, compressed volume, throughput, or accepted batch output—not only instantaneous kW.
Steadier operation
Reduce avoidable variation around approved pressure, flow, process, throughput, or quality targets while respecting the controller and operating envelope.
Lower equipment stress
Evaluate operating patterns that can contribute to avoidable starts, vibration, alarms, limit excursions, or off-design operation without promising a universal reliability gain.
More operator leverage
Give operators and engineers a tested proposal, assumptions, refusal reasons, approval state, and measured result instead of another unexplained optimization score.
Connected platform
DRIVE adds a governed supervisory layer to the stack already in place.
The product is designed for brownfield operations. It uses supported interfaces and preserves the role of the deterministic control and safety layers.
The VFD executes motor speed and retains its configured drive protections.
The PLC or DCS retains deterministic logic, sequencing, permissives, interlocks, modes, and operator overrides.
SCADA and historians remain operational sources and records; DRIVE adds quality-aware physics and decision evidence.
TwinEdge OS provides the local runtime, supported protocol access, storage, analytics, and governed command path where configured.
TwinEdge Platform can coordinate fleet context, review, evidence, analytics, and governance when the deployment permits connection.
Safety PLC and SIS functions remain authoritative and outside DRIVE’s optimization authority.
Frequently asked questions
Questions about TwinEdge DRIVE
Clear answers for buyers, operators, engineers, and evaluation teams.
What is TwinEdge DRIVE?
TwinEdge DRIVE is governed Physical AI for selected variable-speed industrial systems. It uses supported VFD, PLC, and process signals to evaluate bounded operating moves in a physics twin, applies data and limit gates, routes approved action through the existing control path where configured, and records the measured outcome.
Is TwinEdge DRIVE a VFD?
No. A VFD executes motor speed and drive protections. DRIVE sits above supported VFD and controller interfaces as a supervisory intelligence layer that evaluates and governs candidate operating points.
Does DRIVE replace a PLC, DCS, SCADA, safety PLC, or SIS?
No. The PLC or DCS retains deterministic logic and interlocks, SCADA retains its operator and supervisory role, the VFD retains drive protections, and safety PLC or SIS functions remain authoritative. DRIVE is not a safety controller or hard-real-time motion controller.
What signals does DRIVE use?
Depending on the validated asset and deployment, inputs can include speed, frequency, current, power, torque or load, drive state, controller mode, flow, pressure, temperature, process demand, production context, and operating limits. Signal semantics, units, freshness, quality, and adapter support are confirmed for the site.
How does the physics twin test a candidate move?
The twin compares the current operating state with a bounded candidate speed or setpoint, estimates the expected asset and process response, and checks the result against configured physical, process, OEM, controller, and policy limits before the proposal is eligible.
Does DRIVE write setpoints autonomously?
DRIVE starts read-only. Advice and shadow modes do not write a live setpoint. A supervised or bounded action is available only for a separately approved action class, range, operating state, controller path, evidence threshold, and rollback policy in a validated deployment.
What happens when data is stale, missing, or low quality?
The proposal is refused or frozen. DRIVE records which freshness, quality, plausibility, model-state, or source requirement failed so an operator or engineer can correct the condition rather than receiving a silent or uncontrolled retry.
How are energy and operational outcomes verified?
The outcome ledger compares an approved baseline with the candidate prediction, controller receipt, and measured physical response. Results should be normalized for demand, production, weather, batch, or another agreed driver, and modeled estimates remain labeled until validated.
Which variable-speed assets are a good fit?
Potential fits include selected pumps, fans, blowers, compressors, conveyors, and mixers with trustworthy signals, a bounded controllable variable, explicit limits, an authoritative controller path, and a measurable outcome. Exact driver, asset model, and action support must be validated for each deployment.
How does DRIVE move from read-only to bounded action?
It progresses through Observe, Advise, Shadow, Supervised, and Bounded modes. Promotion requires named evidence and owner approval for a specific action class; bad data, failed evidence, unexpected response, a limit breach, or a policy change can freeze, revoke, or step down authority.
Can DRIVE operate locally or during a cloud disconnection?
DRIVE is designed to run with TwinEdge OS close to equipment. The exact signals, models, evidence retention, and action behavior permitted during a disconnection are defined and validated in the customer deployment policy rather than assumed.
How is DRIVE different from predictive maintenance or advanced process control?
Predictive maintenance focuses on condition and future maintenance need. DRIVE focuses on a governed current operating move and its measured outcome. Advanced process control can address broader or more tightly engineered process optimization; DRIVE does not claim to replace every APC application.
Who this is not for / non-goals
- •Not a replacement for a PLC, DCS, VFD protection, safety PLC, SIS, or hard-real-time motion controller.
- •Not unbounded writeback, and not live action on stale, bad, missing, or physically invalid data.
- •Not a guaranteed savings, reliability, production, or asset-life percentage.
- •Not universal support for every VFD, PLC, protocol, driver, asset, model, or action class without validation.
- •Not a claim that a variable-speed drive inherently improves component efficiency; value depends on the physical system, operating point, and constraints.
- •Not a substitute for controls engineering, OEM requirements, process safety review, change management, or operator judgment.
See claims and boundaries and labeled proof.
Related for search and evaluation
TwinEdge OS edge runtime
Local protocol access, storage, analytics, and governed deployment close to equipment.
Industrial energy optimization
The broader solution for equipment efficiency context, waste findings, and reviewed action.
Physics-based analytics
First-principles equipment models, operating points, quality checks, and engineering context.
Pump station digital twin
A concrete variable-speed pump application with telemetry, energy, risk, and operational context.
Governed industrial AI
Approval, scope, evidence, and replay controls across the TwinEdge operating layer.
Claims and boundaries
Review how TwinEdge labels shipped, modeled, planned, and deployment-specific claims.
Evaluate TwinEdge
Find the first variable-speed action worth proving.
Bring one asset class, its VFD and controller path, available signals, operating limits, baseline KPI, and desired outcome. We will assess signal readiness, physics fit, proof method, and the safest starting authority level.