OEM Compatibility Packs
OEM compatibility packs let Xolver work with existing robot controllers while keeping the core runtime OEM-agnostic.
What A Pack Provides
A compatibility pack captures the controller-facing behavior needed for a specific robot family or integration path. It does not change the model, safety layer, or runtime contract. Instead, it sits below the bounded execution boundary and translates validated intent into the shape expected by the target controller.
- Controller profile
- Communication expectations
- Supported control modes
- Timing assumptions
- Adapter readiness checks
- Safety-state handling
- Commissioning requirements
- Evidence expectations
- Live-operation blockers
Not A Safety Bypass
The pack is not a bypass around safety. Every hardware-facing path still passes through Xolver's contract, safety, watchdog, evidence, and approval gates.
Current Direction
KUKA RSI bench workflows are the first active retrofit path.
Additional OEM pack profiles are being prepared for proof-of-concept validation across major industrial robot families. These profiles are designed to reuse the same commissioning, preview, readiness, and evidence surfaces rather than creating one-off integrations.
Why This Matters
Most factories already have working robots. The challenge is not replacing every controller. The challenge is adding adaptive intelligence while preserving control boundaries, safety expectations, and operator trust.
OEM compatibility packs let Xolver meet existing cells where they are.
FAQ
Does an OEM compatibility pack replace the robot controller?
No. A pack defines controller-facing behavior for an integration path. It lets Xolver translate validated intent into the shape expected by the target controller while preserving the existing automation stack.
Can an OEM pack bypass runtime safety gates?
No. Hardware-facing behavior still passes through runtime contracts, safety shields, watchdogs, evidence requirements, and operator approval gates.
Which OEM path is active first?
KUKA RSI bench workflows are the first active retrofit path. Additional profiles are being prepared for proof-of-concept validation across major industrial robot families.
Why keep OEM logic in packs instead of the core runtime?
Keeping controller-specific behavior in packs lets the core runtime remain OEM-agnostic while still supporting commissioning, preview, readiness, and evidence surfaces for specific robot families.