Giới thiệu
AUTOSAR có vẻ khá xa lạ đối với người làm về công nghệ thông tin, nhưng đối với những bạn làm về Embedded System, đặc biệt là trong lĩnh vực Automotive, thì cũng... xa lạ nốt.
Dạo một vòng trên Google, mình thấy tài liệu về AUTOSAR bằng tiếng Anh rất chi là hàn lâm, còn tiếng Việt thì hầu như không có. Theo dòng sự kiện MayFest2023, mình muốn chia sẻ chút kiến thức ít ỏi học lỏm được khi vẫn còn ăn bám ở công ty.
AUTOSAR (AUTomotive Open System ARchitecture) là một kiến trúc phần mềm được tiêu chuẩn hóa dùng để thiết kế ECU trong ngành công nghiệp Automotive. Nhưng, tiêu chuẩn là tiêu chuẩn gì, tiêu chuẩn hóa như thế nào và tiêu chuẩn đó nằm ở đâu trên một chiếc ô tô ?
Lấy ví dụ đơn giản - Trường đại học. Đến kỳ thi cuối kỳ, sinh viên có rất nhiều môn phải lo.
Cái mình muốn nói ở đây, đó là giữa học sinh và nhà trường luôn luôn có sự "thống nhất".
Trở lại, đối với lĩnh vực Automotive, sự phức tạp của software trên ô tô ngày càng cao là một trong những lý do chính cho sự ra đời AUTOSAR. Do đó, thứ mà chúng ta cần chính là sự "thống nhất" trong thiết kế giữa bên mua, bên bán, giữa phần cứng, phần mềm và ti tỉ thứ khác nữa. Cụ thể hơn, mình có một flow giao dịch đơn giản trông như thế này:
Hmm, vậy người mua xe nằm ở đâu trong flow này ? Họ chính là những End-users, tức "người dùng cuối" trong flow trên. Vậy OEM (Original Equipment Manufacturers) ở đây là ai ? Chính là các hãng xe: Volkswagen, BWM, Peugeot, v.v.. có đủ. Những ông lớn này tất nhiên sẽ không làm ra một chiếc xe hẳn hoi mà chỉ tập trung vào sản xuất thứ mà họ giỏi nhất, sau đó mua những component lặt vặt khác, chẳng hạn như hệ thống sensor từ một bên chỉ chuyên sản xuất sensor, trong trường hợp này là ECU. Các hãng xe phần lớn sẽ không tự thiết kế ECU mà phải nhờ đến một bên thứ ba, tức Supplier như Bosch, Hitachi, Continental,...
Mọi người thấy đấy, OEM đâu chỉ mua mỗi ECU mà còn mua linh ta linh tinh. OEM thì mua rất nhiều thịt từ những Suppliers khác nhau, Supplier thì bán rất nhiều cá cho những OEMs khác nhau.Đã thế, xe thì đâu chỉ có mỗi xe xăng, còn có xe điện, xe hybrid,... Nhưng dù cho có là xe gắn phản lực, xe bay, xe tàng hình đi chăng nữa, AUTOSAR vẫn cân tất, bởi lẽ như mình đã nói, nó được sinh ra cũng bởi sự bộn bề của software mà 😵💫.
Dưới đây là thứ tự các tầng từ cao xuống thấp:
- Application Layer
- Runtime Environment
- Basic Software
- Services Layer
- ECU Abstraction Layer
- Microcontroller Abstraction Layer
- Complex Drivers
- Microcontroller
ah shiet 🤓 Big brain time !!!
1. Application Layer (ASW)
Là tầng cao nhất trong kiến trúc AUTOSAR, cũng là thằng "gần" nhất với người dùng. Gần ở đây nghĩa là những thứ ta có thể tương tác trực tiếp, chẳng hạn như đèn báo trên tablo, hệ thống phanh, khí thải, điều hòa, đồng hồ đo nhiên liệu, vòng tua, hay cả màn hình cảm ứng ở những xe đời mới.
Nhưng đó chỉ là bề nổi của ASW, trái tim thật sự của tầng này được gọi là các SWCs (Software Components). Từng chức năng riêng biệt trên xe sẽ được đảm nhận bởi một Component riêng.
| ⚠️Tẹo nữa mình sẽ nói về anh bạn Runtime Environment (RTE) sau. RTE đóng vai trò như cầu nối giúp hai khứa ASW và BSW tâm sự với nhau. Mà muốn biết tâm sự kiểu gì trước hết phải biết BSW hoạt động ra sao đã. |
|---|
2. Basic Software (BSW)
Là tầng thấp nhất của software, và cũng là tầng khó nhai nhất 🤕.
BSW được chia ra thành những sub-layers, mỗi sub-layer cung cấp từng service nhất định cho các SWCs ở tầng ASW.
2.1. Service Layer
Là thằng gần nhất với ASW, thật ra RTE gần hơn nhưng mình không coi RTE là hẳn một tầng 🤫. Service Layer chịu trách nhiệm chính trong việc giúp BSW cung cấp các service lên trên ASW sử dụng API (API thì tầng nào cũng có nhé).
Ví dụ:
| Loại API | Chức năng |
|---|---|
| Communication | Giao tiếp trong network của các ECU, gửi message qua CAN, LIN, FlexRay,... |
| Diagnostic | Chuẩn đoán lỗi, dùng để đọc DTC (Diagnostic Trouble Codes). |
| Time Management | Kiểm soát các cyclic task, trên ô tô có vô số giá trị phải đọc trong lúc xe chạy như tốc độ, nhiệt độ,... |
| Memory Management | Tương tự Time Management nhưng là kiểm soát bộ nhớ dùng cho các cyclic task. |
Và còn rất nhiều loại khác như API cho Event Management, File System hoặc Security.
2.2 ECU Abstraction Layer (EAL)
Sub-layer này và cả sub-layer bên dưới của BSW sẽ hơi lằng nhằng bởi chúng đều mang tính "trừu tượng".
Trừu tượng ở đây cũng giống như tính chất trừu tượng bên OOP, đều mang mục đích giấu đi độ phức tạp của các implementation, giúp dev viết code một cách chuẩn hóa hơn và đỡ trầm cảm hơn.
Cụ thể, khi dev viết code ở sub-layer này, họ không phải căng mắt tìm cho ra địa chỉ của thanh ghi ADCs, ngắt, timer,... mà chỉ việc lụm API, truy cập vào tài nguyên của hardware thông qua ngoại vi, rồi config theo requirement. Mình từng thắc mắc, làm sao API có thể compatible với các hardware khác nhau ứng với mỗi con ECU khác nhau trên từng dòng xe khác nhau ? Welp, như đã nói, mọi thứ đều đã được chuẩn hóa, hardware được chuẩn hóa, và API cũng vậy.
Abstraction cũng là một key principle của AUTOSAR. Như mình đã đề cập từ đầu, có rất nhiều OEMs và Suppliers trong cuộc chơi này, nghĩa là có cả trăm loại software và hardware sắp sửa đánh nhau. Nhưng nhờ vào Abstraction, software từ một Supplier có thể dễ dàng được "tái sử dụng" khi switch sang hardware platform của một OEM khác và ngược lại.
Nói tóm lại, ngoài abstract giữa phần mềm với phần mềm như mọi người thường thấy, còn có cả abstract giữa phần mềm và phần cứng 🥴.
3.2 Microcontroller Abstraction Layer (MCAL)
Đây là thằng cuối cùng còn sót lại trong mớ software, nằm ngay trên hardware.
Thằng này thì cũng không có gì phức tạp, cơ bản là ở gần hardware nên nguyên lý khá giống với compiler. Khác ở chỗ, compiler gen ra .bin, .hex hay .obj gì đó một lần để flash xuống rồi thôi, còn MCAL cho phép high-level với low-level code nói chuyện với nhau trong real-time.
Tưởng tượng như này, ECU Abstraction Layer (EAL) chính là "bộ não", trong khi Microcontroller Abstraction Layer (MCAL) đóng vai trò như một "hệ thần kinh". EAL gửi đi các high-level command, còn MCAL biến các command đó thành low-level, rồi mới đi vào ECU. EAL ngồi trên đầu trên cổ thằng MCAL, giống như một bộ não, gửi tín hiệu qua hệ thần kinh để các cơ bắp hay nội tạng hoạt động theo ý muốn. Trong trường hợp này, EAL nếu muốn sử dụng tài nguyên của hardware thì phải nhờ vả MCAL.
3.4 Complex Device Drivers (CDDs)
Đang cập nhật
4. Runtime Environment (RTE)
Đây giồi đôi giầy, cùng quay lại với người anh em thiện lành RTE.
RTE thật ra là một term chung chứ không chỉ của riêng ngành nhúng, và là một environment có liên quan mật thiết đến "system".
Mình chưa có cơ hội làm nhiều với system nên cũng không dám nói nhăng nói cuội. Mentor của mình đã giải thích về nó 800 lần nhưng mình vẫn không hiểu. Btw, mình từng đọc một tài liệu nói về RTE như sau:
RTE là lớp phần mềm trung gian giúp hai tầng ASW và BSW giao tiếp với nhau. Mục đích của việc này là làm cho các thành phần phần mềm độc lập nhất có thể để "ánh xạ" tới một hệ thống điều khiển.
Yep, đúng là không hiểu thật.
Cơ mà, "ánh xạ" là gì nhỉ ? Mình chỉ nghĩ đơn giản thế này: Sở dĩ RTE tồn tại là vì AUTOSAR muốn đảm bảo ASW và BSW độc lập với nhau nhất có thể. BSW không chỉ trừu tượng hóa các sub-layers bên trong mình mà còn giữa chính bản thân nó với ASW.
Giả dụ:
- ASW sẽ được dev 100% bởi OEM để điều khiển các function trên xe.
- BSW sẽ được dev bởi Supplier để cung cấp các service cơ bản nhất cho ASW lụm về dùng.
Trên thực tế con số 100% này ở tầng ASW có thể khác, OEM có thể chỉ dev 75%, 50% hoặc quẳng hết cho Supplier làm luôn tùy thuộc vào thỏa thuận hai bên. Vì lý do bảo mật công nghệ, phần trăm càng cao nghĩa là OEM càng không muốn tiết lộ công nghệ của họ 🙄 mình cho là vậy.
Dễ thấy hai khứa ASW và BSW hợp tác rất đơn giản, chỉ việc đưa và nhận, đổi lại là sự flexibility trong kiến trúc mỗi thằng. BSW vốn chơi rất thân với hardware nên hiển nhiên sẽ được viết bằng C, Assem,.. vì lý do performance. ASW ngược lại sẽ được viết bằng Py, Java,.. bởi sự tiện dụng của các library, dễ đọc, dễ maintain và đẩy nhanh quá trình dev. Và "ánh xạ", một lần nữa, chính việc abstraction kết nối hai thằng này với nhau, dịch sang tiếng người nghĩa là "mapping".
Nhưng map là map cái gì ? Vâng, chính là SWCs. Đơn giản, quá trình mapping chỉ định SWC nào sẽ được map đến ECU nào, chẳng hạn cụm ABS, cụm cửa sổ, cụm túi khí,...
Chưa hết, anh bạn này còn đóng vai trò như một debugger.
5. Microcontroller (MCU)
Đang cập nhật
Liên quan: Cùng mình tự tạo Web cá nhân 👽️