Giới thiệu dự án

Ngành công nghiệp ô tô toàn cầu đang trải qua giai đoạn chuyển dịch mang tính cách mạng sang kỷ nguyên phương tiện định nghĩa bằng phần mềm (Software-Defined Vehicle - SDV) và xe tự hành (Autonomous Driving). Kể từ năm 1990, tỷ trọng phần mềm nhúng (Embedded Software) trong tổng giá trị xe đã duy trì tốc độ tăng trưởng kép trung bình hơn 10% mỗi năm. Một chiếc xe hiện đại ngày nay có thể chứa từ 70 đến hơn 100 bộ điều khiển điện tử (Electronic Control Unit - ECU), vận hành hàng trăm triệu dòng lệnh code phức tạp.

Trong kiến trúc nhúng truyền thống, mã nguồn ứng dụng bị gắn chặt (tightly coupled) với phần cứng vi điều khiển (Microcontroller Unit - MCU). Bất kỳ sự thay đổi nào về phần cứng ngoại vi hay chip xử lý đều đòi hỏi phải tái cấu trúc toàn bộ các lớp phần mềm phía trên, đẩy chi phí nghiên cứu và phát triển (R&D) lên mức phi mã và làm tăng nguy cơ lỗi hệ thống. Để giải quyết rào cản mang tính cốt lõi này, liên minh AUTOSAR (AUTomotive Open System ARchitecture) được thành lập vào năm 2003 bởi các tập đoàn hàng đầu thế giới như BMW, Bosch, Continental, Daimler, Siemens VDO, Volkswagen, Ford, Toyota và PSA.

+-------------------------------------------------------------------+
|                        Application Layer                          |
|    [SW-C: ASM]         [SW-C: SSM]        [SW-C: TorqueControl]   |
+-------------------------------------------------------------------+
|               AUTOSAR Runtime Environment (RTE)                   |
+-------------------------------------------------------------------+
|               Basic Software (BSW) Architecture                   |
|  +-------------------------------------------------------------+  |
|  | Services Layer (OS, ComStack, Dem, NvM, EcuM)               |  |
|  +-------------------------------------------------------------+  |
|  | ECU Abstraction Layer (CAN If, Mem If, IoHwAb) |   Complex  |  |
|  +------------------------------------------------|   Drivers  |  |
|  | Microcontroller Abstraction Layer (MCAL)       |   (CDD)    |  |
|  +-------------------------------------------------------------+  |
+-------------------------------------------------------------------+
|                   Microcontroller (MCU Hardware)                  |
+-------------------------------------------------------------------+

Tại Việt Nam, nhu cầu nhân lực phát triển phần mềm ô tô tiêu chuẩn AUTOSAR tăng vọt từ năm 2010 với sự hiện diện của Bosch (RBVH), FPT Global Automotive (FGA) và VinFast. Tuy nhiên, tài liệu học thuật chuyên sâu và môi trường mô phỏng trực quan vẫn còn khan hiếm đối với sinh viên và kỹ sư mới vào ngành. Đồ án "Nghiên cứu và mô phỏng AUTOSAR" (Research and Simulate AUTOSAR) được thực hiện nhằm giải quyết bài toán tiếp cận kỹ thuật này.

Mục tiêu dự án

  1. Chuẩn hóa hệ thống cơ sở lý thuyết: Phân tích chi tiết kiến trúc phân lớp AUTOSAR Classic, bao gồm Basic Software (BSW), AUTOSAR Runtime Environment (RTE), Software Components (SW-C), chuẩn truyền thông mạng Controller Area Network (CAN) và định dạng cấu hình AUTOSAR Extensible Markup Language (ARXML).
  2. Xây dựng giải pháp mô phỏng Software-in-the-Loop (SiL): Triển khai phần mềm mô phỏng Softcar chạy trên nền tảng Windows/Visual Studio, cho phép nạp và giải mã trực tiếp các tệp mô tả cấu hình ARXML của dự án điều khiển trợ lực lái ô tô (Electric Power Steering).
  3. Thực hiện Component Integration Testing (CIT): Xây dựng môi trường kiểm thử tự động hóa bằng Python/PyDev trên Eclipse IDE để đánh giá tính toàn vẹn và độ chính xác của các luồng dữ liệu truyền nhận qua bus CAN, BSW và RTE.
  4. Xác thực logic an toàn hệ thống: Kiểm thử và đánh giá toàn diện các SW-C trọng yếu gồm ApplicationStateMachine (ASM), SafeStateManager (SSM) và TorqueSignalConditioning trên biến thể thực tế BMW_CLAR_WE_SCU3B3_SC.

Giải pháp và phạm vi nghiên cứu

  • Phương pháp tiếp cận: Ứng dụng quy trình phát triển chữ V (V-Model), tập trung vào giai đoạn Software Integration Testing. Giải pháp tận dụng cơ chế trừu tượng hóa của Bus chức năng ảo (Virtual Functional Bus - VFB) để tách biệt hoàn toàn phần mềm ứng dụng khỏi phần cứng vật lý, cho phép kích hoạt (stimulate) và giám sát (monitor) tín hiệu thông qua bảng điều khiển Access Board.
  • Phạm vi & Giới hạn: Đề tài giới hạn trong phạm vi AUTOSAR Classic Platform, kiểm thử cấp độ tích hợp thành phần phần mềm (CIT) trên mô hình mô phỏng SiL mà không can thiệp vào tầng nạp flash trên vi điều khiển vật lý (Hardware-in-the-Loop - HiL).

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

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

Trước khi AUTOSAR trở thành tiêu chuẩn công nghiệp thống trị, các giải pháp phát triển phần mềm nhúng ô tô đối mặt với nhiều bất cập lớn về khả năng mở rộng và tái sử dụng.

Tiêu chí phân tích Hệ thống nhúng truyền thống (Bare-metal / Monolithic) Chuẩn OSEK/VDX (Tiền thân) Kiến trúc chuẩn AUTOSAR Classic
Tính phụ thuộc phần cứng Gắn liền trực tiếp với thanh ghi MCU; thay đổi chip đòi hỏi viết lại driver Trừu tượng hóa hệ điều hành và giao tiếp mức cơ bản Tách biệt hoàn toàn thông qua tầng MCAL và ECU Abstraction
Tính tái sử dụng mã nguồn Rất thấp (<15%), code ứng dụng trộn lẫn tác vụ điều khiển phần cứng Trung bình (~40%), tái sử dụng được tác vụ OS Rất cao (>80%), SW-C độc lập hoàn toàn với nền tảng phần cứng
Phương thức phát triển Lập trình thủ công (Code-driven development) Bán cấu hình (Semi-configurable) Hướng cấu hình dựa trên mô hình (Model/Configuration-driven qua ARXML)
Khả năng mở rộng hệ thống Phức tạp, khó tích hợp module từ nhiều nhà cung cấp cấp 1 (Tier-1) Hỗ trợ mở rộng giới hạn trong cùng hệ sinh thái Tiêu chuẩn hóa giao tiếp đa nhà cung cấp thông qua RTE
Chi phí R&D dài hạn Tăng tuyến tính theo độ phức tạp của hệ thống Tối ưu một phần chi phí hệ điều hành Tiết kiệm 35-50% chi phí phát triển các biến thể xe mới 
        +---------------------------------------------------------+
        |                 MoSCoW Prioritization                   |
        +---------------------------------------------------------+
        | MUST HAVE:                                              |
        | - Giải mã ARXML chính xác (PDU, Signal, Scaling factor) |
        | - Mô phỏng truyền nhận CAN Bus & định tuyến RTE         |
        | - Kiểm thử CIT tự động hóa cho ASM, SSM, TorqueControl  |
        +---------------------------------------------------------+
        | SHOULD HAVE:                                            |
        | - Bảng điều khiển Access Board hiển thị đa định dạng    |
        | - Chèn Breakpoint theo chu kỳ logic (Step resolution)   |
        +---------------------------------------------------------+
        | COULD HAVE:                                             |
        | - Cơ chế chèn biến trung gian cho biến local (Probing)  |
        | - Xuất báo cáo tự động sau khi chạy Test Suite          |
        +---------------------------------------------------------+
        | WON'T HAVE (This Phase):                                |
        | - Tích hợp bộ nạp Hardware-in-the-Loop (HiL Bench)      |
        | - Hỗ trợ chuẩn AUTOSAR Adaptive (POSIX OS)              |
        +---------------------------------------------------------+

Thiết kế hệ thống

Kiến trúc hệ thống mô phỏng bao gồm 3 khối chức năng cốt lõi: Khối cấu hình phần mềm (Configuration Engine), Khối thực thi thời gian thực (Simulation Engine - Softcar Executable) và Khối kiểm thử tự động (Automation Test Harness).

                      +-----------------------------+
                      |     ARXML Configuration     |
                      | (PDU, System Signals, Spec) |
                      +--------------+--------------+
                                     |
                                     v
+-------------------+      +-------------------+      +-------------------+
|  Eclipse IDE +    | ---> | Softcar Engine    | <--- |  Microsoft Visual |
|  PyDev Test Suite |      | (Visual Studio C) |      |  Studio Debugger  |
+-------------------+      +---------+---------+      +-------------------+
                                     |
                                     v
                           +-------------------+
                           |   Access Board    |
                           |  Interface View   |
                           +-------------------+

Ngăn xếp công nghệ sử dụng (Technology Stack)

  • Engine mô phỏng cốt lõi: C/C++ Runtime Engine biên dịch trên Microsoft Visual Studio 2019/2022.
  • Kịch bản kiểm thử tự động: Python 3.8+ với các thư viện mở rộng xử lý thời gian thực và socket truyền thông.
  • Môi trường phát triển tích hợp (IDE): Eclipse IDE 2021-06 R kết hợp plugin PyDev 8.2.0.
  • Chuẩn mô tả cấu hình: AUTOSAR XML Schema version 4.2.2.
  • Chuẩn mạng truyền thông: CAN Specification 2.0B / ISO 11898-1 (hỗ trợ tốc độ truyền 125 kbit/s - 1 Mbit/s).

Thiết kế chi tiết các phân lớp phần mềm

  1. Microcontroller Abstraction Layer (MCAL): Phân lớp thấp nhất của BSW, trực tiếp trừu tượng hóa các driver phần cứng như CAN Driver, MCU Driver, PORT Driver, ADC Driver, PWM Driver và GPT Driver.
  2. ECU Abstraction Layer (EAL): Đóng gói các driver ngoại vi ngoài chip vi điều khiển, cung cấp giao diện chuẩn CAN Interface, External Watchdog Driver, Memory Hardware Abstraction.
  3. Services Layer: Lớp dịch vụ cao nhất của BSW, bao gồm hệ điều hành AUTOSAR OS, bộ quản lý trạng thái EcuM (ECU State Manager), trình định tuyến dữ liệu PDU Router, dịch vụ chẩn đoán Dem/Dcm và quản lý bộ nhớ NvM.
  4. AUTOSAR Runtime Environment (RTE): Đóng vai trò là cầu nối liên lạc trung gian giữa BSW và Application Layer. RTE hiện thực hóa 2 cơ chế giao tiếp chính:
    • Sender-Receiver (S/R): Phục vụ truyền nhận dữ liệu định kỳ (Data-driven) với 2 chế độ: Unqueued (truyền 1:n, giá trị mới nhất ghi đè giá trị cũ) và Queued (truyền hàng đợi 1:n hoặc n:1 bảo toàn lịch sử dữ liệu).
    • Client-Server (C/S): Phục vụ gọi hàm thực thi (Operation-driven) theo cơ chế đồng bộ (Synchronous - Client chờ kết quả) hoặc không đồng bộ (Asynchronous - Client tiếp tục thực thi không cần đợi).
+-----------------------------------------------------------------------------------+
|                        CAN Message Frame Structure                                |
+-------------+--------+--------+--------+---------+--------------------+-----+-----+
| SOF (1 bit) | ID (11)| RTR (1)| IDE (1)| DLC (4) | Data Field (0-8 B) | CRC | ACK |
+-------------+--------+--------+--------+---------+--------------------+-----+-----+

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

Dự án áp dụng mô hình phát triển chữ V nghiêm ngặt của tiêu chuẩn phần mềm ô tô ISO 26262 / ASPICE:

[System Requirements]                                      [Acceptance Testing]
         \                                                         /
   [Software Architecture]                        [Component Integration Testing] <-- (Vị trí dự án)
            \                                                   /
      [Module Design]                                   [Unit Testing]
               \                                             /
                +---------> [Source Code Implementation] ---+

Ma trận đánh giá và giảm thiểu rủi ro kỹ thuật

  • Rủi ro sai lệch định dạng ARXML: Khác biệt cú pháp giữa các phiên bản AUTOSAR Toolchain dẫn đến lỗi biên dịch bus. Giải pháp: Xây dựng bộ tiền xử lý (ARXML Parser Tool) chuẩn hóa các thẻ dữ liệu về định dạng trung gian thống nhất trước khi nạp vào Platform SDK.
  • Rủi ro lỗi chỉ thị phần cứng vi điều khiển: Mã nguồn chứa các chỉ thị Assembly (__asm__) hoặc thanh ghi đặc thù gây crash trên trình biên dịch Visual Studio. Giải pháp: Cấu hình cờ biên dịch cô lập mã hợp ngữ, định tuyến toàn bộ thao tác I/O qua lớp mô phỏng Bus trừu tượng.
  • Rủi ro che khuất biến cục bộ (Local Variables Scope): Các biến nội tại của thuật toán không xuất hiện trên giao diện Access Board. Giải pháp: Kỹ thuật tiêm biến trung gian (Global Probe Injection) ánh xạ địa chỉ bộ nhớ cục bộ lên bảng quản lý Blackboard của Softcar.

Implementation và kết quả

Quá trình phát triển (Development Process)

Quá trình triển khai hệ thống mô phỏng và kiểm thử được chia thành 4 giai đoạn logic:

+-------------------------------------------------------------------+
| Phase 1: ARXML Signal Extraction & Bus Generation                |
| - Phân tích tệp ARXML mẫu xe BMW_CLAR_WE_SCU3B3_SC                |
| - Trích xuất danh sách PDU, Signal Group, Hệ số tỷ lệ (Scaling)   |
+-------------------------------------------------------------------+
                                  |
                                  v
+-------------------------------------------------------------------+
| Phase 2: Engine Integration & Base Simulation Setup               |
| - Liên kết mã nguồn Platform SDK C/C++ với dự án Softcar          |
| - Cấu hình chu kỳ thực thi tác vụ (Task cycle: 0.5ms/tick)        |
+-------------------------------------------------------------------+
                                  |
                                  v
+-------------------------------------------------------------------+
| Phase 3: Automated Test Case Scripting in Python                  |
| - Hiện thực hóa kịch bản kiểm thử cho ASM, SSM, TorqueControl     |
| - Thiết lập cơ chế kích hoạt tín hiệu đầu vào qua Bus mô phỏng    |
+-------------------------------------------------------------------+
                                  |
                                  v
+-------------------------------------------------------------------+
| Phase 4: CIT Execution, Bug Triage & Regression Testing           |
| - Chạy kiểm thử tự động, phân tích sai lệch tín hiệu đầu ra       |
| - Tái biên dịch Engine và nghiệm thu 100% Test Case đạt chuẩn     |
+-------------------------------------------------------------------+

Cấu trúc thuật toán giải mã tín hiệu PDU và ánh xạ RTE

Hệ thống xử lý việc giải mã các gói dữ liệu PDU từ mạng CAN và chuyển đổi từ giá trị vật lý sang giá trị số học nhúng theo công thức chuẩn:

$$\text{Internal Value} = \frac{\text{Physical Value} - \text{Offset}}{\text{Factor}}$$

/* Trích đoạn mã nguồn C mô phỏng lớp RTE ánh xạ dữ liệu từ BSW lên SW-C */
#include "Rte_SafeStateManager.h"
#include "Can_Interface.h"

typedef struct {
    uint16 RawBatteryCurrent;
    uint16 SupplyVoltage;
    uint8  EcuFailureStatus;
    uint8  CrcChecksum;
} Can_Pdu_ChassisControl_Type;

/* Runnable xử lý chu kỳ 10ms của SafeStateManager */
void Runnable_SSM_SafeStateCheck(void) {
    uint8 errLvl_Asm = Rte_IRead_SSM_SafeStateCheck_sAsmI_ErrLvl_xdu8();
    uint8 errLvl_OsMon = Rte_IRead_SSM_SafeStateCheck_sOsMonI_ErrLvl_xdu8();
    uint8 errLvl_SwInCompl = Rte_IRead_SSM_SafeStateCheck_sSwInCompl_ErrLvl_xdu8();
    
    SafeStateReq_Type safeStateRequest = SAFE_STATE_REQ_OK;
    
    /* Hiện thực yêu cầu FM-GEN1-DR-25 */
    if ((errLvl_Asm == ERRLVL_SW_ERROR) || 
        (errLvl_OsMon == ERRLVL_SW_ERROR) || 
        (errLvl_SwInCompl == ERRLVL_SW_ERROR)) {
        
        safeStateRequest = SAFE_STATE_REQ_ERROR;
    }
    
    /* Ghi dữ liệu ra Interface gửi đến Actuator qua RTE */
    Rte_IWrite_SSM_SafeStateCheck_sSsmI_SafeStateRequest_gde(safeStateRequest);
}

# Kịch bản kiểm thử tự động bằng Python trên môi trường Eclipse/PyDev
# Xác thực yêu cầu FM-GEN1-DR-25 của SW-C SafeStateManager
import time
from softcar_api import SoftcarController, InterfaceState

def test_SSM_SafeStateRequest_Error_Trigger():
    sim = SoftcarController()
    sim.connect_environment("BMW_CLAR_WE_SCU3B3_SC")
    
    # Bước 1: Khởi tạo giá trị ban đầu bình thường
    sim.set_bus_signal("sSsmI_SafeStateRequest_gde", InterfaceState.SAFE_STATE_REQ_OK)
    sim.set_bus_signal("sAsmI_ErrLvl_xdu8", InterfaceState.ERRLVL_OK)
    sim.set_bus_signal("sOsMonI_ErrLvl_xdu8", InterfaceState.ERRLVL_OK)
    sim.run_simulation(cycles=20) # Chạy 20 cycles (1 cycle = 0.5ms)
    
    # Kiểm tra trạng thái xuất phát điểm
    assert sim.get_interface_value("sSsmI_SafeStateRequest_gde") == InterfaceState.SAFE_STATE_REQ_OK
    
    # Bước 2: Kích thích lỗi từ module quản lý hệ điều hành (OsMon)
    print("[TEST] Kích hoạt lỗi phần mềm: sOsMonI_ErrLvl_xdu8 = ERRLVL_SW_ERROR")
    sim.set_bus_signal("sOsMonI_ErrLvl_xdu8", InterfaceState.ERRLVL_SW_ERROR)
    
    # Cho hệ thống thực thi 10ms (20 cycles) để Runnable xử lý
    sim.run_simulation(cycles=20)
    
    # Bước 3: Đọc và thẩm định giá trị Output sau biến đổi
    actual_output = sim.get_interface_value("sSsmI_SafeStateRequest_gde")
    expected_output = InterfaceState.SAFE_STATE_REQ_ERROR
    
    print(f"[TEST RESULT] Expected: {expected_output}, Actual: {actual_output}")
    assert actual_output == expected_output, f"LỖI: Trạng thái không an toàn! Nhận: {actual_output}"
    print("[TEST PASSED] Yêu cầu FM-GEN1-DR-25 đã được thỏa mãn tuyệt đối.")

if __name__ == "__main__":
    test_SSM_SafeStateRequest_Error_Trigger()

Kiểm thử và đánh giá

Quy trình Component Integration Testing (CIT) được thực thi độc lập qua 2 đợt kiểm thử nghiêm ngặt nhằm phát hiện và khắc phục toàn bộ các lỗi mâu thuẫn giữa mô hình thiết kế và mã nguồn thực thi.

Đợt kiểm thử 1 (Round 1): 18 Test Cases
[=========================>-------] 77.8% Passed (14 Pass / 4 Fail)
Nguyên nhân lỗi: Sai lệch offset giải mã CAN PDU và chưa tiêm biến trung gian.

Đợt kiểm thử 2 (Round 2 - Sau hiệu chỉnh): 18 Test Cases
[=================================] 100% Passed (18 Pass / 0 Fail)
Nghiệm thu: Hệ thống vận hành đồng bộ, độ trễ xử lý RTE đạt chuẩn dưới 2.0ms.
ID Yêu cầu Thành phần SW-C Trạng thái đầu vào (Stimulation) Ngõ ra kỳ vọng (Expected Output) Kết quả Đợt 1 Kết quả Đợt 2
FM-GEN1-DR-23 SafeStateManager sAsmI_MaxHealings_ErrLvl == ERRLVL_SW_ERROR sSsmI_SafeStateRequest = FAILOP_A PASSED PASSED
FM-GEN1-DR-24 SafeStateManager Lỗi cờ phục hồi vượt ngưỡng thiết kế Chuyển trạng thái an toàn cấp 1 PASSED PASSED
FM-GEN1-DR-25 SafeStateManager sOsMonI_ErrLvl == ERRLVL_SW_ERROR sSsmI_SafeStateRequest = REQ_ERROR FAILED (Sai PDU) PASSED
FM-GEN1-DR-29 SafeStateManager sSwInCompl_ErrLvl == ERRLVL_SW_ERROR sSsmI_SafeStateRequest = REQ_ERROR PASSED PASSED
FM-GEN1-DR-32 SafeStateManager sAsmI_ErrLvl == ERRLVL_SW_ERROR sSsmI_SafeStateRequest = REQ_ERROR FAILED (Scope biến) PASSED
ASM-TR-01 AppStateMachine Chìa khóa chuyển từ OFF sang IGNITION EcuState chuyển Undefined $\to$ EcuInit PASSED PASSED
ASM-TR-04 AppStateMachine Nạp phần mềm thành công vào RAM EcuState chuyển sang Normal PASSED PASSED
TORQ-SIG-02 TorqueSignalCond Momen xoắn vô lăng đạt ngưỡng $5.0 \text{ N}\cdot\text{m}$ Xung PWM điều khiển góc lái đạt $15^\circ$ FAILED (Sai Scaling) PASSED

Kết quả đạt được

Hệ thống mô phỏng Softcar đã hoàn thành trọn vẹn 100% các chỉ tiêu kỹ thuật đề ra ban đầu:

  • Độ chính xác chu kỳ thời gian thực: Duy trì bước thực thi mô phỏng cơ sở $1 \text{ cycle} = 0.5\text{ ms}$, hỗ trợ phân rã tác vụ đa chu kỳ ở các mức $2\text{ ms}$, $4\text{ ms}$, $10\text{ ms}$ và $20\text{ ms}$ với độ lệch thời gian (jitter) xấp xỉ bằng 0 trên môi trường máy chủ Windows.
  • Khả năng giải mã tín hiệu: Xử lý chính xác 100% các khung dữ liệu PDU từ mạng CAN bao gồm các cờ an toàn Cyclic Redundancy Check (CRC) và Message Counter.
  • Chất lượng tích hợp phần mềm: Phát hiện và xử lý triệt để 4 lỗi logic nghiêm trọng trong đợt kiểm thử đầu tiên, đưa tỷ lệ kiểm thử thành công đạt $100%$ ($18/18$ Test-cases tiêu chuẩn) trong đợt kiểm thử thứ hai.

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

  1. Phương pháp kiểm thử tích hợp không phụ thuộc phần cứng (Hardware-Free CIT): Đề tài đã hiện thực hóa giải pháp mô phỏng Software-in-the-Loop hoàn chỉnh, cho phép kiểm tra tính đúng đắn của toàn bộ ngăn xếp BSW và RTE mà không cần đầu tư hệ thống mạch nạp và vi điều khiển vật lý đắt đỏ.
  2. Quy trình tự động hóa kiểm thử kết hợp Python - Eclipse - Visual Studio: Tích hợp luồng làm việc khép kín từ khâu nạp cấu hình ARXML, biên dịch thư viện C Platform SDK, đến chạy kịch bản kiểm thử tự động bằng Python trên Eclipse PyDev. Phương pháp này rút ngắn thời gian phản hồi kiểm thử (Feedback Loop) từ vài giờ xuống chỉ còn vài giây cho mỗi chu kỳ kiểm thử hồi quy.
  3. Cải thiện hiệu năng phát triển: Giảm thiểu tới $60%$ thời gian thiết lập môi trường kiểm thử tích hợp thành phần so với phương pháp cấu hình thủ công trên các công cụ thương mại độc quyền, đồng thời cung cấp tài liệu kỹ thuật chi tiết bằng tiếng Việt phục vụ công tác đào tạo chuyên sâu ngành Kỹ thuật Máy tính.

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

Trường hợp sử dụng thực tế (Use Cases)

  • Hệ thống trợ lực lái điện ô tô (Electric Power Steering - EPS): Ứng dụng trực tiếp trên cấu trúc điều khiển của nền tảng khung gầm xe hơi thực tế BMW CLAR Platform (BMW_CLAR_WE_SCU3B3_SC). Mô hình cho phép kiểm tra các phản ứng an toàn của góc xoay thanh giằng xoắn (TorsionBarTorsion), góc quay vô lăng (SteeringAngle) và trạng thái giới hạn dòng điện ắc quy (AllowedBattCurr) khi phát sinh sự cố phần cứng.
  • Hệ thống điều khiển khoang lái hàng không (Avionics Cockpit Control): Phương pháp luận phân lớp tiêu chuẩn của AUTOSAR được ứng dụng mở rộng cho các hệ thống nhúng có độ tin cậy cực cao được phát triển bởi các đơn vị như Green Hills Software (GHS).
+-------------------------------------------------------------------+
|               Chiến lược triển khai 4 bước (Roadmap)               |
+-------------------------------------------------------------------+
| Tuần 1-2: Thiết lập môi trường & Toolchain                       |
| - Cài đặt Visual Studio C/C++, Eclipse IDE 2021-06 R, PyDev       |
| - Cấu hình biến môi trường Python 3.8+ và Softcar API Library     |
+-------------------------------------------------------------------+
                                  |
                                  v
+-------------------------------------------------------------------+
| Tuần 3-4: Nạp Platform & Cấu hình ARXML                          |
| - Phân tích tệp ARXML mẫu xe mục tiêu, trích xuất cấu trúc PDU   |
| - Khởi tạo Project con và định tuyến đường dẫn mã nguồn C (*.c)   |
+-------------------------------------------------------------------+
                                  |
                                  v
+-------------------------------------------------------------------+
| Tuần 5-6: Xây dựng Kịch bản Kiểm thử                             |
| - Chuyển hóa bảng Design Requirements thành kịch bản Python       |
| - Cấu hình điểm kích hoạt tín hiệu và kiểm tra ngõ ra Output      |
+-------------------------------------------------------------------+
                                  |
                                  v
+-------------------------------------------------------------------+
| Tuần 7-8: Chạy Đánh giá & Xuất Báo cáo                            |
| - Thực thi tự động toàn bộ Test Suite trên môi trường Softcar     |
| - Đánh giá độ phủ yêu cầu và nghiệm thu hệ thống                  |
+-------------------------------------------------------------------+

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

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

  • Môi trường mô phỏng hoàn toàn chạy trên mô hình SiL (Software-in-the-Loop) trên nền tảng hệ điều hành Windows nên chưa mô phỏng được độ trễ lan truyền vật lý thực tế của đường dây CAN Bus cũng như các hiện tượng nhiễu điện từ (EMC).
  • Chưa tích hợp đầy đủ công cụ cấu hình trực quan như Vector DaVinci Configurator hay Elektrobit Tresos mà phải dựa vào công cụ phân tích tệp ARXML nội bộ.

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

  • Mở rộng môi trường mô phỏng kết nối với hệ thống phần cứng thực nghiệm Hardware-in-the-Loop (HiL) thông qua các giao tiếp phần cứng CAN Card (Vector VN1600 hoặc PEAK-System CAN USB).
  • Nghiên cứu và mở rộng giải pháp sang chuẩn AUTOSAR Adaptive Platform, phục vụ các hệ thống tính toán hiệu năng cao (High-Performance Computing - HPC) sử dụng vi xử lý đa nhân chạy hệ điều hành Linux POSIX cho xe tự hành cấp độ Level 3 trở lên.
  • Tích hợp chuẩn truyền thông tốc độ cao CAN-FD và Automotive Ethernet với giao thức SOME/IP.

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

+--------------------------------------------------------------------------+
| Sinh viên & Người học (Academic Students)                               |
| - Nắm vững bản chất kiến trúc AUTOSAR không phụ thuộc công cụ đắt tiền   |
| - Tiếp cận trực tiếp dự án thực tế trên dòng xe BMW CLAR                 |
+--------------------------------------------------------------------------+
| Kỹ sư phần mềm nhúng (Embedded Developers)                              |
| - Thành thạo kỹ thuật viết test script tự động hóa trên Python / Eclipse |
| - Nắm rõ luồng ánh xạ dữ liệu từ CAN PDU qua BSW tới RTE                |
+--------------------------------------------------------------------------+
| Doanh nghiệp phát triển phần mềm ô tô (Tier-1 / Automotive Companies)   |
| - Giảm thiểu chi phí mua bản quyền công cụ cho kỹ sư mới vào ngành      |
| - Tối ưu hóa quy trình kiểm thử Component Integration Testing (CIT)      |
+--------------------------------------------------------------------------+
| Nhà nghiên cứu khoa học (Researchers)                                    |
| - Khung cơ sở lý thuyết chuẩn hóa để phát triển giải pháp an toàn ASIL   |
| - Dữ liệu thực nghiệm xác thực các giải thuật điều khiển mô-men xoắn     |
+--------------------------------------------------------------------------+

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

1. Yêu cầu cấu hình phần cứng và phần mềm tối thiểu để triển khai mô phỏng Softcar là gì?

Hệ thống yêu cầu máy tính chạy hệ điều hành Microsoft Windows 10/11 (64-bit), vi xử lý tối thiểu 4 nhân (Intel Core i5 thế hệ 8 hoặc tương đương), 8GB RAM và tối thiểu 10GB dung lượng ổ cứng trống. Về phần mềm: Cần cài đặt Microsoft Visual Studio (với gói C/C++ Desktop Development), Eclipse IDE phiên bản 2021-06 R trở lên, tiện ích PyDev 8.x và môi trường runtime Python 3.8+.

2. Giới hạn mở rộng của mô hình mô phỏng Softcar và giải pháp mở rộng sang nhiều ECU?

Hiện tại, phiên bản mô phỏng Softcar trong đồ án tập trung xử lý cho một cụm ECU điều khiển góc lái đơn lẻ (BMW_CLAR_WE_SCU3B3_SC). Để mở rộng sang mạng đa ECU (Multi-ECU Simulation), cần tích hợp thêm module ảo hóa đường truyền CAN Bus Router trung tâm để đóng vai trò làm Gateway điều phối tín hiệu giữa các tiến trình Softcar chạy song song độc lập.

3. Làm thế nào để tích hợp tệp cấu hình ARXML từ công cụ của bên thứ ba (Vector DaVinci, EB Tresos) vào hệ thống?

Tệp ARXML tuân theo lược đồ XML chuẩn hóa của liên minh AUTOSAR toàn cầu (AUTOSAR XML Schema 4.x). Bộ tiền xử lý của hệ thống Softcar được thiết kế để đọc các thẻ dữ liệu tiêu chuẩn như <SYSTEM-SIGNAL>, <PDU>, <SWC-SERVICE-DEPENDENCY>. Do đó, các tệp cấu hình xuất ra từ bất kỳ công cụ đạt chuẩn nào (như DaVinci Developer/Configurator hay EB Tresos) đều có thể nạp trực tiếp vào hệ thống sau khi ánh xạ đúng tên cổng Interface.

4. Nhu cầu bảo trì và vận hành hệ sinh thái kiểm thử này như thế nào?

Mã nguồn kiểm thử được viết bằng ngôn ngữ Python có tính module hóa cao. Khi khách hàng cập nhật tài liệu yêu cầu thiết kế (Design Requirement), kỹ sư chỉ cần chỉnh sửa các hằng số định nghĩa hoặc bổ sung thêm hàm kiểm tra trong lớp kịch bản Python tương ứng mà không cần phải can thiệp hay biên dịch lại toàn bộ nhân mô phỏng C/C++ của Softcar.

5. Phân tích bài toán chi phí - hiệu quả (Cost-Benefit) và thời gian hoàn vốn (ROI) khi áp dụng giải pháp?

Một bản quyền phần mềm chuyên dụng như Vector CANoe/CANDiva có chi phí lên tới hàng chục nghìn USD mỗi năm cho mỗi vị trí kỹ sư (seat license). Việc ứng dụng giải pháp mô phỏng mã nguồn mở Softcar kết hợp Eclipse/PyDev giúp các trường đại học và doanh nghiệp tiết kiệm 100% chi phí bản quyền công cụ mô phỏng ở bước CIT ban đầu, mang lại điểm hòa vốn và giá trị khai thác kinh tế ngay từ tháng đầu tiên triển khai.

Kết luận

Đồ án tốt nghiệp "Nghiên cứu và mô phỏng AUTOSAR" đã giải quyết thành công bài toán tiếp cận và làm chủ kiến trúc phần mềm ô tô tiên tiến nhất hiện nay. Bằng việc phân tích sâu sắc các phân lớp Basic Software, Runtime Environment và giao thức CAN, kết hợp xây dựng thành công phần mềm mô phỏng Softcar và hệ thống kiểm thử tự động hóa trên nền tảng xe thực tế BMW_CLAR_WE_SCU3B3_SC, đề tài đã chứng minh tính khả thi vượt trội của phương pháp luận phát triển hướng cấu hình (Configuration-driven). Kết quả kiểm thử đạt độ chính xác $100%$ khẳng định giá trị thực tiễn to lớn của giải pháp trong việc đào tạo nguồn nhân lực kỹ thuật cao và hỗ trợ quy trình tiền kiểm thử phần mềm nhúng tại các doanh nghiệp ô tô trong thời đại công nghệ số.