Giới thiệu dự án

Sự phát triển mạnh mẽ của cuộc Cách mạng Công nghiệp 4.0 và công nghệ vạn vật kết nối (Internet of Things - IoT) đã tạo ra bước chuyển dịch căn bản trong ngành công nghiệp ô tô (Automotive). Theo số liệu từ Hiệp hội các nhà sản xuất ô tô Việt Nam (VAMA), thị trường trong nước năm 2022 đã ghi nhận mức tiêu thụ kỷ lục với hơn 490.000 xe, tăng 33% so với năm 2021. Sự gia tăng mật độ phương tiện đặt ra thách thức nghiêm trọng về an toàn vận hành, kiểm soát khí thải và quản lý bảo dưỡng phương tiện. Trên một chiếc ô tô hiện đại, hàng chục Bộ điều khiển điện tử (Electronic Control Unit - ECU) liên tục trao đổi dữ liệu qua mạng vùng điều khiển (Controller Area Network - CAN). Tuy nhiên, phần lớn người dùng cá nhân và các doanh nghiệp vận tải quy mô vừa và nhỏ vẫn gặp khó khăn trong việc tiếp cận dữ liệu vận hành thời gian thực do các thiết bị chẩn đoán chuyên dụng thường có giá thành cao, tính đóng kín và thiếu khả năng đồng bộ đám mây.

       +-------------------------------------------------------------+
       |                     KIẾN TRÚC TỔNG QUAN                     |
       +-------------------------------------------------------------+
       | [STM32 / Arduino] (Mô phỏng ECU & Phát sinh dữ liệu OBD-II)  |
       |                              | (CAN Bus 500 kbps - ISO 15765)|
       |                              v                              |
       | [Raspberry Pi 4 + CAN HAT MCP2515] (Bộ xử lý trung tâm)     |
       |         /                                   \               |
       | (Local Dashboard)                   (HTTPS / REST Client)   |
       |        v                                     v              |
       | [Màn hình 7" LCD Node-RED]          [Firebase Realtime DB]  |
       |                                              |              |
       |                                              v              |
       |                                 [Ứng dụng di động Flutter]  |
       +-------------------------------------------------------------+

Đề tài khóa luận tốt nghiệp "Thiết kế và thi công hệ thống giám sát và chẩn đoán trên ô tô" do sinh viên Trần Mạc Gia Phong và Trần Lam Nhật Vy thực hiện dưới sự hướng dẫn của ThS. Trương Quang Phúc (Trường Đại học Sư phạm Kỹ thuật TP.HCM) giải quyết trực tiếp bài toán thu thập, xử lý, hiển thị và cảnh báo từ xa các thông số kỹ thuật then chốt của xe hơi theo chuẩn quốc tế OBD-II.

Mục tiêu cụ thể của dự án:

  1. Nghiên cứu cấu trúc vi điều khiển 32-bit ARM Cortex-M3 STM32F103C8T6 và Arduino Nano để mô phỏng dữ liệu khung truyền OBD-II chuẩn SAE J1979/ISO 15765-4.
  2. Thiết kế phần cứng giao tiếp mạng CAN Bus đạt chuẩn CAN 2.0B sử dụng bộ điều khiển MCP2515 kết hợp bộ thu phát TJA1050/RS485 CAN HAT.
  3. Xây dựng khối xử lý trung tâm trên máy tính nhúng Raspberry Pi 4 Model B để giải mã dữ liệu thô, phân tích lỗi DTC (Diagnostic Trouble Code) và tính toán thông số vật lý.
  4. Phát triển giao diện điều khiển cục bộ (Dashboard) trên màn hình LCD 7 inch thông qua nền tảng luồng Node-RED.
  5. Thiết lập hệ thống cơ sở dữ liệu thời gian thực Google Firebase Realtime Database và xây dựng ứng dụng di động đa nền tảng bằng Flutter SDK để giám sát từ xa và kích hoạt cảnh báo nguy cấp.

Phạm vi nghiên cứu tập trung vào 5 thông số vận hành cốt lõi: Tốc độ vòng tua động cơ (Engine RPM), Vận tốc xe (Vehicle Speed), Nhiệt độ nước làm mát động cơ (Coolant Temperature), Mức nhiên liệu (Fuel Level) và Quãng đường di chuyển (Distance Traveled). Hệ thống giới hạn ở giao thức OBD-II Mode 01 (Dữ liệu chẩn đoán hiện hành) và Mode 02 (Dữ liệu khung đóng băng), áp dụng cơ chế truyền nhận điểm - điểm và broadcast an toàn.

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

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

Các giải pháp giám sát phương tiện trên thị trường hiện nay bộc lộ nhiều điểm hạn chế khi cân nhắc giữa chi phí, tính linh hoạt và khả năng xử lý thời gian thực:

Tiêu chí so sánh Máy chẩn đoán cầm tay (Autel, Launch) Thiết bị phát Wi-Fi/Bluetooth ELM327 Hệ thống IoT Gateway đề xuất
Giao thức xử lý CAN, K-Line, J1850 (Đa chuẩn) CAN, K-Line cơ bản qua tập lệnh AT CAN 2.0B, OBD-II ISO 15765-4 Native
Độ trễ xử lý dữ liệu Rất thấp (< 10 ms) Trung bình (80 - 150 ms qua Bluetooth) Cực thấp cục bộ (< 15 ms), Cloud (< 250 ms)
Hiển thị trực quan Màn hình tích hợp phần cứng Điện thoại di động qua app bên thứ ba Màn hình LCD 7" trên xe & App Flutter riêng biệt
Đồng bộ hóa Cloud Giới hạn / Phải trả phí Server hãng Không hỗ trợ lưu trữ đám mây tự động Đồng bộ liên tục lên Firebase Realtime Database
Hệ thống cảnh báo Còi báo tại chỗ / Đèn Check Engine Thông báo cục bộ trên điện thoại Đa tầng: Đèn LED cảnh báo LCD & Push Alert App
Chi phí triển khai Rất cao ($800 - $3,000) Rẻ ($10 - $30) nhưng độ bền kém Tối ưu ($100 - $130), khả năng mở rộng cao

Yêu cầu người dùng được phân loại theo mô hình MoSCoW:

  • Must Have (Bắt buộc): Thu thập chính xác mã PID 0x0C, 0x0D, 0x05, 0x2F; phân xử ưu tiên khung CAN theo CSMA/CD+AMP; hiển thị tức thời lên LCD 7 inch; cảnh báo khi thông số vượt ngưỡng an toàn.
  • Should Have (Nên có): Đẩy dữ liệu liên tục lên cơ sở dữ liệu Firebase; giao diện mobile trực quan hiển thị đồng hồ đo (gauge) và biểu đồ; chức năng xác thực đăng nhập người dùng.
  • Could Have (Có thể mở rộng): Lưu trữ lịch sử chuyến đi dạng offline khi mất sóng di động; tính toán mức tiêu hao nhiên liệu trung bình.
  • Won't Have (Chưa thực hiện ở giai đoạn này): Can thiệp xóa mã lỗi chuyên sâu (Clear DTC Mode 04) hoặc điều khiển cơ cấu chấp hành hai chiều (Bi-directional Control Mode 08) nhằm bảo đảm an toàn hệ thống lái.

Thiết kế hệ thống

Kiến trúc hệ thống tuân theo mô hình 3 tầng: Edge Sensor/ECU Layer, Gateway Processing Layer, và Cloud Application Layer.

+-----------------------------------------------------------------------------------+
|                            KIẾN TRÚC PHẦN CỨNG & PHẦN MỀM                         |
+-----------------------------------------------------------------------------------+
| [STM32F103C8T6]       --> SPI --> [MCP2515 CAN Controller]                        |
| [Arduino Nano]        --> SPI --> [TJA1050 Transceiver]                           |
|                                         |                                         |
|                                    [CAN BUS] (CAN_H / CAN_L - 120 Ohm Resistors)  |
|                                         |                                         |
| [Raspberry Pi 4 Model B] <-- SPI <-- [RS485 CAN HAT (MCP2515 + SN65HVD230)]       |
|   |                                                                               |
|   +--> [Node-RED Engine v3.1]       --> UI Dashboard (Màn hình 7" LCD HDMI/DSI)   |
|   +--> [Python SocketCAN Bridge]   --> HTTPS REST Client                          |
|                                                 |                                 |
|                                     [Firebase Realtime DB]                        |
|                                                 |                                 |
|                                     [Flutter 3.16 Mobile App]                     |
+-----------------------------------------------------------------------------------+

Danh mục công nghệ và phiên bản sử dụng:

  • Vi điều khiển Node: STM32F103C8T6 (32-bit ARM Cortex-M3, 72MHz clock), Arduino Nano (ATmega328P, 16MHz).
  • Bộ xử lý Gateway: Raspberry Pi 4 Model B (Broadcom BCM2711, Quad-core Cortex-A72 @ 1.5GHz, 4GB LPDDR4 RAM) chạy Raspberry Pi OS (Debian 64-bit).
  • Giao thức phần cứng: SPI Interface kết nối vi điều khiển và MCP2515 (tần số thạch anh 8MHz/16MHz), mạng CAN 2.0B tốc độ 500 kbps.
  • Nền tảng luồng: Node-RED v3.1.0 vận hành trên môi trường Node.js v18 LTS.
  • Cơ sở dữ liệu đám mây: Google Firebase Realtime Database (REST API / WebSockets).
  • Framework ứng dụng di động: Flutter SDK v3.16.x kết hợp ngôn ngữ Dart v3.2.x.
{
  "telemetry": {
    "vehicle_id": "HCMUTE-AUTO-01",
    "timestamp": 1705891200000,
    "engine_rpm": 2450.0,
    "vehicle_speed": 62.5,
    "coolant_temp": 88.0,
    "fuel_level": 74.5,
    "distance_traveled": 12450.8,
    "alerts": {
      "rpm_warning": false,
      "temp_overheat": false,
      "fuel_low": false,
      "speed_overshoot": false
    }
  }
}

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

Dự án áp dụng mô hình phát triển tích hợp chữ V (V-Model) kết hợp kỹ thuật phân đoạn Agile Sprint trong vòng 16 tuần:

  • Tuần 1 - Tuần 4: Khảo sát chuẩn SAE J1979/ISO 15765-4, kiến trúc phần cứng CAN, cấu hình Raspberry Pi 4 và lập trình thử nghiệm SPI-MCP2515.
  • Tuần 5 - Tuần 8: Thiết kế sơ đồ nguyên lý mạch nguồn, bộ cách ly quang, thiết kế lưu đồ thuật toán đóng gói/giải mã khung CAN và cấu trúc luồng Node-RED.
  • Tuần 9 - Tuần 12: Thi công phần cứng, lập trình ứng dụng Flutter, tạo API giao tiếp Firebase, đồng bộ dữ liệu song song LCD - Mobile.
  • Tuần 13 - Tuần 16: Kiểm thử tích hợp toàn diện, đánh giá lỗi bit mạng CAN, đo kiểm trễ truyền thông, tối ưu hiệu năng và đóng tập báo cáo kỹ thuật.

Triển khai và kết quả thực nghiệm

Quy trình lập trình và thuật toán xử lý

Thuật toán của hệ thống được chia thành hai module chính: Bộ tạo/phản hồi yêu cầu chẩn đoán OBD-II trên vi điều khiển và Bộ giải mã/phân phối dữ liệu trên Raspberry Pi 4.

          [Khởi tạo Module CAN & Bộ lọc Filter ID: 0x7DF]
                                 |
                                 v
                     [Có khung yêu cầu đến?]
                          /             \
                    (Không)             (Có)
                        |                 |
                        v                 v
                 [Tiếp tục quét]   [Kiểm tra Service Mode]
                                          |
                                   (Mode == 0x01?)
                                    /           \
                               (Sai)            (Đúng)
                                 |                 |
                                 v                 v
                         [Bỏ qua Frame]     [Kiểm tra mã PID]
                                                   |
                         +-------------------------+-------------------------+
                         |                         |                         |
                    (PID == 0x0C)             (PID == 0x0D)             (PID == 0x05)
                         |                         |                         |
                         v                         v                         v
                  [Đọc Engine RPM]         [Đọc Vehicle Speed]      [Đọc Coolant Temp]
                  [Data = RPM * 4]          [Data = Speed]            [Data = Temp + 40]
                         \                         |                         /
                          +------------------------+------------------------+
                                                   |
                                                   v
                                   [Đóng gói khung phản hồi: 0x7E8]
                                   [DLC=8, Byte0=Len, Byte1=0x41, Byte2=PID]
                                                   |
                                                   v
                                        [Truyền lên CAN BUS]

Cấu trúc một khung yêu cầu dữ liệu tiêu chuẩn (Request Frame) từ Gateway có dạng: ID: 0x7DF | DLC: 8 | 02 01 0D 55 55 55 55 55 (Yêu cầu đọc Vehicle Speed - PID 0x0D tại Mode 01).

Khung phản hồi từ STM32F103C8T6 (Response Frame): ID: 0x7E8 | DLC: 8 | 03 41 0D 3C AA AA AA AA.

// Cấu hình giải mã và phản hồi mã PID OBD-II trên vi điều khiển STM32
void CAN_Process_OBDII_Request(CanRxMsg *RxMessage, CanTxMsg *TxMessage) {
    if (RxMessage->StdId == 0x7DF && RxMessage->Data[1] == 0x01) {
        uint8_t pid = RxMessage->Data[2];
        TxMessage->StdId = 0x7E8;
        TxMessage->IDE = CAN_ID_STD;
        TxMessage->RTR = CAN_RTR_DATA;
        TxMessage->DLC = 8;
        
        switch (pid) {
            case 0x0C: // Engine RPM: Formula = ((A * 256) + B) / 4
                {
                    uint16_t rpm_raw = (uint16_t)(simulated_rpm * 4);
                    TxMessage->Data[0] = 0x04; // Chiều dài payload hợp lệ
                    TxMessage->Data[1] = 0x41; // Phản hồi Mode 01 (0x01 + 0x40)
                    TxMessage->Data[2] = 0x0C; // Mã PID
                    TxMessage->Data[3] = (rpm_raw >> 8) & 0xFF; // Byte A
                    TxMessage->Data[4] = rpm_raw & 0xFF;        // Byte B
                }
                break;
            case 0x0D: // Vehicle Speed: Formula = A (km/h)
                TxMessage->Data[0] = 0x03;
                TxMessage->Data[1] = 0x41;
                TxMessage->Data[2] = 0x0D;
                TxMessage->Data[3] = (uint8_t)simulated_speed;
                break;
            case 0x05: // Coolant Temperature: Formula = A - 40 (Deg C)
                TxMessage->Data[0] = 0x03;
                TxMessage->Data[1] = 0x41;
                TxMessage->Data[2] = 0x05;
                TxMessage->Data[3] = (uint8_t)(simulated_temp + 40);
                break;
        }
        CAN_Transmit(CAN1, TxMessage);
    }
}

Phía ứng dụng di động Flutter, cơ chế lắng nghe sự kiện luồng dữ liệu (StreamSubscription) từ Firebase Realtime Database được tối ưu hóa nhằm loại bỏ hiện tượng lag giao diện:

// Lắng nghe dữ liệu viễn thông từ Firebase và kích hoạt cảnh báo
void initializeTelemetryStream() {
  DatabaseReference telemetryRef = FirebaseDatabase.instance.ref('telemetry');
  
  telemetryRef.onValue.listen((DatabaseEvent event) {
    final data = event.snapshot.value as Map<dynamic, dynamic>?;
    if (data != null) {
      double rpm = (data['engine_rpm'] as num).toDouble();
      double temp = (data['coolant_temp'] as num).toDouble();
      double speed = (data['vehicle_speed'] as num).toDouble();
      double fuel = (data['fuel_level'] as num).toDouble();

      // Kiểm tra ngưỡng cảnh báo nguy hiểm
      bool isOverheat = temp > 105.0; // Nhiệt độ > 105 độ C
      bool isRpmHigh = rpm > 4500.0;   // Vòng tua > 4500 RPM
      bool isFuelLow = fuel < 15.0;     // Mức nhiên liệu < 15%

      setState(() {
        currentVehicleData = VehicleTelemetry.fromMap(data);
        alertStatus.update(isOverheat, isRpmHigh, isFuelLow);
      });
    }
  });
}

Kiểm thử và đánh giá hiệu năng

Hệ thống đã trải qua quá trình kiểm thử tải liên tục trong 72 giờ tại phòng thí nghiệm Viễn thông - Đại học Sư phạm Kỹ thuật TP.HCM:

Hạng mục kiểm thử Giá trị đo lường thực tế Ngưỡng chỉ tiêu kỹ thuật Trạng thái
Độ trễ truyền nhận CAN Bus $4.25\text{ ms} \pm 0.8\text{ ms}$ $< 15.0\text{ ms}$ Đạt (Vượt chỉ tiêu 71.6%)
Độ trễ đồng bộ Cloud (Firebase) $185\text{ ms} \pm 35\text{ ms}$ $< 500.0\text{ ms}$ Đạt (Tốc độ phản hồi cao)
Tỷ lệ mất gói tin (Packet Loss) $0.038%$ trên 500.000 frames $< 0.1%$ Đạt tiêu chuẩn mạng công nghiệp
Tải CPU trung bình trên RPi 4 $14.6%$ (Chạy song song Node-RED) $< 40.0%$ Ổn định, nhiệt độ SoC $48.2^\circ\text{C}$
Tần số làm tươi giao diện Flutter $59.8\text{ FPS}$ $60.0\text{ FPS}$ Giao diện mượt mà, không giật 
    CAN Bus Latency (ms)      : [====] 4.25 ms (Target: < 15 ms)
    Cloud Sync Latency (ms)    : [============] 185 ms (Target: < 500 ms)
    Packet Loss Rate (%)       : [=] 0.038% (Target: < 0.1%)
    Raspberry Pi CPU Load (%)  : [======] 14.6% (Target: < 40%)

Các kịch bản kiểm thử cảnh báo bất thường:

  • Cảnh báo quá nhiệt: Khi mô phỏng nhiệt độ động cơ vượt $105^\circ\text{C}$, màn hình LCD lập tức đổi màu nền thông số sang đỏ trong $0.15\text{s}$, ứng dụng di động hiển thị cảnh báo đẩy (Push Alert) sau $0.22\text{s}$.
  • Cảnh báo cạn nhiên liệu: Khi mức nhiên liệu giảm xuống dưới $15%$, icon cảnh báo trên Dashboard Node-RED kích hoạt trạng thái nhấp nháy tần số $1\text{Hz}$.
  • Cảnh báo quá tốc độ vòng tua: Khi RPM $> 4500\text{ RPM}$, thanh đo Gauge trên ứng dụng di động chuyển sang dải đỏ cảnh báo tài xế chuyển số.

Đổi mới và đóng góp kỹ thuật

  1. Kiến trúc xử lý lai (Edge-Cloud Hybrid Processing): Khắc phục triệt để điểm yếu của các dòng máy chẩn đoán thông thường. Khi xe di chuyển vào vùng mất sóng viễn thông (đường hầm, đèo núi), hệ thống Edge trên Raspberry Pi 4 vẫn duy trì xử lý và hiển thị $100%$ tính năng trên màn hình LCD 7 inch; khi có kết nối Internet trở lại, dữ liệu được tự động bù đồng bộ lên Firebase.
  2. Tối ưu hóa chi phí phần cứng đến 92%: Thay vì sử dụng các bộ quét OBD-II chuyên dụng đắt tiền của các hãng với chi phí từ $800 - $1,500, giải pháp mã nguồn mở kết hợp giữa STM32, Raspberry Pi và module CAN HAT có tổng chi phí linh kiện dưới $120$ nhưng cung cấp đầy đủ khả năng số hóa dữ liệu.
  3. Chuẩn hóa dữ liệu theo tiêu chuẩn quốc tế SAE J1979: Toàn bộ thuật toán mã hóa và giải mã tuân thủ chính xác từng byte trường dữ liệu chuẩn OBD-II, cho phép hệ thống dễ dàng kết nối trực tiếp vào cổng chẩn đoán DLC (Data Link Connector) trên các dòng xe thương mại thực tế mà không cần chỉnh sửa phần mềm giải mã.
  4. Giao diện người dùng kép thời gian thực: Kết hợp trực quan hóa cục bộ bằng Node-RED và ứng dụng di động Flutter viết bằng Dart, tạo ra hệ sinh thái quản lý toàn diện cho cả tài xế đang ngồi trong khoang lái và người quản lý từ xa.

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

Hệ thống được thiết kế theo dạng module hóa công nghiệp, sẵn sàng triển khai trong các kịch bản thực tế:

                          CÁC KỊCH BẢN TRIỂN KHAI THỰC TẾ
   +-------------------------------------------------------------------------+
   |  [Quản lý Đội xe Doanh nghiệp] --> Giám sát RPM, Nhiệt độ, Hành trình   |
   |  [Hỗ trợ Lái xe Cá nhân]       --> Bảng đồng hồ kỹ thuật số Digital LCD |
   |  [Dịch vụ Thuê xe Tự lái]      --> Kiểm soát tốc độ, Cảnh báo cạn xăng  |
   |  [Xưởng Dịch vụ Sửa chữa]      --> Đọc nhanh thông số vận hành máy      |
   +-------------------------------------------------------------------------+
  1. Hệ thống Quản lý Đội xe Vận tải (Fleet Management): Cho phép các doanh nghiệp logistics giám sát liên tục tình trạng kỹ thuật của hàng trăm đầu xe tải/xe khách theo thời gian thực, ngăn ngừa hiện tượng quá nhiệt động cơ gây cháy nổ hoặc ép số làm hỏng hộp số.
  2. Bảng đồng hồ kỹ thuật số cho xe ô tô đời cũ (Digital Cockpit Retrofit): Nâng cấp các dòng xe đời cũ chưa có màn hình thông minh thành cụm đồng hồ kỹ thuật số hiển thị đa thông số với độ nét cao trên màn hình LCD 7 inch.
  3. Dịch vụ cho thuê xe tự lái: Cung cấp giải pháp giám sát hành vi lái xe, phát hiện xe chạy quá tốc độ quy định hoặc thiếu hụt nhiên liệu để tính cước chính xác.

Yêu cầu triển khai và dự toán kinh tế

+-----------------------------------------------------------------------+
| Nguồn cấp xe hơi (12V - 24V DC từ Accu hoặc cổng DLC)                |
|       |                                                               |
|       v                                                               |
| [Mạch chuyển đổi Nguồn Buck Converter LM2596: 12V -> 5V/3.5A]         |
|       |                                                               |
|       +---> Cấp nguồn ổn định cho Raspberry Pi 4 & LCD 7 inch         |
|       +---> Cấp nguồn vi điều khiển STM32 & Can Transceiver           |
+-----------------------------------------------------------------------+
  • Yêu cầu lắp đặt: Nguồn điện 12V/24V từ ắc quy ô tô đi qua mạch hạ áp DC-DC LM2596 (ngõ ra 5V-3.5A có diode bảo vệ ngược cực); 2 đường tín hiệu CAN_H và CAN_L bấm đầu giắc chuẩn OBD-II 16 chân (Chân 6: CAN High, Chân 14: CAN Low); USB 4G Dongle hoặc module phát Wi-Fi mini để duy trì kết nối Internet.
  • Phân tích Chi phí - Lợi ích (ROI):
    • Chi phí phần cứng một bộ thiết bị: ~2.800.000 VNĐ ($115).
    • Chi phí vận hành Cloud Firebase (Gói Spark/Blaze cơ bản): ~0 - 50.000 VNĐ/tháng/xe.
    • Lợi ích kinh tế: Giảm thiểu $35%$ chi phí sửa chữa đột xuất nhờ phát hiện sớm hiện tượng quá nhiệt và lỗi áp suất dầu; tiết kiệm $8 - 12%$ chi phí nhiên liệu nhờ giám sát và cảnh báo dải tốc độ vòng tua tối ưu. Thời gian hoàn vốn đầu tư (ROI) ước tính dưới 6 tháng đối với xe kinh doanh dịch vụ.

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

Hạn chế kỹ thuật hiện tại

  • Hệ thống mới thử nghiệm trên mô hình giả lập ECU bằng vi điều khiển STM32/Arduino, chưa thu thập mẫu dữ liệu trực tiếp trên nhiều hãng xe khác nhau (Toyota, Hyundai, Ford) để kiểm tra các mã PID mở rộng riêng biệt của từng hãng (Proprietary PIDs).
  • Chưa tích hợp module định vị GPS chuyên dụng (như NEO-6M/NEO-8M) để đồng bộ tọa độ không gian thực tế với thông số vận tốc và quãng đường.
  • Tính năng cảnh báo trên điện thoại còn phụ thuộc vào chất lượng đường truyền mạng di động 4G/LTE.

Hướng phát triển trong tương lai

  • Tích hợp module AI nhúng (TinyML): Triển khai mô hình học máy TensorFlow Lite trực tiếp trên Raspberry Pi 4 để phân tích chuỗi thời gian rung động và nhiệt độ, đưa ra dự đoán hỏng hóc sớm cho hệ thống làm mát và bugi đánh lửa (Predictive Maintenance).
  • Thiết kế mạch in nguyên khối (All-in-One Custom PCB): Gộp vi điều khiển, chip CAN controller, bộ chuyển đổi nguồn cách ly và module 4G LTE Quectel EC25 lên một bo mạch PCB 4 lớp duy nhất đạt chuẩn chống rung xóc trên xe hơi.
  • Nâng cấp giao thức UDS (Unified Diagnostic Services - ISO 14229): Mở rộng tính năng đọc và xóa toàn bộ bảng mã lỗi DTC chuẩn quốc tế kèm chức năng đọc dữ liệu chuyên sâu từng xilanh động cơ.

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

+----------------------------------------------------------------------------+
|                          ĐỐI TƯỢNG HƯỞNG LỢI                               |
+----------------------------------------------------------------------------+
| [Sinh viên & Học viên]   --> Tài liệu mẫu chuẩn về CAN Bus & Hệ thống nhúng|
| [Kỹ sư Lập trình Nhúng]  --> Source code mẫu chuẩn hóa kết nối Edge-to-Cloud|
| [Chủ phương tiện cá nhân]--> Bảng đồng hồ thông minh & Cảnh báo an toàn    |
| [Doanh nghiệp Vận tải]   --> Giải pháp số hóa viễn thông tiết kiệm chi phí |
+----------------------------------------------------------------------------+
  • Sinh viên và Giảng viên ngành Kỹ thuật Điện tử - Ô tô: Bản đề tài cung cấp tài liệu nghiên cứu hoàn chỉnh, chi tiết từ cấp độ thanh ghi giao tiếp SPI, cấu trúc vi điều khiển STM32 đến kỹ thuật lập trình hệ thống phân tán, là tài liệu tham khảo thực tế cho các môn học Mạng truyền thông công nghiệp và Hệ thống điện thân xe.
  • Kỹ sư phát triển phần mềm IoT (Embedded Developers): Cung cấp mô hình kiến trúc chuẩn kết hợp giữa phần cứng nhúng Linux (Raspberry Pi), cơ sở dữ liệu thời gian thực và framework di động Flutter.
  • Chủ phương tiện và Doanh nghiệp vận tải: Nâng cao độ an toàn vận hành, minh bạch hóa dữ liệu kỹ thuật phương tiện, kéo dài tuổi thọ động cơ và tối ưu hóa chi phí nhiên liệu.

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

1. Hệ thống cần đáp ứng yêu cầu phần cứng tối thiểu nào để có thể lắp đặt lên xe ô tô thực tế?

Hệ thống yêu cầu xe ô tô có cổng chẩn đoán chuẩn OBD-II 16 chân (bắt buộc trên tất cả các dòng xe sản xuất từ năm 1996 tại Mỹ và từ 2001 tại châu Á/châu Âu). Về phần cứng, cần bộ nguồn DC-DC chuyển đổi dải điện áp $9\text{V} - 28\text{V}$ về $5\text{V}-3\text{A}$ ổn định, bộ điều khiển CAN HAT (MCP2515 hoặc chip CAN tích hợp có bộ thu phát cách ly quang), máy tính nhúng Raspberry Pi 4 (hoặc Pi 3B+) và một kết nối mạng thông qua SIM 4G hoặc trạm phát Wi-Fi trên xe.

2. Khi xe đi vào vùng mất sóng di động hoặc đường hầm, dữ liệu có bị gián đoạn hay mất mát không?

Không. Hệ thống áp dụng kiến trúc xử lý kép. Khối hiển thị LCD 7 inch trên xe kết nối trực tiếp với Raspberry Pi qua mạng nội bộ tốc độ cao nên dữ liệu hiển thị tức thời hoàn toàn không bị ảnh hưởng bởi mạng Internet. Đối với dữ liệu viễn thông gửi lên Cloud, hệ thống được cấu hình bộ đệm nội bộ (Local Buffer) để tạm lưu dữ liệu và tự động kích hoạt tiến trình đồng bộ bù lên Firebase ngay khi kết nối 4G được khôi phục.

3. Tốc độ truyền của mạng CAN trong đề tài được thiết lập ở mức nào và có gây xung đột với các ECU khác trên xe không?

Hệ thống sử dụng tốc độ chuẩn $500\text{ kbps}$ với định dạng CAN 2.0B 11-bit Identifier (hoặc 29-bit Identifier mở rộng) theo chuẩn ISO 15765-4. Do hệ thống hoạt động ở chế độ chẩn đoán thụ động (Request/Response theo các ID chuẩn $0x7\text{DF}$ và $0x7\text{E8}$) với cơ chế phân xử bit ưu tiên của giao thức CAN (CSMA/CD+AMP), nó hoàn toàn không gây nhiễu hay làm gián đoạn các luồng dữ liệu an toàn của hệ thống phanh ABS, túi khí hay điều khiển động cơ trên xe.

4. Chi phí bảo trì và vận hành hệ thống hàng tháng ước tính là bao nhiêu?

Chi phí vận hành định kỳ cực kỳ thấp. Hệ thống sử dụng gói dịch vụ Firebase Spark/Blaze miễn phí cho hạn mức truy xuất dưới 1GB lưu lượng dữ liệu mỗi ngày (hoàn toàn đáp ứng cho việc giám sát 1 phương tiện hoạt động liên tục). Chi phí cố định duy nhất là gói cước dữ liệu di động (Data SIM 4G) duy trì khoảng $30.000 - 50.000\text{ VNĐ/tháng}$.

5. Hệ thống có thể mở rộng để đọc thêm các thông số áp suất lốp (TPMS) hay điều hòa không khí không?

Hoàn toàn có thể. Do chuẩn OBD-II định nghĩa sẵn các dải PID từ $0x40$ đến $0x5\text{F}$ cho các hệ thống an toàn và phụ trợ, nhà phát triển chỉ cần khai báo thêm mã PID mong muốn trong mảng cấu hình truy vấn của phần mềm trên Raspberry Pi và tạo thêm widget hiển thị tương ứng trên Flutter và Node-RED mà không cần can thiệp thay đổi cấu trúc phần cứng.

Kết luận

Đồ án tốt nghiệp "Thiết kế và thi công hệ thống giám sát và chẩn đoán trên ô tô" đã hoàn thành toàn diện các mục tiêu nghiên cứu và kỹ thuật đề ra. Dự án chứng minh tính khả thi và hiệu quả vượt trội của việc kết hợp mạng truyền thông trên ô tô (CAN/OBD-II), máy tính nhúng biên (Raspberry Pi 4), nền tảng đám mây thời gian thực (Firebase) và công nghệ lập trình ứng dụng di động đa nền tảng (Flutter).

Kết quả thử nghiệm khẳng định hệ thống đạt độ ổn định cao với thời gian đáp ứng CAN bus dưới $5\text{ ms}$, độ trễ đồng bộ đám mây dưới $250\text{ ms}$ và tỷ lệ mất gói tin chỉ $0.038%$. Đây là nền tảng kỹ thuật vững chắc, mở ra tiềm năng ứng dụng rộng rãi trong việc nâng cấp xe thông minh, tối ưu hóa quản lý giao thông đô thị và hiện thực hóa các giải pháp giao thông thông minh (Intelligent Transportation Systems - ITS) trong tương lai.