AUTOSAR (Kiến trúc phần mềm tiêu chuẩn cho ô tô)

1. Tổng quan

A. Định nghĩa

AUTOSAR (AUTomotive Open System ARchitecture) là một tiêu chuẩn nền tảng phần mềm ô tô mở nhằm tách rời (decoupling) phần mềm của bộ điều khiển điện tử (ECU) trên xe khỏi phần cứng, và thông qua cấu trúc phân lớp·giao diện·định dạng trao đổi được chuẩn hóa, cho phép tái sử dụng·khả chuyển·cộng tác. Nó khởi đầu năm 2003 từ một quan hệ đối tác phát triển (development partnership) do BMW·Bosch·Continental·Daimler·Ford·GM·PSA·Toyota·Volkswagen và các bên khác lập nên, dựa trên triết lý "Hợp tác về tiêu chuẩn, cạnh tranh về triển khai (Cooperate on standards, compete on implementation)."

Bối cảnh ra đời của AUTOSAR nằm ở quá trình "phần mềm hóa" nhanh chóng của chiếc xe. Các chức năng phanh·lái·truyền động vốn được hiện thực bằng cơ khí·thủy lực cho đến thập niên 1990 đã chuyển sang điều khiển điện tử, khiến số ECU trang bị trên một chiếc xe cao cấp bùng nổ lên vài chục đến hơn một trăm, và quy mô phần mềm tăng tới hàng chục triệu đến 100 triệu dòng (LoC). Thế nhưng vì phần mềm của mỗi ECU gắn chặt (tightly coupled) với một vi điều khiển·nhà cung cấp cụ thể, sự kém hiệu quả tích lũy dần: mỗi khi thay một linh kiện hay chuyển một chức năng sang ECU khác thì phần mềm gần như phải viết lại. Khi nhà sản xuất xe hoàn chỉnh (OEM), nhà cung cấp cấp một (Tier-1) và hãng bán dẫn (Tier-2) mỗi bên phát triển theo cấu trúc riêng, chi phí tích hợp·kiểm chứng và rủi ro triệu hồi cũng gia tăng.

Do đó ý tưởng cốt lõi của AUTOSAR là trừu tượng hóa phần cứng — "để ứng dụng hoạt động mà không cần biết phần cứng" — và mô-đun hóa, "thành phần phần mềm (SWC) có thể lắp ghép như linh kiện." Nếu logic ứng dụng được mô tả thành các thành phần trên một bus hàm ảo (VFB), và lớp phần mềm trung gian được chuẩn hóa bên dưới đảm nhận truyền thông·bộ nhớ·chẩn đoán·mạng, thì dù tái bố trí cùng một chức năng sang ECU khác·chất bán dẫn khác, vẫn có thể tái sử dụng mà không đụng tới mã ứng dụng. Vượt khỏi việc chỉ tái sử dụng mã, điều này mang ý nghĩa quản trị công nghiệp: cố định sự phân chia vai trò và hợp đồng cộng tác giữa OEM-Tier-1-Tier-2 bằng các giao diện tiêu chuẩn.

B. Hai thế hệ nền tảng — Classic và Adaptive

Để hiểu AUTOSAR một cách chính xác, phải phân biệt hai nền tảng có tính chất khác nhau. Classic Platform (CP), phát triển từ năm 2003, là cấu trúc tĩnh (static) dành cho ECU nhúng sâu (deeply embedded) nơi đòi hỏi thời gian thực·độ tin cậy cao, như phanh·động cơ·túi khí. Trên một hệ điều hành thời gian thực nền OSEK/VDX, mọi tài nguyên được chốt ở thời điểm build, ưu tiên tính tất định (determinism) và an toàn chức năng ([[iso-26262]]). Ngược lại, Adaptive Platform (AP), công bố năm 2017, là cấu trúc động (dynamic) dành cho ECU tính toán hiệu năng cao (HPC) cần năng lực tính toán hiệu năng cao và tính linh hoạt, như lái tự động·thông tin giải trí; nó áp dụng hệ điều hành nền POSIX, C++ và kiến trúc hướng dịch vụ (SOA) để hỗ trợ khám phá dịch vụ·cập nhật OTA trong lúc chạy.

Lý do căn bản phân tách hai bên là vì "tính chất của bài toán mà chúng xử lý" khác nhau. Phần mềm điều khiển bánh xe sống còn nhờ đáp ứng dự đoán được ở mức một mili-giây và "không bao giờ dừng," nên cấu hình tĩnh và mô hình thực thi đơn giản có lợi. Ngược lại, phần mềm hợp nhất hình ảnh từ vài chục camera bằng học sâu để lập kế hoạch lộ trình cần một runtime phong phú tận dụng đa lõi·GPU và năng lực cập nhật để cải tiến chức năng liên tục. AUTOSAR không cố thỏa mãn cả hai yêu cầu bằng một cấu trúc duy nhất; thay vào đó, nó chọn con đường để hai nền tảng khác mục đích cùng tồn tại trong khi bảo đảm khả năng tương hợp qua một nền chung (Foundation). Chính sự phân tách này là điểm khởi đầu để hiểu toàn bộ cấu trúc AUTOSAR.

2. Cấu trúc tổng thể — Classic·Adaptive·Foundation và phương pháp luận

Tiêu chuẩn AUTOSAR gồm ba bó tiêu chuẩn. Classic Platform (CP), Adaptive Platform (AP), và Foundation (FO) định nghĩa các sản phẩm·quy ước chung được hai nền tảng chia sẻ. Thêm vào đó, phương pháp luận (Methodology) định nghĩa cách mô tả·cấu hình·triển khai phần mềm, và ARXML (AUTOSAR XML), một định dạng XML trao đổi mọi sản phẩm theo cách máy đọc được, xuyên suốt toàn bộ quy trình. Nói cách khác, AUTOSAR là một hệ thống gồm hai "nền tảng thực thi," một "quy ước chung," và một "phương pháp luận phát triển" ràng buộc chúng lại.

graph TD
  subgraph STD["Hệ thống tiêu chuẩn AUTOSAR"]
    FO["Foundation (FO)<br/>yêu cầu·quy ước·giao thức chung(SOME/IP, v.v.)"]
    subgraph CP["Classic Platform (CP)"]
      CPA["ECU nhúng sâu<br/>cấu hình tĩnh·thời gian thực·an toàn chức năng"]
    end
    subgraph AP["Adaptive Platform (AP)"]
      APA["ECU tính toán hiệu năng cao<br/>động·SOA·OTA"]
    end
    METH["Phương pháp luận & ARXML<br/>mô tả·cấu hình·trao đổi dựa trên mô hình"]
  end
  FO --> CP
  FO --> AP
  METH --> CP
  METH --> AP
  CP -. "cổng SOME/IP·DDS" .-> AP

Như sơ đồ cấu trúc trên cho thấy, Foundation định nghĩa giao phần tối thiểu của các giao thức chung và siêu mô hình để hai nền tảng có thể truyền thông·liên thông với nhau. Chẳng hạn giao thức truyền thông hướng dịch vụ SOME/IP được quy định trong Foundation để Classic và Adaptive có thể trao đổi dịch vụ trên Ethernet bằng cùng một quy ước. Trước kia mỗi nền tảng tự định nghĩa yêu cầu một cách trùng lặp, nhưng với việc đưa Foundation vào, cả hai bên tham chiếu một quy ước chung đã định nghĩa một lần, điều này giảm trùng lặp·bất nhất và bảo đảm khả năng tương hợp của kiến trúc hỗn hợp CP↔AP.

Vai trò của phương pháp luận và ARXML cũng là trung tâm. Trước khi viết mã trực tiếp, AUTOSAR mô tả trước các thành phần phần mềm·cổng·giao diện·tài nguyên ECU dưới dạng mô hình ở định dạng ARXML, và từ mô hình này tự sinh mã cấu hình RTE·ngăn xếp truyền thông. Trong một dự án sản xuất hàng loạt thực tế, OEM chuyển thiết kế hệ thống cho Tier-1 dưới dạng ARXML, Tier-1 nhận nó và chi tiết hóa cấu hình ECU (ECU Configuration), rồi hợp nhất với cài đặt MCAL do hãng bán dẫn cung cấp để sinh ra tệp nhị phân cuối cùng. Theo cách này ARXML vừa là văn bản hợp đồng chuyển giao trách nhiệm thiết kế giữa các công ty, vừa là đầu vào cho tự động hóa, cho thấy AUTOSAR không phải một quy ước mã đơn thuần mà là một "phương pháp luận cộng tác dựa trên mô hình."

3. Classic Platform — cấu trúc phân lớp và các thành phần

Khung xương của Classic Platform là sự phân lớp triệt để (layered architecture). Ở lớp ứng dụng (Application Layer) trên cùng đặt logic chức năng như điều khiển phanh·quản lý mô-men động cơ, theo đơn vị thành phần phần mềm (SWC, Software Component). Bên dưới nó, môi trường thời gian chạy (RTE, Runtime Environment) trung chuyển truyền thông giữa các thành phần và các lệnh gọi xuống phần mềm cơ bản bên dưới; ở tận đáy, phần mềm cơ bản (BSW, Basic Software) cung cấp truyền thông·bộ nhớ·chẩn đoán·OS·trình điều khiển, và vi điều khiển ở mức thấp nhất thực thi chúng.

graph TD
  APP["Application Layer<br/>SWC(logic chức năng phanh·lái)"] --> RTE["RTE (Runtime Environment)<br/>hiện thực VFB·trung chuyển truyền thông giữa thành phần"]
  RTE --> SVC["Services Layer<br/>OS·truyền thông·chẩn đoán·bộ nhớ·NM"]
  SVC --> ECUAL["ECU Abstraction Layer<br/>trừu tượng hóa thiết bị onboard·trình điều khiển"]
  ECUAL --> MCAL["MCAL<br/>Microcontroller Abstraction Layer"]
  RTE -. "truy cập trực tiếp" .-> CDD["Complex Device Drivers (CDD)<br/>điều khiển trực tiếp phần cứng tốc độ cao·đặc biệt"]
  CDD --> MCU
  MCAL --> MCU["Microcontroller (phần cứng)"]

Khái niệm cốt lõi của cấu trúc này là bus hàm ảo (VFB, Virtual Function Bus). Lập trình viên ứng dụng thiết kế với giả định rằng SWC của mình chỉ kết nối một cách logic với các thành phần khác qua "cổng (port)," mà không cần biết nó sẽ chạy trên ECU nào·đường truyền nào (CAN/LIN/FlexRay/Ethernet). Một khi bố trí vật lý thực tế được quyết định, RTE hiện thực (realize) VFB, tự động kết nối bằng lệnh gọi hàm nếu ở trong cùng một ECU, hoặc bằng thông điệp đi qua ngăn xếp truyền thông nếu ở ECU khác. Nhờ đó, ngay cả khi "thành phần gửi tín hiệu lực phanh" được chuyển từ ECU A sang ECU B thì mã ứng dụng vẫn không đổi — đây là thực chất của khả năng tái bố trí (relocatability) mà AUTOSAR đề cao.

Phần mềm cơ bản (BSW) lại chia thành ba lớp cộng một ngoại lệ. Ở tận đáy, MCAL (Microcontroller Abstraction Layer) bọc các thanh ghi·thiết bị ngoại vi (ADC·PWM·SPI, v.v.) của một MCU cụ thể bằng API tiêu chuẩn để các lớp trên không cần biết loại chất bán dẫn. Bên trên nó, lớp trừu tượng hóa ECU (ECU Abstraction Layer) trừu tượng hóa các linh kiện ngoài gắn trên bo mạch (cảm biến·bộ thu phát, v.v.), và lớp dịch vụ (Services Layer) trên cùng cung cấp các dịch vụ nền tảng như OS·quản lý truyền thông·chẩn đoán (UDS)·bộ nhớ (NvM)·quản lý mạng. Tuy nhiên, với các trường hợp như camera tốc độ cao hay bộ truyền động đặc biệt không thể chịu độ trễ của các lớp tiêu chuẩn, trình điều khiển thiết bị phức hợp (CDD, Complex Device Driver) vòng qua các lớp để điều khiển trực tiếp phần cứng được cho phép như một ngoại lệ. Nhờ thiết kế "trừu tượng hóa chất bán dẫn bằng MCAL" này, OEM có thể giữ nguyên ứng dụng bên trên ngay cả khi đổi nhà cung cấp bán dẫn từ Renesas sang Infineon.

Lớp BSW	Vai trò	Mô-đun·ví dụ tiêu biểu	Đối tượng trừu tượng hóa
Services Layer	cung cấp dịch vụ nền tảng	OS, Com, Dcm/Dem(chẩn đoán), NvM, NM	dịch vụ độc lập phần cứng
ECU Abstraction	trừu tượng hóa thiết bị onboard	lớp bọc trình điều khiển, bộ xử lý I/O	linh kiện ngoài gắn trên bo
MCAL	trừu tượng hóa vi điều khiển	trình điều khiển ADC·PWM·CAN·SPI	thiết bị ngoại vi bên trong MCU
CDD(ngoại lệ)	điều khiển trực tiếp vòng qua lớp tiêu chuẩn	cảm biến tốc độ cao·bộ truyền động đặc biệt	phần cứng nhạy độ trễ

Mô hình thực thi của Classic Platform là một hệ điều hành thời gian thực tĩnh·dựa trên độ ưu tiên bắt nguồn từ OSEK/VDX. Tác vụ·sự kiện·tài nguyên được chốt ở thời điểm build, tránh cấp phát bộ nhớ động, và bảo vệ bộ nhớ (MPU) ngăn can nhiễu khi các ASIL trộn lẫn. Tính chất tĩnh này đối lập với sự linh hoạt như lái tự động, nhưng tối ưu cho yêu cầu tất định·an toàn kiểu "dù có chuyện gì, lệnh phanh phải phát ra trong vòng 10 mili-giây." Trên thực tế, gần như toàn bộ ECU hệ truyền động·khung gầm·thân xe của xe du lịch đến nay vẫn chạy trên Classic Platform.

4. Adaptive Platform — kiến trúc hướng dịch vụ và thực thi động

Adaptive Platform lật ngược trực diện các giới hạn của Classic — "tĩnh·đơn mục đích·khó cập nhật." Môi trường thực thi cốt lõi của nó là ARA (AUTOSAR Runtime for Adaptive Applications), nơi các ứng dụng viết bằng C++ hoạt động trên một hệ điều hành nền POSIX (hồ sơ PSE51) bằng cách gọi các API tiêu chuẩn do cụm chức năng (Functional Cluster) cung cấp. Vì giả định đa lõi·bộ nhớ ảo·nạp động, nó có thể xử lý các tác vụ nặng về tính toán như hợp nhất camera·lidar hay thông tin giải trí độ phân giải cao.

graph LR
  subgraph APP["Ứng dụng Adaptive (C++)"]
    A1["Tri giác(Perception)"]
    A2["Lập kế hoạch(Planning)"]
  end
  subgraph ARA["ARA: cụm chức năng"]
    COM["ara::com<br/>truyền thông hướng dịch vụ"]
    EXEC["ara::exec<br/>quản lý thực thi·trạng thái"]
    UCM["ara::ucm<br/>cập nhật OTA"]
    DIAG["ara::diag / per / crypto"]
  end
  OS["POSIX OS (PSE51)"]
  A1 --> COM
  A2 --> COM
  A1 --> EXEC
  COM -->|"SOME/IP · DDS"| NET["trục Ethernet của xe"]
  EXEC --> OS
  UCM --> OS
  DIAG --> OS

Bước chuyển hệ hình lớn nhất của Adaptive là truyền thông hướng dịch vụ (ara::com). Nếu Classic truyền "tín hiệu (signal)" theo chu kỳ trên các đường cố định, thì Adaptive để bên cung cấp dịch vụ đăng ký một dịch vụ và bên tiêu thụ khám phá (service discovery) nó trong lúc chạy để kết nối. Làm tầng truyền tải, nó dùng SOME/IP (Scalable service-Oriented MiddlewarE over IP) hoặc DDS (Data Distribution Service) do Foundation quy định. Nhờ liên kết động này, chẳng hạn nếu thêm một dịch vụ hợp nhất cảm biến mới qua OTA, các bên tiêu thụ hiện có có thể khám phá·đăng ký dịch vụ đó mà không cần biên dịch lại. Nói cách khác, bản chất của Adaptive là bước chuyển từ "truyền thông cố định như dây nối" sang "truyền thông ghép lỏng như một dịch vụ internet."

Quản lý thực thi (ara::exec) và quản lý cập nhật (ara::ucm) cũng là những năng lực mà Classic không có. ara::exec quản lý khởi động·dừng·chuyển trạng thái (Machine State·Function Group) của ứng dụng, để ngay cả khi đang chạy xe vẫn có thể nạp·chuyển chỉ tập chức năng cần thiết. ara::ucm chuẩn hóa cập nhật không dây (OTA), cho phép cả các OEM truyền thống hiện thực mô hình "cải tiến liên tục chức năng của xe" mà Tesla đã trình diễn. Trên thực tế, công ty con phần mềm CARIAD của Volkswagen, hệ điều hành thế hệ kế tiếp của BMW·Mercedes, và chiến lược SDV của Tập đoàn ô tô Hyundai đều áp dụng Adaptive Platform (hoặc một biến thể) làm nền cho kiến trúc tính toán trung tâm·theo vùng (zonal) hiệu năng cao.

Tuy nhiên tính linh hoạt này sinh ra căng thẳng với an toàn chức năng·tính tất định. Lập lịch động và bộ nhớ ảo của POSIX khiến việc bảo đảm "thời gian thực thi xấu nhất (WCET)" khó hơn so với tính tất định tĩnh của Classic. Vì vậy Adaptive nhắm tới an toàn đến mức ASIL B trong khi bù phần thiếu hụt bằng Ethernet tất định ([[tsn]])·hypervisor được chứng nhận an toàn·cách ly thực thi. Tóm lại Adaptive là nền tảng "được hiệu năng và tính linh hoạt nhưng gánh thêm bài tập mới là chứng minh tính tất định," và chính vì thế trong thời gian trước mắt, một sự cùng tồn tại theo kiểu phân chia vai trò — nơi Classic đảm nhận các chức năng cấp an toàn cao nhất như phanh·lái, còn Adaptive đảm nhận tri giác·lập kế hoạch·HMI — là lời giải thực tế.

5. So sánh Classic vs Adaptive và phương pháp luận phát triển

Khác biệt giữa hai nền tảng không phải một lựa chọn kỹ thuật đơn thuần mà bắt nguồn từ khác biệt về "chúng đáp ứng yêu cầu an toàn·hiệu năng·vòng đời nào." Bảng so sánh dưới nên được đọc không như một danh sách các mục mà cùng với lý do vì sao mỗi khác biệt phát sinh.

Phân loại	Classic Platform(CP)	Adaptive Platform(AP)	Lý do phát sinh khác biệt
ECU mục tiêu	nhúng sâu (vài trăm KB~MB)	tính toán hiệu năng cao (bộ nhớ cỡ GB)	điều khiển vs tri giác·tính toán
OS	RTOS nền OSEK	POSIX(PSE51)	tất định vs runtime phong phú
Ngôn ngữ	chủ yếu C	C++(14 trở lên)	yêu cầu mô-đun·hướng đối tượng
Thời điểm cấu hình	tĩnh (chốt lúc build)	động (nạp·khám phá lúc chạy)	an toàn vs linh hoạt
Truyền thông	dựa trên tín hiệu (CAN/LIN/FlexRay)	hướng dịch vụ (SOME/IP·DDS)	đường cố định vs ghép lỏng
Cập nhật	nạp toàn bộ (xưởng dịch vụ)	OTA (ara::ucm)	hệ đóng vs cải tiến liên tục
Cấp an toàn	tới ASIL D	chủ yếu ASIL B (nâng bằng thiết kế bổ trợ)	độ khó bảo đảm tính tất định

Trong bảng so sánh này, các điểm có hàm ý thực tiễn lớn nhất là mô hình cập nhật và phương thức truyền thông. Việc nạp toàn bộ của Classic "thay thế trọn gói tệp nhị phân đã kiểm chứng," nên an toàn, nhưng chỉ để sửa một lỗi nhỏ cũng cần đưa xe vào xưởng dịch vụ, dẫn tới chi phí triệu hồi trên hàng triệu chiếc. Ngược lại, OTA của Adaptive cải tiến chức năng từ xa và thay việc triệu hồi bằng các bản vá phần mềm, nhưng bắt buộc phải đi kèm thiết kế an ninh như [[secure-boot]]·xác minh chữ ký·quay lui để firmware bị giả mạo không làm hỏng các chức năng an toàn. Tức là tính linh hoạt và trách nhiệm an ninh cùng lớn lên.

Về mặt phương pháp luận phát triển, AUTOSAR đã chuẩn hóa một quy trình làm việc dựa trên mô hình·phân chia vai trò. Đại thể, khi OEM thiết kế các SWC·cổng·giao diện ở mức hệ thống và phân phát dưới dạng ARXML, Tier-1 ánh xạ chúng lên các ECU (SWC-to-ECU mapping) và cấu hình BSW, còn bộ sinh RTE tự sinh mã keo truyền thông. Trong sản xuất hàng loạt thực tế, các bộ công cụ thương mại như Vector (DaVinci·MICROSAR), ETAS và EB (Elektrobit) nhận mô hình ARXML này làm đầu vào, cấu hình hàng nghìn tham số BSW và sinh mã. Cách "trao đổi mô hình và sinh mã" này là phương pháp hiện thực duy nhất để bảo đảm nhất quán·truy vết·tự động hóa trong một dự án quy mô lớn liên quan hàng chục ECU·hàng chục nhà cung cấp, và đồng thời để lại những thách thức quản lý mới là khả năng tương hợp ARXML·phụ thuộc công cụ.

6. Chuyên sâu — xu hướng mới nhất (AUTOSAR trong kỷ nguyên SDV)

AUTOSAR phát hành bản định kỳ mỗi tháng 11 theo dạng "Rxx-11." Bản mới nhất, R25-11 (công bố công khai cuối 2025), bao gồm khoảng 1.900 nhiệm vụ hợp nhất trên ba tiêu chuẩn Classic·Adaptive·Foundation, và thông báo công khai đã coi là các chủ đề chính gồm Giao thức dữ liệu xe (Vehicle Data Protocol), tăng cường an ninh, hỗ trợ DDS trên Classic Platform, triển vọng áp dụng Rust trên Classic Platform, và Triển khai Adaptive Platform chung (CAPI, Common Adaptive Platform Implementation) (chi tiết thay đổi, xem các tài liệu tổng quan bản phát hành chính thức). So với bản liền trước R24-11 (2024), vốn hợp nhất khoảng 2.400 nhiệm vụ và hơn 350.000 dòng mã Adaptive, có thể đọc thấy rằng các bản gần đây đang dịch trọng tâm từ bổ sung tính năng sang việc củng cố thực chất về an ninh·an toàn bộ nhớ·tích hợp nền tảng.

Xu hướng đáng chú ý nhất là sự hội tụ với xe định nghĩa bằng phần mềm (SDV, Software Defined Vehicle). Khi các chức năng từng phân tán trên hàng chục ECU được tích hợp vào một số ít bộ điều khiển trung tâm·theo vùng (zonal) hiệu năng cao, một môi trường đa mức tới hạn (mixed-criticality) — nơi điều khiển ASIL D và thông tin giải trí cấp QM cùng tồn tại trên một phần cứng duy nhất — đang trở nên phổ biến. Ở đây AUTOSAR trình bày một kiến trúc lai (hybrid) trong đó Adaptive đảm nhận miền hiệu năng cao và Classic đảm nhận miền an toàn, trong khi một hypervisor và một mạng tất định như [[tsn]] cách ly·kết nối hai thế giới. Trên thực tế, một sáng kiến triển khai chung như CAPI hội tụ các bản triển khai Adaptive vốn khác nhau theo từng OEM, nhắm tới một "nền chung kiểu Android" của phần mềm xe.

Xu hướng thứ hai là an toàn bộ nhớ và sự trỗi dậy của Rust. Hệ quả của việc Classic Platform phụ thuộc vào C suốt nhiều thập niên là các khuyết tật tiềm ẩn do lỗi bộ nhớ ([[memory-safety]]) đã tích lũy. Việc triển vọng áp dụng Rust trên Classic Platform được coi là một mục nghị sự chính thức tại R25-11 cho thấy ngành ô tô đã bắt đầu nghiêm túc xem xét một ngôn ngữ an toàn bộ nhớ như một phương tiện căn bản của an toàn·an ninh. Thứ ba là đồng thiết kế an ninh-an toàn: khi một cuộc tấn công mạng trở thành đe dọa an toàn trong một chiếc xe kết nối, ISO/SAE 21434 (an ninh mạng)·UNECE WP.29 R155/R156 (CSMS/SUMS) và các mô-đun mật mã·an ninh của AUTOSAR (ara::crypto, SecOC) đang được kết hợp một cách hữu cơ. Về các hướng ra đề có khả năng, các luận đề kiểu hội tụ như "các phương án thiết kế cho kiến trúc lai Classic·Adaptive trong giai đoạn chuyển đổi SDV" hay "một chiến lược tích hợp an toàn chức năng·an ninh mạng cho OTA dựa trên AUTOSAR" là khả dĩ.

7. Điểm cân nhắc và hàm ý

Chiến lược áp dụng — trộn nền tảng và chuyển đổi tiệm tiến: Chuyển ngay toàn bộ chức năng sang Adaptive là phi thực tế. Giữ các chức năng ASIL D như phanh·lái trên Classic đã kiểm chứng, và đưa Adaptive vào bắt đầu từ các mảng cần linh hoạt như tri giác·lập kế hoạch·HMI·OTA, là một chuyển đổi lai theo kiểu phân chia vai trò thực tế. Kỹ sư chuyên nghiệp phải có sự tinh tường để thiết kế chức năng nào đặt trên nền tảng nào (mapping), theo các trục cấp an toàn·yêu cầu thời gian thực·chu kỳ cập nhật của từng chức năng.
Đánh đổi — lợi ích chuẩn hóa vs chi phí phức tạp·phụ thuộc công cụ: AUTOSAR mang lại lợi ích lớn về tái sử dụng·cộng tác·truy vết, nhưng kéo theo chi phí cấu hình hàng nghìn tham số BSW, quản lý mô hình ARXML, phụ thuộc vào các bộ công cụ thương mại (Vector·ETAS·EB), và đường cong học dốc. Với các ECU quy mô nhỏ·đơn giản, nó có thể lại là chi phí phụ quá mức, nên cần một phán đoán chi phí-lợi ích khớp với quy mô áp dụng và năng lực tổ chức.
Triển vọng — hội tụ về SDV·kiến trúc tập trung: Khi chiếc xe tiến hóa thành "một máy tính có bánh xe," vai trò của AUTOSAR đang mở rộng từ một tiêu chuẩn ECU phân tán thành nền phần mềm của kiến trúc tính toán trung tâm·theo vùng. Một khi OTA·truyền thông hướng dịch vụ·triển khai chung (CAPI) trở nên phổ biến, vòng đời phần cứng và vòng đời phần mềm sẽ tách rời, và "chiếc xe tiếp tục tốt lên ngay cả sau khi xuất xưởng" sẽ trở thành tiêu chuẩn.
Công nghệ liên kết — tích hợp an toàn·an ninh·mạng: AUTOSAR không tự hoàn chỉnh một mình. Chỉ khi nó được kết hợp hữu cơ với an toàn chức năng của [[iso-26262]]·[[sotif-iso-21448]], an ninh mạng của ISO/SAE 21434, mạng tất định của [[tsn]], và nền an ninh của [[secure-boot]]·[[memory-safety]] thì một SDV an toàn mới thành hình. Kỹ sư chuyên nghiệp nên nhìn AUTOSAR không phải một công nghệ riêng lẻ mà là trục trung tâm của một kiến trúc tích hợp đan dệt các tiêu chuẩn này lại với nhau.
Tổ chức·quản trị — cộng tác chuỗi cung ứng và hệ quản lý mô hình: Giá trị thực sự của AUTOSAR đến từ sự quản trị cộng tác trong đó OEM-Tier-1-Tier-2 trao đổi trách nhiệm thiết kế qua ARXML. Trừ phi có quản lý thay đổi giao diện, quản lý cấu hình mô hình, và quản lý tương thích phiên bản·bản phát hành công cụ, lợi ích của chuẩn hóa sẽ bị triệt tiêu bởi sự hỗn loạn tích hợp. Do đó kỹ sư chuyên nghiệp phải có quan điểm thiết kế·vận hành, vượt khỏi việc hiểu đặc tả kỹ thuật, cả quản trị quy trình·quản lý cấu hình·hợp đồng nhằm duy trì sự cộng tác đa bên.

Tài liệu tham khảo

AUTOSAR, "AUTOSAR Official Website": https://www.autosar.org/
AUTOSAR, "About AUTOSAR — History": https://www.autosar.org/about/history
AUTOSAR, "Release R25-11 is Now Available": https://www.autosar.org/news-events/detail/release-r25-11-is-now-available
AUTOSAR, "Classic Platform": https://www.autosar.org/standards/classic-platform
AUTOSAR, "Adaptive Platform": https://www.autosar.org/standards/adaptive-platform

Tóm tắt một câu: AUTOSAR là một tiêu chuẩn SW ô tô mở tách rời SW xe khỏi phần cứng để cho phép tái sử dụng·cộng tác·khả chuyển, để Classic Platform tĩnh·thời gian thực và Adaptive Platform động·hướng dịch vụ cùng tồn tại được ràng buộc bởi phương pháp luận Foundation·ARXML, và đang mở rộng thành nền phần mềm của các kiến trúc tập trung giữa xu hướng tích hợp SDV·OTA·an ninh-an toàn.