Edge device
Read, buffer, sign, transmit.
The adapter sits close to the vehicle, where timing, signal quality and identity matter. It should not be treated as a dumb modem.
Technology
The adapter is only the edge. The platform is the product.
OTP Adapter 2 reads and buffers vehicle signals. The OTP backend turns them into controlled, permissioned data products for fleets, insurers, service networks and mobility applications.
Adapter to backend
Vehicle data becomes usable only after identity, buffering and permission handling.
OTP Adapter 2
Built on WingMan Pro EVO. Repositioned as a vehicle-data gateway.
WingMan Pro EVO provides the hardware heritage: embedded device, sensor context, connectivity and field experience. OTP Adapter 2 defines the platform role: a controlled edge gateway between the vehicle and authorized products.
OBD II and supported vehicle signals
Retrofit access starts at the OBD II interface and can be enriched by supported CAN, GPS, motion and trip context.
Works without a phone babysitting it
Local buffering and embedded logic support products that need reliable trip and vehicle-state capture.
Data path
Four layers, one controlled route.
OTP is designed so every integration has a clear place in the system. Vehicle data moves through identity, processing and permissions before it reaches an application.
VehicleOBD II, CAN, trip, location and supported manufacturer-specific signals.
Adapter 2Reads signals, timestamps events, buffers locally and prepares transmission.
OTP BackendRegisters devices, maps vehicle capabilities and validates application access.
ProductsFleet, insurance, logbook, service and mobility products consume permissioned APIs.
Backend
The backend is the trust layer.
OTP does not hand every partner raw access to a vehicle device. The backend manages adapter identity, vehicle identity, app identity and data permissions. That is what turns a device into a platform.
Request technical briefing
Permissions
Every product should get the data it needs. Nothing more.
A logbook, an insurance product and a fleet dashboard do not need the same cadence, depth or scope. OTP's model is built around controlled access instead of one giant data dump.
Device registryWhich adapter exists, where it belongs and whether it is trusted.
Vehicle registryWhich signals are available for this vehicle and product context.
Application registryWhich service may access which data, at which frequency.
API surfaceNormalized data streams for authorized product teams and partners.
Why it matters
A dongle sends data. A platform creates product leverage.
OTP Adapter 2 is valuable because it belongs to a larger architecture. Hardware, backend and permissions are designed together, so each new use case can reuse the same vehicle-data foundation.
Field proof
RideLink validates the platform with real mobility use cases.
OTP is owned by RideLink and shaped by actual connected products, not only by a technical architecture diagram.
One hardware path for multiple services
Partners should not need a new device for every product concept.
API access instead of device chaos
Products integrate with the platform layer, not directly with raw vehicle hardware.
Need the technical deep dive?
RideLink can walk through OTP Adapter 2, backend permissions, data models and integration options for your specific product.