Mình trước chỉ làm classic Autosar cho ECU chạy MCU, chưa thực sự làm adaptive, cũng bỏ mấy năm rồi. Hồi đó có từng ngâm cứu Adaptive Autosar chút, nó define kiến trúc cho POSIX operating system - không giới hạn chỉ Linux nhé. Mục đích chính của nó là follow trend càng ngày càng có nhiều ECU chạy linux - https://www.automotivelinux.org/ là một ví dụ, hay https://www.genivi.org/. Nên cần define Adaptive Autosar để đảm bảo một quy trình phát triển thống nhất đã với Classic Autosar - chứ không thể 1 số ECU phát triển kiểu classic Autosar, một số ECU còn lại lại theo quy trình phát triển khác. Ở view system engineer thì họ define là các SWCs.Adaptive Autosar có khác gì linux thường không bạn?
Mình đọc overview thì chỉ thấy nó là distro dành cho automotive.
Nhưng có những điểm khác thì mình không biết. Với cả tại sao phải sinh ra nó.
Mỗi SWC sẽ đại diện cho 1 chức năng, và sau đó thì tuỳ vào implementation thì các SWC sẽ được map xuống các physical ECUs, khi đó interface giữa các SWCs sẽ được convert thành internal IPC - nếu hai SWC trên cùng ECU, hoặc map xuống bus vật lý (CAN/LIN/FlexRAY/Ethernet) - nếu khác ECU.
Ở mức system engineer họ chỉ quan tâm interface giữa các SWC, nó như kiểu contract - thống nhất rồi thì mỗi ông handle ECU nào đảm bảo implement đúng cái contract đó. Với Autosar thì khi define SWC này thì tuỳ vào layout xuống ECU, thì nó generate luôn cho mình cái boilerplate code là dạng các API interface, developer giờ chỉ cần code cái flow bên trong, giảm chi phí phải tạo các code lặp lại.
Cũng như kiểu dùng protobuf, mình define service bằng protobuf, rồi tuỳ vào ngôn ngữ mình muốn implementation mình dùng protobuf gen ra phần client/service code, mình chỉ cần implement logic thôi, còn phần RPC call nó generate sẵn rồi.
Đây chỉ là 1 ví dụ simple với COM thôi. Bạn làm với Autosar mức SWC rồi thì chắc cũng rõ cái mình nói.
Expectation là khi có SWC definition rồi thì:
- Với classic Autosar thì nó gen code cho RTOS là Osek-based.
- Với adaptive Autosar thì nó gen code cho Posix OS-based.
Thằng Posix OS tài nguyên mạnh hơn rất nhiều nên có thể resource là dynamically được, còn như RTOS - OSEK chẳng hạn thì về cơ bản lương task của nó là phải fix cứng lúc config - chứ ko phải là dynamically created lúc runtime.
Lý do của Adaptive Autosar là cũng gần như vậy theo mình hiểu. Nhưng hồi đó chưa có cơ hội thực chiến với nó. Hồi đó làm với Classic Autosar là do mình may mắn lắm - mình làm full từ MCAL tới BSW/CDD tới SWC luôn - chứ hồi đó gần như ở VN có FPT làm MCAL layer thôi.
Last edited: