Single acquisition-to-I/O path
Detection and output live on one device, rather than an architecture where acquisition and logic are separate devices requiring a network round trip. Verified against the specific competitor before we name one.
High-speed spindles · compressors · turbines
Trip the machine before damage happens — deterministically, locally
Real-time threshold detection tied directly to physical I/O over EtherCAT, with no dependency on cloud connectivity.
0network hops between detection and output
Built for the controls and safety engineer
The challenge
Built for the controls and safety engineer.
- High-speed spindles, compressors and turbines can go from fine to damaged in milliseconds during an overspeed or shock event.
- Systems where acquisition and control logic live on separate devices or networks introduce latency and extra failure points in the protection path.
- Cloud-dependent alerting is unacceptable for time-critical protection.
How the system solves it
Only the capabilities that apply to this use case.
- 01
High-g sensor
IEPE · shock · overspeed in ms
- 02
EtherCAT DC
Deterministic cycle · synced channels
- 03
Inline detect
RMS / Kurtosis threshold on runtime
- 04
Physical trip
Relay · tower light · interlock — 0 hops
Cloud not in the protection path · TwinSAFE certifiable on same segment
- Detect and act on one runtime
- RMS, Peak and Kurtosis thresholds are evaluated on the same EtherCAT-connected runtime that drives the physical outputs — no network hop between detect and act.
- Deterministic EtherCAT
- Consistent cycle timing, with Distributed Clocks keeping multi-channel comparisons valid across the segment.
- Safety-capable architecture
- Built on standard Beckhoff control hardware, so certified safety I/O such as TwinSAFE can be designed into the same segment where a rated safety function is required. A SIL rating is stated only for a specific certified configuration.
- Diagnostics on the same box
- The protection loop and the full DSP/AI diagnostic stack share one runtime and one dataset.
Why it wins here
Architectural differences, not slogans.
Protection and diagnostics unified
One system both trips the interlock and keeps the raw waveform that explains why, instead of a protection rack plus a separate analysis tool.
Standard, long-lived control hardware
Beckhoff IPCs with 20+ year availability, not a proprietary monitoring chassis on a five-year obsolescence cycle.
Deployment path
Variant
Wired / TwinCAT-EtherCAT only
Hardware tier
Higher-tier IPC (C6030)
Why
Protection logic must run deterministically alongside DSP and AI when both are enabled, which needs top-tier headroom.
This use case does not fit the wireless variant. LoRaWAN latency and duty-cycle limits make it unsuitable for a protection path — deploy wired for machine protection.
Proof & validation
Measured latency, tested configuration
We publish the tested configuration, not a generic rating. The pilot measures alarm-to-relay latency end to end, and any safety claim is stated only for a specific certified TwinSAFE configuration.
Next step
Protection requirements deserve a conversation with an engineer rather than a self-serve demo.
Explore the other use cases
Rotating equipment PdM
Catch bearing failures weeks before they cause downtime
Read use caseRemote & hard-to-wire assets
Monitor equipment kilometers from the control room — without a wiring project
Read use caseMulti-site fleet standardization
One condition-monitoring platform, right-sized for every site in your fleet
Read use caseBrownfield retrofit
Add condition monitoring without ripping out what's already there
Read use case