Definition
OBD (On-Board Diagnostics, vehicle diagnostic interface) is the standardized diagnostic interface of vehicles, usually located below the driver's seat (OBD-II has a 16-pin connector). Through OBD, engine fault codes (DTC), fuel consumption, mileage, RPM, vehicle speed, coolant temperature, throttle position, and other data can be read. OBD-II is the North American standard, EOBD is the European standard, and China uses the national standard OBD (GB/T 32960, etc.).
OBD uses CAN bus or K-line communication, supporting protocols such as ISO 15765 and ISO 14230. Some vehicle models have restrictions on OBD data reading and require vehicle authorization or dedicated protocols.
Technical Features
The OBD box (OBD Dongle) draws power and reads data through the OBD interface, and uploads it to the cloud platform via 4G IoT SIM cards. It supports remote diagnostics, fault code clearing, driving behavior scoring, mileage statistics, fuel consumption analysis, and more. When combined with UBI car insurance, it can adjust premiums based on driving behavior. In car-sharing scenarios, the OBD is used for mileage billing and vehicle condition monitoring.
Use Cases
OBD is widely used in scenarios such as IoT for vehicles, UBI car insurance, fleet management, car-sharing, used car inspection, and remote diagnostics. The OBD box reads vehicle data through the OBD interface and uploads it to the cloud platform via IoT SIM cards. SimtoLink provides stable connectivity and dedicated APNs for OBD boxes, T-Box, and other in-vehicle devices, ensuring real-time transmission of vehicle data.
How the diagnostic session and the report stay separate
The IoT SIM on an OBD dongle does not carry a mirror of the vehicle bus. It carries the values the diagnostic session is allowed to read: fault codes, freeze frames, speed, engine speed, coolant temperature, odometer, or computed fuel figures. The two sides have different jobs. On the connector, the dongle requests and the vehicle answers, reading item by item under the diagnostic protocol that model supports. On the SIM, the dongle sends what it has already parsed, or a packet it has wrapped as-is. This works only when that model opens third-party reads, and when the ignition or vehicle power is in a state that allows a diagnostic session. Some models keep only a short session window after the engine stops. If the dongle keeps polling on a driving cycle, it gets an empty answer or the previous cache. That is not the current condition of the vehicle.
Unlike an on-board unit, OBD does not carry vehicle-to-vehicle safety messages, and it does not replace the vehicle's own remote terminal. It fits aftermarket fleets, shared cars, and cases that need generic fault codes. Whether the data can support mileage billing or driving-behavior analysis depends on whether the identifiers read are standard or vendor-specific. Converting a vendor identifier into fuel use without checking it on that model shifts the platform curve as a whole. The report rate should follow the ignition cycle, not a one-second heartbeat: denser while driving, and after parking only fault-code changes and the engine-off event.
Constant power misreads a stopped engine
The most common mistake is to power the dongle from a constant pin on the diagnostic connector. The link stays online, and the platform records the vehicle as never switched off. On many vehicles those power pins do not follow the ignition switch. SIM attachment and a valid diagnostic session are two different facts. Watch engine speed or ignition state together, not only whether the SIM is online. Another mistake is to clear a fault code as soon as it is read at the far end. Clearing wipes the freeze frame. The repair has not started, and a later read on site no longer has the conditions at the time. Only a platform note that "it was reported once" remains.
The wrong protocol looks the same as "network up, no data." The dongle uses the wrong session mode, the request gets no answer, the SIM stays attached, and traffic is near zero or only a heartbeat. Changing the data plan does nothing. Confirm the model year and the diagnostic protocol first. If a shared-car charge uses only the mileage the dongle computes, also stop a counter that freezes during sleep and then reports the whole gap at once, which gets booked as a burst of high speed. Acceptance should include one engine-off dwell: the SIM may stay attached, the platform must show not driving, and no new engine-speed samples may appear.
A stopped engine should not produce new RPM samples
Switch the vehicle off and leave it. The SIM may stay attached, but the platform must not add engine speed, road speed, or "driving" samples. If the odometer still jumps during the dwell, the dongle is usually reporting the difference across sleep in one shot. Spread that increment over real time, or drop the false delta. A fault code may keep the last read after the engine stops, but the read time must be shown. It must not look as if the fault just happened again. Clearing a fault code must record who did it. The reporting program must not clear codes on its own.
When the car or the dongle changes, the last message from the old car must not be written onto the new one. The binding is the VIN, the dongle, and the SIM together. Changing only the SIM joins two vehicles' fuel curves into one. A car whose protocol does not match should show "diagnostic session could not be opened," not a fill of zeros. OBD data on that SIM is usable only after the engine-off dwell, a rebind, and one real fault-code read.