You decoded this truck's CAN bus first. How long will that edge last?

You're deciding whether another reverse-engineering sprint on a new truck configuration will pay back before the adapter vendor catches up. A GPS terminal needs a CAN profile to read RPM, fuel consumption, and other parameters: which messages carry which fields, which bytes to read, which conversion factors to apply. Without documentation from the vehicle manufacturer, engineers build that profile by reverse engineering the bus. While you're the only one who has it, you can bring that configuration online ahead of the competition.

That edge is temporary. CAN-adapter vendors are reverse-engineering the same trucks in parallel and rolling new entries into their own firmware. By our estimate, the window is typically six to eighteen months. For planning, use roughly a year: once the vendor includes the profile in a general release, providers using eligible adapter versions can receive it through a FOTA update.

The durable margin sits above the decoding step: normalizing the finished attributes, verifying the install, turning the numbers into service rules. The adapter decodes the CAN bus and hands finished parameters to the platform.

Why every truck configuration needs its own CAN profile

Key IoT, a Chinese gateway manufacturer, lays out a simple example: reading engine RPM off a FAW and off a Dongfeng means different CAN message IDs, different field positions in the frame, and different conversion factors — even though both are the same class of vehicle.

So engineers look for protocol documentation, and failing that, log bus traffic, change the parameter under test, and match the shifts to specific messages. The result is saved as a configuration file — a CAN profile — with no change to the adapter's own code. The accumulated library of these profiles is what a phrase like "we support this vehicle" actually rests on.

The adapter vendor runs the same process for its broader hardware base. Once the profile you needed becomes available in firmware for compatible adapters, your reverse engineering stops separating your service from a competitor running the same hardware.

Why a coverage roadmap can't be built by brand alone

The working unit of a coverage plan isn't the brand, and it isn't even the truck line — it's the vehicle configuration: chassis code, destination market, emissions class. Teltonika's CAN-adapter support lists show this directly: one European tractor family can carry around fifteen separate CAN profiles, split across generations and variants. A single catalog entry never equals "brand supported."

In practice, treating a proprietary CAN profile as durable is the planning mistake. The margin from that one configuration has to pay back the reverse-engineering cost before the same profile becomes available in general firmware.

The same value shift appears when vehicle data moves into an OEM cloud.

What gets commoditized when firmware updates

Getting and using CAN data splits cleanly into three layers.

Acquisition. The adapter or gateway decodes bus messages and returns finished values.

CAN profile. The decoding configuration for one specific vehicle configuration — adapter catalogs often list it as a program number.

Usage. Normalization, installation verification, and the rules that turn a vehicle's parameters into a decision, such as a service booking.

Once a profile becomes available in general firmware, acquisition and that shared catalog entry stop differentiating providers that use compatible hardware. Installation verification, normalization, and service rules remain provider-owned processes. That's the Decode Depreciation Curve: a proprietary CAN profile's value drops once broad support becomes available; the rules built on top of the data keep theirs.

How Navixy preserves margin after the firmware update

A CAN adapter or GPS terminal decodes the bus and hands the platform finished vehicle parameters. Navixy's work starts there.

Navixy Generic Protocol brings attributes from different terminals into one common format. When a device reports a packed numeric status word, IoT Logic can pull a specific flag from it with the bitwise function util:checkBit(...) — a PTO-engaged flag, for instance. The bit number comes from the device's own contract, and IoT Logic applies it to the numeric attribute the device sent. That single flag is enough to build a rule separating billable equipment use from idle time.

In Flow Inspector, an engineer verifying an install sees a device's raw attributes next to the scenario's computed attributes and checks them against the truck: engage the PTO, confirm the flag moved.

In practice, an engineering month spent on installation verification and normalization produces returns for longer than one spent on one more catalog entry. A proprietary CAN profile remains a way to bring a new configuration online faster; the durable margin comes from the rules already living in the platform.

Compare your reverse-engineering payback against the firmware date

Take one recently connected truck configuration where you're the only one with it today. Plan on a six-to-eighteen-month window before the same CAN profile becomes available in general firmware, using roughly a year as the working assumption. Work out the margin from projects on that configuration and weigh it against the cost of reverse engineering.

Then open Flow Inspector on that vehicle and check the rule in IoT Logic: which attributes arrive, which service rule fires on them, and whether the value visibly moves when the parameter changes on the truck. Use the result to define the post-update offer in operational terms: normalized attributes, a verified install, and a clear service rule. Those assets continue earning after the profile becomes common.