For Tesla Model S owners and automotive enthusiasts, understanding the inner workings of your vehicle can be a fascinating endeavor. While Tesla vehicles don’t strictly adhere to traditional OBD2 protocols in the same way as internal combustion engine cars, accessing vehicle data is still possible through the Controller Area Network (CAN) bus system. This article delves into the journey of reverse engineering the Tesla Model S CAN bus, revealing insights into vehicle diagnostics and data accessibility.
Initially, the project began with the fundamental task of identifying and decoding various CAN IDs within the Tesla Model S. Early investigations focused on pinpointing specific data points. For instance, researchers identified CAN ID 268 as potentially related to temperature readings, specifically on byte 3 of the data frame. Another ID, 412, presented a 6-byte data stream, exhibiting rolling and repeating patterns across 96 bytes, though it was determined not to be the Vehicle Identification Number (VIN). CAN ID 7E2 also emerged as promising, showing counter and data elements. Furthermore, CAN ID 302 was noted to have connections to supercharging functionalities.
A significant breakthrough came with access to Tesla documentation, which illuminated the control domains of different CAN buses within the Model S. This knowledge streamlined the decoding process by providing context to the data being observed. The CAN bus architecture was mapped as follows:
- CAN 2 – 10 Modules: Handles convenience and infotainment features including the Radio Head Unit, Door Controls, and Sunroof.
- CAN 3 – Powertrain – 9 Modules: Dedicated to powertrain management, encompassing the Thermal Controller, DC-DC Converter, Charger (1 and 2), High Voltage Battery Management System (HV BMS), and Charge Port operations.
- CAN 4 – Body Fault Tolerant: Manages body control functions like the Remote Climate Control Module (RCCM), Positive Temperature Coefficient (PTC) Air Heater, and Memory Seat Module.
- CAN 6 – Chassis – 14 Modules (depending on options): Deals with chassis and safety systems, including Power Steering, Stability Control and Braking, Air Suspension, Instrument Cluster and LIN Bus, Blind Spot and Parking Aid, Tire Pressure Monitoring System (TPMS), and Electronic Parking Brake (EPB) ECU.
Further online research uncovered a valuable resource on GitHub, specifically within the Open Vehicles project. This resource provided decoded information for approximately 10 CAN IDs and their corresponding messages. Verification efforts confirmed the accuracy of several key IDs:
- Headlights ID: 266
- Charge Level ID: 2C8
- Country Code ID: 398
- Climate Control ID: 268
The research progressed to deciphering the bitwise structure within these CAN ID messages to understand the different states and values they represent. For example, for ID266 (Headlights), bit 1 was found to control headlight and Daytime Running Light (DRL) status. A value of 89 indicated lights off with DRL running, while 8A signified lights on with DRL running. Conversely, for lights on without DRL, the value was 88, and 89 for lights off.
Initially, ID 268 was thought to be related to climate control. Further analysis of ID 268 (Climate) revealed details about various climate system parameters encoded in different bits:
- Bit 1: Climate control on/off status (
00=off,55=on,01=noise?). - Bit 2: Undetermined value (
00,193,232,7). - Bit 3: Temperature related data (
26,4D,74,9B,C1,E8,07,26,45,68,87,A6,C9,2A,49,48,68,67,8B,8A,AA,A9). - Bit 4: Potentially fan speed control (
00ramping to02and back, correlating with fan sound). - Bit 5: Possible steady temperature reading in °C, perhaps
19.3°C(values likeC1,C2,C3,C4which are193,194,195,196in decimal). - Bit 6: Possibly fan related or outside temperature (
00to08range). - Bit 7: Likely the set temperature in °C.
- Bit 8: Sample values observed (
00,40,50,60,70,80,90,A0,B0,C0,D0,E0,00,10).
However, subsequent research indicated that ID 268 is not actually linked to climate control, highlighting the iterative nature of reverse engineering and the importance of continuous validation.
Significant progress was achieved in decoding the convenience bus (CAN2) and key components on the chassis bus (CAN6) with dedicated in-car testing and specialized hardware provided by TowerTech. This led to the identification of CAN IDs related to:
- Power mirrors, emergency flashers, and turn signals.
- Passenger front and back windows (but notably not the driver’s side window).
- Radio unit functions.
- Partial sunroof control.
- VIN broadcast on multiple CAN buses.
- Steering wheel position sensing.
- Brake pedal status.
- Charging status and charge limit settings.
Decoded CAN ID lists for CAN2 and CAN3 were compiled and made available online, with CAN6 decoding as an ongoing effort.
Further advancements focused on the powertrain system and related aspects (drivetrain), revealing CAN data points for:
- Motor RPM.
- Gear selector commands.
- Charge port status.
- DC-to-DC converter voltages.
- Main battery pack voltage.
- Individual battery module voltages.
- Charging current and voltage measurements, including supercharging data.
- HVAC temperature and statuses.
- Powertrain and battery cooling systems.
- Lifetime battery discharge counter (Wh), valuable for long-term efficiency analysis.
This collective effort, involving data sharing and collaborative analysis among Tesla owners, helped overcome challenges posed by variations across car models and firmware versions. Tools like CANtact and Kvaser Leaf Light significantly aided in data logging, analysis, and the development of custom Python applications for CAN bus interaction.
While the journey of decoding the Tesla Model S CAN bus is ongoing, the progress made provides valuable insights into accessing and understanding vehicle data. This information is crucial for diagnostics, performance analysis, and advanced customizations within the Tesla ecosystem. Stay tuned for further updates as research continues to unlock more of the Tesla Model S’s data communication network.
