Giới thiệu dự án

Thị trường ô tô toàn cầu và tại Việt Nam đang chứng kiến sự chuyển dịch mạnh mẽ từ phương tiện cơ khí thuần túy sang các phương tiện định nghĩa bằng phần mềm (Software-Defined Vehicles). Theo các báo cáo công nghiệp ô tô giai đoạn 2023–2024, thị trường buồng lái thông minh (Smart Cockpit) đạt tốc độ tăng trưởng kép hàng năm (CAGR) trên 12,8%, trong đó màn hình Android đa nhiệm đã trở thành trang bị tiêu chuẩn trên hơn 75% các dòng xe thương mại và xe nâng cấp thứ cấp (aftermarket).

Tuy nhiên, phần lớn các màn hình Android aftermarket hiện nay hoạt động độc lập, chỉ phục vụ giải trí cơ bản mà thiếu sự tương tác dữ liệu chuyên sâu với mạng điều khiển nội bộ của phương tiện. Để theo dõi thông số hoặc đọc lỗi động cơ, người dùng buộc phải sử dụng các thiết bị chẩn đoán chuyên dụng đắt tiền hoặc các adapter OBD-II bên thứ ba với giao diện rời rạc, không tích hợp liền mạch vào hệ thống điều khiển tiện nghi và giọng nói của khoang lái.

Đồ án tốt nghiệp "Nghiên cứu, thử nghiệm giao diện tiện nghi thông minh trên ô tô cho màn hình Android" (Chuyên ngành Công nghệ Kỹ thuật Ô tô, Khoa Cơ khí Động lực, Trường Đại học Sư phạm Kỹ thuật TP.HCM) giải quyết bài toán cốt lõi này thông qua 5 mục tiêu cụ thể:

  1. Hệ thống hóa cơ sở lý thuyết về giao thức mạng CAN (Controller Area Network - ISO 11898), chuẩn chẩn đoán OBD-II (SAE J1979, ISO 15765-4) và nguyên lý giải mã thông số PIDs (Parameter IDs).
  2. Thiết kế và chế tạo phần cứng bộ chuyển đổi, thu thập và giải mã tín hiệu CAN bus sang chuẩn truyền thông không dây Bluetooth/UART bằng vi điều khiển ATmega328P và vi mạch MCP2515.
  3. Thiết kế mạch phần cứng giả lập tín hiệu cảm biến điện thân xe (áp suất lốp TPMS, hệ thống đèn cảnh báo taplo, mô phỏng lỗi động cơ MIL).
  4. Lập trình phát triển ứng dụng giao diện tiện nghi đa chức năng trên nền tảng Android (bằng MIT App Inventor 2) tích hợp hiển thị dữ liệu động cơ thời gian thực, đọc/xóa mã lỗi DTC (Diagnostic Trouble Codes), điều khiển giọng nói (Voice Control), giải trí đa phương tiện và bản đồ dẫn đường.
  5. Thử nghiệm, đánh giá độ trễ và độ chính xác thực tế trên mô hình mạng CAN xe Kia Morning 2011 AT và xe thực tế Ford Focus 2019.

Giải pháp mang lại khả năng giám sát thông số vận hành theo thời gian thực với tần số quét 20 Hz, độ trễ truyền dữ liệu dưới 100 ms, nhận diện và xóa mã lỗi DTC chính xác 100% theo tiêu chuẩn SAE J1979. Phạm vi nghiên cứu tập trung vào các dòng xe sử dụng giao thức ISO 15765-4 CAN 11-bit tốc độ 250 kbps và 500 kbps, kết nối thông qua cổng DLC 16 chân chuẩn SAE J1962 Loại A.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Trước khi thiết kế, các giải pháp giám sát và chẩn đoán trên xe hơi hiện hành được phân tích kỹ lưỡng nhằm xác định khoảng trống công nghệ:

Tiêu chí so sánh Adapter thương mại (ELM327 + Torque Pro) Màn hình Android OEM (Canbus Box kèm xe) Giải pháp tích hợp tự phát triển của đồ án
Giao diện người dùng Rời rạc, phức tạp, khó tùy biến sâu Cố định theo nhà sản xuất, không hỗ trợ đổi giao diện Thiết kế trực quan, hỗ trợ đa theme, đồng bộ HUD/Dashboard
Điều khiển giọng nói Không hỗ trợ điều khiển xe bằng giọng nói Chỉ điều khiển ứng dụng Android cơ bản Tích hợp Voice Command trực tiếp điều hướng và kiểm tra thông số
Mô phỏng & Chẩn đoán Đọc lỗi thụ động, không có phần cứng mô phỏng Không tích hợp mô phỏng tín hiệu thân xe Tích hợp kit giả lập TPMS, đèn báo và mô phỏng lỗi thực nghiệm
Chi phí triển khai $15 – $40 (chưa gồm màn hình và phần mềm bản quyền) $150 – $300 (phụ thuộc theo từng dòng xe cố định) Dưới 350.000 VNĐ cho toàn bộ module giải mã & giả lập
Khả năng mở rộng Mã nguồn đóng, không can thiệp thuật toán giải mã Hoàn toàn đóng, phụ thuộc Canbus decoder của hãng Mã nguồn mở, dễ dàng thêm PIDs và cập nhật giải thuật

Phân tích yêu cầu người dùng theo ma trận MoSCoW:

  • Must have: Thu thập dữ liệu PID Mode 01 (RPM, Speed, Coolant Temp, Throttle Position); Đọc và xóa mã lỗi DTC Mode 03 / Mode 04; Giao tiếp Bluetooth SPP không dây ổn định.
  • Should have: Giao diện giải trí chơi nhạc từ bộ nhớ máy/USB; Tích hợp Google Maps với chức năng đánh dấu lộ trình; Nhận dạng giọng nói tiếng Việt/tiếng Anh để gọi chức năng.
  • Could have: Mô phỏng áp suất lốp 4 bánh bằng biến trở; Giả lập công tắc bật/tắt đèn cảnh báo khẩn cấp (MIL, ABS, Door Ajar).
  • Won't have: Can thiệp nạp lại bản đồ xăng lửa ECU (Remapping/Flashing) hoặc can thiệp túi khí để đảm bảo an toàn tuyệt đối.

Thiết kế hệ thống

Hệ thống hoạt động theo mô hình phân tầng từ phần cứng thu thập tín hiệu trên xe đến lớp ứng dụng Android hiển thị:

Ngăn xếp công nghệ (Technology Stack)

  • Phần cứng thu thập & giải mã:
    • Vi điều khiển: Microchip ATmega328P (Arduino Uno R3), xung nhịp 16 MHz, 32 KB Flash, 2 KB SRAM.
    • CAN Controller: Microchip MCP2515 hỗ trợ chuẩn CAN 2.0B tốc độ lên đến 1 Mbps, giao tiếp SPI tốc độ 10 MHz.
    • CAN Transceiver: NXP TJA1050 chuyển đổi tín hiệu vi sai CAN-H, CAN-L sang mức logic TTL 5V.
    • Module truyền thông: JDY-33 Dual-Mode Bluetooth (hỗ trợ chuẩn SPP 3.0 và BLE 4.2), giao tiếp UART 9600 bps.
    • Trở đầu cuối: Điện trở 120 $\Omega$ phối hợp trở kháng chống phản xạ sóng trên đường truyền bus vi sai.
  • Phần mềm & Ứng dụng:
    • Lập trình firmware: C/C++ trên Arduino IDE v2.3.2, sử dụng thư viện mcp_can v1.5.0.
    • Lập trình ứng dụng Android: Nền tảng MIT App Inventor 2 (Buildserver v190), tương thích Android OS 8.0 đến Android 13.
Cấu trúc gói tin dữ liệu chuẩn hóa truyền qua UART/Bluetooth lên Android:
[Header: $][Speed],[RPM],[CoolantTemp],[EngineLoad],[TPMS_FL],[TPMS_FR],[TPMS_RL],[TPMS_RR],[DTC_Count],[DTC_Codes][Checksum:#]

Phương pháp luận (Methodology)

Dự án áp dụng quy trình phát triển lặp kết hợp mô hình chữ V (V-Model) trong kiểm thử hệ thống nhúng ô tô:

  • Tháng 3/2024: Nghiên cứu cơ sở lý thuyết chuẩn SAE J1979, khung truyền CAN 2.0A/2.0B, ánh xạ chân giắc OBD-II DLC3 (Chân 6 CAN-H, Chân 14 CAN-L, Chân 4/5 Mass, Chân 16 Dương ắc quy 12V).
  • Tháng 4/2024: Xây dựng phần mềm trên MIT App Inventor 2, lập trình các Blocks xử lý chuỗi ký tự, tách mảng (String Spliting), xây dựng giao diện UI/UX và logic điều khiển âm thanh, giọng nói.
  • Tháng 5/2024: Chế tạo phần cứng bộ giải mã OBD-II, thiết kế hộp bảo vệ, tích hợp mạch giả lập tín hiệu áp suất lốp và đèn cảnh báo; tiến hành cân chỉnh bit timing trên mô hình sa bàn Kia Morning 2011 AT.
  • Tháng 6/2024: Thực nghiệm trên xe Ford Focus 2019, tối ưu hóa thuật toán lọc nhiễu SPI, hoàn thiện báo cáo và bảo vệ đồ án tốt nghiệp.

Implementation và kết quả

Quá trình phát triển và thuật toán cốt lõi

Quá trình truy vấn dữ liệu OBD-II sử dụng định dạng khung truyền tiêu chuẩn CAN 11-bit. Thiết bị chẩn đoán gửi khung yêu cầu với CAN ID 0x7DF. Bộ điều khiển động cơ (ECU) phản hồi với CAN ID trong dải 0x7E8 đến 0x7EF.

Thuật toán tính toán và giải mã các thông số PID (Mode 01)

Khi nhận khung dữ liệu từ ECU, các byte dữ liệu $A, B, C, D$ ở định dạng thập lục phân (Hexadecimal) được xử lý theo các công thức chuẩn SAE J1979:

  1. Tốc độ động cơ (Engine RPM - PID 0x0C): Trả về 2 byte dữ liệu $A$ và $B$. $$\text{RPM} = \frac{256 \times A + B}{4} \quad (\text{vòng/phút, dải đo } 0 - 16.383,75 \text{ RPM})$$

  2. Tốc độ xe (Vehicle Speed - PID 0x0D): Trả về 1 byte dữ liệu $A$. $$V = A \quad (\text{km/h, dải đo } 0 - 255 \text{ km/h})$$

  3. Nhiệt độ nước làm mát (Engine Coolant Temperature - PID 0x05): Trả về 1 byte $A$. $$T_{\text{Coolant}} = A - 40 \quad (^\circ\text{C, dải đo } -40^\circ\text{C} \text{ đến } +215^\circ\text{C})$$

  4. Tải trọng động cơ tính toán (Calculated Engine Load - PID 0x04): Trả về 1 byte $A$. $$\text{Load} = \frac{A \times 100}{255} \quad (%)$$

  5. Nhiệt độ khí xả (Exhaust Gas Temperature EGT - PID 0x78 / 0x79): $$T_{\text{EGT}} = \frac{256 \times A + B}{10} - 40 \quad (^\circ\text{C})$$

Thuật toán giải mã mã lỗi chẩn đoán DTC (Mode 03)

Mỗi mã lỗi DTC được mã hóa bằng 2 byte (16 bit). Hai bit có trọng số cao nhất (MSB) của byte đầu tiên ($A_7, A_6$) quy định phân loại hệ thống:

  • 00 $\rightarrow$ P (Powertrain - Hệ thống truyền động, động cơ, hộp số)
  • 01 $\rightarrow$ C (Chassis - Hệ thống khung gầm, phanh ABS, cân bằng)
  • 10 $\rightarrow$ B (Body - Hệ thống điện thân xe, điều hòa, chiếu sáng)
  • 11 $\rightarrow$ U (Network - Hệ thống giao tiếp mạng và tích hợp phương tiện)

14 bit còn lại ($A_5 \dots A_0$ và $B_7 \dots B_0$) được chuyển đổi sang số Hex để tạo thành 4 ký tự số tiếp theo (ví dụ: P0113, U0158).

// Code snippet triển khai trên vi điều khiển ATmega328P + MCP2515
#include <SPI.h>
#include <mcp_can.h>

const int SPI_CS_PIN = 10;
MCP_CAN CAN(SPI_CS_PIN);

unsigned char requestRPM[8] = {0x02, 0x01, 0x0C, 0x00, 0x00, 0x00, 0x00, 0x00};

void setup() {
  Serial.begin(9600); // Giao tiếp UART với JDY-33 Bluetooth
  while (CAN_OK != CAN.begin(CAN_500KBPS)) { // Thiết lập tốc độ bus CAN 500 kbps
    delay(100);
  }
}

void loop() {
  // Gửi gói tin truy vấn PID 0x0C (Engine RPM) tới CAN ID 0x7DF
  CAN.sendMsgBuf(0x7DF, 0, 8, requestRPM);
  delay(50); // Khoảng chờ đáp ứng từ ECU

  if (CAN_MSGAVAIL == CAN.checkReceive()) {
    unsigned char len = 0;
    unsigned char buf[8];
    unsigned long canId = CAN.getCanId();

    CAN.readMsgBuf(&len, buf);
    // Kiểm tra phản hồi từ ECU (ID trong dải 0x7E8 - 0x7EF) cho Mode 01 PID 0x0C (buf[1]=0x41, buf[2]=0x0C)
    if (canId >= 0x7E8 && canId <= 0x7EF && buf[1] == 0x41 && buf[2] == 0x0C) {
      unsigned int rawRPM = ((unsigned int)buf[3] << 8) | buf[4];
      float rpm = (float)rawRPM / 4.0;
      
      // Đóng gói chuỗi truyền lên màn hình Android
      Serial.print("RPM:");
      Serial.println(rpm);
    }
  }
  delay(50);
}

Thuật toán phân tích chuỗi trên MIT App Inventor 2:
Khi nhận được chuỗi dữ liệu (DataReceived):
  1. Gán biến tempString = BluetoothClient.ReceiveText()
  2. Phân tách chuỗi dựa trên ký tự phân cách (delimiter ',')
  3. Ánh xạ phần tử mảng index 1 -> Cập nhật Gauge RPM
  4. Ánh xạ phần tử mảng index 2 -> Cập nhật Digital Speedometer
  5. Kiểm tra giá trị Temp: Nếu Temp > 105°C -> Kích hoạt cảnh báo giọng nói (TextToSpeech)

Thử nghiệm và kiểm định (Testing & Validation)

Hệ thống được kiểm thử thực nghiệm qua hai giai đoạn:

+-----------------------------------------------------------------------+
|                     KẾT QUẢ KIỂM THỬ HỆ THỐNG                        |
+--------------------------+---------------------+----------------------+
| Kịch bản kiểm thử        | Mô hình Kia Morning | Xe Ford Focus 2019   |
+--------------------------+---------------------+----------------------+
| Tốc độ truyền bus CAN    | 500 kbps (HS-CAN)   | 500 kbps (HS-CAN)    |
| Tần số làm mới dữ liệu   | 20 Hz (50 ms/lần)   | 18 Hz (55 ms/lần)    |
| Tỷ lệ mất gói tin (Drop) | 0.12%               | 0.28%                |
| Độ trễ Bluetooth SPP     | 45 ms               | 60 ms                |
| Độ chính xác RPM & Vận tốc| 100% (so với ODO)   | 100% (so với ODO)    |
| Nhận diện mã lỗi giả lập | 10/10 mã thành công | 5/5 mã DTC chính xác |
| Độ trễ lệnh giọng nói    | 1.1 giây            | 1.3 giây             |
+--------------------------+---------------------+----------------------+
  1. Thử nghiệm trên mô hình sa bàn Kia Morning 2011 AT:
    • Hoạt động ổn định ở chế độ cầm chừng (Idle: 750–800 RPM) và chế độ tăng ga (Accelerating: 2000–3500 RPM).
    • Kiểm thử mạch giả lập áp suất lốp: Thay đổi điện áp biến trở từ 0–5V tương ứng dải áp suất 0–3.5 Bar. Màn hình Android hiển thị chính xác từng bánh xe và chuyển sang trạng thái cảnh báo đỏ khi áp suất giảm dưới 1.8 Bar.
  2. Thử nghiệm trên xe thực tế Ford Focus 2019:
    • Kết nối trực tiếp qua cổng OBD-II dưới chân taplo. Dữ liệu nhiệt độ nước làm mát, tốc độ xe, độ mở bướm ga đồng bộ tức thời với bảng đồng hồ táp-lô nguyên bản.
    • Thử nghiệm chẩn đoán: Cố tình ngắt giắc cảm biến nhiệt độ khí nạp (IAT Sensor), ứng dụng quét và đọc chính xác mã lỗi P0113 (Intake Air Temperature Sensor Circuit High). Sau khi cắm lại giắc, thực hiện lệnh "Clear DTC" trên màn hình Android thành công, đèn Check Engine (MIL) trên bảng đồng hồ tắt hoàn toàn.

Đổi mới và đóng góp

  1. Tích hợp "3-trong-1" trên một nền tảng mở: Đề tài kết hợp thành công chức năng Telemetry (giám sát thời gian thực), Diagnostic Tool (chẩn đoán lỗi OBD-II tiêu chuẩn) và Smart Infotainment (giải trí, bản đồ, điều khiển bằng giọng nói) chạy native trên hệ điều hành Android của xe hơi.
  2. Hiệu quả tối ưu chi phí (Cost Efficiency): Thiết kế thành công module phần cứng giải mã CAN/OBD-II hoàn chỉnh với tổng chi phí linh kiện dưới 350.000 VNĐ, thấp hơn 70–80% so với các bộ giải mã Canbus Box thương mại nhập khẩu hoặc máy quét chẩn đoán cầm tay.
  3. Giải pháp thực nghiệm mô phỏng kết hợp: Việc tích hợp khối mạch giả lập tín hiệu điện thân xe (TPMS, đèn báo nguy hiểm, công tắc lỗi) cho phép tạo ra công cụ giảng dạy, học tập trực quan sinh động cho sinh viên chuyên ngành Công nghệ Kỹ thuật Ô tô và Kỹ thuật Cơ điện tử.

Ứng dụng thực tế và triển khai

Tình huống sử dụng thực tế (Real-World Use Cases)

  • Tài xế cá nhân / Chủ xe dịch vụ: Cài đặt ứng dụng trực tiếp lên màn hình Android trung tâm của xe để theo dõi liên tục mức tiêu thụ nhiên liệu, nhiệt độ động cơ trong các chuyến đi dài, chủ động phát hiện sớm hiện tượng quá nhiệt hoặc bỏ máy (Misfire).
  • Gara sửa chữa / Trạm dịch vụ ô tô: Sử dụng như một công cụ chẩn đoán nhanh không dây qua kết nối Bluetooth màn hình máy tính bảng/điện thoại, đọc và xóa nhanh các mã sự cố DTC cơ bản mà không cần mang vác máy chẩn đoán cồng kềnh.
  • Phòng thí nghiệm / Cơ sở đào tạo ô tô: Đóng vai trò là mô hình học cụ trực quan giúp học viên hiểu rõ cấu trúc khung truyền CAN bus vi sai, các byte phân tích trong tiêu chuẩn SAE J1979 và cách phát triển ứng dụng IoT cho ô tô.

Lộ trình nâng cấp và mở rộng

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Nền tảng MIT App Inventor 2 sử dụng cơ chế kéo thả khối lệnh (Block-based) dẫn đến kích thước file APK lớn, khó tối ưu hóa bộ nhớ khi xử lý các chuỗi đồ họa phức tạp và hiệu ứng hoạt họa (Animation) ở tốc độ làm mới cao (> 30 Hz).
  • Tốc độ truyền thông Bluetooth SPP bị giới hạn ở 9600 bps, tiềm ẩn độ trễ nhẹ khi truyền đồng thời nhiều danh sách mã lỗi DTC kéo dài nhiều khung truyền (Multi-frame ISO 15765-2).
  • Mạch phần cứng hiện tại chỉ hỗ trợ giao thức CAN (ISO 15765-4), chưa tích hợp các mạch phần cứng tương thích ngược với các giao thức cũ như SAE J1850 PWM/VPW hoặc ISO 9141-2 (K-Line).

Hướng phát triển tiếp theo

  • Viết lại ứng dụng Android bằng ngôn ngữ thuần Kotlin/Java trên Android Studio hoặc Flutter để tối ưu hóa hiệu năng render đồ họa và đa luồng (Multi-threading).
  • Chuyển đổi vi điều khiển sang ESP32-S3 tích hợp sẵn bộ điều khiển TWAI (Two-Wire Automotive Interface tương thích CAN 2.0B) và kết nối Wi-Fi/Bluetooth 5.0 tốc độ cao, giúp tinh giản kích thước bo mạch phần cứng.
  • Phát triển tính năng phân tích dự đoán hỏng hóc (Predictive Maintenance) dựa trên thuật toán máy học (Machine Learning) nhẹ phân tích dữ liệu lịch sử của cảm biến oxy và áp suất nhiên liệu.

Đối tượng hưởng lợi

  • Sinh viên ngành Kỹ thuật Ô tô / Cơ điện tử: Cung cấp tài liệu tham khảo chi tiết từ cấu tạo vật lý mạng CAN (CAN-H, CAN-L, điện áp vi sai 1.5V – 3.5V), cấu trúc khung Data Frame, đến các công thức toán học giải mã PID theo tiêu chuẩn quốc tế.
  • Kỹ sư phát triển phần mềm nhúng / Lập trình viên Android: Nắm bắt được phương pháp kết nối dữ liệu giữa phần cứng vi điều khiển và ứng dụng di động thông qua Bluetooth UART, kiến trúc đóng gói và bóc tách chuỗi dữ liệu trong các hệ thống giám sát xe hơi.
  • Chủ phương tiện ô tô: Tiếp cận giải pháp công nghệ giá rẻ, giúp làm chủ thông tin vận hành xe, tiết kiệm chi phí chẩn đoán lỗi tại gara từ 200.000 – 500.000 VNĐ cho mỗi lần xóa mã lỗi định kỳ.

Câu hỏi thường gặp

1. Yêu cầu phần cứng tối thiểu để triển khai ứng dụng là gì?

Xe cần trang bị cổng chẩn đoán tiêu chuẩn OBD-II (SAE J1962) sử dụng giao thức ISO 15765-4 CAN (các dòng xe sản xuất từ năm 2008 trở lại đây). Về phía người dùng, màn hình Android hoặc điện thoại thông minh chạy hệ điều hành Android 8.0 trở lên, có hỗ trợ kết nối Bluetooth 3.0/4.0.

2. Thiết bị có gây ảnh hưởng hoặc xung đột với mạng CAN nguyên bản của xe không?

Không. Module phần cứng sử dụng vi mạch MCP2515 với chế độ lọc ID (CAN Acceptance Filters) và chỉ gửi các truy vấn chẩn đoán tiêu chuẩn ở tần số an toàn (20 Hz) lên địa chỉ quảng bá 0x7DF. Bộ thu phát TJA1050 có cơ chế bảo vệ chống ngắn mạch và quá áp, hoàn toàn cách ly và an toàn với hệ thống ECU của xe.

3. Làm thế nào để giải mã được các mã lỗi DTC phức tạp xuất hiện trên nhiều khung truyền?

Khi có từ 3 mã lỗi DTC trở lên, hệ thống áp dụng giao thức vận chuyển ISO-TP (ISO 15765-2). ECU sẽ gửi khung đầu tiên (First Frame - FF), vi điều khiển phản hồi khung kiểm soát luồng (Flow Control - FC), sau đó ECU tiếp tục gửi các khung liên tiếp (Consecutive Frames - CF) để vi điều khiển ghép nối đầy đủ danh sách mã lỗi.

4. Tại sao không sử dụng trực tiếp cổng USB trên màn hình Android mà dùng Bluetooth?

Bluetooth JDY-33 mang lại tính linh hoạt cao, loại bỏ việc đi dây cáp rườm rà từ cổng OBD-II dưới gầm taplo lên màn hình trung tâm. Tuy nhiên, hệ thống vẫn dự phòng phương thức giao tiếp qua cổng USB nối tiếp (USB Serial) khi cần tốc độ truyền dữ liệu cao hơn.

5. Chi phí sản xuất hàng loạt ước tính của bộ giao tiếp OBD-II là bao nhiêu?

Khi triển khai mạch in PCB công nghiệp và sản xuất hàng loạt từ 100 bộ trở lên, chi phí linh kiện (MCU ESP32 + Transceiver SN65HVD230 + Vỏ cổng OBD-II đực) chỉ dao động trong khoảng 150.000 – 200.000 VNĐ/bộ.

Kết luận

Đồ án tốt nghiệp "Nghiên cứu, thử nghiệm giao diện tiện nghi thông minh trên ô tô cho màn hình Android" đã hoàn thành trọn vẹn các mục tiêu kỹ thuật đặt ra: từ việc nghiên cứu lý thuyết chuyên sâu về mạng CAN, chuẩn OBD-II SAE J1979, đến việc chế tạo thành công phần cứng thu thập/giả lập tín hiệu và phát triển ứng dụng điều khiển đa năng trên hệ điều hành Android. Kết quả thử nghiệm thực tế trên xe Kia Morning 2011 AT và Ford Focus 2019 đã chứng minh tính khả thi, độ tin cậy và giá trị ứng dụng cao của giải pháp trong xu hướng thông minh hóa khoang lái xe hơi hiện đại.