Autosar là gì ?
Điều kiện học Autosar ban đầu
Người đọc phần này và sử dụng AUTOSAR cần phải hiểu biết về Hệ thống nhúng, lập trình C, kiến trúc phân lớp cũng như các giao thức truyền thông như CAN, I2C, v.v. Bởi vì AUTOSAR là một bước tiến cao hơn của Hệ thống nhúng, nên việc nắm rõ những thuật ngữ trên là điều thiết yếu.
AUTOSAR là viết tắt của Kiến trúc Hệ thống Mở Ô tô (AUTomotive Open System AR chitecture), được tổ chức thành một kiến trúc nhiều lớp với các thông số kỹ thuật tiêu chuẩn mà một liên minh gồm những công ty như BMW Group, BOSCH, Continental, Daimler, Ford, General Motors, PSA Group, Toyota và VOLKSWAGEN đã thiết lập. Đây là các thành viên chính tạo nên quan hệ đối tác AUTOSAR, đóng vai trò quan trọng trong việc thành lập AUTOSAR. Có nhiều loại tư cách thành viên mà một thực thể có thể tham gia vào quá trình phát triển AUTOSAR, bao gồm Thành viên cốt lõi, Thành viên cao cấp và Thành viên phát triển. Tôi đã đề cập đến các thành viên cốt lõi ở trên, nhưng cũng có nhiều thành viên cao cấp tham gia vào việc phát triển công cụ, cung cấp dịch vụ, v.v. Mục tiêu của AUTOSAR là chuẩn hóa quy trình phát triển phần mềm cho ECU dùng trong các ứng dụng ô tô.
AUTOSAR đã thiết lập một kiến trúc phân lớp tương tự như mô hình OSI. Nó bao gồm nhiều lớp khác nhau nhằm xử lý và trừu tượng hóa các hoạt động của mã nguồn. AUTOSAR được áp dụng cho các bộ điều khiển vi mô, chủ yếu phục vụ cho các ứng dụng trong lĩnh vực ô tô sử dụng các giao thức như CAN, Flex Ray, Ethernet, v.v. Được thiết kế cho các ứng dụng dựa trên vi điều khiển, nó được phát triển với mục tiêu tiết kiệm bộ nhớ do những hạn chế về tài nguyên của vi điều khiển.
Hình minh họa là một cấu trúc AUTOSAR phân lớp được đơn giản hóa. Thuật ngữ “đơn giản hóa” được sử dụng vì trong mỗi khối vẫn có các lớp phức tạp hơn. Dưới đây là mô tả ngắn gọn về các lớp:
Application Layer
Lớp này chứa mã ứng dụng ở vị trí cao nhất. Nó có thể bao gồm nhiều khối ứng dụng khác nhau, gọi là Software Components (SWC), cho từng chức năng mà ECU cần hỗ trợ dựa trên ứng dụng cụ thể. Ví dụ, các chức năng như cửa sổ điện và đo nhiệt độ sẽ sở hữu các SWC riêng lẻ. Điều này không phải là tiêu chuẩn cố định, mà phụ thuộc vào thiết kế của nhà phát triển.
AUTOSAR RTE
Xem thêm tại : AUTOSAR RTE Runtime Environment – Môi trường Thực thi AUTOSAR
Đây là một trong những lớp cơ bản và quan trọng của AUTOSAR, cung cấp khả năng giao tiếp giữa các SWC và cả các ECU khác nhau. Lớp Application Layer sử dụng lớp này để giao tiếp với các lớp bên dưới thông qua các cổng. Để tìm hiểu thêm về RTE, bạn có thể tham khảo liên kết này.
Services Layer
Lớp này đề xuất nhiều dịch vụ khác nhau cho ứng dụng sử dụng. Một số dịch vụ điển hình bao gồm: System Services, Memory Services, Crypto Services, Off board communication services, và Communication services.
ECU Abstraction Layer
Lớp này cung cấp các tóm tắt liên quan đến ECU. Nó bao gồm các lớp trừu tượng khác nhau như lớp I/O Hardware Abstraction layer, On board device abstraction, Memory hardware Abstraction, Crypto hardware abstraction, v.v., nhằm mục đích làm cho phần cứng của ứng dụng trở nên độc lập.
Lý do phải có Autosar
Dưới đây là một số khó khăn thường gặp khi phát triển phần mềm cho ECU:
– Ngành hệ thống nhúng rất phong phú với nhiều nhà sản xuất chất bán dẫn, phần cứng và phần mềm khác nhau có thể lựa chọn tùy thuộc vào nhu cầu của ứng dụng. Sự đa dạng này khiến cho việc phát triển trở nên phức tạp và khả năng di động của mã trở nên khó khăn, từ đó gia tăng chi phí phát triển.
– Ô tô là một cấu trúc phức tạp với nhiều hệ thống nhúng nhỏ gọi là Bộ điều khiển điện tử (ECU), vì vậy việc bảo trì và phát triển mã cho các bộ điều khiển này không hề đơn giản. Độ phức tạp còn tăng lên nếu các ECU sử dụng các MCU khác nhau để đáp ứng yêu cầu về chi phí, dẫn đến việc mỗi ECU sẽ có phần mềm riêng biệt do sự khác nhau trong nền tảng phần cứng.
– Để tạo ra sự đồng nhất, đôi khi cần phát triển và tuân theo những tiêu chuẩn được tùy chỉnh (tiêu chuẩn tùy chỉnh có nghĩa là phát triển một giao thức liên lạc mà tất cả các ECU trong mạng đồng tình sử dụng) để giao tiếp với các ECU khác. Cách viết phần mềm truyền thống tồn tại những khó khăn trong việc bảo trì và khả năng chuyển giao hoặc tái sử dụng mã rất hạn chế.
– Một chiếc xe hơi có nhiều bộ phận được sản xuất bởi các công ty khác nhau được gọi là nhà cung cấp cấp 1, cung cấp linh kiện cho các OEM như BMW, Volkswagen, và những hãng tương tự. Hiện nay, nhiều bộ phận cơ khí đã thông minh hơn nhờ tích hợp ECU để cải thiện khả năng kiểm soát và hiệu suất. Bởi vậy, các ECU này cũng cần một chuẩn giao tiếp chung để kết nối với ECU của OEM, dẫn đến việc cần triển khai và duy trì một tiêu chuẩn tùy chỉnh.
Vì vậy, cần có một hệ thống hạ tầng phần mềm đồng nhất để giải quyết những vấn đề này, và AUTOSAR đã thực hiện rất tốt trong việc này.
AUTOSAR áp dụng kiến trúc nhiều lớp với các tầng chuyên biệt khác nhau để thực hiện các chức năng và trừu tượng hóa. Code ứng dụng hoàn toàn có khả năng di động bởi vì AUTOSAR được thiết kế sao cho code ứng dụng có thể hoạt động độc lập với phần cứng, cho phép cùng một đoạn mã chạy trên các nền tảng phần cứng khác nhau. Trong AUTOSAR, có một tầng chuyên biệt hỗ trợ cho các chức năng phần cứng, gọi là MCAL (Trừu tượng hóa bộ điều khiển vi mô), cung cấp trình điều khiển để truy cập vào các thiết bị ngoại vi cơ bản của MCU. Nhờ vào tính năng giao tiếp chuẩn mà AUTOSAR cung cấp, các ECU có thể trao đổi thông tin với nhau mà không cần quan tâm đến nhà phát triển ECU (dù là OEM hay Cấp 1) và do đó không cần duy trì tiêu chuẩn giao tiếp tùy chỉnh. Các ECU áp dụng AUTOSAR có khả năng giao tiếp qua lại mặc dù có sự khác biệt về phần cứng cơ bản. Hầu hết các nhà sản xuất chip đều cung cấp lớp MCAL của AUTOSAR, nhưng nếu không có thì các nhà phát triển sẽ phải tự viết hoặc thuê các công ty bên ngoài để làm lớp MCAL này.
Đây không phải là một hạn chế vì AUTOSAR đã cung cấp tất cả các trình điều khiển và lớp cần thiết rồi sao?
Thực tế, đây không phải là một trở ngại vì trong bối cảnh hiện nay có nhiều yêu cầu thời gian căng thẳng để hoàn thành dự án. Tuy nhiên, khi xem xét các vấn đề đã nêu trong thiết kế phần mềm truyền thống, việc phát triển phần mềm nhanh chóng để đáp ứng nhu cầu là rất khó khăn, do đó AUTOSAR trở nên hữu ích. Dù AUTOSAR có vẻ đã bao gồm mọi thứ, nhưng chúng ta vẫn cần viết mã theo cách thủ công cho chức năng của SWC trong Runnable của SWC.
Nếu tôi sử dụng thiết bị ngoại vi bên ngoài mà AUTOSAR không hỗ trợ thì có vấn đề gì không?
Nếu bạn đang làm việc với thiết bị không được AUTOSAR hỗ trợ, bạn có thể sử dụng Complex Device Drivers SWC để tương tác với thiết bị đó. Lớp này cho phép bạn kết nối trực tiếp đến lớp MCAL từ ứng dụng và giao tiếp với ECU, nhưng bạn sẽ cần tự phát triển phần mềm cho nó và vì phụ thuộc vào phần cứng, nên nó không thể tái sử dụng hoặc được di động như SWC.
Các loại AUTOSAR
Có hai loại kiến trúc AUTOSAR: Classic và Adaptive. Kiến trúc Classic cung cấp tất cả các mô-đun thông dụng cần thiết cho một ứng dụng, trong khi kiến trúc Adaptive có thể được tùy chỉnh và điều chỉnh cho ứng dụng cụ thể bằng cách loại bỏ các mô-đun không cần thiết. Phiên bản Classic hiện tại là 4.4.0 và phiên bản Adaptive hiện tại là 19.03.
Các hình ảnh liên quan.
Quy Trình Phát Triển Autosar
AUTOSAR có thể gây khó khăn cho các nhà phát triển mới, do đó phần này sẽ giới thiệu về việc bắt đầu với dự án sử dụng AUTOSAR.
Xem Phương pháp phát triển Autosar chi tiết hơn tại :
Phương pháp phát triển Autosar
AUTOSAR đã xây dựng một kiến trúc phân lớp cùng với những thông số kỹ thuật tiêu chuẩn, và phần mềm cho ECU dựa trên AUTOSAR được phát triển theo các thông số kỹ thuật này. Phần mềm có thể được phát triển bởi các lập trình viên hoặc cũng có thể tạo mã nguồn bằng cách sử dụng các phần mềm cấu hình ECU khác nhau như Vector’s DaVinci Configurator and Developer, K-SAR, v.v. Phần mềm này chủ yếu dành cho những nhà phát triển có kinh nghiệm, cho phép bạn tạo mã nguồn thông qua việc định cấu hình các yêu cầu ứng dụng trong phần mềm giao diện đồ họa, sau đó tích hợp mã ứng dụng vào mã đã tạo ra trước đó. Bài viết này sẽ giúp bạn tìm hiểu về quy trình cấu hình ECU dựa trên AUTOSAR.
Cần lưu ý rằng bài viết này sẽ không đi vào chi tiết từng bước, mà chỉ cung cấp cái nhìn tổng quan về quy trình, điều này sẽ hữu ích cho những người mới bắt đầu.
Tất cả các ECU và toàn bộ hệ thống mạng trong xe được gọi là Hệ thống, và trước tiên Hệ thống sẽ được định cấu hình, sau đó từng ECU trong hệ thống này sẽ được cấu hình.
Hình ảnh trên minh họa quy trình tạo mã ECU từ Cấu hình hệ thống đến ECU thực hiện. Mặc dù hình vẽ chỉ ra tệp thực thi dưới dạng .exe, nhưng điều này không nên bị nhầm lẫn với tệp .exe trên PC Windows 😀. Tại đây, .exe ám chỉ đến một tệp thực thi tổng quát có thể là .elf, .bin, và các định dạng khác. AUTOSAR sử dụng một định dạng tệp riêng để trao đổi thông tin giữa các bước trong quy trình. Định dạng này tương tự như XML, nhưng trong bối cảnh của AUTOSAR, nó được gọi là tệp .arxml (Ngôn ngữ đánh dấu mở rộng AUTOSAR). Phần mềm cấu hình sẽ đọc và xử lý tệp này để tạo ra mã dựa trên thông tin có trong nó.
Một số bước trong quá trình cấu hình bao gồm
Cấu hình Hệ thống: Trong bước này, các ECU cần thiết cho xe hơi (Hệ thống) cùng với phần cứng của chúng được thiết lập, đồng thời các SWC và Composition SWC được gán đến các ECU thích hợp.
Tạo mô tả cấu hình hệ thống: Sau khi hoàn tất cấu hình ở bước một, kết quả sẽ được ghi lại trong tệp Mô tả Cấu hình Hệ thống với định dạng .arxml.
Tạo tệp trích xuất ECU: Sử dụng tệp arxml mô tả cấu hình hệ thống từ bước hai làm đầu vào, một tệp mới mang tên tệp arxml trích xuất ECU sẽ được tạo ra. Tệp này chứa thông tin chỉ về các ECU riêng lẻ, không giống như tệp mô tả Cấu hình Hệ thống, vốn lưu giữ thông tin cho tất cả các ECU trong xe.
Cấu hình ECU: Ở giai đoạn này, ECU được trích xuất sẽ được sử dụng làm đầu vào và ECU tương ứng sẽ được thiết lập theo yêu cầu của ứng dụng. Các thiết lập bao gồm cấu hình BSW, cấu hình hệ điều hành, v.v.
Tạo Mô tả Cấu hình ECU: Giai đoạn này sẽ tạo ra đầu ra cho bước 4, tức là tạo tệp arxml để mô tả cấu hình ECU, tệp này sẽ được sử dụng tiếp để tạo ra các cấu hình có thể thực thi.
Bạn nên lưu ý rằng các tệp có hậu tố “Description” là kết quả đầu ra từ bước hoặc quy trình tương ứng. Ví dụ, Mô tả Cấu hình Hệ thống arxml là kết quả của bước Cấu hình Hệ thống.
Mô tả Nội dung của Tệp Thông tin Mô tả Cấu hình Hệ thống Là Gì?
Tệp Mô tả Cấu hình Hệ thống (được tạo ra sau khi thực hiện Cấu hình Hệ thống) chứa tất cả thông tin cấu hình của hệ thống như:
Các ECU có trong hệ thống.
Các hệ thống truyền thông kết nối giữa các ECU và cấu hình của chúng.
Ma trận truyền thông chỉ ra dữ liệu sẽ gửi và nhận cho các hệ thống truyền thông đó. Vì mục tiêu của AUTOSAR là tiêu chuẩn hóa toàn bộ quá trình phát triển, mọi dữ liệu, kích thước, v.v., cần phải được định cấu hình tại thời điểm cấu hình.
Định nghĩa SWC với các cổng và giao diện cũng như cách kết nối của chúng.
Mapping của các SWCs (Các thành phần Phần mềm) tới các ECU.
=> Tệp này đóng vai trò là đầu vào cho việc cấu hình ECU. Tệp trích xuất ECU tương tự như Mô tả Cấu hình Hệ thống nhưng chỉ chứa thông tin liên quan đến ECU cụ thể.
File mô tả cấu hình ECU chứa gì?
File extract ECU chỉ định các yếu tố cấu hình, nhưng điều này không đủ để phát sinh mã có thể hoạt động trên phần cứng. Bởi vì file này thiếu thông tin cấu hình cấp thấp cần thiết để thiết lập các lớp dưới của kiến trúc AUTOSAR. Do đó, file mô tả cấu hình ECU cung cấp thông tin mà phần mềm sử dụng để cấu hình và tạo ra các tệp .c và .h sẽ được biên dịch và chạy trên phần cứng
Xem thêm :
Các vấn đề chính trong hệ thống nhúng trên xe: Nền tảng phần mềm chuẩn AUTOSAR
