Năm bài trước của series này đã dựng xong một chiếc xe biết nhìn, biết mình ở đâu, và biết nên làm gì. Bài 5 kết thúc với một bộ MPC giải xong trong 3 ms và một kết quả benchmark đẹp. Nhưng giữa "chạy tốt trong mô phỏng" và "được phép bán cho người thật" còn một khoảng cách mà phần lớn kỹ sư phần mềm chưa từng phải bước qua.
Khoảng cách đó có một cái tên cụ thể: bạn không thể chứng minh an toàn bằng cách lái thử.
Nghiên cứu kinh điển của RAND Corporation, Driving to Safety (Kalra & Paddock, 2016), tính ra con số này: để chứng minh với độ tin cậy 95% rằng một hệ thống tự hành có tỷ lệ tử vong thấp hơn tài xế người, đội xe của bạn phải chạy khoảng 275 triệu dặm không xảy ra tai nạn chết người — và nếu muốn chứng minh nó tốt hơn 20% thì con số lên tới hàng tỷ dặm. Với một đội 100 xe chạy 24/7 ở tốc độ trung bình 25 dặm/giờ, 275 triệu dặm mất khoảng 12,5 năm. Không hãng nào đủ kiên nhẫn, và không phiên bản phần mềm nào sống lâu đến vậy.
Vì thế ngành ô tô không chứng minh an toàn bằng thống kê thô. Nó chứng minh bằng quy trình có cấu trúc: ISO 26262 cho lỗi linh kiện, ISO 21448 (SOTIF) cho giới hạn năng lực, và một bộ kịch bản có chủ đích thay cho hàng trăm triệu dặm ngẫu nhiên.
Roadmap series
- Bài 1 — SAE Level 2 vs 2+ vs 3 vs 4: xác định ai chịu trách nhiệm lái, ODD và fallback.
- Bài 2 — Sensor fusion: camera, radar và LiDAR dựng perception suy giảm an toàn khi cảm biến lỗi.
- Bài 3 — Perception: 3D detection, occupancy grid và tracking trên nuScenes.
- Bài 4 — Localization và HD map: GNSS/IMU fusion, NDT trên LiDAR, hướng map-free.
- Bài 5 — Planning & control: từ rule-based tới MPC và PDM, bám quỹ đạo thực tế.
- Bài 6 — Validation: ISO 26262, SOTIF và Euro NCAP — chứng minh an toàn khi không lái đủ km.
ISO 26262 — an toàn chức năng: chuyện gì xảy ra khi linh kiện hỏng
ISO 26262 (bản hiện hành: 2018, gồm 12 phần) trả lời một câu hỏi hẹp nhưng sâu: nếu một thành phần trong hệ thống hỏng, hậu quả có thể tệ đến đâu, và ta phải nghiêm ngặt đến mức nào để ngăn điều đó?
Chú ý chữ "hỏng". ISO 26262 giả định hệ thống được thiết kế đúng; nó lo về bit lật trong RAM, transistor cháy, cảm biến ngừng gửi dữ liệu, bus CAN mất gói. Nó không lo về chuyện camera nhìn nhầm một chiếc xe tải trắng thành bầu trời — đó là lãnh địa của SOTIF ở phần sau.
HARA: từ nguy hiểm tới mức ASIL
Quy trình bắt đầu bằng HARA (Hazard Analysis and Risk Assessment). Với mỗi tình huống nguy hiểm, kỹ sư chấm ba trục:
| Trục | Ý nghĩa | Thang |
|---|---|---|
| S — Severity | Mức thương tổn nếu xảy ra | S0 (không thương tích) → S3 (đe doạ tính mạng) |
| E — Exposure | Tình huống đó xuất hiện thường xuyên đến đâu | E0 (gần như không) → E4 (rất thường xuyên) |
| C — Controllability | Tài xế bình thường có tránh được không | C0 (kiểm soát được hoàn toàn) → C3 (khó hoặc không thể) |
Ba giá trị đó tra vào một bảng cho ra mức ASIL (Automotive Safety Integrity Level) từ QM (chỉ cần quản lý chất lượng thông thường) đến ASIL D (nghiêm ngặt nhất). Bảng của ISO 26262-3 có một cấu trúc đẹp mà ít tài liệu nói ra: nó hoàn toàn tương đương với phép cộng chỉ số.
"""Tra mức ASIL theo bảng ISO 26262-3 (HARA).
Chạy được ngay: python3 asil.py
"""
S_LEVELS = {"S0": 0, "S1": 1, "S2": 2, "S3": 3}
E_LEVELS = {"E0": 0, "E1": 1, "E2": 2, "E3": 3, "E4": 4}
C_LEVELS = {"C0": 0, "C1": 1, "C2": 2, "C3": 3}
# Tổng chỉ số S+E+C: <=6 -> QM, 7 -> A, 8 -> B, 9 -> C, 10 -> D
_BY_SUM = {7: "ASIL A", 8: "ASIL B", 9: "ASIL C", 10: "ASIL D"}
def determine_asil(s: str, e: str, c: str) -> str:
si, ei, ci = S_LEVELS[s], E_LEVELS[e], C_LEVELS[c]
# S0 (không thương tích), E0 (không bao giờ xảy ra) hoặc C0 (luôn kiểm soát được)
# đều đưa về QM theo định nghĩa của tiêu chuẩn.
if si == 0 or ei == 0 or ci == 0:
return "QM"
return _BY_SUM.get(si + ei + ci, "QM")
HAZARDS = [
# (mô tả, S, E, C)
("Mất trợ lực lái ở tốc độ cao", "S3", "E4", "C3"),
("AEB phanh gấp sai trên cao tốc (false brake)", "S3", "E3", "C3"),
("Lane keeping đánh lái sai sang làn ngược chiều", "S3", "E4", "C2"),
("Adaptive cruise không giảm tốc khi vào cua", "S2", "E4", "C1"),
("Đèn báo ADAS trên bảng đồng hồ tắt", "S0", "E4", "C1"),
]
if __name__ == "__main__":
for desc, s, e, c in HAZARDS:
print(f"{determine_asil(s, e, c):>7} | {s}/{e}/{c} | {desc}")
Kết quả:
ASIL D | S3/E4/C3 | Mất trợ lực lái ở tốc độ cao
ASIL C | S3/E3/C3 | AEB phanh gấp sai trên cao tốc (false brake)
ASIL C | S3/E4/C2 | Lane keeping đánh lái sai sang làn ngược chiều
ASIL A | S2/E4/C1 | Adaptive cruise không giảm tốc khi vào cua
QM | S0/E4/C1 | Đèn báo ADAS trên bảng đồng hồ tắt
ASIL không phải nhãn dán — nó là hoá đơn
Mức ASIL quyết định các chỉ tiêu định lượng mà phần cứng phải đạt (ISO 26262-5):
| Chỉ tiêu | ASIL B | ASIL C | ASIL D |
|---|---|---|---|
| SPFM — tỷ lệ lỗi đơn điểm được bao phủ | ≥ 90% | ≥ 97% | ≥ 99% |
| LFM — tỷ lệ lỗi tiềm ẩn được bao phủ | ≥ 60% | ≥ 80% | ≥ 90% |
| PMHF — xác suất lỗi nguy hiểm ngẫu nhiên | < 100 FIT | < 100 FIT | < 10 FIT |
1 FIT = 1 lỗi trên 10⁹ giờ hoạt động. Dưới 10 FIT nghĩa là: nếu bạn có một tỷ ECU cùng loại chạy liên tục một giờ, được phép có chưa tới 10 cái hỏng theo kiểu nguy hiểm. Đây là lý do một ECU ASIL D đắt gấp nhiều lần một board có cùng năng lực tính toán.
Và vì ASIL D đắt, ngành dùng một thủ thuật hợp chuẩn gọi là ASIL decomposition: một yêu cầu ASIL D có thể tách thành hai yêu cầu ASIL B(D) độc lập về mặt lỗi chạy trên hai kênh riêng. Chữ "(D)" nhắc rằng gốc của nó vẫn là D. Điều kiện sống còn là chứng minh được freedom from interference — hai kênh không chia sẻ nguồn điện, xung nhịp, bộ nhớ hay nguyên nhân hỏng chung nào. Một team ghép hai kênh "độc lập" lên cùng một con SoC và cùng một nguồn 5 V thì phép tách đó vô giá trị.
ISO 21448 (SOTIF) — khi không có gì hỏng cả
Năm 2016, một chiếc xe đang bật hệ thống hỗ trợ lái đâm vào rơ-moóc trắng cắt ngang đường trong điều kiện nắng gắt. Không có linh kiện nào hỏng. Camera hoạt động đúng thiết kế, phần mềm chạy đúng code, không có bit nào lật. Hệ thống chỉ đơn giản là không đủ năng lực phân biệt một thành xe tải màu sáng với nền trời.
ISO 26262 không có gì để nói về tình huống đó. ISO 21448:2022 — Safety Of The Intended Functionality (SOTIF) ra đời chính vì khoảng trống này.
Bốn vùng của SOTIF
SOTIF chia toàn bộ không gian kịch bản thành bốn vùng:
AN TOÀN NGUY HIỂM
┌──────────────────┬──────────────────┐
ĐÃ BIẾT │ Vùng 1 │ Vùng 2 │
│ biết & an toàn │ biết & nguy │
├──────────────────┼──────────────────┤
CHƯA BIẾT │ Vùng 4 │ Vùng 3 │
│ chưa biết & │ chưa biết & │
│ an toàn │ nguy hiểm │
└──────────────────┴──────────────────┘
Toàn bộ công việc SOTIF là thu nhỏ Vùng 2 và Vùng 3:
- Vùng 2 → Vùng 1: đã biết kịch bản nguy hiểm, sửa nó — thêm cảm biến, siết ODD, thêm cảnh báo, hạ tốc độ tối đa.
- Vùng 3 → Vùng 2: chưa biết thì phải đi tìm — fleet data mining, fuzzing kịch bản, mô phỏng quy mô lớn. Đây là phần khó nhất, vì theo định nghĩa bạn đang tìm thứ mình chưa biết là gì.
Khái niệm trung tâm là triggering condition — điều kiện môi trường kích hoạt một giới hạn năng lực đã có sẵn. Vài ví dụ thật, không phải giả định:
| Triggering condition | Giới hạn bị kích hoạt | Biện pháp SOTIF điển hình |
|---|---|---|
| Nắng chiếu ngược thấp lúc bình minh | Camera bão hoà, mất tương phản | Fusion radar bắt buộc, hạ cấp chức năng |
| Mưa lớn, mặt đường ướt phản chiếu | LiDAR nhiễu, vạch kẻ biến mất | Thu hẹp ODD theo dữ liệu cảm biến mưa |
| Xe tải sơn hình phong cảnh ở đuôi | Detector phân loại nhầm | Kiểm tra nhất quán đa khung, ưu tiên radar |
| Biển báo bị dán decal | Nhận dạng biển sai | Đối chiếu với HD map (xem Bài 4) |
| Công trường với vạch kẻ tạm chồng vạch cũ | Lane detector chọn nhầm vạch | Yêu cầu tài xế tiếp quản, thoát ODD |
Hai tiêu chuẩn bổ sung nhau, không thay thế nhau
| ISO 26262 | ISO 21448 (SOTIF) | |
|---|---|---|
| Nguyên nhân nguy hiểm | Lỗi (fault) của linh kiện | Giới hạn năng lực + sử dụng sai có thể lường trước |
| Câu hỏi | "Nếu nó hỏng thì sao?" | "Nếu nó hoạt động đúng thiết kế nhưng thiết kế chưa đủ thì sao?" |
| Công cụ chính | FMEA, FTA, chỉ tiêu phần cứng | Phân tích kịch bản, mô phỏng, dữ liệu đội xe |
| Bằng chứng | Metric định lượng (SPFM/PMHF) | Độ phủ kịch bản + lập luận rủi ro tồn dư |
Một hệ thống ADAS L2+ phải qua cả hai. Chúng trả lời hai câu hỏi khác nhau, và bỏ sót một câu là bỏ sót một nửa không gian rủi ro.
Scenario-based validation: thay 275 triệu dặm bằng vài nghìn kịch bản
Nếu không lái đủ dặm được, giải pháp là lái đúng chỗ. Thay vì mẫu ngẫu nhiên từ phân phối thực tế — nơi 99,9% số dặm là đi thẳng trên đường trống — ta lấy mẫu có chủ đích ở phần đuôi phân phối.
ASAM OpenSCENARIO: ngôn ngữ chung để mô tả kịch bản
OpenSCENARIO (ASAM) là định dạng XML mô tả chuyện gì xảy ra trên một mạng đường OpenDRIVE (đã gặp ở Bài 4). Cấu trúc gốc của một file .xosc:
Sáu khối gốc của một file .xosc. RoadNetwork trỏ tới bản đồ OpenDRIVE, Entities khai báo các xe tham gia, Storyboard mô tả diễn biến. Nguồn: repo carla-simulator/scenario_runner
Phần đắt giá nhất là Storyboard, tách rõ ba thứ mà người mới hay trộn lẫn:
Init— trạng thái ban đầu: xe ở đâu, tốc độ bao nhiêu, thời tiết thế nàoStory→Act→ManeuverGroup→Maneuver→Event— hành vi được kích hoạt bởi điều kiện (ví dụ: khi khoảng cách tới xe ego còn 40 m thì bắt đầu cắt đầu)StopTrigger— khi nào kịch bản kết thúc
Một kịch bản được thực thi trong CARLA bằng scenario_runner: HUD bên trái hiển thị tốc độ, GNSS, lệnh ga/phanh/lái và các xe lân cận — chính là những đại lượng dùng để chấm pass/fail. Nguồn: repo carla-simulator/scenario_runner
Chạy một kịch bản với CARLA scenario_runner:
# Terminal 1 — khởi động CARLA server
./CarlaUE4.sh -quality-level=Epic
# Terminal 2 — chạy kịch bản cut-in theo định dạng OpenSCENARIO
python scenario_runner.py \
--openscenario srunner/examples/FollowLeadingVehicle.xosc \
--reloadWorld
# Terminal 3 — điều khiển thủ công hoặc gắn planner của bạn vào
python manual_control.py
Quét tham số: nơi giá trị thật sự nằm
Một kịch bản đơn lẻ gần như vô dụng. Sức mạnh đến từ việc quét không gian tham số của nó — tốc độ xe cắt đầu, khoảng cách khi bắt đầu cắt, thời gian cắt — rồi tìm biên giữa vùng an toàn và vùng va chạm.
Đoạn dưới đây làm đúng việc đó với một mô hình dọc tối giản, chỉ cần NumPy:
"""Quét tham số kịch bản cut-in, tìm biên an toàn của AEB.
Chỉ mô hình trục dọc — đủ để minh hoạ cách chấm điểm một lưới kịch bản.
"""
import numpy as np
DT = 0.02 # bước mô phỏng 50 Hz
T_END = 8.0
A_BRAKE = -7.0 # gia tốc phanh tối đa trên đường khô (m/s²)
T_REACT = 0.35 # trễ hệ thống: cảm biến → nhận diện → cơ cấu (Bài 5)
TTC_TRIGGER = 1.6 # ngưỡng TTC kích hoạt AEB (s)
def simulate(v_ego, v_cut, gap0):
"""Trả về (khoảng cách nhỏ nhất, TTC nhỏ nhất). gap < 0 nghĩa là va chạm."""
x_ego, x_cut = 0.0, gap0
v_e, v_c = v_ego, v_cut
braking_since = None
min_gap, min_ttc = np.inf, np.inf
for step in range(int(T_END / DT)):
t = step * DT
gap = x_cut - x_ego
rel_v = v_e - v_c
ttc = gap / rel_v if rel_v > 0.1 else np.inf
min_gap = min(min_gap, gap)
min_ttc = min(min_ttc, ttc)
if gap <= 0:
return gap, min_ttc # đã va chạm
if braking_since is None and ttc < TTC_TRIGGER:
braking_since = t # AEB quyết định phanh
a = A_BRAKE if (braking_since is not None
and t >= braking_since + T_REACT) else 0.0
v_e = max(0.0, v_e + a * DT)
x_ego += v_e * DT
x_cut += v_c * DT
return min_gap, min_ttc
if __name__ == "__main__":
v_ego = 27.8 # 100 km/h
grid_vcut = np.arange(13.9, 25.0, 2.0) # 50 → 90 km/h
grid_gap = np.arange(10.0, 45.0, 5.0)
fails = 0
total = 0
print("v_cut(km/h) gap0(m) min_gap(m) kết quả")
for v_cut in grid_vcut:
for gap0 in grid_gap:
min_gap, _ = simulate(v_ego, v_cut, gap0)
total += 1
ok = min_gap > 0.0
fails += (not ok)
print(f"{v_cut*3.6:9.0f} {gap0:9.0f} {min_gap:12.2f} "
f"{'PASS' if ok else 'VA CHẠM'}")
print(f"\nTỷ lệ thất bại: {fails}/{total} = {100*fails/total:.1f}%")
Chạy đoạn này, bạn sẽ thấy ngay biên: với T_REACT = 0.35 s, những ô lưới có khoảng cách ban đầu nhỏ và chênh lệch tốc độ lớn rơi vào vùng va chạm. Thử đổi T_REACT thành 0.55 — con số hoàn toàn thực tế nếu perception chậm thêm 200 ms như phân tích ngân sách độ trễ ở Bài 5 — và đếm lại số ô thất bại. Đó chính là cách một yêu cầu latency phần mềm trở thành một yêu cầu an toàn định lượng, thay vì một dòng ghi chú "nên tối ưu thêm".
Nguồn kịch bản: đừng tự nghĩ ra hết
Ba nguồn mà mọi chương trình validation nghiêm túc đều dùng:
- Danh mục chuẩn — thư viện kịch bản của Euro NCAP và UN ECE (cắt đầu, phanh gấp, người đi bộ băng qua giữa hai xe đỗ, xe máy tạt ngang).
- Khai thác dữ liệu đội xe — quét log tìm các sự kiện có TTC thấp, phanh mạnh, tài xế giật vô-lăng; mỗi sự kiện đó là một kịch bản thật đã xảy ra.
- Sinh tự động quanh biên — lấy một kịch bản thất bại rồi nhiễu loạn tham số quanh nó để vẽ chính xác đường biên an toàn. Đây là cách hiệu quả nhất để đẩy Vùng 3 của SOTIF về Vùng 2.
Khung pháp lý: UN R157 và bộ giao thức Euro NCAP 2026
UN R157 — cánh cửa pháp lý cho Level 3
Quy định UN R157 về ALKS (Automated Lane Keeping Systems) là văn bản quốc tế đầu tiên cho phép một hệ thống Level 3 lưu hành hợp pháp. Bản gốc có hiệu lực từ đầu năm 2021 giới hạn ở 60 km/h, chỉ trên đường có dải phân cách cứng, không đổi làn. Loạt sửa đổi 01 nâng trần tốc độ lên 130 km/h và cho phép đổi làn tự động — đó là lý do vì sao các hệ thống L3 thương mại xuất hiện ở châu Âu và Nhật Bản đúng vào giai đoạn này.
Điểm mấu chốt với kỹ sư: R157 không chỉ yêu cầu hệ thống lái tốt. Nó yêu cầu Data Storage System for Automated Driving (DSSAD) — hộp đen ghi lại mọi thời điểm kích hoạt, mọi yêu cầu tiếp quản, mọi lần chuyển giao quyền điều khiển. Nếu không thiết kế logging này từ đầu, bạn sẽ phải viết lại kiến trúc khi xin phê duyệt.
Euro NCAP 2026 — bản sửa đổi lớn nhất kể từ 2009
Từ 2026, Euro NCAP thay hoàn toàn cách chấm sao. Bốn hộp cũ (người lớn, trẻ em, người đi đường dễ tổn thương, hỗ trợ an toàn) được thay bằng bốn trụ cột dựa trên ma trận Haddon — tức là chia theo giai đoạn của một vụ va chạm chứ không theo đối tượng bị ảnh hưởng:
| Trụ cột | Đánh giá cái gì | Liên quan tới bài nào trong series |
|---|---|---|
| Safe Driving | Công nghệ giúp lái an toàn hơn: giám sát trạng thái tài xế, chất lượng tương tác người–máy | Bài 1 (trách nhiệm, ODD) |
| Crash Avoidance | Hệ thống ngăn hoặc giảm nhẹ va chạm: AEB, hỗ trợ làn, ISA | Bài 2, 3, 5 |
| Crash Protection | Bảo vệ thụ động: kết cấu thân xe, dây đai, túi khí, bảo vệ người đi bộ | Ngoài phạm vi series |
| Post-Crash Safety | "Giờ vàng" sau va chạm: eCall, thông tin cứu hộ | Ngoài phạm vi series |
Mỗi trụ cột được chấm trên thang 100 điểm quy ra phần trăm, và số sao tổng thể bị chặn bởi ngưỡng tối thiểu ở từng trụ cột — nghĩa là không thể bù điểm: một xe có kết cấu thân tuyệt vời nhưng ADAS kém sẽ không lên được 5 sao.
Ba thay đổi cụ thể đáng chú ý nhất với đội ADAS:
- ISA được kiểm chứng ngoài đường thật. Độ chính xác của thông tin giới hạn tốc độ lần đầu tiên được kiểm tra trong điều kiện lái thật, không còn chỉ trên đường thử. Nghĩa là pipeline nhận dạng biển báo và đối chiếu bản đồ của bạn phải đúng trên những con đường mà bạn không được chọn trước.
- Giám sát tài xế trở thành điều kiện cần cho 5 sao. Theo dõi mắt và đầu liên tục là bắt buộc ở hạng cao nhất, cùng với điểm thưởng cho hệ thống phát hiện dấu hiệu suy giảm năng lực do rượu hoặc thuốc, và cho can thiệp "tài xế không phản hồi" — tự đưa xe về trạng thái dừng an toàn khi phát hiện sự cố y tế.
- Nút bấm vật lý quay lại. Chỉ báo rẽ, đèn khẩn cấp, gạt mưa, còi và SOS/eCall phải có nút vật lý riêng mới đạt hạng cao nhất. Đây là một đòn giáng thẳng vào xu hướng dồn mọi thứ vào màn hình cảm ứng, và là lời nhắc rằng an toàn bao gồm cả giao diện người dùng, không chỉ thuật toán.
Ghép lại: V-model cho một đội ADAS
Trên thực tế, ba lớp ở trên xếp thành một V-model duy nhất, và điều quan trọng là mỗi ô bên trái có đúng một ô đối chứng bên phải:
Yêu cầu cấp xe (ODD, Bài 1) ─────────────► Thử nghiệm cấp xe (Euro NCAP, đường thật)
│ ▲
├─ HARA → mức ASIL Kiểm định ASIL (fault injection)
│ ▲
├─ Phân tích SOTIF → triggering Quét kịch bản (OpenSCENARIO, HIL)
│ ▲
├─ Kiến trúc phần mềm (Bài 3–5) Test tích hợp (SIL, dữ liệu ghi lại)
│ ▲
└─ Thiết kế module Unit test + phân tích tĩnh (MISRA C)
Ba sai lầm mà các đội phần mềm chuyển sang ô tô thường mắc:
- Coi SOTIF là "thêm vài test case". SOTIF là một lập luận về rủi ro tồn dư, cần bằng chứng độ phủ kịch bản và tiêu chí chấp nhận được định nghĩa trước, không phải một bộ test bổ sung viết sau khi code xong.
- Bỏ qua sử dụng sai có thể lường trước. Tài xế gác chân lên vô-lăng để đánh lừa cảm biến giữ tay không phải là chuyện ngoài phạm vi — ISO 21448 xếp nó vào đúng phạm vi, và Euro NCAP 2026 chấm điểm chính xác chỗ này.
- Thiết kế logging sau cùng. DSSAD của R157 và việc tái hiện lỗi trong mô phỏng đều đòi hỏi dữ liệu có dấu thời gian nhất quán giữa mọi module. Gắn thêm vào cuối dự án luôn tốn hơn nhiều lần so với thiết kế từ đầu.
Tóm tắt series
Sáu bài vừa qua đi hết một vòng: từ việc đọc đúng nhãn tự động hoá, qua cảm biến, nhận thức, định vị, lập kế hoạch, đến việc chứng minh tất cả những thứ đó an toàn.
- Không thể chứng minh an toàn bằng số dặm — 275 triệu dặm không tai nạn là cái giá thống kê, và không ai trả nổi.
- ISO 26262 xử lý lỗi linh kiện, biến rủi ro thành mức ASIL rồi thành chỉ tiêu phần cứng định lượng như PMHF < 10 FIT.
- ISO 21448 (SOTIF) xử lý phần ISO 26262 không chạm tới: hệ thống hoạt động đúng thiết kế nhưng thiết kế không đủ cho tình huống gặp phải.
- Scenario-based testing thay dặm ngẫu nhiên bằng kịch bản có chủ đích, và quét tham số là chỗ biến yêu cầu kỹ thuật thành biên an toàn đo được.
- Euro NCAP 2026 dịch chuyển trọng tâm sang bốn giai đoạn của va chạm, đưa giám sát tài xế và cả nút bấm vật lý vào phạm vi chấm điểm.
Điều đáng suy ngẫm nhất từ cả series: phần khó nhất của xe tự hành không phải là làm cho nó chạy. Bài 5 cho thấy một bộ luật đơn giản có thể đánh bại mạng nơ-ron phức tạp ở closed-loop; bài này cho thấy phần lớn công sức của một chương trình ADAS thật nằm ở việc chứng minh chứ không phải xây dựng. Đó là khác biệt lớn nhất giữa một demo ấn tượng và một sản phẩm được phép chở người.
