AUTOSAR hiện nay là một chủ đề hot khi thế giới chứng kiến sự phát triển vũ bão của ngành công nghiệp ô tô. Bài viết dưới đây của tôi cố gắng “giải mã” giúp các bạn AUTOSAR là gì và tầm quan trọng của tổ chức này.
Mục lục
AUTOSAR là gì?
AUTOSAR viết tắt của AUTomotive Open System ARchitecture. Đây là một hiệp hội gồm các công ty hàng đầu trong ngành công nghiệp ô tô, với mong muốn tạo ra tiêu chuẩn mở cho kiến trúc phần mềm của các thiết bị điều khiển điện tử (ECU) trong ngành công nghiệp ô tô, đáp ứng cho sự phát triển mạnh mẽ và ngày càng phức tạp của các chức năng xe hơi.
Vì sao lại cần tiêu chuẩn như AUTOSAR?
Hệ thống điện/điện tử (E/E system) trong chiếc ô tô rất phức tạp, được điều khiển bởi các bộ điều khiển điện tử (ECU) và chúng kết nối với nhau như các cơ quan trong cơ thể.
ECU viết tắt của Electronic Control Unit, là một thiết bị trong ô tô đảm nhiệm việc thu thập thông tin và điều khiển các chức năng nào đó. Một chiếc ô tô có thể có từ vài chục đến cả trăm ECU.
Các ECU điều khiển các chức năng, từ trọng yếu như điều khiển động cơ, phanh hay trợ lực vô lăng; cho đến phục vụ sự thoải mái như HAVC, cửa tự động hay chỉnh ghế điện.
Với sự phát triển của công nghệ chip tích hợp, một ECU giờ đây đã trở nên mạnh mẽ hơn và có thể thực hiện hàng nghìn chức năng thay vì cần nhiều ECU như trước kia.
Theo thời gian, các tính năng mới liên tục được bổ sung để tạo lợi thế cạnh tranh, vì thế số lượng cũng như số chức năng của ECU cũng tăng lên và phức tạp hơn.
Trò đời là cái gì càng phức tạp thì càng dễ mắc lỗi và càng khó phát hiện lỗi. Lỗi với một chiếc ô tô đôi khi trả giá bằng tính mạng con người, kèm theo đó là mất uy tín và rất nhiều tiền.
Xét cho cùng, thứ người dùng cuối cần ở một chiếc ô tô để “đi đến nơi về đến chốn“. Những tính năng hào nhoáng chẳng có nghĩa lý gì nếu có dấu hiệu mất an toàn nào đó.
Dù có là một nhà sản xuất ô tô (Carmaker) hàng đầu, bạn cũng không thể tự làm hết mọi thứ.
- Các Carmaker đặt hàng ECU từ các OEM.
- Các OEM thiết kế và yêu cầu các Tier 1 phát triển ECU.
- Tier 1 thuê Tier 2, rồi Tier 2 thuê Tier 3 v.v… để hoàn thiện.
Nếu như không có chuẩn chung, trường hợp OEM muốn thay đổi Tier 1 – hoặc ngược lại – Tier 1 hợp tác với một OEM mới thì Tier 1 (và các vendor) sẽ phải tiêu tốn chi phí nghiên cứu hệ thống hiện có và có khi phải làm mọi thứ từ đầu.
Chính các OEM với nhau cũng muốn xây dựng tiêu chuẩn cho những thứ thuộc về chuẩn mực của ô tô (mà không phải yếu tố cạnh tranh) để cùng nhau tăng tốc, đưa ngành công nghiệp ô tô lên một tầm cao mới.
Và thế là AUTOSAR ra đời, với cha đẻ là những OEM và Tier 1 hàng đầu.
Mục tiêu của AUTOSAR
Mục tiêu của các tiêu chuẩn do AUTOSAR đề xuất thể hiện mong muốn:
- Kiểm soát sự phát triển ngày càng phức tạp của hệ thống E/E.
- Rút ngắn thời gian phát triển phần mềm.
- Tối thiểu hóa lỗi phát sinh trong quá trình phát triển.
- Dễ dàng sửa đổi, nâng cấp và cập nhật.
- Có thể tùy biến trên cùng sản phẩm hoặc trên nhiều dòng sản phẩm.
- Đảm bảo được chất lượng và sự ổn định.
Rút ngắn thời gian phát triển
Để rút ngắn thời gian phát triển, phần mềm phải có khả năng tái sử dụng (reusability).
Kiến trúc nền tảng ECU cần hạn chế sự phụ thuộc thiết bị (hardware independent) để giảm thiểu chỉnh sửa nếu port phần mềm sang ECU khác.
Thiết kế module hóa và chuẩn hóa giao diện giữa các module. Nhờ vậy việc phát triển các module nhanh hơn do có thiết kế trước (API spec), và debug cũng dễ dàng hơn.
Nền tảng phải cung cấp các giao diện (API) thống nhất, giúp mã nguồn ứng dụng trở nên ‘portable’, từ đó cắt giảm thời gian tái thiết kế và testing.
Giao thức liên lạc cũng được chuẩn hóa (đặc biệt là giữa các ECU của các OEM khác nhau với nhau) để đảm bảo tính tương thích (compatibility) trong quá trình tích hợp (integration).
Dễ dàng cập nhật và tùy biến
Do xử lý phần cứng được thực thi ở module cấp thấp hơn và không mấy khi thay đổi, các ứng dụng chức năng của ECU chủ yếu tập trung về thuật toán logic. Vì vậy việc chỉnh sửa và tùy biến cũng dễ dàng hơn.
Tối thiểu hóa lỗi phát sinh trong quá trình phát triển
Mã nguồn phần mềm cần tuân thủ AUTOSAR coding guildline (cho ngôn ngữ C và C++).
Yêu cầu này vô cùng chặt chẽ và giới hạn nhằm hạn chế những lỗi vặt xảy ra trong quá trình phát triển và có thể kiểm chứng tự động bằng các phần mềm Static Analysis như Astrée, Coverity v.v…
Kiến trúc nền tảng phần mềm AUTOSAR
Có hai loại kiến trúc AUTOSAR đó là Classic Platform và Adaptive Platform.
Classic Platform (CP)
Classic Platform thường dùng cho ECU chuyên dụng xử lý tín hiệu. Những chức năng này đòi hỏi phải hồi thời gian thực và thường không cần thay đổi hay cập nhật trong suốt vòng đời của xe.
Kiến trúc của AUTOSAR Classic Platform khá tương đồng với các Hệ điều hành (operating system) phổ biến, hoặc mô hình OSI trong hạ tầng mạng, đó là kiến trúc “phân lớp” (layered architecture).
Các layer trong kiến trúc Classic Platform như sau:
| Application Layer | Gồm một hoặc nhiều module phần mềm gọi là Software Component (SW-C). Mỗi module thực hiện một chức năng nào đó của ECU. Một SW-C hợp lệ khi nó chỉ dùng các giao diện do RTE cung cấp. SW-C hoàn toàn độc lập thiết bị, chỉ tập trung vào logic. Một luồng logic xử lý trong SW-C được gọi là một Runnable (kiểu như một hàm chức năng, task, hoặc handler v.v…). Một SW-C có thể có một đến nhiều Runnable. |
| Runtime Environment (RTE) | RTE tạo nên môi trường thực thi cho các SW-C. RTE cung cấp Virtual Function Bus (VFB) – một giao diện ‘ảo’ giúp các SW-C giao tiếp với nhau; với các service trong BSW và với các SW-C trên những ECU khác mà không cần biết giao diện vật lý giữa chúng. RTE scheduling hoặc trigger thực thi các Runnable của SW-C theo những sự kiện (event) định sẵn trong configuration nhờ sự trợ giúp của Hệ điều hành (nếu có) trong Service Layer. RTE không có khả năng reusable do phụ thuộc vào kết nối liên lạc giữa các SW-C. Mã của RTE thường được tự động sinh (auto-generate) theo configuration. |
| Service Layer | Service Layer giúp các SW-C sử dụng tài nguyên hệ thống một cách có “kỷ luật”. Service Layer có thể có một Hệ điều hành (operating system) – thường là RTOS, hoặc một implementation của OSAL (Operating System Abstraction Layer) làm nhiệm vụ scheduling các SW-C và trigger Runnable xử lý sự kiện từ interrupt. Service Layer cung cấp các dịch vụ nền (background service) quản lý hệ thống như bộ nhớ (memory); kết nối mạng (network); Bus liên lạc giữa các ECU (off-board); quản lý lỗi (fault management); mã hóa bảo mật (crypto) v.v… Service Layer hầu như độc lập thiết bị (hardware independent), ngoại trừ Hệ điều hành (OS) do sử dụng trực tiếp system timer và xử lý hardware interrupt từ MCU. |
| ECU Abstraction Layer | ECU AL mô hình hóa các thiết bị dưới ý nghĩa chức năng thay vì kết nối vật lý, xóa nhòa mối bận tâm về việc thiết bị đó là on-chip hay gắn ngoài. Layer này có thể gọi là Hardware abstraction layer. Layer này không phụ thuộc MCU nhưng phụ thuộc vào thiết kế của ECU board – các thiết bị gắn ngoài MCU. Layer này chứa các Driver điều khiển các thiết bị trên ECU thông qua các giao tiếp tín hiệu như DIO, SPI v.v… (các giao tiếp này đã được mô hình hóa trong MCAL). |
| Complex Drivers | Gồm các chức năng mới chưa được định nghĩa trong AUTOSAR, code cũ không thể refactor, hoặc có bảo vệ bản quyền (proprietary). Phụ thuộc phần cứng (MCU và ECU board). |
| Microcontroller Abstraction Layer (MCAL) | Cung cấp các API không phụ thuộc vào MCU. MCAL gồm các driver điều khiển đọc/ghi các thiết bị tích hợp trong MCU (on-chip) như EEPROM, Watchdog hay ADC v.v… Các driver giao tiếp tín hiệu cơ bản như SPI, DIO v.v… dùng để điều khiển các thiết bị ngoài MCU trên ECU. Implementation của MCAL phụ thuộc MCU, tức là cần thay đổi khi port sang những MCU khác. |
| Microcontroller (MCU) | Bộ vi điều khiển, trái tim và khối óc của ECU. Phần mềm của ECU được lưu trữ và hoạt động trên bộ nhớ Flash của MCU. |
Các SWC giao tiếp với nhau thông qua một cơ chế là Virtual Function Bus (VFB) với các API được định nghĩa tại RTE.
VFB giúp các SW-C trên cùng ECU trao đổi thông tin với nhau và với các SW-C trên những ECU khác thông qua khái niệm cổng kết nối (port). Cổng kết nối này được định nghĩa trong configuration – mang ý nghĩa kết nối logic, hoàn toàn độc lập thiết bị. Các SW-C không quan tâm kết nối vật lý (kiểu như CAN, LIN hoặc FlexRay v.v…) giữa chúng là gì.
VFB là sự kết hợp của RTE, Operating System (OS), Communication Stack (COM) và một số module khác trong BSW.
Adaptive Platform (AP)
Ngày nay chiếc ô tô đã vượt ra khỏi giới hạn là phương tiện di chuyển mà được nâng tầm trở thành một trung tâm thông tin giải trí (infotainment), thậm chí không khác gì robot với tính năng trợ lái (ADAS), tự lái (autonomous driving) và trí tuệ nhân tạo (artificial intelligent).
Để thực hiện những xử lý phức tạp này, ECU cần tận dụng lợi thế của kiến trúc tính toán hiệu năng cao (high-performance computing – HPC), có thể kết nối các dịch vụ trực tuyến và liên tục được cập nhật (over-the-air – OTA).
Những điều này không thể đáp ứng được với kiến trúc Classic Platform do hiệu năng hạn chế của MCU cũng như muốn cập nhật thì phải phải reflash MCU tại chỗ bằng thiết bị chuyên dụng.
Adaptive Platform (AP) đã được đề xuất vào năm 2017 nhằm đáp ứng 4 yếu tố gọi tắt là C.A.S.E:
- Connectivity (Kết nối)
- Autonomous / automated driving (Tự lái)
- Mobility Sharing services (Dịch vụ chia sẻ di động)
- Electric Vehicle (Xe điện)
Ý nghĩa của từ “adaptive” (thích ứng) cho thấy các tính năng của chiếc ô tô không nhất thiết mãi như thiết kế ban đầu mà có thể được thay đổi bất kỳ lúc nào – chỉ với một bản cập nhật OTA.
Cảm hứng cho sự ra đời của AP đến từ hai công nghệ: Ethernet và Multi-core processor.
Ethernet có băng thông lớn hơn nhiều so với giao thức CAN truyền thống, cùng khả năng kết nối đa dịch vụ trên nền Internet Protocol (IP) nên đây là kết nối vật lý chủ đạo trong kiến trúc AP.
Đáp ứng với băng thông của Ethernet và những thuật toán phức tạp chính là bộ xử lý đa lõi (multi-core processor). Khả năng xử lý song song (parallel processing) không chỉ đem lại hiệu năng vượt trội mà còn giúp tích hợp nhiều chức năng hơn lên một ECU (nhờ vậy giảm số lượng ECU xuống).
Về phần mềm, AP là một kiến trúc hướng dịch vụ (service-oriented architecture – SOA). Thay vì chia theo layer như Classic Platform thì AP chia các chức năng thành các dịch vụ (service). Các ứng dụng gọi là Adaptive Application (AA).
Adaptive Application và Service đều là các POSIX process.
Các khối nằm trong Adaptive Foundation và Adaptive Services được gọi là functional cluster. Mỗi functional cluster là một service cung cấp một nhóm chức năng cho ứng dụng AA.
AA có thể yêu cầu chức năng của một service trên cùng AP ECU hoặc trên một AP ECU khác thông qua lời gọi remote procedure call (RPC) hoặc subscribe event trên nền giao thức SOME/IP (Scalable service-Oriented MiddlewarE over IP).
| Adaptive Applications (AA) | Các AA là độc lập thiết bị (hardware independent) nhờ sử dụng các API đã được chuẩn hóa để sử dụng các Service. Những API này cung cấp bởi ARA. AA có thể single hoặc multi-threaded. Mỗi AA chỉ được chạy 01 process (yêu cầu của POSIX PSE51) và không được dùng IPC truyền thống. AA có thể hoạt động như một service để các AA khác sử dụng. |
| AUTOSAR Runtime for Adaptive Application (ARA) | Cung cấp các API đã được chuẩn hóa (API specs) để sử dụng các functional clusters trong Adaptive Service hoặc Adaptive Foundation. |
| Adaptive AUTOSAR Services | Các service quản lý giao tiếp giữa các AA. |
| Adaptive AUTOSAR Foundation | Gồm một Hệ điều hành giao diện chuẩn POSIX (PSE51 profile) tạo ra môi trường thực thi (scheduling và cấp phát bộ nhớ) cho các AA và Service; Cùng các Service mô hình hóa phần cứng (hardware abstraction). AA sử dụng các thiết bị thông qua các Service này. |
| Hardware / (Virtual) Machine | Adaptive Platform được cài đặt trên máy ảo với công nghệ ECU virtualization hoặc máy thật, tùy theo thiết kế và hiệu năng của AP ECU. |
Kiến trúc của AUTOSAR Adaptive Platform phù hợp để đáp ứng những tính năng tương lai như:
- Xe tự lái (autonomous driving)
- Xe kết nối (connected vehicles) – Kết nối các xe hơi với nhau (vehicle-to-vehicle – V2V), xe hơi với mọi thứ (vehicle-to-everything – V2X).
- Ô tô điện (vehicle electrification)
Sự khác biệt giữa Classic Platform và Adaptive Platform
| Classic Platform (CP) | Adaptive Platform (AP) | |
| Thiết kế | Hướng tín hiệu (signal oriented) | Hướng dịch vụ (service oriented) |
| Bộ xử lý | Microcontroller (MCU) Năng lực tính toán thấp | Các kiến trúc HPC (ví dụ xử lý song song với multi-core processor). Năng lực tính toán cao. |
| Hệ điều hành | OSEK/VDX OS based | POSIX-based (Minimal Realtime System Profile in IEEE Std 1003.13-2003: PSE51) |
| Ngôn ngữ lập trình | C (chuẩn MISRA C) | C++ (chuẩn MISRA C++) |
| Yêu cầu thời gian thực | Cao (hard real-time) | Trung bình – Cao (soft real-time) |
| Scheduling | Thiết lập trong configuration. | Thay đổi lúc runtime, tùy theo yêu cầu và trạng thái của các AA và service. |
| Liên kết | Nguyên khối (monolithic), không thể thay đổi sau biên dịch compile | Liên kết động (dynamic linked). AA có thể liên kết với Service bất kỳ thông qua remote procedure call hoặc event subscription trong runtime. |
| Thread | Single threaded | Single hoặc multi-threaded |
| Kết nối giữa các ECU | Chủ yếu là các chuẩn giao tiếp tín hiệu như CAN/CAN FD, LIN, FlexRay giữa các ECU. Có thể hỗ trợ SOME/IP khi cần giao tiếp với AP ECU. | Chuẩn giao tiếp SOME/IP (hoặc tương tự) qua Ethernet. Trong vài trường hợp có thể hỗ trợ các chuẩn giao tiếp tín hiệu để liên lạc với CP ECU. |
| Yêu cầu độ an toàn | Đến mức ASIL D | ASIL B – D, tùy yêu cầu |
| Sử dụng trong | Hệ thống điều khiển truyền thống, yêu cầu nghiêm ngặt thời gian thực. | Thường dùng trong thiết bị Domain / Gateway controller. Hệ thống cần kiểm soát trạng thái và điều khiển rất nhiều thiết bị I/O, thuật toán xử lý phức tạp, có thể kết nối với bên ngoài. |
| Cập nhật phần mềm | Hiếm khi cập nhật trong suốt vòng đời ô tô. Cần reflash MCU để nâng cấp bằng thiết bị chuyên dụng. | Cập nhật thường xuyên qua OTA. |
Adaptive Platform có thể thay thế Classic Platform?
Nếu xét về những yếu tố cần cân nhắc khi chuyển một ứng dụng từ CP ECU sang AP ECU thì về kỹ thuật là yêu cầu thời gian thực (hard real-time); ngoài ra là vấn đề chi phí phát triển và thời gian ra thị trường.
Do vậy tại thời điểm hiện tại, chúng vẫn đang tồn tại song hành và phối hợp với nhau.
Tham khảo:
- https://www.autosar.org/