Các mức độ trừu tượng của kịch bản lái xe — Chức năng, Logic, Cụ thể

Trong kiểm thử hệ thống ADAS (Advanced Driver Assistance Systems) và AD (Autonomous Driving) theo kịch bản, cách tiêu chuẩn là phân chia kịch bản thành ba mức độ trừu tượng. Cách phân loại này xuất phát từ dự án PEGASUS và hiện là tiền đề cho hầu hết catalog kiểm thử, safety case và thư viện kịch bản.

Kịch bản chức năng (functional scenario) — mô tả định tính bằng ngôn ngữ tự nhiên.
Kịch bản logic (logical scenario) — mô tả có cấu trúc với “phạm vi” tham số.
Kịch bản cụ thể (concrete scenario) — một instance với tất cả tham số được cố định giá trị cụ thể.

Trang này là bài giới thiệu trung lập về ý nghĩa của từng mức, quan hệ với ODD (Operational Design Domain), các định dạng tương ứng và phạm vi drawtonomy liên quan.

Ba mức độ trừu tượng

Kịch bản chức năng

Kịch bản chức năng là mô tả định tính tình huống lái xe bằng ngôn ngữ tự nhiên. Mô tả các đối tượng tham gia, bố cục đường và hành vi, nhưng không đi vào con số cụ thể.

Ví dụ: “Trên đường cao tốc 2 làn mỗi chiều, một phương tiện ở làn trái đang chạy nhanh hơn tự xe, sau khi vượt qua tự xe thì cắt sang làn phải.”

Kịch bản chức năng được dùng ở mức “trao đổi giữa con người với nhau” — kế hoạch kiểm thử, tài liệu design review, slide, hình trong bài báo, mô tả trong safety case.

Kịch bản logic

Kịch bản logic là phiên bản cấu trúc hóa của kịch bản chức năng, trong đó mỗi biến được gán phạm vi tham số. Tốc độ ban đầu của tự xe, khoảng cách đầu xe, TTC (Time to Collision), tốc độ tương đối của xe đối diện, thời tiết, độ cong đường — mỗi tham số có phạm vi hoặc phân phối thay vì một giá trị duy nhất.

Ví dụ: “Tốc độ tự xe ∈ [70, 130] km/h, tốc độ tương đối xe cắt làn ∈ [+10, +30] km/h, TTC tại thời điểm bắt đầu cắt làn ∈ [1.5, 4.0] giây, …”

Kịch bản logic là đối tượng của sampling, quét tham số và tìm kiếm trong campaign kiểm thử. Các công cụ và DSL xử lý trực tiếp layer này: Scenic, scenariogeneration (pyoscx / pyodrx), OpenSCENARIO 2.0 / DSL.

Kịch bản cụ thể

Kịch bản cụ thể là một điểm lấy ra từ kịch bản logic, với tất cả giá trị đã được cố định. Đây là mức mà simulator thực sự chạy hoặc trường kiểm thử tái hiện.

Ví dụ: “Tự xe 90 km/h, tốc độ tương đối xe cắt làn +20 km/h, TTC tại bắt đầu cắt = 2.5 giây, mặt đường: nhựa khô, …”

OpenSCENARIO 1.x XML, phát lại trên esmini và các replay tool khác đều xử lý ở mức cụ thể này.

Quan hệ với ODD

ODD (Operational Design Domain) là tập hợp các điều kiện trong đó một tính năng lái xe nhất định được thiết kế để hoạt động (loại đường, thời tiết, thời điểm trong ngày, phạm vi địa lý, v.v.). Ba mức trừu tượng đều gắn với ODD:

Kịch bản chức năng được viết trong ODD (ví dụ: “đường cao tốc trời nắng”).
Kịch bản logic cho phạm vi tham số phù hợp với ODD (nếu chỉ áp dụng trên cao tốc thì phạm vi tốc độ cũng phải phù hợp).
Kịch bản cụ thể là instance nằm trong ODD, hoặc được chọn có chủ đích để tấn công biên của ODD dưới dạng edge case.

Các tiêu chuẩn và framework liên quan

PEGASUS — dự án nghiên cứu của Đức đã hệ thống hóa phân loại chức năng/logic/cụ thể. Đây là nguồn gốc của thuật ngữ được dùng ở đây.
ISO 21448 (SOTIF) — Safety of the Intended Functionality. Phân loại kịch bản được dùng làm xương sống để chứng minh “tính năng hoạt động đúng theo ý định trong ODD”.
ASAM OpenSCENARIO — 1.x dành cho kịch bản cụ thể, 2.0 / DSL dành cho kịch bản logic.
ASAM OpenDRIVE — kịch bản ở mọi mức trừu tượng đều tham chiếu đến đây như thế giới tĩnh.

Phạm vi drawtonomy liên quan

drawtonomy không phải sampler cho kịch bản logic, cũng không phải execution engine cho kịch bản cụ thể. Đây là bảng trắng trên trình duyệt dành cho cảnh lái xe. Tuy nhiên, trong ba mức trừu tượng, drawtonomy hữu ích ở các trường hợp sau:

Minh họa kịch bản chức năng. Hình kịch bản trong kế hoạch kiểm thử, design review, safety case, slide, bài báo — về mặt trực quan chính là visualization kịch bản chức năng. drawtonomy phù hợp để tạo các hình này.
“Bức tranh” kịch bản logic. Kịch bản logic chứa phạm vi tham số dưới dạng bảng, nhưng điều người đọc muốn thấy đầu tiên là “bố cục như thế nào, đối tượng nào, di chuyển như thế nào”. drawtonomy đảm nhận bức tranh này. Bảng tham số vẫn nằm trong DSL hay bảng tính.
Phác thảo trước khi viết kịch bản cụ thể. Khi sắp viết XML OpenSCENARIO 1.x bằng tay, có luồng tạo sketch 2D trên drawtonomy rồi xuất .xosc làm điểm xuất phát. Xem chi tiết tại Phác thảo trước khi viết OpenSCENARIO.

Việc soạn thảo nghiêm túc kịch bản logic và cụ thể trong thực tế — quét tham số, trigger có điều kiện, Storyboard phức tạp — thuộc về lãnh địa của Scenic, scenariogeneration, XML OpenSCENARIO viết tay hoặc OpenSCENARIO 2.0 / DSL. drawtonomy đảm nhận “bức tranh”, không phải logic kiểm thử.

Trong hệ sinh thái kiểm thử theo kịch bản

Xem thêm

Phác thảo kịch bản kiểm thử ADAS — tạo hình cut-in, hợp lưu, người đi bộ băng qua.
Phác thảo trước khi viết OpenSCENARIO — luồng từ sketch trực quan sang XML.
Hình minh họa cho bài báo xe tự lái — hình kịch bản chất lượng xuất bản.