Introduction to two-Wheeler Architecture, electronic control units and telematics, for dummies.

Executive Summary

Every scooter — electric or petrol — breaks down into the same four systems: an energy source, a propulsion unit, a rider interface, and a chassis. EV and ICE differ only in the first two blocks (battery vs. fuel tank, motor vs. engine); the rider interface and chassis are essentially identical.

All vehicle electronics communicate over a shared internal network called the CAN bus — effectively a "group chat" where components like the motor controller and battery management system broadcast their status. A TCU (Telematics Control Unit) is simply a listener on this bus: it reads what's already being broadcast and relays it to the cloud over cellular, but never controls the vehicle. Real-time control stays entirely on-vehicle, handled by the ECU (ICE) or, on EVs, by three specialised units — VCU, MCU, and BMS — working together.

How much telematics data is actually available depends on integration, not vehicle type. A bolt-on aftermarket GPS tracker (like ICE fleets typically use today) sees very little — mostly just location and ignition status. A factory-fitted, CAN-integrated cluster (TVS's own SmartXonnect on the Ntorq, for example) can see nearly as much as an EV — engine RPM, temperature, throttle, fuel level. The technology to make ICE vehicles just as "connected" as EVs already exists and is already shipping.

So why do EVs get cellular TCUs by default while most ICE scooters don't? The gap is commercial, not technical. A cellular TCU carries a permanent recurring cost (modem hardware plus a monthly data plan) that has to be justified by someone willing to pay for it. EVs currently have stronger monetizable use cases — battery health monitoring, range/charging data, and a buyer base (often fleet or financed) with a direct financial reason to want always-on visibility. ICE scooters compete in a far more price-sensitive segment where that recurring cost is harder to absorb without a proven revenue stream to offset it.

1. Anatomy of a scooter: the four-block model

Whether electric or petrol, a scooter can be broken down into four functional systems. The two blocks that differ between EV and ICE are the energy source and the propulsion unit — the rider interface and chassis are essentially unchanged.

1.1 Electric scooter 

System	Components
Power system	Battery pack, Battery Management System (BMS), charging port
Drive system	Electric motor (hub or mid-drive), motor controller (MCU)
Rider interface	Throttle, brake levers, display / dashboard
Chassis & suspension	Frame, suspension, wheels & tires

1.2 ICE (petrol) scooter

System	Components
Fuel system	Fuel tank, fuel pump, carburetor or fuel injector
Engine & drivetrain	Combustion engine, CVT / transmission, exhaust
Rider interface	Throttle, brake levers, display / dashboard
Chassis & suspension	Frame, suspension, wheels & tires

1.3 Side-by-side contrast

Block	ICE scooter	EV scooter	What changed
Energy source	Fuel system: tank, pump, carburetor/injector	Power system: battery, BMS, charger port	Chemical energy in liquid fuel becomes electrochemical energy in cells; BMS is new — no ICE equivalent.
Propulsion	Engine & drivetrain: engine, CVT, exhaust	Drive system: motor, motor controller	Hundreds of moving parts collapse to essentially one (the rotor); no combustion byproducts, no CVT needed.
Rider interface	Throttle, brakes, display	Same, functionally	Mostly unchanged; EV display shows battery % / range instead of fuel gauge / RPM.
Chassis & suspension	Frame, suspension, wheels	Same	Unchanged, though EV frames accommodate battery pack weight/placement.

2. How the vehicle's electronics talk to each other

2.1 CAN bus

CAN (Controller Area Network) is the shared internal messaging system that lets a vehicle's electronic components talk to each other over one pair of wires, instead of needing a dedicated wire between every pair of components. Think of it as a group chat: every component (motor controller, BMS, display, TCU) broadcasts small labeled messages — e.g. ‘motor temp = 42°C’ — that any other component can read if it needs to. Originally a 1980s automotive standard (Bosch), it carried over into EVs and two-wheelers because it is cheap, reliable, and noise-resistant.

2.2 ECU vs. TCU

	ECU (Electronic Control Unit)	TCU (Telematics Control Unit)
Role	The vehicle's own brain — real-time control	A connectivity module — reports data outward
Reads	Local sensors (throttle, temp, current, speed)	Whatever the ECU/VCU is already broadcasting on CAN
Decides / acts	Yes — fuel injection, torque, fault handling	No — read-only listener, does not control anything
Needs the outside world?	No	Yes — SIM/cellular modem + GPS to reach the cloud

Relationship: the TCU is wired onto the same CAN bus the ECU already broadcasts on. The ECU does not send anything specifically for the TCU — it keeps broadcasting its normal operational messages for its own use (and for other listeners like the instrument cluster). The TCU is simply another listener that packages the relevant messages and pushes them over cellular to a backend.

2.3 EV control units: VCU, MCU, BMS

An EV typically splits the ICE ECU's job across three specialised controllers, all on the same CAN bus:

• VCU (Vehicle Control Unit): Top-level arbitration — arbitrates throttle input, braking, battery limits, and safety interlocks.

• MCU (Motor Control Unit / motor controller): Converts battery DC to the motor's drive waveform via the inverter and regulates torque/RPM based on throttle input.

• BMS (Battery Management System): Monitors cell voltage/temperature, balances charge across cells, enforces safety cutoffs. No ICE equivalent exists.

This is why the EV data set tends to be richer than ICE: instead of reading one ECU's view of the world, the TCU is reading three specialised controllers' views.

2.4 The full data path

Two loops run on the same CAN bus but serve very different purposes:

• Control loop: BMS + MCU + rider interface → VCU. Runs continuously, in milliseconds, entirely on the vehicle. Makes the scooter drivable and safe. Has nothing to do with connectivity.

• Telematics loop: VCU → TCU → cellular → cloud backend. Runs on a much slower cadence (seconds to minutes). Purely for visibility: fleet ops, billing, alerts, analytics. The TCU never controls anything — it is read-only on the bus.

The connectivity backend (e.g. a cloud platform such as P360) never touches vehicle safety-critical control — it is strictly a downstream consumer of what VCU/BMS/MCU are already doing.

4. Why EVs ship with cellular TCUs and ICE mostly doesn't

The Ntorq example proves the technical capability exists on ICE. The real gap is commercial: nobody has built a business case that justifies the recurring cost of an eSIM/modem on the ICE side.

• Who pays, and for what: BLE (used on Ntorq-style clusters) is essentially free at scale — a Bluetooth chip costs cents, and the ‘backend’ is the rider's own phone data plan. An eSIM TCU adds a permanent recurring cost (modem/antenna BOM plus a monthly data plan) that exists whether or not the rider uses any connected feature that month.

• Price sensitivity is asymmetric: ICE scooters compete in a brutally commoditized, high-volume segment where a small on-cost genuinely moves purchase decisions. EV buyers already pay a technology premium and expect ‘smart’ as part of the value proposition.

• The monetizable use cases are stronger on EV: Battery health/degradation monitoring carries real safety and warranty liability (thermal risk, insurance claims) with no ICE fuel-tank equivalent. Range anxiety drives EV riders to want live charging data; ICE riders don't have that problem. EV ownership skews more toward fleet/gig/financed use, where a financer or fleet operator has a direct commercial reason to pay for always-on tracking (asset recovery, usage-based financing risk).

• Platform economics: EVs are largely clean-sheet platforms today, so an eSIM TCU is one more line in a new BOM. ICE platforms like Ntorq are mature and cost-optimized over years — adding a new recurring cost line is a much harder internal sell without proven revenue offset.

Net: an eSIM-based TCU only becomes commercially rational once there is a monetization stream — insurance, fleet, financing — large enough to cover the recurring SIM cost. That is the same logic underlying the Connected Vehicle Services subscription model being piloted on EV 3W — and, if it proves out, the likely template for eventually justifying eSIM-based ICE TCUs, rather than the reverse.

Key takeaways

• EV and ICE scooters share the same four-block anatomy; only the energy-source and propulsion blocks differ.

• CAN bus is the shared internal ‘group chat’ that lets vehicle components exchange data; a TCU is just another listener on that bus.

• ECU (or VCU on EVs) drives real-time control; TCU only reports data outward — it never controls the vehicle.

• EVs split ICE's single ECU role across three specialised controllers — VCU, MCU, BMS — which is part of why EV telematics data is richer.

• Data depth depends on integration, not vehicle type: an aftermarket ICE tracker sees very little; a CAN-integrated ICE cluster (already shipping, e.g. SmartXonnect) sees almost as much as an EV.

• The EV/ICE telematics gap today is commercial, not technical — driven by who is willing to pay the recurring connectivity cost.