One of the most common complaints we hear from developers starting on DIMO is some version of this:

"I want to build a fleet app, but I only have one vehicle and don't have a DIMO device. I don't want to drive around every time I need to test a webhook."

That's a reasonable problem. Telemetry-driven development is inherently hardware-dependent — or it was, until you have a simulator.

The DIMO Vehicle Simulator lets you spin up a fully connected virtual vehicle from the Developer Console, generate realistic driving signals, and exercise every part of the DIMO stack — identity, permissions, telemetry, webhooks, agents — without touching a physical car.

Here's how we built it, what it can do today, and where we're taking it next.

🏗️ Architecture: keeping it honest​

The simulator isn't a mock. That's the key design decision.

A mocked vehicle would short-circuit the stack — you'd test against stubbed data and discover production bugs at the worst possible time. Instead, we built the simulator to behave exactly like a real connected vehicle: it holds a vehicle identity on-chain, it goes through the same SACD permission grant flow, and it emits signals through the same telemetry pipeline everything else uses.

From an API perspective, there's no "simulator mode." Your application code is identical whether it's talking to a Tesla or a virtual Civic.

The three layers:

1. 🔑 Identity layer — Each simulated vehicle is a real digital ID minted to your developer wallet. It has an on-chain identity, a token ID, and all the same permission semantics as a physical vehicle. You own it, you grant access to it, you revoke it. Same primitives.

2. 📡 Signal emitter — A backend service generates telemetry payloads on a configurable cadence. Signals are modeled against real OBD-II and OEM data shapes — we didn't invent our own schema. This means your application code works against real signal definitions from day one.

3. 🗺️ Routing engine — The simulator traces a pre-recorded GPS route and advances the vehicle along it over time. Speed varies by road type and segment. The walker slows for sharp turns, stops at traffic lights with realistic dwell times, and reverses direction at the end of a route — so it keeps driving indefinitely without needing route management. Location, speed, and all derived signals update every tick.

Everything flows through the same telemetry ingest, signal normalization, and data API stack that physical vehicles use. No special cases. No simulator flags.

📊 Current signals and capabilities​

The simulator emits 13 signals per tick, all using real DIMO/VSS signal names — the same names you'd see from a physical vehicle:

The simulator runs a daily schedule across four routes based on real NYC/NJ roads:

All signals flow into the Telemetry API in real time. You can query historical signal data via our Telemetry API, subscribe to live updates, or let them trigger webhooks and agentic workflows — same as any physical vehicle on the DIMO network.

🛠️ Creating your first simulated vehicle: a walkthrough​

Here's the full experience, start to finish.

Step 1: Log in to the Developer Console

Head to console.dimo.org and sign in. The console uses Login with DIMO — the same authentication flow your end users will experience. You'll authenticate with a passkey or wallet, and you land in your developer dashboard.

If you don't have a developer account yet, you can register one directly from the console. Getting a license takes a few minutes.

Step 2: Create a simulated vehicle

From your dashboard, navigate to Vehicles → Add Vehicle → Simulator. Give it a name, pick a make/model (we have a growing catalog), and confirm. The console mints a digital ID to your developer wallet on the DIMO Network. You now have a vehicle with a real on-chain identity.

Step 3: Grant data access

This is where you experience exactly what your users will experience. The console walks you through a SACD permission grant — you're selecting what data scopes to allow (location, telemetry, trips, etc.) and signing the grant with your wallet.

This is the same flow a user goes through when they connect a vehicle to your app via Login with DIMO. Building with the simulator means you understand the permission model before your users hit it.

Step 4: Configure and start a drive

The simulator gives you control over the vehicle parameters before you start. Set the initial fuel level, odometer, and which route to run — then hit Start Simulation and the vehicle comes online.

The routing engine begins advancing the vehicle along the selected route. You'll see signals appear in the Telemetry API within seconds. You can also open the GraphQL playground directly from the console and query your vehicle's live data — speed, location, engine coolant temp — as it updates in real time.

Step 5: Build against it

From here, the simulator is just a DIMO vehicle. Use the Server SDK, the Client SDK, or raw API calls — it all works the same. Your application receives telemetry streams and permission grants identically to a physical vehicle.

The mobile app experience works too: if you install the DIMO mobile app and import your developer account, your simulated vehicles appear alongside real ones. You can see the telemetry, view trip history, and verify the end-user experience of any feature you're building — all from a virtual vehicle.

🔭 What's coming next​

The current simulator is solid for development and integration testing. Here's where we might be investing next:

🗺️ Better routes — The current four routes cover NYC/NJ road types well but are limited in variety. We want to add more cities, more traffic patterns, and eventually dynamic route generation: give it an origin and destination and the routing engine builds the path from OSRM without needing a hand-crafted JSON file.

🛣️ Longer routes — The longest route today is 32 km (the I-95 segment). We want to support full interstate drives — multi-state, multi-hour sessions — which is what you need to test long-distance trip modeling, EV range estimation, and fleet utilization analytics.

⚡ More signals — The current signal set is ICE-focused. EV-specific signals (state of charge, charging status, target charge level, estimated range) are the top request. Beyond that: HVAC state, door/window state, seatbelt status, and headlight/wiper signals. Anything a well-integrated physical vehicle would expose, the simulator should be able to generate.

🔧 Fault injection — Deliberately emit bad data, drop signals, or simulate sensor edge cases — stale GPS mid-trip, fuel sensor stuck at a fixed value, RPM spiking on engine start. Resilient applications need to be tested against the real tail of production data, not just the happy path.

🚛 Multi-vehicle scenarios — Spin up a fleet of simulated vehicles running concurrently, each on its own route and schedule. Useful for testing aggregated telemetry queries, fleet dashboards, and event fan-out at scale.

Let us know what features you'd like to see in the vehicle simulator.

💡 Why it matters​

The goal isn't simulation for its own sake. It's reducing the time between "I have an idea" and "I've shipped something real."

Waiting on hardware, managing access to physical test vehicles, coordinating drives to generate test data — these are all friction points that slow down good developers. The simulator removes them.

More importantly, it lets you test the full DIMO integration: identity, permissions, telemetry, and event flows — not just the data layer. If you're building on DIMO, you want confidence that the permission grant flow your users will see works correctly, that your webhooks fire when they should, and that your app handles the edge cases in telemetry.

The simulator gives you that confidence without a parking lot.

🚀 Get started​

• Developer Console — create your simulated vehicle
• Server SDK — query telemetry and manage vehicles from your backend
• Client SDK — add Login with DIMO and vehicle connections to your frontend
• Telemetry API — real-time and historical signal access
• Webhooks — subscribe to vehicle events

The best way to understand DIMO's permission model is to go through it yourself. The simulator is the fastest path to that.

On January 14, the FTC finalized a 20-year order against General Motors for selling driver data without proper consent. Five days later, Lemonade announced 50% insurance discounts for Tesla drivers who share their FSD telemetry data.

The contradiction is stark:

• OEMs can't share data (massive liability risk)
• Customers want to share data (hundreds in annual savings)
• Insurance companies need data (to price risk accurately)

Here's what the GM settlement actually means:​

The FTC found that GM "monitored and sold people's precise geolocation data and driver behavior information, sometimes as often as every three seconds" through its OnStar Smart Driver program. The result? A 20-year consent order requiring "affirmative express consent" before collecting or sharing any connected vehicle data.

Source: https://www.ftc.gov/news-events/news/press-releases/2026/01/ftc-finalizes-order-settling-allegations-gm-onstar-collected-sold-geolocation-data-without-consumers

Meanwhile, the insurance economics are already in motion:​

Lemonade just launched "Autonomous Car Insurance" with 50% rate cuts for Tesla drivers using Full Self-Driving. How? Direct access to Tesla's onboard computer data. Lemonade Co-Founder Shai Wininger said:

By connecting to the Tesla onboard computer, our models are able to ingest incredibly nuanced sensor data that lets us price our insurance with higher precision. Source: https://finance.yahoo.com/news/lemonade-halve-tesla-insurance-rates-133146153.html

The impossible position for traditional OEMs:​

Ford Motor Company, Stellantis , Toyota Motor Corporation, Honda — none of you can do what Tesla does. You don't own insurance companies. You can't be data brokers (the FTC just proved that). But your customers will demand access to their data when it means $800-1,200 in annual insurance savings.

Building consent management infrastructure in-house? That's a multi-year, multi-million dollar compliance project with ongoing legal liability.

This is exactly why we built DIMO protocol.

As a 2026 MotorTrend Group SDV Award finalist alongside Tesla, Ford, GM, and Mercedes-Benz, we've already solved the infrastructure problem that just cost GM a 20-year FTC order.

DIMO isn't a data broker. We're open-source consent management infrastructure helps remove OEM liability.

Article content How DIMO solves the consent problem How DIMO works in practice:

When a customer wants that 50% Lemonade discount:

1. Customer logs into their account
2. Customer grants permission to Lemonade via our consent system
3. Lemonade queries authorized telemetry data via our APIs
4. OEM provisions data access safely — never touches the liability

The OEM never becomes a data broker. The customer controls permissions. The insurer gets compliant access. Everyone stays FTC-clean. Win-win-win situation :)

Why open-source matters here:​

Proprietary consent systems create trust problems. Customers don't trust OEMs, 3rd parties don't trust black boxes. Here's why we built it on open-source:

1. Open protocol = auditable and independently verifiable
2. Every permission grant verified
3. Every data access logged
4. Zero hidden data sales

The market forcing function is already here:​

• Insurance companies will offer data-driven discounts (economics demand it)
• Customers will demand data access (FTC gives them this right)
• OEMs need infrastructure that scales without liability (GM proves the alternative)

Tesla solved this by vertically integrating everything. However, that's not an option for the rest of the industry.

The technical stack we're using:​

• EIP-4337 (Account Abstraction) for seamless account UX
• SACD (Service Access Contract Definitions) for granular permissions
• GraphQL APIs for real-time telemetry queries
• Cryptographically signed audit trails for compliance verification

All open-source. All interoperable. All designed for an industry that needs neutral infrastructure, not another walled garden.

Here's what I believe will happen next:​

The next year or so will separate OEMs into three categories:

1. Pioneers who adopt open consent protocols and enable customer data rights safely
2. Fast followers who scramble to build compliant infrastructure after the next headline
3. The GM category — compliance orders, class action lawsuits, customer trust erosion

The FTC ruling isn't an isolated incident, it's a preview of what happens when OEMs try to be data brokers instead of adopting proper consent infrastructure.

If you're working on automotive data governance and compliance, insurance telematics product development, fleet management data systems, or OEM connected vehicle architecture - we should talk.

The consent management problem isn't going away — and building it in-house means taking on liability that just cost GM 20 years of regulatory oversight.

DIMO provides the neutral infrastructure layer that protects OEMs, empowers customers, and enables the consumer economy ecosystem.

Learn more about our protocol: https://dimo.org

The future isn't OEM walled gardens competing on data access.​

It's open protocols where customers control permissions, OEMs provision safely, third parties access compliantly, and everyone operates transparently.

We're building that infrastructure layer. And we need you to help spread the word.